敏捷开发的文章，我之前也写过，不过那是为了应付领导用的，写的忒死板，现在打算重新给大家写一篇，应该是我关于项目管理方面的最后一篇，是不是要祭奠一下~~

什么是敏捷开发

我们一般习惯用瀑布模型，它以文档为驱动，将软件生命周期划分为固定的六个基本活动，并且规定了它们自上而下、相互衔接的次序，如同瀑布流水，逐级下落。

那什么是敏捷开发呢？敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，它能应对快速的需求变化，以交付客户满意的软件为最终目标，其中 Scrum 就是实现敏捷开发的标准和流程之一。

Scrum

Scrum 就是实现敏捷开发的标准和流程之一，这个必须掌握，要不然后面的实战会有点蒙圈，大家如果对 Scrum 非常清楚，这部分内容可以直接跳过。

Scrum 主要术语

• 产品建议表（Product Backlog）：整个项目被切分成许多Backlog并形成研发团队的原始工作任务池；
• 用户故事（User Story）：团队从技术的角度对Backlog的一种细化与分解并可投入开发的产物；
• 任务（Task）：比User Story粒度更小的任务；
• 每日的工作会议（Sprint Daily Standup Meeting）；
• 看板（Kanban）：一个可以写字的白板，用于展现项目进度等；
• 时间燃尽图（Burning Down Chart）：用于管理任务的进度，剩余量工作的一张图。

Scrum 的三个角色

• 产品负责人：需求方，提出需求，能对功能流程，业务流程拍板的人。
• 团队负责人：负责解决团队问题，领导项目。
• 项目执行人员：开发项目一般包括前后端开发、UI、QA等。

Scrum 的三个工件

• 产品建议表（Product Backlog）：头脑风暴，如果产品负责人对产品需求非常清楚，就可以省略这个步骤，开发一个原则“先紧后松”， 必须先把需求了解清楚，这里产品负责人可以召集技术团队对其需求进行公开征求意见，最后输出一个产品建议表。
• 产品需求表（Release Backlog）：产品负责人对产品建议表进行筛选，做减法提炼最核心的需求。在确定了需求后，这个时候由团队负责人进行输出技术方案文档，这里就和传统的瀑布流一样了，该有的文档都必须有了，必须由团队负责人和产品负责人确定好需求，包括业务逻辑，功能流程等。
• 时间燃尽图（Burning Down Chart）：时间燃尽图是 Scrum 的精华，通过该表格可以可视化任务的时间进度，每天按照任务完成度更新剩余时间，或者增加时间（例如发现一个技术难点，团队成员请假等要增加开发时间）。

Scrum 运作框架

前方高能，这个图非常重要！！！ 掌握了这个，就知道敏捷是怎么玩的，里面包含 4 个阶段（需求梳理、任务拆分、迭代开发和总结回顾）和 5 个会议（需求评审会、计划会、每日站会、演示会和回顾会）。

什么，还是看不懂这个图？我简单串一下：

• 需求梳理：我们开始和产品梳理出需求，将需求落入需求池，然后再将这次需要迭代的需求，通过需求评审会进行评审；
• 任务拆分：需求评审完毕后，我们会再开一个计划会，对任务进行拆分，即初步评估每项任务的工时，然后根据大家的时间，将任务拆分到本次迭代中；
• 迭代开发：本次迭代任务确定后，进入迭代开发，我们会通过每日站会，保证项目进度；
• 总结回顾：开发完后，会开个演示会（评审会），业务方会验收产品，项目全部结束后，会再开个回顾会（反思会），总结项目经验。

大家可能会说，这还不简单，那我抛 2 个问题：

1. 任务拆分中，你都没进行方案设计，是如何评估工时的呢？
2. 本周五项目上线了，你可能连下个迭代的需求都不知道，下周一你能正常开下一期的迭代会么？

这两个问题，你要是能回答上来，证明你项目管理还有些本事，后面的实战会告诉你答案。

项目实战

