Scrum敏捷开发中的各种会议到底怎么开?
敏捷的迭代实现始于计划会议,所以一个好的计划会议是每个迭代成功的基础;Scrum站立会议,可以有效反馈项目存在的问题,及时跟进;Scrum验收会议,是在迭代结束前给产品负责人演示并接受评价的会议,以根据反馈结果,提出新的产品Backlog;Scrum回顾会议,在每个迭代结束后召开的关于自我持续改进的会议。
这些会议究竟怎么开,对项目研发有什么具体的帮助呢?
一、计划会议
视频地址:https://www.zentao.net/scrum/planmeeting-part2-80184.html/?f=bokeyuan
计划会议的意义是让团队共同确认和理解本次Sprint要完成的工作。参与本次Sprint的所有人员都要参加。
计划会议的第一步,是产品负责人向团队成员详细讲解每一个User Story。讲解后并对User Story进行排序和估算,团队集体参与,可以借助敏捷扑克牌来进行集体估算。最终制定出这一期Sprint要完成的Story列表,即Sprint Backlog。与会人员应认真听产品负责人的讲解,并发表自己的意见,以确保自己对每一个Story理解都是正确的。
我们在分析用户故事时,要清楚用户的根本需求,从而制定最佳解决方案,问题的最优解往往要考虑其投入产出比。
视频中讲述的空肥皂盒的故事,其实就是说,不应该对某种方案简单否定、教条照搬别人的方案,而是要根据自己的实际情况采用灵活的解决方案。
计划会议中,Sprint Backlog的制定,是整个Scrum团队基于自身情况共同商议讨论的结果,而不是产品负责人自己独裁决定的。Sprint Backlog制定出来后,下一步就是要对Story进行任务分解和领取。
在确认了Sprint Backlog之后,计划会议的第二部分是团队对每一个Story进行任务分解并自由领取。 分解的标准是将完成该Story所要做的所有任务进行分解。当然,这些任务不仅仅是开发的,也可能包括非开发性事务。如文档撰写、销售联系、付款采购等等。分解任务后,大家自愿领取喜欢的任务,并完成工时的预估,最终每个任务都有明确的负责人。
要注意:任务的领取要遵守自由、自愿的原则,而不是由项目经理硬性指派并指定工时。
计划会议中,为什么任务可以自由领取,并且不怕团队成员多估工时呢?主要有以下几个原因:
1. 开发人员自己领取,并做估算,是对团队的一种承诺。
2. 任务的规模大家有共识,加上良性竞争,所以不怕故意高估工时。
3. 每天召开站立会议也会及时同步信息,保证信息公开透明。
4. 借助禅道项目管理软件的工时、动态、燃尽图等功能,及时了解大家的工作情况。
二、站立会议
在Scrum站立会议中,可能有不同部门或岗位的人一起参加,但是要注意,只有真正参与项目的人才有发言权。
会议中可准备一个话筒或道具,只有拿着该道具的人才能发言,每个人说一下昨天做了什么,今天做什么,以及遇到的问题,但会议中并不去解决问题,可以会后探讨。 其他非参与项目的与会人员可以旁听,但不可喧宾夺主,每个人的角色、职责不同。
视频中跟大家分享了猪与鸡的故事, 在Scrum中,猪包括Scrum Master 、产品所有者、开发团队等成员,而客户,市场商务人员都是Scrum中的鸡。猪才是团队的核心,拥有较大的话语权。
但实际项目中往往是猪类角色没有发言,而鸡类角色喋喋不休,最后每个决定却让猪去承担后果,这是Scrum要尽力避免的。
三、验收会议
视频地址:https://www.zentao.net/scrum/Sprintreviewmeeting-80187.html/?f=bokeyuan
每次迭代结束后,团队需要召开迭代验收会议,展示本次迭代取得的进展。在验收会议中,Scrum团队成员可以采用demo的方式来演示完成的功能或者改进。
在上期视频中,我们介绍了站立会议中“猪”与“鸡”的角色,像研发人员等“猪”类角色是团队的核心,可以在站立会议中发言,而像市场销售等“鸡”类角色,在站立会议中是不能发言的。不过,风水轮流转,在验收会议中,终于轮到他们登场了。
![](https://pic3.zhimg.com/80/v2-5526e9bc4cad2e686dc8d2ae34bef64c_720w.jpg?source=1940ef5c)
验收会议是一个非正式会议,并不是进度汇报会议,无需整理幻灯片,只要提前准备下要演示的内容即可。
验收会议的意义并非单纯的演示,最主要的目的是通过演示获取反馈,从而促进产品优化改进。根据最后的完成情况,所有参会人员协同讨论,并记录下发现的Bug及问题。
![](https://pic2.zhimg.com/80/v2-b4406fde158d0491709fdf607ece27ad_720w.jpg?source=1940ef5c)
验收会议中,整个团队都需要参加,并会邀请所有与产品相关人员参加。会议的结果产出,也就是演示过程中,发现、商讨并记录的所有问题,会列入到Product Backlog中,以便产品负责人后期管理。
四、回顾会议
Scrum回顾会议是一个周期性的回顾,总结工作中的经验和教训。回顾会议发生在验收会议结束之后,下个迭代计划会议之前。时间一般为1-2小时。Scrum团队所有成员都要参加,Scrum Master要确保回顾会议的正常举行。
回顾会议旨在对前一个迭代周期中的人、关系、过程和工具进行检验。从而明确了团队接下来要开始做什么,停止做什么,以及继续做什么。
比如:下个迭代要修复上期迭代中已发现、记录的bug问题;
之前团队开站立会议时不同角色沟通发言的方式不对,我们要停止并进行改善;
我们之前采用的结对编程感觉效果不错,所以后面可以继续做。
Scrum团队中,除了产品的迭代改进,团队的技术实践同样需要逐步优化改进。很多Scrum团队对于回顾会议并没有足够的重视,甚至直接跳过了这一步。
如果不开回顾会议会有什么问题呢?
会导致对于项目结果及过程中的问题不清晰,长此以往,技术债务累积,最终导致项目失败。所以,回顾会议必不可少,Scrum Master应该鼓励团队在Scrum的流程框架内改进开发过程和实践,使得团队能在下个迭代中更高效。
而实际要开好回顾会议也并非易事。
召开回顾会议的最高指导原则是:“相信每个人当时都是尽了最大的努力。”这样可以给团队创造安全环境,避免开成“抱怨会”或“甩锅会”。
另外,Scrum项目中要避免“六拍”,下面给大家再讲一个猪与鸡的故事。继上次猪与鸡合作失败之后,他们又开启了第二轮创业。这回成功了吗?快去看视频吧~
Scrum回顾会议要求Scrum Master 要有足够的协调能力并活跃会议氛围,以提升团队成员的参与积极性,促使大家能够说出真实的想法,并发掘更有效的改进建议。在回顾会议的最后,Scrum团队应该确定在下个迭代中将要实现的有效改进方法,并在接下来的迭代中付诸行动。