每日站会是Scrum团队每天自我检查和调整的机会。关于站会的流程，一般的团队都知道，本书不再赘述。但是大部分刚开始尝试Scrum的团队，或多或少都会碰到以下一些误区。

1.站会不是每天开

经常有团队质疑：“站会为啥要每天开？太浪费时间了。我们从前一周一次周会，不就够了吗？”

如果一周一次会议，团队彼此之间的信息同步、状态对齐，以及工作的调整周期就是一周发生一次。这样的频次不可避免地会有一个又一个意料之外的事情发生，而这时才开始采取措施来调整，很难保证在一个Sprint内能够实现目标。

也有团队说：“我们每天开站会，好像也没发生什么大问题需要解决，是不是太频繁了？还是一周开两次吧！”

如果每天没有什么大问题发生，应该庆幸才对，因为在发生之前团队已经提前规避了风险。如果等发生了大问题后隔了一天才知道，这时候已经晚了一步。

2.总是有人迟到

如果团队经常有人迟到，应该分析一下大家为什么迟到。是不是因为时间不合适，是不是因为大家的座位不在一起，还是由于任务板的位置离工位太远，等等。总之，要了解背后的原因，才能解决根本问题。

如果没有什么背后的原因，只是因为大家不习惯按时到会，那就可以用团队的工作协议来解决。设定工作协议也要注意符合团队和组织的文化。有的团队喜欢采取惩罚的机制，而有的公司不喜欢这种罚款机制，更喜欢用一些正面的奖励机制来牵引。采用什么工作协议没有对错之分，只要团队达成共识，一同遵守即可。

1.只动嘴，不更新任务板

站会上轮到每个人说话的时候，大家都面朝着任务板，只动嘴说，而任务卡原封不动，或者只是更新了个别任务卡的状态。

为什么要用任务板？因为任务板具有可视化功能，可以让团队每个人对每个用户故事、每个任务的状态一目了然。一个状态不保真的任务板，意味着每个人只知道自己手里的任务和用户故事的状态，而其他人不知道；已经完成的卡片还在进行状态中，而已经启动的卡片还在准备状态中，这样团队就对整体上这个Sprint的状态没有正确的认识。

2.啥都谈，就是不谈障碍和风险

我曾经辅导过一个团队，每天站会上风平浪静，大家一一说完自己昨天做了什么，今天要做什么，移动一下卡片就结束了。可是团队每天的进展都很慢。为什么会这样呢？我仔细观察后发现，站会上没有一个人提及自己碰到了什么问题，有什么障碍和风险需要解决。于是，在团队站会结束的时候，我问大家：“真的什么事情都没有吗？请每位同事把站会的第三个问题说出来——我遇到了什么障碍。”

结果一发不可收拾。第一个同事说：“我昨天认领了这个任务，可是我发现原先的代码逻辑我有些看不懂，所以过了一天也没做完。也不知道从前这块是谁做的，为啥要那样设计……”随后，几乎每个同事都说出了自己碰到的困难和问题。为什么之前大家都不愿意说呢？因为这个团队已经养成了“一切靠自己”的习惯。更深层的原因是，当工程师求助的时候，其他人忙于做自己的任务，而没有时间和意愿帮助他。

障碍是站会的一个重要议题，ScrumMaster的职责之一就是引导团队 障碍，帮助团队解决障碍。

3.僵化站会的三个问题

Scrum站会上，标准的三个问题是：

• 我昨天做了什么？
• 我今天要做什么？
• 我遇到了什么障碍？
  
  

这并不意味着每个团队必须永远使用这个模板。每个团队要依据自己的情况，调整会议日程。比如，有个团队在试点了Scrum几个月后，发现了一个问题：他们昨天做的并没有给他们带来什么实际价值，反而他们需要及时 项目的潜在风险，而这个问题在日程里没有。于是他们将站会问题改为：

• 我今天要做什么？
• 我遇到了什么障碍？
• 我的任务有什么风险？
  
  

1.团队向ScrumMaster汇报工作