敏捷的基础其实不难，但是当结合具体实践，还是会遇到很多问题，我之前带领团队同学走敏捷，也是摸爬滚打几个月，才把这套敏捷流程跑通，下面就以之前做的海外电商 ShareSave 项目为原型，给大家讲讲我们如何实践敏捷。

需求池

为了明确 ShareSave 存在哪些问题，团队成员通过头脑风暴的方式，将自己的想法通过卡片的方式展现出来，然后进行投票筛选，流程如下：

• 核心流程：产品负责人先将 ShareSave 整个的拼团流程，包括开团、分享、下载和支付等12个核心流程，用蓝色卡片贴成一条水平直线；
• 优缺点描述：大家对对这12个核心流程，说明每个流程存在的优点和缺点，优点用绿色卡片表示、缺点用黄色卡片表示；
• 情感曲线图：根据优缺点卡片个数及重要程度，将绿色卡片多的流程上移动，并将黄色卡片多的流程下移，形成一条上下波动的曲线；代表用户使用产品时的心情曲线，越高代表体验越好，越低代表体验越差；
• 流程建议：针对曲线中突出的问题，大家给出自己的想法和改进意见，通过红色卡片表示；
• 投票表决：团队成员每人5票，用绿色圆点表示，然后贴到红色的卡片上，票数最多的红色卡片就是比较好的建议。

温馨提示：这个只是收集需求的一种方式，大家可以借鉴这种玩法，很有意思，当然我们也可以跳过需求收集，让产品和业务方确定需求即可。

产品负责人根据 ShareSave 目前的“痛点”，结合团队成员的意见，并结合运营和竞品调研，输出如下产品代办列表。需要重点强调一点，为了更好满足整个迭代的节奏，产品负责人需要整理出至少满足2个迭代的需求，来保证整个项目的正常迭代开发。

产品负责人对产品代办列表进行筛选，做减法提炼最核心的需求，在输出产品需求表的过程中，产品负责人需要和项目负责人进行沟通，确保梳理的需求能基本满足一个迭代，同时项目负责人也需要对需求进行初步的方案评估，包括业务逻辑和核心功能流程，如果发现有些需求的工作量比较大，需要对需求进行拆分和取舍。这个流程会比较长，可能会反复几次，最后就会输出最终的产品需求表。

任务拆分&日常迭代

梳理完本次迭代的需求后，会举行迭代会议，该迭代会议主要有3个主要事情：

• 决定本迭代要做哪些需求，也就是 What To Do；
• 将需求进行任务拆分，并将任务录入 TB，每个任务需要明确责任人,也就是 How To Do，以及 Who To Do；
• 对任务进行排期，确定任务是否有人力瓶颈，如果存在人力瓶颈，调整任务优先级，将不紧急的列入下一个迭代。

迭代会结束后，大家将自己的任务写入卡片，然后贴到任务看板上，任务看板，我们有如下3条规定：

• 看板中任务进度的更新，全部通过团队成员自己维护；
• 通过每日站会，实时更新看板中的任务进度，并周知任务下游的同学；
• RD 提测前，需要进行“冒烟自测”（ DoD 之一），然后才能提测给 QA。

冲刺燃尽图是 scrum 的精华之一，通过该图表可以可视化任务的时间进度，如果实线在虚线下面，表示任务完成度超前，如果实线在虚线上面，表示任务有延期风险。

每日站会是为整个团队最有效的沟通方式，会议不超过 15 分钟，需要回答以下 3 个问题：

1. 你昨天做了什么？
2. 今天打算做什么？
3. 有没遇到什么困难？

验收&总结

当迭代结束，且在产品正式交付前，需要全队成员进行迭代评审，即对产品功能进行演示，然后团队成员会充当用户的角色，体验本次迭代完成的所有的功能，并给出相关建议。

当迭代评审结束后，需要对本次迭代进行迭代回顾，为了避免会议过多，我们团队每两个迭代进行一次回顾，回顾时间一般 1 小时左右，本次分享的回顾方式为“海星回顾”。

