缘起
还是在13年的时候，彼时还在某福报厂做某旅行APP。当时在搞的一个大版本，团队里来了几个奇怪的人，不写代码，一来就拉着大家开会，往黑板上画好几个格子，贴一堆纸片，每天还坐在我们项目室监视我们，动不动往我们耳朵里扔各种没听过的专业词汇，燃尽图、sprint、scrum 等等等，早上还非要拉着团队开站会，要知道互联网公司晚上都是干到十一二点，尤其在上下班通勤平均需要1.5小时的大北京，早上十点公司根本没人来，站会往往人员不齐，大家也就是敷衍了事。稀里糊涂的项目上线后，那几个人也跟着消失了。回过头来才意识到，哦，我们搞了一个敏捷项目，奇怪的人是外面请来的 ScrumMaster，早上开的会叫 Stand-up。
山回路转，如今有幸加入敏捷开发的黄埔军校，是时候系统、体系的，重新认识一下 Stand-up。
什么是 Stand-up（每日站会）
先来回顾一下，敏捷宣言的内容：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
- 尽管右项有其价值，我们更重视左项的价值
Scrum 的理论基础是，通过保持过程透明，让所有参与项目的人了解项目的真实状况，然后进行 Review，以及对发现的问题做调整。而 Stand-up则是 Scrum 中，进行每天 Review 和调整的正式场合。
注意，Stand-up是开发团队自己的会议（没有领导/上级来指派/分配任务），在会上：
- 开发团队回顾昨天的工作内容；
- 开发团队讨论并决定今天需要完成的内容，并制定计划；
- 开发团队沟通项目/个人的状态，发现问题，并持续改进；
Stand-up需要做什么
Stand-up是一个 Scrum团队每天要做的第一件事情。按照 Scrum 的定义，Stand-up会议必须在每一天的同一时间、同一地点召开。这么做可以省去定会议室、通知团队成员等一系列不必要的步骤，进一步提高团队的沟通效率，也是一种仪式感（嗯，生活需要仪式感），让Scrum深入每个团队成员的DNA。
Stand-up的纪律，也可以理解为仪式上的规则：
- 所有团队成员需要按时到场；
- 团队可以建立自己的游戏规则来约束成员，比如迟到要接受惩罚（请吃水果balabala）
- 会议时间最多不超过15分钟；
- 一定要站着开，保证每个人精神集中，提升沟通效率；
- 同一时间只能有一个人发言；
- ScrumMaster需要控场，引导发言不被带跑偏，变成茶话会
- 需要讨论的问题，记录下来，线下再讨论
- 任何团队之外的人，不得发言或干扰会议；
Stand-up的目标在上文已经说了，是为了让团队成员了解项目真实状况，以便制定当日的工作计划，或者调整当日的工作内容。根据Scrum的定义，Stand-up会上需要做的事情有：
- 团队需要在任务板上更新任务的状态；
- 以便每个团队成员都清楚，当前整个项目的进展情况
-
团队成员每个人回答三个问题：
- 我昨天完成了什么任务
- 我今天打算做什么任务
- 我遇到了哪些问题
Stand-up的注意事项
回头再看当时在福报厂的那个 Scrum 项目，每日站会并没有对每天的研发效率带来显著的提升，整个 Scrum 项目，大家也都觉得是为了敏捷而在敏捷。
立足当下，再来总结当时项目中的问题，有很多违反 Stand-up原则的地方，比如：
- 会上团队成员说出问题之后，立即讨论技术细节，其他人站着等他们讨论结束，或者干脆几个人开起小会；
- 发言时，被其他人打断或者挑战，陷入撕逼；
- 某成员昨天的任务没有完成，被TL质疑；
- TL发表鼓舞人心的演说（俗称画饼），成功打断 Stand-up进行；
- 约定早上十点站会开始，还有一半人迟到；
- 边吃早饭，边开会；
- 其他人发言时，我先去喝个水；
- 我太累了，我坐着听吧；
参考Martin Fowler的《Patterns of Daily Stand-up Meetings》，一个好的Stand-up，应该具备以下属性：
- 按照不同的团队规模，站会应该在10~15分钟之内结束，如果超时了，那么肯定在哪个地方出了问题；
- 团队成员互相交流，而不是机械的汇报进度；
- 在会上抛出问题、记录问题，在会后解决问题；
- 站会结束后，每个成员知道自己要做什么，知道哪些问题需要解决；
高效的站会是一天高效工作的开始，是一个自组织团队的心跳。如果你能够感受到这个节奏，则说明团队是很健康的，每日站会起到了很好的效果。
