项目进度跟踪的最佳实践:每日站立会议

Posted 麦哲思科技任甲林

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了项目进度跟踪的最佳实践:每日站立会议相关的知识,希望对你有一定的参考价值。

项目进度跟踪的最佳实践:每日站立会议

1 每日站立会议的具体做法

每日站立会议是Scrum方法中的一条关键实践,看似很简单的一个活动,其实内涵丰富,站立会议通过每天面对面的沟通,可以:

  (1)快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。

  (2)给每个人一种精神压力,信守承诺。这是一种面对面的精神压力,直面项目进展。

  (3)培养团队的文化,让每个人意识到:我不是一个人在战斗,我们是一个团队。

 

 每日站立会议应该固定时间、固定地点、固定参与人员、固定话题、固定时长的召开,即:

1)在项目初期确定好本项目的站立会议的召开时间,比如可以是每天早晨的固定时间召开,也可以每天下午的固定时间召开。

2)每个项目固定一个会议的地点,可以在会议室,可以在办公位置上,也可以在其他地点。

3)项目的所有成员都要参加,需求、开发、测试等角色都要参加。其他项目组外部的人员也可以旁观,但是一般不发言。

4)在站立会议上每个人当且仅当回答3个问题:

     昨天按计划完成了什么?

     有什么难题需要别人帮助解决的?

     今天计划做什么?

    也可以项目组根据自己的特点追加问题,比如也有的项目组会要求每个人回答问题:

        今天完成的工作是否测试通过了?

        今天是否有需求或设计变更?

在汇报每个人的进展时,不需要汇报是如何做的,将要如何做。

5)站立会议应该保持在15分钟内结束。在会议上除了上述的3个问题,不做过多的讨论,需要别人帮助的问题在会后单独讨论。


图一 站立会议实景

 

2 每日站立会议成功的要点

看上去很简单的一个活动,在实践中如何做好站立会议,有很多细节需要注意:

1)  一般有Scrum Master主持会议,确保每位组员发言时不能跑题;也有的项目是大家轮流主持会议的。

2)  要制定会议的纪律,每个人不能迟到,如果迟到就惩罚之;

3)  在每个人回答上述的3个问题时,其他人不能开小会,要专心听;

4)  非本小组的成员,可以旁观,不需要发言;

5)   不能中途有人退席,有的人汇报完自己的进展后就退席是不允许的;

 6)  每个人任务的状态要在白板上展示出来;


图二 看板实景

 7)  每个人任务通过了功能测试,得到了product owner的认可,才算结束;

 8)  延期的任务,应该在看板上注明延期的天数,如果连续延期,应该采取措施;

 9)在白板上展示任务的状态,要比通过项目管理的工具展示任务的状态更有视觉冲击力;

 10)白板的面积要大,如果所有的任务不能在白板上贴下,则可以只贴本次迭代的或最近一段时间的,比如2周的。

 11)如果白板面积不够,可以不用贴纸,手写任务。

 12) 站立会议后一定要更新燃尽图!



图三 燃尽图实景

 13)一定要当面开会,不能邮件替代站立会议;

 14)一定要每天开会,每天跟踪项目的进展;

 15)不需要整理会议纪要,除非有其他必须的目的;形成的决议,可以直接书写在看板上;

 16)当有问题自己难以解决时,一定要抛出来,充分利用团队的智慧来解决这个问题,一定要记住,大家是一个团队,你的问题就是大家的问题,大家的智慧一定可以超越你。千万不要捂着问题不讲!

 17)PO或测试经理一定要参加站立会议,对于每个人完成的任务是否经过了功能测试要进行确认;

 18) 如果是一个比较大的项目组,可以分拆成几个小组,分别召开站立会议,每个小组的负责人再召开整个大项目组的站立会议;

 19)在大项目组的站立会议上,涉及到各小组之间的接口任务要重点关注,比如接口的调整、接口的联调;

 20)在站立会议上控制对技术问题的讨论,技术难点的讨论要放在会后,少数人进行专门的讨论;

 21)缺陷修复的任务可以估算出工作量,作为单独的任务识别在看板上;

 

 

3 每日站立会议的案例剖析

  【案例1】:

现象:项目的迭代周期为1个月,目前是第4周,看板中已经没有todo任务,但是每位成员在汇报工作进展时,却讲解了任务。经过询问,发现前2周是用户故事驱动的开发,后2周是bug驱动的开发,后2周的任务主要是修复bug。

  分析:因为在前期在质量方面没有投入,所以导致后期出现了很多缺陷,是一种快而脏的开发模式。为什么前期没有质量投入呢?因为担心前期做了质量投入,降低了开发速度,后期就会延误工期。这是违背了敏捷方法的基本思想的,没有保持平稳的开发速度。

  也有的项目组成员讲,无法在前期安排测试人员进来,因为测试时需要编写桩程序或驱动程序。这种理由通常是不成立的,因为如果真是如此,就要思考我们的需求开发顺序安排的是否合理。 

 

【案例2】:

现象:在2个组中观察到有scrummaster或product owner安排任务的现象,有一个组的成员对安排的任务未置可否,有另外一个组的成员对安排的任务进行了抵抗性辩解,不太乐意做写文档的工作。

  分析:反思,在敏捷实践中,哪些做法是用来维持每个人的工作积极性的?

(1) 在分配任务时,按照自愿的原则挑选任务,让每个人挑选自己喜欢做的任务;

(2) 民主决策,而非一人独裁;

 

【案例3】:

现象:在项目组的看板上,有的任务连续多天总是处在进行中的状态。发现任务的颗粒度比较大,达到10人天。

  分析:在前期进行任务分解形成sprint backlog时,没有把任务拆分到2人天以内,导致任务总是处在进行中的状态。在站立会上,大家也就无法准确了解任务的进展情况。有的开发人员会讲任务无法再细分了,通常情况下,这种理由是不成立的,是没有对任务进行认真思考的表现。

 

【案例4】:

现象:有的项目组召开晨会的时间比较长,有的项目组召开晨会的时间比较短。

  分析:每个项目组在晨会开始与结束时,也可以记录自己每次晨会的时间。对召开晨会的时间进行量化的控制,比如画出每日晨会花费时间的控制图。


图四每日站立会议时长的控制图

【案例5】:

现象:有的项目组在坚持每日站立会议一段时间后,大家认为意义不大,废止了此条实践。

分析:站立会议看着简单,实际有很多细节需要注意,之所以出现无法坚持下来的现象,应该仔细温习前面讲的成功要点,建议项目组在每日召开站立的会议的第1分钟,大家可以投影出来成功的要点,一起学习一遍,强化一下成功的要求,然后再召开站立会议。在每日站立会议的最后,也可以对本日例会的经验教训进行总结。





以上是关于项目进度跟踪的最佳实践:每日站立会议的主要内容,如果未能解决你的问题,请参考以下文章

scrum站立会议

站立会议变形记

SCRUM站立会议

浅谈scrum站立会议

第二期冲刺每日站立会议——20160609

敏捷开发 - 每日站立会议