温馨提示：总结回顾的方式很多种，“海星回顾”是一种玩法，你也可以百度更多玩法。

“海星回顾”是将一个平面区域划分为5个象限，形状类似于海星，包括以下5个方面的内容：

• 继续保持——团队做的好，并且能从中发现价值的活动；
• 少做一些——一些已经做了的，虽然能看到一些收获，但是宁可少做一点的事；
• 多做一些——一些已经做了的，而且已经被确信做的多就能带来更大的收益的事；
• 停止做——那些不能带来收益，甚至更糟，正在阻碍团队前进的事；
• 开始做——一个全新的想法，或从其他地方看到，并且能帮助团队的想法。

团队成员以轮流发言的方式，将每个人的想法通过卡片的方式贴到对应的象限，大家对上述观点进行投票（卡片上的小绿点），并选出核心的建议（卡片上的小红点），最后由项目负责人总结并讨论改进的地方，由大家一起给出问题的解决方案。

教你如何控制迭代节奏

如果一轮迭代完毕之后，再开始梳理第二轮迭代的需求，那么第二轮迭代在进入开发前，估计还需要花费至少 3 天的时间去梳理需求、UI 交互以及方案评估等。目前我们的迭代周期为 2 周，为了解决两个迭代的时间衔接问题，我们团队制定了一套迭代日历，全是大家摸索出来的：

• 迭代第一周周二，开始开迭代计划会，拆分需求，确认排期；
• 迭代第二周周二，项目负责人需要提前评估下一轮迭代的需求，然后让 UI 出交互设计、RD 评估设计方案；
• 迭代第二周周五，项目负责人需要确定下一轮迭代需求的初步方案，便于在迭代计划会时，能准确并快速进行任务拆分，提前规避风险；
• 对于回顾会，为了尽量少打扰大家，我们是每 2 个迭代回顾一次。

通过这个迭代日历，就可以回答最开始提的两个问题，我们是在第二周进行方案设计，第三周周一就可以直接开迭代会，所以能完美衔接两个迭代，且能避免没有进行方案设计，就随意给出项目排期的情况。

敏捷是万金油么

敏捷如果用好了，真的可以提高产研效率，拥抱变化、快速迭代，但是敏捷也不是万金油，需要满足天时地利人和，条件有些苛刻，下面是一些经验之谈：

• 老板大力支持：这个是一切的前提，比如我们之前是老板大力推广敏捷，全部门就能搞起来，后来老板方向变了，敏捷就不搞了；
• 项目能支持小步迭代：敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目，因为需求非常容易变更、任务好拆分；如果是传统项目，需求一开始就定好了，任务也不好拆，你就还是老实用瀑布模型吧；
• 团队成员闭环：敏捷的团队成员，需要全部 follow 到该项目中，因为迭代节奏很快，任何一个人不可能再去搞别的项目，否则他会成为敏捷的瓶颈；
• 团队成员目标一致：因为迭代节奏非常快，所以产品、研发、测试和UI必须目标一致，如果有任何一位同学心不齐，敏捷也很难搞起来。

我理解的敏捷，更像是一把利刃，用好了能威力无比！但是这把利刃并不是所有人都用得好，也不是任何场景都需要这把利刃，很多时候，我们只需要一把菜刀。

写在最后

如果要问我这 7 年的工作，哪段时光最让我怀念，我肯定会告诉你，就是我带领 ShareSave 团队做敏捷的那段时光。

我们有一个非常优秀的产品经理（俊杰），一个非常细心的测试小姐姐（卓玲），一个对技术有强烈追求的 H5 前端（小瑞），一个对项目有超强责任心的 Android 小妹（亚楠），一个超赞的 UI 设计师（康康），我们不是为了做项目而做项目，而是发自内心的想把这个产品做好。有时大家都是产品、有时大家都会帮忙一起测试，大家目标如一，所向披靡！

尽信书则不如无书，因个人能力有限，难免有疏漏和错误之处，如发现 bug 或者有更好的建议，欢迎批评指正，不吝感激。