只会用传统开发模式？10分钟教你玩转敏捷！
1年半的敏捷开发经验，告诉你如何实战敏捷。
大家好，我是楼仔！和众多网上关于敏捷的博文，我敢保证，我这篇属于精品了，如果你能找到比我写的好的，请一定私我，我也想看看
可能有同学会说，我连常规项目流程都搞不好，搞什么敏捷。。。别着急，这 2 篇文章已经给你安排了，反响很不错，强烈建议需要带项目的同学看看。
谈到敏捷开发，大家可能会说，不就是小步快跑，快速迭代，有什么大不了的，我只想说，一看就是个外行！
敏捷开发的文章，我之前也写过，不过那是为了应付领导用的，写的忒死板，现在打算重新给大家写一篇，应该是我关于项目管理方面的最后一篇，是不是要祭奠一下~~
什么是敏捷开发
我们一般习惯用瀑布模型，它以文档为驱动，将软件生命周期划分为固定的六个基本活动，并且规定了它们自上而下、相互衔接的次序，如同瀑布流水，逐级下落。
那什么是敏捷开发呢？敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，它能应对快速的需求变化，以交付客户满意的软件为最终目标，其中 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 个问题：
任务拆分中，你都没进行方案设计，是如何评估工时的呢？ 本周五项目上线了，你可能连下个迭代的需求都不知道，下周一你能正常开下一期的迭代会么？
这两个问题，你要是能回答上来，证明你项目管理还有些本事，后面的实战会告诉你答案。
项目实战
敏捷的基础其实不难，但是当结合具体实践，还是会遇到很多问题，我之前带领团队同学走敏捷，也是摸爬滚打几个月，才把这套敏捷流程跑通，下面就以之前做的海外电商 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 小时左右，本次分享的回顾方式为“海星回顾”。
温馨提示：总结回顾的方式很多种，“海星回顾”是一种玩法，你也可以百度更多玩法。
“海星回顾”是将一个平面区域划分为5个象限，形状类似于海星，包括以下5个方面的内容：
继续保持——团队做的好，并且能从中发现价值的活动； 少做一些——一些已经做了的，虽然能看到一些收获，但是宁可少做一点的事； 多做一些——一些已经做了的，而且已经被确信做的多就能带来更大的收益的事； 停止做——那些不能带来收益，甚至更糟，正在阻碍团队前进的事； 开始做——一个全新的想法，或从其他地方看到，并且能帮助团队的想法。
团队成员以轮流发言的方式，将每个人的想法通过卡片的方式贴到对应的象限，大家对上述观点进行投票（卡片上的小绿点），并选出核心的建议（卡片上的小红点），最后由项目负责人总结并讨论改进的地方，由大家一起给出问题的解决方案。
教你如何控制迭代节奏
如果一轮迭代完毕之后，再开始梳理第二轮迭代的需求，那么第二轮迭代在进入开发前，估计还需要花费至少 3 天的时间去梳理需求、UI 交互以及方案评估等。目前我们的迭代周期为 2 周，为了解决两个迭代的时间衔接问题，我们团队制定了一套迭代日历，全是大家摸索出来的：
迭代第一周周二，开始开迭代计划会，拆分需求，确认排期； 迭代第二周周二，项目负责人需要提前评估下一轮迭代的需求，然后让 UI 出交互设计、RD 评估设计方案； 迭代第二周周五，项目负责人需要确定下一轮迭代需求的初步方案，便于在迭代计划会时，能准确并快速进行任务拆分，提前规避风险； 对于回顾会，为了尽量少打扰大家，我们是每 2 个迭代回顾一次。
通过这个迭代日历，就可以回答最开始提的两个问题，我们是在第二周进行方案设计，第三周周一就可以直接开迭代会，所以能完美衔接两个迭代，且能避免没有进行方案设计，就随意给出项目排期的情况。
敏捷是万金油么
敏捷如果用好了，真的可以提高产研效率，拥抱变化、快速迭代，但是敏捷也不是万金油，需要满足天时地利人和，条件有些苛刻，下面是一些经验之谈：
老板大力支持：这个是一切的前提，比如我们之前是老板大力推广敏捷，全部门就能搞起来，后来老板方向变了，敏捷就不搞了； 项目能支持小步迭代：敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目，因为需求非常容易变更、任务好拆分；如果是传统项目，需求一开始就定好了，任务也不好拆，你就还是老实用瀑布模型吧； 团队成员闭环：敏捷的团队成员，需要全部 follow 到该项目中，因为迭代节奏很快，任何一个人不可能再去搞别的项目，否则他会成为敏捷的瓶颈； 团队成员目标一致：因为迭代节奏非常快，所以产品、研发、测试和UI必须目标一致，如果有任何一位同学心不齐，敏捷也很难搞起来。
我理解的敏捷，更像是一把利刃，用好了能威力无比！但是这把利刃并不是所有人都用得好，也不是任何场景都需要这把利刃，很多时候，我们只需要一把菜刀。
写在最后
如果要问我这 7 年的工作，哪段时光最让我怀念，我肯定会告诉你，就是我带领 ShareSave 团队做敏捷的那段时光。
我们有一个非常优秀的产品经理（俊杰），一个非常细心的测试小姐姐（卓玲），一个对技术有强烈追求的 H5 前端（小瑞），一个对项目有超强责任心的 Android 小妹（亚楠），一个超赞的 UI 设计师（康康），我们不是为了做项目而做项目，而是发自内心的想把这个产品做好。有时大家都是产品、有时大家都会帮忙一起测试，大家目标如一，所向披靡！
最后附上一张大家的合照，缅怀我们一起曾经共度的岁月吧（遗憾没有正式拍一张合照，那就用一张我们晨会的照片吧）
尽信书则不如无书，因个人能力有限，难免有疏漏和错误之处，如发现 bug 或者有更好的建议，欢迎批评指正，不吝感激。
往期精选：