告诉你如何从执行测试到管理测试（25）

第二十五章 敏捷开发到底是什么？

“上次你跟我说单元测试和提测质量的关系时，说到了几个比较热门的概念，我印象深刻，也比较感兴趣的一个是敏捷，一个是持续集成，今天是来特意学习求教敏捷开发到底是什么？”我趁午饭前的一个空档，看老大好像不忙，就跑到老大那问道。

老大说，“看在你这么好学的份上，我就跟你简单普及一下吧，很多深入的知识，还需要你自己去学习摸索。”

我们先通过两张图来看下传统的瀑布研发模式和敏捷模式的区别在哪：

瀑布

敏捷

第一张图就是我们已经很熟悉的瀑布研发模型，产品交付之前所有的过程都象是在一个黑盒子里进行的，用户直到产品发布才知道它是不是自己想要的，最终的产品与用户想要的可能会有较大的偏差。

第二张图就是我今天要跟你说的敏捷研发模型了，瀑布里的那个黑盒子还是黑盒子，不过已经从一个大盒子被拆分成若干个小盒子了，用户能持续地、阶段性地看到可用的产品实体，并能及时提出改进反馈，最终的产品与用户想要的偏差不会太大。

敏捷开发是一种以用户的需求进化为核心，迭代，循序渐进的开发方法，而
Scrum 是一种迭代式增量敏捷开发模型。在国内，我们听到最多的就是 Scrum，因为它经过很多项目和团队的实践，证明了其有效、简单、持续交付的能力，所以很多初创公司或小规模团队都比较青睐它。

Scrum

我们再来看一张图，简单了解一下 Scrum 中主要的角色、产物、会议和流程：

三个角色：

1. PO （Product Owner），产品负责人

充分理解组织中的相关干系人、客户和用户的需求，充当其代言人。并做好需求管理，以及和开发团队定好优先级，还必须明确需求的验收标准。

2. SM（Scrum Master），敏捷教练

负责帮助每个人理解并乐于接受 Scrum 的价值观、原则和实践。负责团队的过程管理，帮助Scrum团队和组织其他成员发展具有组织特色的、高效的Scrum方法，并且需要保护团队不受外力干扰。

3. Team，以功能开发为核心，建立的跨职能团队

依据产品需求，完成交付。

五个产物：

1. Product Backlog：产品需求清单。

2. Sprint Goal：迭代目标，也叫冲刺目标。

3. Sprint Backlog：迭代需求清单。

4. Task List：任务列表。

5. Increment Product：增量产品。

四个会议：

1. Planning Meeting：计划会议。

2. Daily Scrum Meeting：每日站会，“站”只是多种会议形式中被认为效率最高的一种。

3. Review Meeting：评审会议，也可叫验收会议。

4. Retrospective Meeting：反思会议，所有会议里我认为最重要的一个，因为敏捷思想中最核心的就是持续改进，而持续改进来源于持续的总结和反思。

流程：

1. Team 在 PO 的主持下，通过 Planning Meeting、Product Backlog 和 Sprint Goal 产出 Sprint Backlog；

2. Team 在 SM 的指导下，通过 Sprint Backlog、Task List 和 Daily Scrum Meeting，在一个迭代周期（图中是30天）产出 Increment Product；

3. PO 和 Team，通过 Review Meeting，验收每个迭代周期产出的增量产品；

4. SM、PO 和 Team，通过 Retrospective Meeting，反思每个 Sprint 里做的好的和做的不好的地方，持续总结和改进，以此来提高 Team 的战斗力和产出能力。

最后再跟你讲几个敏捷常用工具：

1. User Story，用户故事，从用户的角度来描述用户渴望得到的功能。

2. Task Board，任务墙，将 Scrum 过程中的各项事务放大并进行可视化展示的各种类型的载体。

3. Burn Down Chart，燃尽图，迭代周期内用于跟踪任务进度的可视化图形。