>why目标：

目的在于反馈进展，协调工作；识别风险，移除障碍；加强沟通与协作。

首先，工作进度的沟通和协调，预测工作完成程度

其次，可以尽早发现问题，识别风险，在发展迅速、变化丰富的环境中，促进快速地决策，从容迅捷地响应随时可能出现的不确定，提高开发团队的认知程度。

    PS：反馈环中，结对编程（秒级）->单元测试（分级）->持续集成（小时级）->站会（天级）->sprint 回顾（周级/月级）

前三种，虽然反馈快，但是一方面实践要求较高，另一方面主要针对开发人员，Sprint的反馈周期有几周，它的意义是回答：我们定的目标正确么？所以站会是比较容易实施，也比较适合团队参与的实践，反馈周期适当，能够以天来核查我们做的正确吗？

最后，团队成员有机会频繁见面，也是一种团队建设，如果运用合理仍效，加强沟通可以提高团队成员之间的了解、信任，使团队更加团结。

站会的形式很简单，但想使之有效却是个难事，稍不小心，就会成鸡肋，区别在于参与者是团队还是群体。

PS：构成团队的四要素：

（1）具有共同的目标；

（2）成员之间相依赖；

（3）团队成员有归属感；

（4）共同承担责任。

团队和群体的区别可以参考《引导：团队群策群力的实践指南》

值得信任的团队成员需要具备:

搞定问题的能力

积极主动的态度

团队合作的意识

>who参与者：

团队成员（猪）：全身心投入，可以讲话

旁听者（鸡）：可以旁听，但不能在会上讲话

>when 时间

每个工作日的固定时间，限长15分钟

>what

主要内容：互相同步彼此的工作状态；关注工作项、价值的流动；了解团队成员状态。

主要是通过回答三个问题审视状态，对当前的Sprint做检查和必要的调整。

1. 小回顾：上次会议到本次会议期间哪些已经完成  (PS: 具有专业能力，能搞定一些事情)

2. 承诺：到下一个会议期间，计划做什么？ (PS: 积极思考，主动承担任务)

3. 检视：有什么问题阻碍了工作？预见什么样的风险 (我不是万能的，但我信任团队，把搞不定的问题暴露出来)

带来什么

成员间通过面对面的快速沟通，达到细粒度的同步,只关注当下最紧要、最具体的任务，每天都作出新的承诺。

成员间相互鼓励，相互帮助，及时地高清度地觉察已然或将要发生的阻碍，并迅速将之击破。

别人的成长带来的压力与动力。

>How

从下游向上游同步工作状态，然后，按照流程步骤，做出拉动某一工作项的决策：

1. “正在处理”的任务：如果任务完成，由“正在处理”转为“完成”（相当于成为后续相关工作流的待处理）；如果未完成，询问是否存在阻碍任务完成的问题

2. 选择“待处理”的任务，转为“正在处理”（拉动哪一个工作项是团队的决定，总的来说要遵循“stop starting, start finishing”的原则。决策时需要综合考虑工作项的服务类别、延期成本，价值、风险、依赖关系、工作量、进入看板的时间和截至日期等。）

3. 如果需要处理的任务不在Backlog中，评估并添加相关信息

4. 如果任务不能在一天内完成，看是否能把任务拆分成多个任务

5. 如果有什么问题阻碍了工作，把阻碍标注出来（在任务贴或需求贴上明示）

团队要重点关注如下工作项：

* 被阻碍的工作项

* 有延期风险的工作项

* 几天都没进展的工作项

* 有bug的工作项

做完上述工作后，团队综合检视看板系统的如下方面：

* 是否有在看板墙里没有可视化的信息吗？（查缺补漏）

* 瓶颈在哪里？（风险与问题）

* 是否有没识别的阻碍吗？

* 优先级对每个人都清楚吗？

* 如果有需要进一步展开讨论的话题，纪录下来，站会后另行组织

>常见问题

站会的形式简单，一般来说团队很容易掌握，但在实践中还是看到有各种各样的问题。

现象1：团队中的三两人讨论的热火朝天，其余看Email的、走神的、刷朋友圈的、打瞌睡的、去WC的、取快递包裹的。

现象2：站会老有人迟到

现象3：经常延长时间，议题发散，冗长的会议令人疲惫不堪

现象4：团队养成了随时沟通的习惯后，认为站会没有存在的必要，且形式过于呆板

现象5：所有人都面向一个人，自顾自说3句话，然后结束形式化的汇报

现象6：·当阻碍出现时，没有人或者只有SM在想办法解决，·阻碍的解决手段没有及时实施，比如说我承诺和你一起结对，结果因为其他紧急任务而耽搁

>误解

站会=汇报会。

站会很容易不知不觉就演变成汇报会议，大家基本没有交流，只是简单工作进展的汇报，信息过于精简，气氛不够放松。

站会 ≈ 知识分享会。

当遇到一个问题/阻碍，很容易发散开去，大家立即集思广益，或者解决了一个棘手的问题或使用一个新技术攻克难题时，特别期望能与队友分享，知识共享是个好的实践，但不适合站会上开展，一方面它打乱了站会的节奏和整体感，可能掩盖风险；另一方面可能要占用很多时间，而且也许只有部分人感兴趣。

站会->细节讨论会。

在站会中，任何一点，或需求，或问题，都容易引发细节讨论，同样也可能要占用较长时间，并干扰了不相关人的精力，可以在站会后组织一个following up meeting，请相关人员与会即可。

套用冰山模型，所有表现出来的现象，根本原因在于动因不同，要向下（价值观：信任、尊重、开放、勇气、同理心）去寻找解决方法。问题可能原因：

1、承诺：缺少团队成员对站会的理解和承诺，他们只是被要求去开会；

2、共识：在站会出现问题的时候，没有让团队成员在一起达成共识，而是自己制定了一个规则，要求团队遵守；

以站会为例，团队每日承诺即是彼此互相信任的表现；人们全神贯注，给予一个走心的倾听则是相互尊重的表现；遇到困难时敢于及时寻求帮助，是需要勇气的，这一点在喜欢埋头苦干的程序员身上体现地十分明显；肯于将工作和代码可视化，让他人审视，甚至有时还需要接纳些不同观点，这既需要勇气，又需要有开放的心态；当解决问题发生冲突时，能够站在对方角度考虑问题，背后支撑的是同理心。我们通过每日站会，关注团队的产出和目标，在不断的小步伐与错误中更正自己的行为，籍此来调整团队的节奏、步伐、方向，甚至还会变更承诺。理解了上述几点，便会领悟到站会不仅仅是更新状态，还有更多的是关注是给自己和队友的。（李月萍）

>Tips

可以指定一个主持人或轮流做主持人。由主持人来召集并控制会议时间，引导会议过程，会议结束时可以做个简短的总结，说出重点就行，做好每日规划。

1.轮流第一个发言

2.团队想办法保证全情投入

3.挑战而非斥责

4.集体调整、集体对站会负责

5. 我们不是孤军奋战，而是一个团队在战斗

6. 让大家看到工作产生的价值，持续获得成就感。

7. 将每日会议时间控制在15分钟内。