每日站会（XP 中叫 Daily Standup Meeting）大概是 Agile 1.0 中最具程式化、仪式感的一个著名实践，Scrum 因此得名。
每日站会的目的
Scrum 的团队是一个 **自组织 **的团队。每日站会，是团队面对面沟通，和团队自组织的体现，是 Scrum 过程，进行 **每天的检查和调整 **的环节。以期达到：
团队商量决定谁做什么（不能有领导人物指派），为当天做出一个计划
团队沟通状态，了解现状，发现障碍
团队回顾昨天的工作，做调整，持续改进
基本规则
相信所有践行过每日站会的人，都对如下规则印象深刻：
会议最好在 **15分钟内 **完成（或者每个人的时间不超过一分钟）
每个人回答三个问题：
我昨天完成了什么任务
我今天打算做什么任务
我遇到了哪些障碍或困难
同一时间只能有一个人发言，任何跑题的讨论，需要被 Scrum Master 阻止
健康站会的效果
但是有时候理想很丰满， 现实总是很骨感。 如果在公司中没有一个完整的敏捷环境和认知， scrum 的实践很容易被实施变形， 下面我之前遇到过的最多的两个问题
1. 站会变成像项目经理或者scrum master的进度汇报会。
形式是这样的， scrum master站在白板前， 其他人站在scrum master 对面， 然后scrum master 说：“现在我们开始今天的站会， 先从小A开始吧”
小A面向scrum master 开始讲。。。
scrum master 拿个小本本开始记。。。
其他人低头看手机或者是发呆。。
小B面向scrum master开始讲。。。
scrum master继续在小本本上记。。。
其他人低头看手机或者发呆。。。 或者先讲完的人说还有代码等着写， 就先走了。。。
。。。。。
2. 问题在站会上提出来了， 但是在接下来的跟踪和解决上没有执行到位， 下面的例子是在知乎上看的， 我觉得很形象， 就直接引用了：）
第一天站会
领导没有说话，大家也都很沉默，低头看地板或者盯着白板，面无表情。
领导说：“那就从小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，还是你先说。”
。。。。。。
当然我们也看到过很多好的站会， 个人感觉， 站会是scrum中非常好的一个实践， 它时间短， 能够快速同步团队的状态和问题， 双向传递信息， 仪式感很强， 如果用的好能够很大的提升团队的效率。
但是用的时候有几点需要注意
1- 尽量在每天的同一时间进行， 不要每天调整时间。 这样可以保持一致性， 也避免了很多沟通浪费， 便于团队成员安排自己的时间。
2-避免会上讨论细节， 但是会下一定要对提出的问题进行跟踪并且解决。