11.ShareSave敏捷开发流程

来源：微信公众号：吕梦楼
敏捷开发(Agile Development)作为软件开发流程，能应对快速的需求变化，是一种以人为核心、迭代、循序渐进的开发方法，其中Scrum就是实现敏捷开发的标准和流程之一。目前，ShareSave项目已经完成两轮迭代，整个ShareSave团队也已经掌握了Scrum的实践方法，结合ShareSave自已的特点，总结了一套初步实践经验，希望通过这篇文章，在此抛砖引玉，能帮更多的团队参与Scrum敏捷开发。

1 爬梳剔抉

**
“爬梳剔抉”指整理选择。出自于《宋史·律历志》：“建安布衣蔡元定著《律吕新书》，朱熹称其超然远览，奋其独见，爬梳剔抉，参互考寻。”

初始产品代办列表（Product Backlog）
产品代办列表就是整个项目被切分成许多Backlog并形成研发团队的原始工作任务池，也可以理解为需求池。为了明确ShareSave目前存在哪些问题，整个团队成员通过“头脑风暴”的方式，将自己的想法和意见通过卡片的方式展现出来，然后进行投票筛选，基本的流程如下：
（1）核心流程：Product owner（产品负责人）先将ShareSave整个的拼团流程，包括开团、分享、下载和支付等12个核心流程，用蓝色卡片贴成一条水平直线；
（2）优缺点描述：大家对对这12个核心流程，说明每个流程存在的优点和缺点，优点用绿色卡片表示、缺点用黄色卡片表示；
（3）情感曲线图：根据优缺点卡片个数及重要程度，将绿色卡片多的流程上移动，并将黄色卡片多的流程下移，形成一条上下波动的曲线；代表用户使用产品时的心情曲线，越高代表体验越好，越低代表体验越差；
（4）流程建议：针对曲线中突出的问题，大家给出自己的想法和改进意见，通过红色卡片表示；
（5）投票表决：团队成员每人5票，用绿色圆点表示，然后贴到红色的卡片上，票数最多的红色卡片就是比较好的建议。

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

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

2 躬体力行

任务列表
梳理完本次迭代的需求后，会举行迭代会议，该迭代会议主要有3个主要事情：
（1）决定本迭代要做哪些需求，也就是What To Do；
（2）将需求进行任务拆分，并将任务录入TB，每个任务需要明确责任人,也就是How To Do，以及Who To Do；
（3）对任务进行排期，确定任务是否有人力瓶颈，如果存在人力瓶颈，调整任务优先级，将不紧急的列入下一个迭代。

任务看板
迭代会结束后，大家将自己的任务写入卡片，然后贴到任务看板上，任务看板，我们有如下3条规定：
（1）看板中任务进度的更新，全部通过团队成员自己维护；
（2）通过每日站会，实时更新看板中的任务进度，并周知任务下游的同学；
（3）RD提测前，需要进行“冒烟自测”（DoD之一），然后才能提测给QA。

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

每日站会
每日站会是为整个团队最有效的沟通方式，会议不超过15分钟，需要回答以下3个问题：
（1）你昨天做了什么？
（2）今天打算做什么？
（3）有没遇到什么困难？

3 继往开来

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

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

“海星回顾”是将一个平面区域划分为5个象限，形状类似于海星，包括以下5个方面的内容：
（1）继续保持——团队做的好，并且能从中发现价值的活动；
（2）少做一些——一些已经做了的，虽然能看到一些收获，但是宁可少做一点的事；
（3）多做一些——一些已经做了的，而且已经被确信做的多就能带来更大的收益的事；
（4）停止做——那些不能带来收益，甚至更糟，正在阻碍团队前进的事；
（5）开始做——一个全新的想法，或从其他地方看到，并且能帮助团队的想法；
团队成员以轮流发言的方式，将每个人的想法通过卡片的方式贴到对应的象限，大家对上述观点进行投票（卡片上的小绿点），并选出核心的建议（卡片上的小红点），最后由Scrum master总结并讨论改进的地方，由大家一起给出问题的解决方案。

4 不以规矩，不成方圆

迭代日历
如果一轮迭代完毕之后，再开始梳理第二轮迭代的需求，那么第二轮迭代在进入开发前，估计还需要花费至少3天的时间去梳理需求、UI交互以及方案评估等。目前我们的迭代周期为2周，为了解决两个迭代的时间衔接问题，我们团队制定了一套迭代日历，主要包括以下几个方面：
（1）迭代第一周周二，开始开迭代计划会，拆分需求，确认排期；
（2）迭代第二周周二，Product owner需要提前评估下一轮迭代的需求，然后让UI出交互设计、RD评估设计方案；
（3）迭代第二周周五，Scrum master需要确定下一轮迭代需求的初步方案，便于在迭代计划会时，能准确并快速进行任务拆分，提前规避风险。

流程管理
不以规矩，不成方圆，每个团队都需要有自己的流程和规范，针对ShareSave目前流程上存在的问题，然后结合海外商城的项目流程规范，形成一套ShareSave自有的项目流程规范，主要包括产品规划、需求评审、项目排期和需求变更4个方面，具体内容详见：ShareSave项目流程规范。

5 结语

快速迭代，拥抱变化，如今我们ShaveSave团队已经正式进入敏捷迭代，如日方升！我们相信，在后面的路途中，我们在王立杰敏捷教练的带领下，能更好去拥抱敏捷，并结合自己团队和业务的特点，找到更适合我们自己的敏捷迭代方式，让ShareSave这款产品做的越来越好。