在很多Scrum团队的站会上，这一幕你应该看到过：每个同事面向ScrumMaster，回答站会日程里那三个问题。然后，ScrumMaster给出指示：你该注意什么，明天需要做什么。每个同事都这样依次汇报完毕后，站会结束。

这种情况在由项目经理、项目组长或管理层的人员转型做ScrumMaster的人身上容易出现。因为在做Scrum之前，团队就是向他/她汇报工作。因此在站会上，大家就自然地继续向他/她汇报。

当然，这也与大家对ScrumMaster的认知有关。很多团队没有接受过Scrum的培训，以为ScrumMaster与管理者没有区别，只是换了个名字，所以自然就把ScrumMaster当作领导，在站会上向他/她汇报情况。

那么如何扭转这个现状呢？其实不止是在站会上，ScrumMaster需要学会在各种活动中引导团队自组织，因为只有自组织的团队才是最高效的（参阅第10章）。

2.ScrumMaster给每个同事分配任务

这个现象产生的原因与上一条相同，不是ScrumMaster本身就是从管理者转型而来，就是团队对ScrumMaster的理解有误。ScrumMaster应该鼓励团队成员主动认领工作任务，积极发挥团队的主观能动性。

3.团队以外的人到站会上指手画脚

团队在开站会的时候，产品负责人突然跑来打断团队，给团队的任务板上放了一张紧急的用户故事卡片，然后现场讲解需求，于是，站会就演变成了新需求澄清会。

除了产品负责人以外，团队所在的部门主管有时候也到站会上来。

一些主管很好奇，想看看大家玩敏捷是个什么样子，到底有没有收益。在一次站会上，团队提出了阻碍，说缺少大容量的服务器。主管着急了，接上话说：“怎么会少呢，给你们团队分配的最多了，你们都做什么用了？”团队立马安静了，后面的同事也都不敢提障碍和问题了。而有的主管则会说：“这个待会我找下IT部门，帮大家推动一下。”这种处理方式就不会破坏团队自组织的积极性。

总之，无论是产品负责人还是部门主管，都尽量别到站会上来。团队如果真的需要他们来帮助推动，会主动找他们的。

每日站会是Scrum团队每天自我检查和调整的机会。关于站会的流程，一般的团队都知道，本书不再赘述。但是大部分刚开始尝试Scrum的团队，或多或少都会碰到以下一些误区。

1.站会不是每天开

经常有团队质疑：“站会为啥要每天开？太浪费时间了。我们从前一周一次周会，不就够了吗？”

如果一周一次会议，团队彼此之间的信息同步、状态对齐，以及工作的调整周期就是一周发生一次。这样的频次不可避免地会有一个又一个意料之外的事情发生，而这时才开始采取措施来调整，很难保证在一个Sprint内能够实现目标。

也有团队说：“我们每天开站会，好像也没发生什么大问题需要解决，是不是太频繁了？还是一周开两次吧！”

如果每天没有什么大问题发生，应该庆幸才对，因为在发生之前团队已经提前规避了风险。如果等发生了大问题后隔了一天才知道，这时候已经晚了一步。

2.总是有人迟到

如果团队经常有人迟到，应该分析一下大家为什么迟到。是不是因为时间不合适，是不是因为大家的座位不在一起，还是由于任务板的位置离工位太远，等等。总之，要了解背后的原因，才能解决根本问题。

如果没有什么背后的原因，只是因为大家不习惯按时到会，那就可以用团队的工作协议来解决。设定工作协议也要注意符合团队和组织的文化。有的团队喜欢采取惩罚的机制，而有的公司不喜欢这种罚款机制，更喜欢用一些正面的奖励机制来牵引。采用什么工作协议没有对错之分，只要团队达成共识，一同遵守即可。

1.只动嘴，不更新任务板

站会上轮到每个人说话的时候，大家都面朝着任务板，只动嘴说，而任务卡原封不动，或者只是更新了个别任务卡的状态。

为什么要用任务板？因为任务板具有可视化功能，可以让团队每个人对每个用户故事、每个任务的状态一目了然。一个状态不保真的任务板，意味着每个人只知道自己手里的任务和用户故事的状态，而其他人不知道；已经完成的卡片还在进行状态中，而已经启动的卡片还在准备状态中，这样团队就对整体上这个Sprint的状态没有正确的认识。

