![](https://i-blog.csdnimg.cn/blog_migrate/7cdd3480d14f7d6b733d465131b9f4c5.png)
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票,用绿色圆点表示,然后贴到红色的卡片上,票数最多的红色卡片就是比较好的建议。
温馨提示:这个只是收集需求的一种方式,大家可以借鉴这种玩法,很有意思,当然我们也可以跳过需求收集,让产品和业务方确定需求即可。
![](https://i-blog.csdnimg.cn/blog_migrate/c911d93a08a0c0f4ffb71954dc78a3ab.png)
产品负责人根据 ShareSave 目前的“痛点”,结合团队成员的意见,并结合运营和竞品调研,输出如下产品代办列表。需要重点强调一点,为了更好满足整个迭代的节奏,产品负责人需要整理出至少满足2个迭代的需求,来保证整个项目的正常迭代开发。
![](https://i-blog.csdnimg.cn/blog_migrate/2cd65e20887589da0998a61b35a045bd.png)
产品负责人对产品代办列表进行筛选,做减法提炼最核心的需求,在输出产品需求表的过程中,产品负责人需要和项目负责人进行沟通,确保梳理的需求能基本满足一个迭代,同时项目负责人也需要对需求进行初步的方案评估,包括业务逻辑和核心功能流程,如果发现有些需求的工作量比较大,需要对需求进行拆分和取舍。这个流程会比较长,可能会反复几次,最后就会输出最终的产品需求表。
任务拆分&日常迭代
梳理完本次迭代的需求后,会举行迭代会议,该迭代会议主要有3个主要事情:
-
决定本迭代要做哪些需求,也就是 What To Do;
-
将需求进行任务拆分,并将任务录入 TB,每个任务需要明确责任人,也就是 How To Do,以及 Who To Do;
-
对任务进行排期,确定任务是否有人力瓶颈,如果存在人力瓶颈,调整任务优先级,将不紧急的列入下一个迭代。
![](https://i-blog.csdnimg.cn/blog_migrate/0aa8b6ad0cb48cd96908402bccad2ef7.png)
迭代会结束后,大家将自己的任务写入卡片,然后贴到任务看板上,任务看板,我们有如下3条规定:
-
看板中任务进度的更新,全部通过团队成员自己维护;
-
通过每日站会,实时更新看板中的任务进度,并周知任务下游的同学;
-
RD 提测前,需要进行“冒烟自测”( DoD 之一),然后才能提测给 QA。
冲刺燃尽图是 scrum 的精华之一,通过该图表可以可视化任务的时间进度,如果实线在虚线下面,表示任务完成度超前,如果实线在虚线上面,表示任务有延期风险。
每日站会是为整个团队最有效的沟通方式,会议不超过 15 分钟,需要回答以下 3 个问题:
-
你昨天做了什么?
-
今天打算做什么?
-
有没遇到什么困难?
验收&总结
当迭代结束,且在产品正式交付前,需要全队成员进行迭代评审,即对产品功能进行演示,然后团队成员会充当用户的角色,体验本次迭代完成的所有的功能,并给出相关建议。
当迭代评审结束后,需要对本次迭代进行迭代回顾,为了避免会议过多,我们团队每两个迭代进行一次回顾,回顾时间一般 1 小时左右,本次分享的回顾方式为“海星回顾”。
温馨提示:总结回顾的方式很多种,“海星回顾”是一种玩法,你也可以百度更多玩法。
“海星回顾”是将一个平面区域划分为5个象限,形状类似于海星,包括以下5个方面的内容:
-
继续保持——团队做的好,并且能从中发现价值的活动;
-
少做一些——一些已经做了的,虽然能看到一些收获,但是宁可少做一点的事;
-
多做一些——一些已经做了的,而且已经被确信做的多就能带来更大的收益的事;
-
停止做——那些不能带来收益,甚至更糟,正在阻碍团队前进的事;
-
开始做——一个全新的想法,或从其他地方看到,并且能帮助团队的想法。
团队成员以轮流发言的方式,将每个人的想法通过卡片的方式贴到对应的象限,大家对上述观点进行投票(卡片上的小绿点),并选出核心的建议(卡片上的小红点),最后由项目负责人总结并讨论改进的地方,由大家一起给出问题的解决方案。
教你如何控制迭代节奏
如果一轮迭代完毕之后,再开始梳理第二轮迭代的需求,那么第二轮迭代在进入开发前,估计还需要花费至少 3 天的时间去梳理需求、UI 交互以及方案评估等。目前我们的迭代周期为 2 周,为了解决两个迭代的时间衔接问题,我们团队制定了一套迭代日历,全是大家摸索出来的:
-
迭代第一周周二,开始开迭代计划会,拆分需求,确认排期;
-
迭代第二周周二,项目负责人需要提前评估下一轮迭代的需求,然后让 UI 出交互设计、RD 评估设计方案;
-
迭代第二周周五,项目负责人需要确定下一轮迭代需求的初步方案,便于在迭代计划会时,能准确并快速进行任务拆分,提前规避风险;
-
对于回顾会,为了尽量少打扰大家,我们是每 2 个迭代回顾一次。
![](https://i-blog.csdnimg.cn/blog_migrate/f9987c106326208a1691421c7236625c.png)
通过这个迭代日历,就可以回答最开始提的两个问题,我们是在第二周进行方案设计,第三周周一就可以直接开迭代会,所以能完美衔接两个迭代,且能避免没有进行方案设计,就随意给出项目排期的情况。
敏捷是万金油么
敏捷如果用好了,真的可以提高产研效率,拥抱变化、快速迭代,但是敏捷也不是万金油,需要满足天时地利人和,条件有些苛刻,下面是一些经验之谈:
-
老板大力支持:这个是一切的前提,比如我们之前是老板大力推广敏捷,全部门就能搞起来,后来老板方向变了,敏捷就不搞了;
-
项目能支持小步迭代:敏捷比较适合探索类的项目、或者是 APP 之类的迭代快的项目,因为需求非常容易变更、任务好拆分;如果是传统项目,需求一开始就定好了,任务也不好拆,你就还是老实用瀑布模型吧;
-
团队成员闭环:敏捷的团队成员,需要全部 follow 到该项目中,因为迭代节奏很快,任何一个人不可能再去搞别的项目,否则他会成为敏捷的瓶颈;
-
团队成员目标一致:因为迭代节奏非常快,所以产品、研发、测试和UI必须目标一致,如果有任何一位同学心不齐,敏捷也很难搞起来。
我理解的敏捷,更像是一把利刃,用好了能威力无比!但是这把利刃并不是所有人都用得好,也不是任何场景都需要这把利刃,很多时候,我们只需要一把菜刀。
写在最后
如果要问我这 7 年的工作,哪段时光最让我怀念,我肯定会告诉你,就是我带领 ShareSave 团队做敏捷的那段时光。
我们有一个非常优秀的产品经理(俊杰),一个非常细心的测试小姐姐(卓玲),一个对技术有强烈追求的 H5 前端(小瑞),一个对项目有超强责任心的 Android 小妹(亚楠),一个超赞的 UI 设计师(康康),我们不是为了做项目而做项目,而是发自内心的想把这个产品做好。有时大家都是产品、有时大家都会帮忙一起测试,大家目标如一,所向披靡!
最后附上一张大家的合照,缅怀我们一起曾经共度的岁月吧(遗憾没有正式拍一张合照,那就用一张我们晨会的照片吧)
尽信书则不如无书,因个人能力有限,难免有疏漏和错误之处,如发现 bug 或者有更好的建议,欢迎批评指正,不吝感激。