站会的时候，每位团队成员围绕故事卡进行更新。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”，准备发言的人首先取得”令牌”，发言完成后将“令牌”传给下一个人。令牌要醒目，可以是毛绒玩具，也可以是一顶帽子)。

用户故事开卡(Story kick-off)：在每个用户故事开发之前，要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常表现为由DEV讲解这个用户故事要完成的功能及AC，一旦发现任何疏漏，BA及时补充。DEV有任何疑惑也需及时提出来，当场确认，使这些功能得以正确实现。在后续开发中如果碰到任何疑惑，也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。

代码审查和回顾

**代码审查(Code Review) **开发团队在完成每天代码之后，会聚在一起评审当天的代码，这样做有几个好处：

团队经过一天高强度的思考与编码，适当地停下来，看看其他人写的代码，同时将自己的代码讲解出来，往往能获得一些意外的灵感，或许能解决自己面临的阻碍；

互相了解设计思路，获得更好的建议和进行思路重构，提高代码质量；

及早发现潜在缺陷，降低事故成本：如果这个时候发现代码的坏味道和一些需要改进的地方，代码审查结束后可以花少量时间作出更改；

促进团队内部的知识共享。

回顾(Retrospective)：回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识，指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈，可以保证团队关心生产力和效率，了解自身的不足，这将成为团队持续改进的起点。

回顾的关注点也多种多样，除了“项目开发”之外，还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时，需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化，不断调整回顾的关注点和形式，确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出，还能够不断提升团队内部的安全感和信任度。

回顾的形式和方法非常多，最常见的是“Well & Less Well”。

最大程度的可视化

看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，形成了具有自己独特风格的可视化管理工具。

在敏捷项目里，挂在墙上的“人人可见的大图表”是一种普遍的实践，它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙，这样的物理墙通常包括三个元素：时间、任务和团队。

除了表示项目状态，项目团队还会可视化其他的元素，比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。

一般来说，通过有关联的团队和个人之间相互协商，可以识别出未来一段时间里各自的活动，以及相应的、对成功的衡量方式，然后将其可视化出来，每段时间再回顾和调整一次。有了这样的可视化，团队会更加容易对齐目标，并不断培养和加深责任感。

可视化带来的好处是：

日常工作透明，将迭代过程中所有的故事卡可视化出来，团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反应更灵敏，可视化的故事墙能立刻聚焦团队的注意力。

将迭代过程中遇到的问题暴露出来，可以促进团队成员在工作中一起积极讨论解决方案。

团队也可以根据现在的进度以及遇到的问题，了解需要哪些帮助，更好的分配资源，减少开发进度被滞后的风险。

沟通计划

敏捷里面的自组织团队其实是敏捷的结果，而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对“做什么、怎么做”的问题时，也会以自组织的方式去解决。每一天，团队中的每一个人都要其他成员保持协调。为了保持同步，我们会创造基于敏捷实践的沟通机会，这个也是实施敏捷的过程之一。