项目管理：每日站立会议要怎么开？

每日站立会议是Scrum方法中的一个关键实践，看似很简单的一个活动，其实内涵丰富。站立会议通过每天面对面的沟通，可以达到以下效果：

1. 快速同步进展，让项目组内部的员工互相了解彼此的进展，从而了解本项目的整体进展。站立的姿势让每个人都会想尽快解决问题。

2. 给每个人一定精神压力，让他们信守承诺。这是一种面对面的精神压力，直面项目进展。

3. 培养团队文化及凝聚力、归属感，让每个人意识到：我不是一个人在战斗，我们是一个团队。

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

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

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

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

4. 在站立会议上每个人需要回答3个基本问题：

——昨天完成了哪些工作？
——有什么难题需要别人帮助解决？
——今天计划做什么？

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

——今天完成的工作是否通过了测试？
——今天是否有需求或设计变更？

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

5. 站立会议应该保持在15分钟内结束。在会议上除了上述的3个问题，不做过多的讨论，需要别人帮助的问题在会后单独讨论。如果要讨论技术问题，会后单独开会，少数人参与讨论。

6. 回答的形式与目的不是向领导汇报工作，而是团队成员之间相互交流，以共同了解项目情况和共同解决问题。

7. 成员在回答三个问题时目光要注视着大家，而不是 Scrum Master，否则就变成了向领导汇报工作。对每个人回答的问题有疑问，其他成员都可以提出，而不是只有Scrum Master 一个人在问。

8. 成员提出的问题或困难其他成员要认真倾听，确定相关的负责人和协作方式，但问题细节不在会议上讨论。

9. 站会结束后，ScrumMaster 一定要知道哪些问题需要帮助团队成员解决。

组织会议其实正是 Scrum Master 一项非常重要的技能；有效的开展会议，能够体现出组织者，也就是 Scrum Master 在控制会场，协调问题的解决，积极推动项目进展和管理团队方面的综合实力了。并且，当敏捷项目分布在不同国家地区、时区时，这类会议的开展更有难度。使用以下推荐的方法和技巧能够帮助成功开展每日站立会议并且将使得 scrum master变得更加专业：

1. 给Scrum Master 的几点建议：
    自信
    声音洪亮
    在会议室中适当走动
    观察团队每个人
    了解每个人的特点
    不做无准备之发言
    保持礼貌
    前后一致
    别太幽默
    避免情绪化
    感激
    平衡发言时间
    请外向型的先发言，请内向型做总结
    保持正常语速
    提醒发言者如果发言时间很长，或是经常打断其他人
    可定期改变发言顺序

 并非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分钟，大家可以投影出来成功的要点，一起学习一遍，强化一下成功的要求，然后再召开站立会议。在每日站立会议的最后，也可以对本日例会的经验教训进行总结。

参考资料：
[1] https://www.cnblogs.com/telwanggs/p/8434086.html
[2] https://blog.csdn.net/dylanren/article/details/50051561
[3] https://www.sohu.com/a/251871878_208218