敏捷开发流程简介

最小可行化产品

硅谷创业家 Eric Rise 在其著作 《精益创业》 一书中提出了 “精益创业”（Lean Startup）的理念，其核心思想是，开发产品时先做出一个简单的原型——最小化可行产品，然后通过测试并收集用户的反馈，快速迭代，不断修正产品，最终适应市场的需求。

假如时光倒流，来到了2007 年，你要从零打造一个类似如今新浪微博的产品，有一系列需求摆在面前：

1. 用户注册、登录
2. 发布 140 字的文字微博
3. 发布带图片的微博
4. 发布带视频的微博
5. 发布投票

现在面临两个选择：1. 花费 6 个月的时间，将以上的需求全部完成后上线，给用户一个强大功能的社交网站体验。2. 花费 2 个月时间，完成用户注册登录和发布文字的功能，让用户最快体验到这个功能相对较弱的全新社交产品，在接下来的时间里，根据用户反馈，完善已有功能，同时开发上传图片的功能，一旦开发测试完成，就立即上线。以小步快跑的节奏不断完成需求表格中的其他需求。

精益创业的思想就是采用第二种方案进行渐进式开发，这样的开发模式有诸多好处：

1. 最小可行化产品能在最短的时间内完成开发，以最快的速度验证用户需求
2. 时间早意味着具有先发优势，方便更早地积累用户，这一点在社交产品上尤为明显，后发的同类产品往往需要背负“模仿”的帽子
3. 能第一时间听到用户的声音，最大程度避免了产品方向上的错误

敏捷开发模式（Scrum）实际上是精益创业思想的实践指南。

敏捷开发模式

敏捷开发采用循序渐进的方法进行软件开发，把一个大项目分为多个相互联系，但也可独立运行的小项目，分别去完成，在此过程中软件一直处于可使用状态，具体流程如下：

1. 梳理产品需求（Product Backlog）

在开发之前，一定会有一个需求列表，定义了产品在接下来需要具备的特性和功能，一般由产品经理来定义，在敏捷流程中，称这个人为 Product Owner（PO）。定义 Product Backlog 时，需要遵循 INVEST 原则，即：

• Independent 独立的，尽量和其他需求没有依赖
• Negotiable 可讨价还价的
• Valuable 有价值的
• Estimable 可预估的
• Small 足够小，拆分到一个迭代内能完成
• Testable 可被测试的

定义需求的同时，Product Owner 还需要定义需求的优先级，定义优先级可以借助一个公式：功能带来的的价值除以实现难度， 这个值越大则代表优先级越高。

2. 制定迭代计划

一般规定两周（ 10 个工作日）为一个迭代，在迭代开始之前，需要召开迭代计划会制定这一个迭代的计划，把 Product Backlog 按照优先级排序，由 PO 为大家讲解具体每一个需求，团队成员根据需求的复杂程度评估每个任务的工作量，当前 n 个任务的工作量之和约等于团队总工时时，那么这个迭代就把 Product Backlog 中前 n 个任务作为这次迭代的任务，在敏捷中称之为 Sprint Backlog。

团队总工时的计算方法：如果团队有 5 个工程师，一个迭代的工时为 5 * 10=50 人日，考虑到工作效率和其他的意外情况，再乘以 80% ，那么最终实际用于开发的工时为 40 人日，有些团队会以小时作为单位，同理，只需将单位换成小时。

团队需要把 Sprint Backlog 和预估的时间写在便签纸上，把它们贴在白板上，白板划分成三大块：未开始、进行中、已完成，当然，所有 Sprint Backlog 的状态开始都应放在未开始那一列。

3. 迭代执行

在迭代进行期间，由大家认领白板上的 Backlog，每天早上要开一个每日站会，时间在 10 分钟以内，由大家依次报告：

1. 我昨天做了什么
2. 今天计划要做什么
3. 遇到了哪些问题

每日站会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上，尽可能让信息公开透明。报告进度的同时移动对应的卡片到合适的位置，修改 Backlog 剩余所需要的工作量，Scrum Master 需要统计剩余所有的工时，更新到燃尽图中。当燃尽图的走到 0 ，就意味着完成了这个迭代中所有的任务。

燃尽图

4. 迭代总结

迭代的最后一天，还有两个环节要做：成果展示和团队的内部总结。

成果展示环节要求团队成员在这个迭代中自己完成的任务展示给所有人看，除了团队内部所有成员以外，还可以邀请领导等关心项目进展的人。内部总结则只在团队内部进行，总结这个迭代中做的好的地方以及不好的地方，接下来如何改进等。

以上是实施敏捷开发模式的大致流程，当然，在实际执行过程中会遇到或多或少的问题，一般需要几个迭代的熟悉和磨合。