小米印度版拼多多团队:敏捷迭代,如日方升

2020-11-20 16:40:00
敏捷助理
原创
259
摘要:敏捷开发(Agile Development)作为软件开发流程,能应对快速的需求变化,是一种以人为核心、迭代、循序渐进的开发方法,其中Scrum就是实现敏捷开发的标准和流程之一。

敏捷开发(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也需要对需求进行初步的方案评估,包括业务逻辑和核心功能流程,如果发现有些需求的工作量比较大,需要对需求进行拆分和取舍。这个流程会比较长,可能会反复几次,最后就会输出最终的产品需求表。

 躬体力行

任务列表

梳理完本次迭代的需求后,会举行迭代会议,该迭代会议主要有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个方面。


5 结语

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

联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105