敏捷大行其道，Daily Scrum过程是团队进行每天的检查和调整的环节。以期达到：

1. 团队商量决定谁做什么（不能有领导人物指派），为当天排一个计划

2. 团队沟通状态，了解现状，发现障碍

3. 团队回顾昨天的工作，做调整，持续改进

基本规则

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

1.    会议最好在15分钟内完成（或者每个人的时间不超过一分钟）

2.    每个人回答三个问题：

·      我昨天完成了什么任务

·      我今天打算做什么任务

·      我遇到了哪些障碍或困难

3.    同一时间只能有一个人发言，任何跑题的讨论，需要被Scrum Master阻止

健康站会的效果

据说如果一个有效执行Scrum的团队是这样的：早上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……

没有成功的daily scrum经验，就分享个不太成功的案例供大家讨论。好奇的是，你所经历的daily scrum都长什么样呢？