敏捷开发（1）敏捷不是方法

要了解敏捷开发，要先了解一下瀑布模型。

所谓瀑布模型（Waterfall Model），它其实是一个项目开发架构，其开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型这种重量级软件开发过程有很多缺点，比如开发模型是线性的、不适应用户需求的变、过于理想化等，因此亟需一种解决方案。

敏捷开发的思想也就应运而生了。

首先澄清一点，敏捷不是一种方法论，也不是一种软件开发的具体方法，而是一套价值观和原则。各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策。

2001年，17个业界专家聚集在一起，提出了著名的《敏捷宣言》，全文如下：

敏捷宣言强调的敏捷软件开发的四个核心价值是：

个体和互动高于流程和工具；
工作的软件高于详尽的文档；
客户合作高于合同谈判；
响应变化高于遵循计划。

右侧的并不少错误或者不重要，而是左侧应该高于右侧，敏捷开发提倡以人为本，而不是以过程为本。

敏捷宣言还提出了12条原则，包括：

1.通过早期和连续型的高价值工作交付满足“客户”。

2.大工作分成可以迅速完成的较小组成部分。

3.识别最好的工作是从自我组织的团队中出现的，

4.为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。

5.创建可以改善可持续工作的流程。

6.维持完整工作的不变的步调。

7.欢迎改变的需求，即使是在项目后期。

8.在项目期间每天与项目团队和业务所有者开会。

9.在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。

10.通过完成的工作量计量工作进度。

11.不断地追求完善。

12.利用调整获得竞争优势。

敏捷开发（2）从Agile到Scrum

前面讲到敏捷（Agile）是一种思想，一种道。而要践行这种“道”，就需要一个切实可行的“术”，Scrum就是其中最受欢迎的一种方法。

Scrum来自橄榄球运动，是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

Scrum有3个角色：

1、Product Owner 产品负责人：

负责产品需求列表，决定发布日期，定义验收标准

2、 Scrum Master 主管：

为团队服务，倾听、引导、鼓励

3、Team Developer 团队开发

T型人才（一专多才），自我驱动

Scrum有3种产出：

1、Product Backlog 产品待办事项

2、Sprint Backlog 迭代待办事项

3、Prodct Deliverable Incrementing 可交付产品增量

Scrum的注意事项：保持迭代的周期稳定

迭代合约是一种承诺，在迭代过程中不能变更。

保持每个迭代周期长短一致，每个迭代周期就是一个心跳周期，要有严格的节奏。

迭代周期通常以周为单位，1周、2周、4周一个迭代都可以，根据团队具体情况而定。

Scrum的注意事项：每日站会只讲3个问题：

1、昨天做了什么

2、今天计划做什么

3、遇到什么问题

敏捷开发（3）以Ticket为中心的看板

一个工业化的软件开发过程包含：需求收集、迭代规划、任务分配、代码管理、质量管理、CI/CD（持续集成/持续部署）、缺陷管理等流程。

Scrum开发交付流程可以简单描述为：

1、收集反馈：从“甲方”或“用户”获得反馈，然后沉淀到需求池水。

2、规划迭代：将用户声音描述为一个个用户故事

3、Sprint会议：进行一个迭代的kickoff，包括拆解任务和确定验收标准等

4、迭代开发：进行开发和测试

5、迭代发布：进行产品的增量交付

敏捷开发的一个特点是，不拒绝文档，也不拘泥于文档，文档不是开发的中心。那么开发的中心是什么，或者开发围绕什么开展呢？为了管理大量的用户故事和任务，我们通常使用Ticket（有些人叫Issue、JIRA、Task等）来形成甘特图来管理每个用户故事的完整生命周期。

看板最开始就是墙上或者支架白板上五颜六色的便利贴纸，后来才逐渐出现了各种事务跟踪工具。看板让Sprint更加可视化，看板上的信息是流动的，而且看板可以限制每个Sprint的Ticket数量，可以让团队更加聚焦于更重要的事情。

通常一个敏捷看板至少包含：ToDo（待办事项）、InProgress（处理中的事项）、Done（已完成事项）三个部分。

在每日站会中，主要的一个任务就是对Sprint中的Ticket进行跟踪和管理，除了每个成员轮流发言介绍一下昨天干了什么事情、今天计划做什么事情、工作上有没有障碍无法推进之外，还要检查每个Ticket的状态。

站会是否站着并不重要，重要的是要高效地沟通反馈。

一般一个团队有如下4个角色：

产品经理：写需求设计文档，将需求整理成 Ticket，随时和项目成员沟通确认需求；
开发人员：每天从看板上按照优先级从高到低领取 Ticket，完成日常开发任务；
测试人员：测试已经部署到测试环境的程序，如果发现 Bug，提交 Ticket；
项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要的帮助，解决问题。

其中项目经理更接近于ScrumMaster的角色，但在实际操作中经常是资深开发人员或者架构人员担任SM的角色。这就很可能造成团队不扁平，重新形成塔形结构，所有人围绕一个主要开发人员开展工作，边缘开发人员参与度不高。这种开发团队，经常是一两个人在卖力“表演”，无论是SprintPlan还是代码评审，大多数人都是以看客心态，这也是敏捷开发在很多公司或者团队无法落地的原因之一。

通过推行轮值SM的制度，让每个成员可以尝试一下ScrumMaster的角色，从而提高大家的专注度。

说到底，敏捷是一个团队的风格，而不是一两个天才跳舞。