敏捷开发

      敏捷开发（agile development）是非常流行的软件开发方法。目前市场上 90%的软件开发采用敏捷开发。本文将从敏捷开发的团队结构、敏捷开发的流程以及敏捷开发的特点及好处四个方面来解释下敏捷开发。

敏捷开发团队结构

• PO-产品负责人：对整个开发进度、开发内容、优先级排序负责
• SM-敏捷负责人：负责整个敏捷团队各项事宜，如部门协调、看板更新、人员调配等
• BA-需求分析师：对需求进行故事拆分，优先级排序，跟进开发
• UX-用户体验及 UI 设计师：负责制作原型、UI 美工
• Techleader-技术负责人：为整个敏捷开发团队，提供更多的技术解决方案
• Developer-开发人员：开发人员，包含前端、后端、测试等

敏捷开发流程

1. 确定需求文档：产品负责人确定功能需求文档，排好优先级

2. 拆分、编写用户故事：需求分析师在微软的 TFS(Team Foundation Server)上，将确定的需求文档进行用户故事的拆分及编写。排好优先级。

3. 绘制交互原型：根据确定的功能需求文档，设计交互原型

4. 设计 UI：根据确定的交互原型与需求文档，设计 UI

5. 编写测试案例：测试人员根据确定的用户故事，结合原型，编写测试案例

6. 迭代计划会：全体成员参加，产品负责人和需求分析师跟其他成员讲解需求，并商议出故事点数

7. 正式开放：开发人员正式开始进行功能开发

8. 迭代评审会：全体成员参加，由产品负责人及相关业务负责人进行迭代开发的功能验收

9. 下发： 安排上生产环境

敏捷开发特点

可视化

在敏捷开发中，所有的工作进程，以及工作目标均以可视化的方式呈现，让所有成员都能看到。

• 绘制迭代工作内容状态实体看板

      我们可以专门用一块白板用来绘制表格，将所有工作内容以写成便签，附上各负责人的名字，粘贴在表格上，所有成员可以看到该迭代工作内容与状态，从而实时了解该迭代的整体工作完成度。

• 绘制目标用户分析实体看板

      以用户画像的形式展现，让所有成员知道产品的目标用户群体，以及价值所在。

• 绘制依赖日历实体看板

      用日历的方式呈现工作目标。让所有成员看到在每个迭代中的工作依赖情况，从而看到相关的负责人。以及价值所在。

• 绘制用户故事地图实体看板

      将所有目前设计好的功能以标签的形式分组排列，让所有成员知晓整个产品的功能及层级关系。

以用户为中心

      跟以往“领导要什么我做什么”、“XXX 产品有所以我们也要有”等有所不同，敏捷开发中，所有需求的是围绕用户为中心的，推崇的是能为我们的目标用户群体解决什么问题。针对一个需求，首先需要提问“为什么”，它能不能为我们的目标用户群体解决问题。通过用户访谈及数据分析，分析出我们的目标群体。再结合我们的功能特点与竞品分析，设计出能够解决目标群体所存在问题的功能方案。

细化需求与用户故事

      与以往的需求文档不同，以往的需求文档是以大功能或以独立业务为单位，整合成一份完整的文档，编写功能需求文档。而敏捷开发的用户故事，是以用户角度为出发点，为解决用户所存在问题为目标编写，其结构主要为：

1. 用户故事（作为 XXX，我想 XXXX，从而解决 XXXXX）；
2. 简略说明（大致介绍一下该功能的操作）；
3. 测试案例；
4. 验收条件。

它不仅仅是给开发人员看的，也可以给其他非开发人员看及理解。

三种形式的高效会议

敏捷开发中的会议，是本着明确目的进行的。主要有三种形式的会议：

1. 每日站会
   大家各自汇报一下自己昨天的工作，以及今天的工作安排，让所有成员知道大家各自做了什么，以及进度情况，每次站会 15 分钟左右。

2. 迭代计划会
   在一个迭代启动的前一周，会进行一次迭代计划会议，主要由 PO（产品负责人）、BA（需求分析）、Tester（测试人员）给开发人员讲解下一个迭代的计划内容。再由开发人员针对于工作内容一起标识工作难易度，以评估在下一次的迭代开发工作中，是否能够完成，如果不能完成，则需要协商是否需要将部分工作放到下一个迭代中（敏捷开发的中，工作的难易度是由所有开发人员一起来评估的，而不是由产品管理者或开发负责人直接评估指派的，而是由大家一起做出的决定）。

3. 迭代工作评审会
   在每个迭代结束时间到了，会进行一次迭代工作评审会，由 PO（产品负责人）验收此次迭代的工作，不管这个迭代中的内容有没有完成，都需要进行，从而总结所存在的问题。

围绕目标用户，注重优先级排序

      对于细化的用户故事，以是否能够解决目标为中心。用户群的核心问题为宗旨，排优先级。优先级越高，放在越早的迭代工作中。

多个迭代工作，工作可持续交付

      每个迭代工作周期为 2 周，这个时间是固定的。工作内容需要完成的多少，也是根据 2 周的量进行安排。2 周时间到了，就需要进行工作验收与交付

测试先行

      在编写完用户故事后，测试人员就可以根据用户故事编写测试案例了。开发人员根据用户故事进行开发，在开发完每个功能后，需要根据测试案例先进行自测，自测通过后，再由测试人员进行验收。这样，可以大大提高每个团队成员的工作时间均衡率，不会跟以往一样，开发人员做完后，再由测试人员编写测试案例，继而测试，再由开发人员修改 BUG。

量化工作

1. 将所有工作进行点数量化，以评估出准确的工作量。如：功能点开发、非功能性需求开发、BUG 修改等；

2. 在完成一个迭代工作，并进行下一个迭代开发时，需将上一个迭代遗留的工作量也计入其中；

3. 完成每个迭代工作，需将点数进行统计，如计划了多少个点数，实际完成的点数。以便于下个迭代工作点数的计划安排。

敏捷开发的好处

早期交付

      敏捷开发的第一个好处，就是早期交付，从而大大降低成本。以盖房子为例，如果按照传统的”瀑布开发模式”，先挖 10 栋楼的地基、再盖骨架、然后架设屋顶，每个阶段都等到前一个阶段完成后开始，可能需要两年才能一次性交付 10 栋楼。也就是说，如果不考虑预售，该项目必须等到两年后才能回款。

敏捷开发是六个月后交付一号楼，后面每两个月交付一栋楼。因此，半年就能回款 10%，后面每个月都会有现金流，资金压力就大大减轻了。

降低风险

      敏捷开发的第二个好处是，及时了解市场需求，降低产品不适用的风险。请想一想，哪一种情况损失比较小：10 栋楼都造好以后，才发现卖不出去，还是造好第一栋楼，就发现卖不出去，从而改进或停建后面 9 栋楼？

对于软件项目来说，先有一个原型产品，了解市场的接受程度，往往是项目成功的关键。有一本书叫做《梦断代码》，副标题就是”20+个程序员，三年时间，4732 个 bug，100+万美元，最后失败的故事”，这就是没有采用敏捷开发的结果。相反的，Instagram 最初是一个地理位置打卡 App，后来发现用户不怎么在乎地理位置，更喜欢上传照片，就改做照片上传软件，结果成了独角兽。

由于敏捷开发可以不断试错，找出对业务最重要的功能，然后通过迭代，调整软件方向。相比传统方式，大大增加了产品成功的可能性。如果市场需求不确定，或者你对该领域不熟悉，那么敏捷开发几乎是唯一可行的应对方式