Scrum 敏捷开发

传统瀑布开发模式开发周期长，一般为3-6个月，不可控因素多、风险大。

而敏捷开发模式每一个迭代开发周期都很短，一般为1-4周，它将瀑布开发过程切分为多个增量开发过程。 每一个迭代结束，都会产生最终可用的产品，如果需求有变化，可以在下一个迭代周期进行开发，基本不会出现最终交付产品是用户无法接受的，即使要浪费时间的话，最多就是一个迭代周期的时间。

Scrum 是敏捷开发方式的一种。

三个角色

Scrum 有三个角色：

Product Owner

负责确定产品待办事项的优先级和管理产品待办事项列表。

Scrum Master

负责主持会议，排除团队遇到的困难以及外界的干扰。

Scrum Team

包括整个开发和测试团队

三个产出物

Product Backlog

产品功能列表

Sprint Backlog

Sprint冲刺列表

燃尽图

燃尽图指的是当前剩余的工作量，可以很好地跟踪项目进展。

四个会议

Sprint 评审会

确定当前 Sprint 需要完成的功能需求。

评审会最终产出 1 张表和 3 个时间节点：

• Sprint 里程碑任务计划表
• 开发完成时间节点、可测试介入时间节点、上线时间节点；

评审会注意事项：

• 每次会议全员参加，每个人都要清楚本次版本的目标，各自职责范围；
• PO 不死压完不成的任务量；
• 任务估时可以讨价还价，但一旦接受则所有人都要对里程碑 no delay；
• 尽量不要压缩测试的时间；

任务估时

任务估时是评审会中最重要的一个环节，只有理解了需求内容，才能估算出准确的时间，确保里程碑的进度可控。

按照团队岗位，成员分别编写自己的任务卡。一张完整的任务卡要包含三个内容：

• 明确的交付内容；
• 责任人；
• 任务完成时间（小时或天）；

确认任务卡时，确保不丢失业务逻辑； 任务卡里的内容要清晰准确，要有量化的内容，不能用模糊不清的概念； 需要注意是否有估算时长与预期、或和以往类似功能时间严重不符的任务卡片，单人的任务时间是否过长，评估整体里程碑时长是否过长。

SM 需要全局观察每个人的任务排序和时间，观察上下游任务衔接情况，合理调整顺序，确保任务的连贯性，尽早的交付可供测试的软件。

任务卡确认完毕，明确三个时间节点，所有人达成共识，将任务按照优先级展示在看板上，输出里程碑计划表，全体成员承诺交付结果。

每日站会

每日站会时间不超过15分钟，主要围绕三个问题展开：

• 我昨天完成了什么？
• 我今天要做什么？
• 我需要哪些帮助？

回答完毕之后将已完成的任务移入 Test 泳道，将今天的任务移入 Doing 泳道。

Sprint 验收会

项目团队将已实现的项目结果进行演示，听取利益相关方的反馈，以便在下一个 Sprint 进行改进。

Sprint 回顾会

对当前 Sprint 进行回顾，哪些是做的好的，哪里需要改进的，并对这些改进的点，提出改进措施，在下一个 Sprint 中进行实现。

看板

看板（Kanban）来源于日语。完整的看板包含了5个泳道：

• Backlog 存放待开发的用户故事卡片
• To Do 存放当前冲刺阶段的待开发任务卡片
• Doing 存放当天开发中的任务卡片
• Test 存放已开发完毕，需要测试的任务卡片
• Done 存放已测试且已验收通过的任务卡片

任务卡片在各个管道中的流动就是燃尽图的动态表现。通过看板，能够很直观的发现项目瓶颈。

敏捷开发的价值

Scrum 开发完全适应现在互联网开发提出的“小步快跑”，以轻量级的 Story 作为需求进行迭代式开发，保证最重要的功能优先做。敏捷团队所有成员都能了解当前项目的进展和问题。