天呐，每日站会居然被开成这样

Scrum 是当前最流行的敏捷软件开发 实施框架。

Scrum 起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

可能有的小伙伴并不熟悉 Scrum ，我们先看下 Scrum 中文网的描述：

Scrum 是一个用于 开发和维护复杂产品的框架 ，是一个**增量的、迭代的 开发过程。在这个框架中，整个开发过程由若干个短的迭代周期 **组成，一个短的迭代周期称为一个 Sprint（迭代），每个Sprint的建议长度是2到4周（互联网产品研发可以使用1周的Sprint）。

Scrum 使用产品 Backlog（一个按照 商业价值排序 的 需求列表） 来管理产品的需求，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具有较高价值的需求。

为了挑选出 最高优先级的需求进行开发，Scrum 团队在Sprint 计划会议经过讨论、分析和估算，得到相应的任务列表，我们称它为 Sprint Backlog。在每个Sprint（迭代）结束时，Scrum 团队将递交潜在可交付的产品增量。

Scrum 流程如下图：

每日站会 是 Scrum 实践中最具代表性的一个形式，也是我们今天讨论的话题。

每日站会的目的

Scrum 的团队是一个 **自组织 **的团队。每日站会，是团队面对面沟通，和团队自组织的体现，是 Scrum 过程，进行 **每天的检查和调整 **的环节。以期达到：

1. 团队商量决定谁做什么（不能有领导人物指派），为当天做出一个计划
2. 团队沟通状态，了解现状，发现障碍
3. 团队回顾昨天的工作，做调整，持续改进

基本规则

相信所有践行过每日站会的人，都对如下规则印象深刻：

1. 会议最好在 **15分钟内 **完成（或者每个人的时间不超过一分钟）
2. 每个人回答三个问题：
   • 我昨天完成了什么任务
   • 我今天打算做什么任务
   • 我遇到了哪些障碍或困难
3. 同一时间只能有一个人发言，任何跑题的讨论，需要被 Scrum Master 阻止

健康站会的效果

据说，一个有效执行 Scrum 的团队是这样的：

早上 scrum 站会前，团队是安静的。站会结束后，团队很活跃，中午饭前慢慢沉寂下来。午饭后，团队再度开始活跃，直到下午下班前又慢慢安静下来。

我的实践是怎么演变成鸡肋的

单看以上对健康站会的描述，我会以为，我曾经经历过的 Scrum 实践是非常有效的——完全符合上文的描述。但实际情况并非如此。

第一天站会

领导没有说话，大家也都很沉默，低头看地板或者盯着白板，面无表情。

领导说：“那就从小A开始吧！”

小A：“我昨天做的事情是：1，2，3；今天计划做：4，5，6。但是我昨天下班前发现了一个 bug，这个 bug 会导致我的 4，5，6 都没有办法开始。这个 bug 所在的部分之前是由小B 负责的，小B 今天把 bug 改好了，我的工作才能开始。”

小B：“怎么可能呢？这部分之前都测过的，如果有这个 bug，测试根本不可能通过，我最近也没动这部分代码，怎么可能会有 bug 呢？ 再说我今天计划好了三件事情，时间排的满满的，根本没时间解 bug。小C 这两天在做某某功能，和这部分相关，是不是小C 做的新功能引起的？”

小C 马上很警觉：“什么bug？抱歉刚才没听仔细。”

小A 把 bug 现象又重新描述了一遍。

小C：“怎么可能会抛出这个错误呢？你用的是什么数据？哪个浏览器，什么版本？”

小A一一回答。

小C 做沉思状：“你说的这个情况有点奇怪，我的代码应该不会引起这个问题。你有没有 debug？Log 上怎么说？”

小A 刚要回答，领导抬手看了下表：“是这样啊，我们 scrum 的目标是平均每人控制在1分钟左右，现在光讨论小A 的问题已经用了6分钟。接下来每个人只说：昨天做了什么，今天计划做什么，遇到了什么问题。不过多谈论细节，好吧！”

小A 作罢，领导说：“小B，该你了！”

小B 按照领导的要求，快速做了更新，包括自己遇到的困难。但是鉴于小A 的经验，没有人对小B 的困难做任何回应。

然后是 小C，小D，小E……

所有人更新完，领导又看了下表，“很好，我们今天的时间控制在了15分钟，虽然比一人一分钟多了点儿，总体还是不错的。大家还有什么问题吗？”

小A：“那我刚才说的那个 bug 怎么办？那个问题不解决，我今天的工作没法开展。”

领导：“你找小B，小C 讨论一下吧。发挥下大家的主观能动性。”

小A喊：“小B，小C，你们能过来看一下吗？”

小B：“等会儿，手头有个急事儿处理一下。”

小C：“我去接个水噢。”

十分钟后，小B 站在了小A 的电脑后，说：“到底是什么问题，再重现下？”，小C 抱了个大水杯也站过来。

两人在小A 身后，一会儿要求打开这个文件，一会儿要点下那个按钮……，大概一个小时后，俩人都摇着头，表示这个问题很奇怪，跟自己那部分代码都没关系。最后语重心长地对小A 说：“你自己再看看吧，实在不行，找大牛帮你看看。”

小A 绝望地扭头，正要喊大牛，却看到他头带着耳机正和国外的同事开会，只好作罢……

第二天站会

仍然沉默，过了半分钟，领导说：“还是从小A 开始吧。”

小A：“我昨天看了下那个 bug，找小B，小C讨论了，可是没有头绪，现在还在debug，任务4，5，6也没办法做。”

领导：“这样下去，我们这个 Sprint 安排的工作风险很高啊。老D（大牛），你帮小A 看看吧。”

老D：“今天跟美国的架构师约了个会，昨天的问题还没讨论完，今天还得继续。这个不讨论完，我们下个 Sprint 的任务没办法安排啊。我尽量挤时间帮小A 看看吧。”

领导：“好的，辛苦你了老D。小A，你今天再花两个小时 debug 问题，还找不出原因，就先去帮小B 或者小C 的忙吧。”

小A 低下头：“好吧”。

一个星期后，Sprint 结束。

领导：“今天是 Sprint 最后一天，我刚看了下我们这个 Sprint 的进度，落后了很多。是什么原因呢？大家分别说说，自己的任务完成情况。小A，还是你先说。”

小A……

你的破法

你参与过 Scrum 实践吗？

对每日站会有什么想法？

如何破解上面的这种鸡肋实践？

欢迎在本文后留言，说出你的看法。