站会，敏捷开发中常见其影子。敏捷团队中也基本热衷于它。然而不同的项目经理在不同的团队对站会也有不同的实操以及不同的感悟，且看本文作者对于站会的实操和理解。

站会，在几乎所有敏捷开发相关的书籍中都会见到其影子，虽然描述上各有差别，但都把它视为敏捷方法中不可或缺的一环。

对于站会我认为其最大的意义在于创造了一种基于面对面沟通的敏捷原则之上的一次“强制性”的沟通机会，为那些在需要面对面沟通时由于个人性格、时间、被沟通者不在现场等客观理由创造一次机会。因此，站会在敏捷开发中具有非常重要的意义，而由此输出的信息同步、问题暴露、以及对于进度的把控等就是我们真实需要的产物。

团队面对面的沟通也存在许多的注意事项，稍不留神，站会不仅不能发挥其较大的作用，反而可能会适得其反。对于站会，我是这样做调整的：

背景

有幸在今年年初跟进一条新的产品线，在前两周的观察期中发现该团队每天早上会执行全员站会（很赞），但是由于人数众多，会看到黑压压的人员拥挤在走廊上（有些人还挤不进去最里层，当然就很难保证他们能够听到其他人在讲什么），而且由于人多，导致站会很冗长，不少同学在站会后期就开小会、玩手机等，站会的整体效率很低下。

对该团队进行的一些改进

1. 将站会团队从一拆成四个（每个站会有一个核心的主题）

站会的一大要素就是小而美，因此需要将站会回归到小的状态（站会参与人数建议小于10人，符合“两个披萨原则”，该原则是由亚马逊CEO杰夫·贝索斯提出的，他认为与会人数不能多到两个披萨饼还不够他们吃的地步，要不然会议效率就会极大降低）。

根据业务情况和团队架构，将站会团队分成了四个站会，分别为：

1. 技术组web端站会，由web端开发、web端测试、加上主策、主设计，主题是同步当前web端迭代的研发情况；
2. 技术组移动端站会，由移动端开发、移动端测试，主题是同步当前移动端迭代的研发情况；
3. 产品组站会，主要同步产品端/设计端/运营等层面的事项；
4. 在如上三个站会结束后进行各端组长/站会owner的站会，主题是同步如上三个站会中碰到的问题。

2. 站会固定开始时间

由于站会不是固定时间点开始，导致很多人员因为参加其他事情而不能参加站会，因此在拆分成四个站会后，将这四个站会的开始时间也进行了确定分别如下所示：

1. 9:40进行技术组web端站；
2. 9:50进行技术组移动端站会；
3. 9:50进行产品组站会。

如上三个站会结束后进行组长/站会owner的站会。

由于确定了开始时间，大家都会有意识的避免事情和站会的冲突，也因为站会的固定时间，团队人员会提前准备相关的同步事项。

3. 站会的执行套路

站会是一个短平快的方式，因此站会的执行方式是有“套路”的。

站会中团队人员需要同步三点：

1. 昨天做了什么；
2. 今天需要做什么；
3. 有什么阻碍我的进度。

这三点可以言简意赅地充分让团队其他同学了解你目前的进度以及你的困难点，并且评估自己能提供的帮助以及自己的任务是否会影响你。

基于这三点的同步，也表明了站会的三个目的：

1. 让团队为一天的合作做好准备；
2. 帮助团队感知他们是否能够达成当前Sprint的目标；
3. 发现任何让团队慢下来的事情。

4. 站会时长控制在15分钟内

站会中时常会碰到一些因为沟通暴露出来的问题，有些问题可能是只涉及到几个同学，因此规定好时间是为了能够让团队人员相互提醒，有些比较复杂的但是影响人员较少的问题可以在会后小范围沟通，避免不相干的同学浪费时间。

5. 白板的细化

由于站会分成了多个，白板当然也要对应的分化；因此我对于物理白板进行了拆分，如下图所示：

图1 改进前的白板

图2 改进后产品组站会白板

 图3 改进后技术组站会白板

这里需要说明下白板的重要性，白板是将每个人最近阶段（当前迭代）的任务在白板上进行体现，这样可以直观的体现每天的进度情况。

并且由于在讲解时有实体目标点，其他同学的思路能够更好地聚焦在上面；另外，关于电子白板和物理白板的选择，我当时的考虑是因为这个团队本身使用了物理白板，并且整体的更新情况还是比较好的，因此继续保持物理白板的使用。

6. 站会需要实时迭代改进

任何一项流程也像产品一样需要迭代发展的，在执行站会的过程中，团队人员也会提出一些很不错的idea。结合这些建议，在站会中融入一些新的方式：

1. 轮流的站会owner，让更多的人能够体验站会owner的站会组织，提升他们本身对于站会的积极性，以及也能够提升他们全局的考虑；
2. 由于在迭代开发中，不可避免的会碰到需求的增加/需求的变更/开发设计的变更等，而站会则成为一个很好的全员同步口，为了更好的确保前一天的变更点让相关的所有人知道，会在每个迭代初建立一个当前迭代的confluence页面，在迭代的过程中，碰到的变更点都需要由提出的人实时记录下来。而第二天站会owner在开站会前需要review下昨天是否有变更点，若有则需要在站会中同步出来。

站会感悟

站会之于SM人员犹如水之于鱼，要想把控团队每天的进度以及可能的风险，站会是你首选的一个方式。

会议对于很多技术人员来说都是很反感的，但是针对如上的第三点改进中所描述的三个目的，这些目的中的任何一个都不能通过简单的一封邮件或者一个自动化工具所能达成的。

当公司的发展速度赶不上团队的发展速度时，这个公司就会处于波荡阶段。同样，当站会的形式赶不上人员的变化以及团队的发展时，站会也注定只流于形式。

站会不应该金科玉律，不应该成为限制我们的框框，抓住站会的核心“沟通的原则”，大胆去迭代发展你的站会形式，让尽可能多的问题暴露在站会之中。

作者：卢跃，网易杭研院项目管理部高级项目经理，来网易多年时间一直致力于教育这项造福人类的伟大事业，关注团队交付与成长。

本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。