2.啥都谈，就是不谈障碍和风险

我曾经辅导过一个团队，每天站会上风平浪静，大家一一说完自己昨天做了什么，今天要做什么，移动一下卡片就结束了。可是团队每天的进展都很慢。为什么会这样呢？我仔细观察后发现，站会上没有一个人提及自己碰到了什么问题，有什么障碍和风险需要解决。于是，在团队站会结束的时候，我问大家：“真的什么事情都没有吗？请每位同事把站会的第三个问题说出来——我遇到了什么障碍。”

结果一发不可收拾。第一个同事说：“我昨天认领了这个任务，可是我发现原先的代码逻辑我有些看不懂，所以过了一天也没做完。也不知道从前这块是谁做的，为啥要那样设计……”随后，几乎每个同事都说出了自己碰到的困难和问题。为什么之前大家都不愿意说呢？因为这个团队已经养成了“一切靠自己”的习惯。更深层的原因是，当工程师求助的时候，其他人忙于做自己的任务，而没有时间和意愿帮助他。

障碍是站会的一个重要议题，ScrumMaster的职责之一就是引导团队 障碍，帮助团队解决障碍。

3.僵化站会的三个问题

Scrum站会上，标准的三个问题是：

• 我昨天做了什么？
• 我今天要做什么？
• 我遇到了什么障碍？
  
  

这并不意味着每个团队必须永远使用这个模板。每个团队要依据自己的情况，调整会议日程。比如，有个团队在试点了Scrum几个月后，发现了一个问题：他们昨天做的并没有给他们带来什么实际价值，反而他们需要及时 项目的潜在风险，而这个问题在日程里没有。于是他们将站会问题改为：

• 我今天要做什么？
• 我遇到了什么障碍？
• 我的任务有什么风险？
  
  

1.团队向ScrumMaster汇报工作

在很多Scrum团队的站会上，这一幕你应该看到过：每个同事面向ScrumMaster，回答站会日程里那三个问题。然后，ScrumMaster给出指示：你该注意什么，明天需要做什么。每个同事都这样依次汇报完毕后，站会结束。

这种情况在由项目经理、项目组长或管理层的人员转型做ScrumMaster的人身上容易出现。因为在做Scrum之前，团队就是向他/她汇报工作。因此在站会上，大家就自然地继续向他/她汇报。

当然，这也与大家对ScrumMaster的认知有关。很多团队没有接受过Scrum的培训，以为ScrumMaster与管理者没有区别，只是换了个名字，所以自然就把ScrumMaster当作领导，在站会上向他/她汇报情况。

那么如何扭转这个现状呢？其实不止是在站会上，ScrumMaster需要学会在各种活动中引导团队自组织，因为只有自组织的团队才是最高效的（参阅第10章）。

2.ScrumMaster给每个同事分配任务

这个现象产生的原因与上一条相同，不是ScrumMaster本身就是从管理者转型而来，就是团队对ScrumMaster的理解有误。ScrumMaster应该鼓励团队成员主动认领工作任务，积极发挥团队的主观能动性。

3.团队以外的人到站会上指手画脚

团队在开站会的时候，产品负责人突然跑来打断团队，给团队的任务板上放了一张紧急的用户故事卡片，然后现场讲解需求，于是，站会就演变成了新需求澄清会。

除了产品负责人以外，团队所在的部门主管有时候也到站会上来。

一些主管很好奇，想看看大家玩敏捷是个什么样子，到底有没有收益。在一次站会上，团队提出了阻碍，说缺少大容量的服务器。主管着急了，接上话说：“怎么会少呢，给你们团队分配的最多了，你们都做什么用了？”团队立马安静了，后面的同事也都不敢提障碍和问题了。而有的主管则会说：“这个待会我找下IT部门，帮大家推动一下。”这种处理方式就不会破坏团队自组织的积极性。

总之，无论是产品负责人还是部门主管，都尽量别到站会上来。团队如果真的需要他们来帮助推动，会主动找他们的。