敏捷开发生态系统系列之二：敏捷生态系统-计划跟踪 I（跨职能团队-共同估算-每日立会-同行压力）

如果说需求管理中尚有一些团队无法控制的因素导致实施困难，计划与跟踪过程总归就没有问题了吧？其实不然，笔者见过领导很放权的全团（很多是因为领导根本管不过来了），但在团队内部仍然存在很大的问题，一般最为突出的，就是每日立会开得毫无生机。这不完全是因为文化差异问题，而是生态系统出了问题。

敏捷开发中的计划跟踪生态大致如此（黑体字即图片中的元素）：

☺ 跨职能团队的整体思路是“每个人可以做每个工作”。好处是消除了资源分配的瓶颈和造成队员无法互助的分工壁垒。

☺ 任务应该先估算后分配给个人，以便整个团队（或至少其中的某个小组）都对其保持兴趣，才可能进行真正的共同估算。

☺ 共同估算（一般采用扑克牌估算）中人们利用整个团队的智慧充分讨论和确认任务的实现目标和方法，因此PO会统一管理/讲解需求，以防止个体理解差异。共同估算是共同跟进的基础，在每日立会中人们之所以关注别人的进展，就是因为人们关心自己曾经参与的估算结果是否正确，方案是否可行。

☺ 共同估算和每日立会产生了同行压力，即每个人都希望以好于或至少持平于团队估算的结果完成任务，从而产生了受激励的个体。

☺ 共同估算和每日立会还防止个体失误，前者通过统一了大家对同一个需求的理解和其实现方法的理解，后者则防止了工作中出现需求镀金、蛮干等问题，从而产生更好的技能和设计。

☺ 作为自组织团队，敏捷团队并非简单地因为“领导让我们自我管理”而受到激励，而是在跨职能团队、共同估算、个体交互、同行压力这些实践的配合下才产生了受激励的个体和更好的技能和设计，从而产生更好的工作效率。

 

跨职能团队-共同估算-每日立会-同行压力是这个生态系统的主线之一。

如果从每日立会的例子看，要解决每日立会问题并不难，可以简单地：

1. 由Scrum Master监督必须召开每日立会

2. 统计每日立会的执行情况

3. 设立按时完成奖和迟到罚款箱

4. ……

这些方法有很多公司都用过，笔者早期知道这些方法时，还真的以为这样就可以了呢，直到后来听说沉闷的每日立会越来越多，才知道存在深层问题。

从生态系统的角度怎样看待呢？

第一个要怀疑的是是否进行了共同估算。如果大家都对别人的任务不了解，也从来没有参与其中（，那么自然就像听天书一样听别人讲；而如果别人对自己的任务不了解，那么即使遇到困难，告诉他们又有何用？（除了表明自己笨……）最终就形成了沉闷的每日立会。

但如果继续分析下去，共同估算的根源又在跨职能团队。这里之所以只把“先估算后分配”当作一个小跳板，是因为不能简单地认为“因为大家不知道会分给谁，所以不得不一起估算”，大家迟早会形成习惯性分工的，所有人都会知道哪个任务其实肯定分给别人。只有“每个人都能做每个任务”的跨职能团队才能解决这个问题。

建立跨职能团队是个难题，个人感觉不可能强制三四个人无缘无故地就跨职能了，他们私下里都会自动形成强分工体系的。一个好的方法是利用师徒制度和松结对编程建立稳固的团队关系，责权利统一远远易于改变团队文化。

尽管计划跟踪整体上是团队内部的事情，但是却可能在计划的时候被强制多做事情，而在跟踪途中又被加入变更而时间点不变。怎样处理这些问题呢？这就是计划跟踪生态系统的另一条生态线，将在下一篇文章中描述。