时间: 2021-07-30 09:49:25 人气: 1 评论: 0
站**，敏捷开发中常见其影子。敏捷团队中也基本热衷于它。然而不同的项目经理在不同的团队对站**也有不同的实操以及不同的感悟，且看本文作者对于站**的实操和理解。
站**，在几乎所有敏捷开发相关的书籍中都**见到其影子，虽然描述上各有差别，但都把它视为敏捷方法中不可或缺的一环。
对于站**我认为其最大的意义在于创造了一种基于面对面沟通的敏捷原则之上的一次“强制性”的沟通机**，为那些在需要面对面沟通时由于个人性格、时间、被沟通者不在现场等客观理由创造一次机**。因此，站**在敏捷开发中具有非常重要的意义，而由此输出的信息同步、问题暴露、以及对于进度的把控等就是我们真实需要的产物。
团队面对面的沟通也存在许多的注意事项，稍不留神，站**不仅不能发挥其较大的作用，反而可能**适得其反。对于站**，我是这样做调整的：
有幸在今年年初跟进一条新的产品线，在前两周的观察期中发现该团队每天早上**执行全员站**（很**），但是由于人数众多，**看到黑压压的人员拥挤在走廊上（有些人还挤不进去最里层，当然就很难保证他们能够听到其他人在讲什么），而且由于人多，导致站**很冗长，不少同学在站**后期就开小**、玩手机等，站**的整体效率很低下。
站**的一大要素就是小而美，因此需要将站**回归到小的状态（站**参与人数建议小于10人，符合“两个披萨原则”，该原则是由亚马逊CEO杰夫·贝索斯提出的，他认为与**人数不能多到两个披萨饼还不够他们吃的地步，要不然**议效率就**极大降低）。
根据业务情况和团队架构，将站**团队分成了四个站**，分别为：
由于站**不是固定时间点开始，导致很多人员因为参加其他事情而不能参加站**，因此在拆分成四个站**后，将这四个站**的开始时间也进行了确定分别如下所示：
如上三个站**结束后进行组长/站**owner的站**。
由于确定了开始时间，大家都**有意识的避免事情和站**的冲突，也因为站**的固定时间，团队人员**提前准备相关的同步事项。
站**是一个短平快的方式，因此站**的执行方式是有“套路”的。
站**中团队人员需要同步三点：
这三点可以言简意赅地充分让团队其他同学了解你目前的进度以及你的困难点，并且评估自己能提供的帮助以及自己的任务是否**影响你。
基于这三点的同步，也表明了站**的三个目的：
站**中时常**碰到一些因为沟通暴露出来的问题，有些问题可能是只涉及到几个同学，因此规定好时间是为了能够让团队人员相互提醒，有些比较复杂的但是影响人员较少的问题可以在**后小范围沟通，避免不相干的同学浪费时间。
由于站**分成了多个，白板当然也要对应的分化；因此我对于物理白板进行了拆分，如下图所示：
图1 改进前的白板
图2 改进后产品组站**白板
图3 改进后技术组站**白板
这里需要说明下白板的重要性，白板是将每个人最近阶段（当前迭代）的任务在白板上进行体现，这样可以直观的体现每天的进度情况。
并且由于在讲解时有实体目标点，其他同学的思路能够更好地聚焦在上面；另外，关于电子白板和物理白板的选择，我当时的考虑是因为这个团队本身使用了物理白板，并且整体的更新情况还是比较好的，因此继续保持物理白板的使用。
任何一项流程也像产品一样需要迭代发展的，在执行站**的过程中，团队人员也**提出一些很不错的idea。结合这些建议，在站**中融入一些新的方式：
站**之于SM人员犹如水之于鱼，要想把控团队每天的进度以及可能的风险，站**是你首选的一个方式。
**议对于很多技术人员来说都是很反感的，但是针对如上的第三点改进中所描述的三个目的，这些目的中的任何一个都不能通过简单的一封邮件或者一个自动化工具所能达成的。
当公司的发展速度赶不上团队的发展速度时，这个公司就**处于波荡阶段。同样，当站**的形式赶不上人员的变化以及团队的发展时，站**也注定只流于形式。
站**不应该金科玉律，不应该成为限制我们的框框，抓住站**的核心“沟通的原则”，大胆去迭代发展你的站**形式，让尽可能多的问题暴露在站**之中。
作者：卢跃，网易杭研院项目管理部高级项目经理，来网易多年时间一直致力于教育这项造福人类的伟大事业，关注团队交付与成长。
本文由 @网易杭研项目管理（微信公众号：NetEasePM） 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
