敏捷开发模式中的四种会议

从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好团队,好的团队一定经常开会。经常开会是需要时间的,因此有利有弊,如果会议时间和节奏控制的不好,就会占用掉团队很多的精力和工作时间,那就得不偿失了。在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,只要把握住会议的关键点,就可以为团队的敏捷模式服务。

关于开会,日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间,因此会议贵精不贵多,在最短的时间内达成最有效的决议,这才是一个有成果的好会议。产品团队必然也会面临这样的问题,在敏捷团队内部,除了必要的全员培训外,尽量保持在团队内部只有敏捷的这四个会议,其余的沟通和会议都可以由PO和SM去参加,然后回来传达给团队成员即可,这样可以减少团队整体的时间消耗,保证团队的工作效率。

Scrum-workflow

Sprint Planning敏捷迭代计划会议

在每个敏捷迭代开始之初,由产品负责人讲解需求,并由开发团队进行估算工时的计划会议。 在会议上需要:排列需求优先级;分析和评估产品Backlog并确定该迭代的目标;计划会议上还需要制定迭代计划,包括: 根据产品Backlog(功能点)创建Sprint Backlog(即迭代任务);然后为Sprint backlog中的任务做估算;团队成员从产品Backlog中挑选他们承诺完成的条目。

敏捷的迭代实现始于计划会议,所以一个好的计划会议是每个迭代成功的基础,一般分两个阶段进行,两个阶段参与会议的人员会不一样;

计划会议的目标:

1、基于敏捷规划产生的Product Backlog以及优先级,通过计划会议,确定迭代的目标、团队成员、形成Sprint Backlog,明确评审会、回顾会时间;

2、分解Sprint Backlog并确定相应的完成时间,并由团队成员共同挑选这些Sprint Backlog;

阶段一参与人员:产品经理、Product Owner、Scrum Master、团队成员,有业务人员的话还可以邀请业务人员一起参加。

会议时长:1-4小时

一般参考进程安排如下:

1、Scrum Master公开迭代时间表;

2、产品经理和Product Owner讲述Product Backlog,对应的业务价值和优先级;

3、团队针对Sprint Backlog和优先级达成一致;

4、Scrum Master和团队成员共同确定Sprint Backlog;

阶段二参与人员:Scrum Master、团队成员,其他人员选择性参加

会议时长:1-4小时

一般参考进程安排如下:

1、团队成员针对Sprint Backlog共同分解任务;

2、团队成员共同进行工作量评估(每个Task不超过2天),确定开始时间和完成时间;

3、团队成员共同认领任务;

4、共同确定DoD,团队达成一致;

5、团队共同确认迭代目标和价值;

如果单个迭代内安排的Product Backlog安排的比较多的话,一般迭代计划会议需要开一个整天,虽然时间有点长,但这个会议会确认整个迭代的详细计划和安排,因此也是值得的。

Daily Stand-up Meeting每日站会

团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名,团队成员通常会在会议上讲述如下3点内容:

1)????? 昨天我做了什么

2)????? 今天我计划要做什么

3)????? 我遇到了什么问题,妨碍了我尽可能有效地工作

Scrum Master记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

Sprint Review敏捷迭代评审会议

在迭代结束前给产品负责人演示并接受评价的会议,并根据反馈结果,提出新的产品Backlog

参与人员:产品经理、Product Owner、Scrum Master、团队所有成员

会议时长:1-4小时,视演示内容而定

主要是检验迭代成果,检查是否完成迭代计划中的迭代目标,有可能的话要求用户参与测试流程,并得到用户对产品的认可,鼓励用户自己进行测试设计和进行破坏性测试,充分暴露产品的设计和功能问题。

由Scrum Master来推进会议进程,Product Owner记录用户反馈,根据结果维护产品 backlog,一般在迭代结束前做一次。

Sprint Retrospective敏捷迭代回顾会议

在每个迭代结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论:

1)????? 本次迭代有哪些做得好;

2)????? 本次迭代我们在哪些方面还能做得更好;

3)????? 我们在下次迭代准备在哪些方面改进;

团队确定问题优先级,并根据优先级确定团队能够解决的Top问题;团队讨论Top问题的措施,并选择在下一个迭代可以完成措施,分配责任人进行跟踪。

参与人员:Scrum Master,Product Owner,团队成员。

会议时长:0.5-1.5小时

主要针对当前迭代,团队成员自由讲述可以需要保持的做法,改进的点以及持续跟踪计划。

Scrum Master将团队讨论以及行动计划形成会议纪要,并发送给整个团队和有关同事。需要按照回顾会议的结论,维护一份待办事项列表,在下次回顾会议上进行跟踪。

案例分析

案例一:某Team在每日站会中,Scrum master准时组织大家开始晨会,成员一个接着一个说,昨天做了什么事情,今天计划做什么事情,遇到什么问题,成员A说昨天遇到了一个问题未能解决,Scrum master问遇到的是什么问题,成员A详细说明了该问题,这时成员B说这个问题他也遇到过,他是通过XX方式解决的,讨论后成员A明白了,然后继续晨会,由于小组成员有10个人,整个会议开下来大概花费了30分钟。

问题分析:Scrum master不应该在每日站会上询问详细的问题细节,而应该转移到会下询问,当团队成员之间进行讨论的时候,Scrum master需要及时拉回来,讨论应该转移到会下进行,晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

案例二:某Team在开回顾会议中,Scrum master详细总结了本次迭代中有哪些做不够好的,并指出了对应的事和人,接着对应的责任人开始述说哪些地方确实是做的不够好及其原因,最后给出改进措施然后结束会议。

问题分析:回顾会不是批斗会,不应该只说做的不好的,做的好的也要说,Scrum master主要是鼓舞大家的士气,应该先从做的好的方面开始说起;并且做的不好的方面都只对事,不对人,做的不好是整个Team的责任,不仅仅是某几个人的责任;最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

在敏捷的迭代执行过程中,上述四种会议会随着每个迭代一直进行,基本上形成了一个闭环,可以让团队在每个迭代的执行过程当中去学习和总结,从而正确的按照敏捷的要求去做,使团队真正的敏捷起来。



无觅相关文章插件,快速提升流量

评论已关闭!