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

这是敏捷生态系统系列的第二篇（之一，之二，之三，之四，之五）。

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

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

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

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

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

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

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

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

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

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

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

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

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

4. ……

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

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

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

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

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

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

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》

转载于:https://www.cnblogs.com/JPAORM/archive/2011/08/09/2510466.html

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

敏捷开发生态系统系列之四：计划跟踪II（自组织团队-开发团队自己估算-PO挑战估算-同行压力）...
这是敏捷生态系统系列的第四篇(之一,之二,之三,之四,之五).一半内容属于需求管理生态,一半内容属于计划跟踪生态. 在实际开发环境中,产品负责人常常和开发组存在潜在的利益对立.前者往往希望在更短的时间 ...
敏捷外包工程系列之二：人员结构（敏捷外包工程，敏捷开发，产品负责人，客户价值）...
本文是敏捷外包工程系列的第二篇.(之一,之二,之三,之四) 敏捷开发整体上适合小团队.产品研发(所以才有product owner一称)的环境,而外包软件开发中常常存在的则相反,因此在创建团队的时候要 ...
敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）...
这是敏捷开发绩效管理的第二篇.(之一,之二,之三,之四,之五,之六,之七) 团队管理是个由来已久的话题,各式各样的管理理论和方法层出不穷.笔者因为工作原因在过去16年里与100多家企业的团队或团队领导 ...
敏捷开发绩效管理之三：个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）...
这是敏捷开发绩效管理的第三篇.(之一,之二,之三,之四,之五,之六,之七) 如果有10个程序员,笔者相信至少有9个是勤奋的.但是如果有一个10人的程序员团队,其中1个人不是勤奋的,而且仍然拿到与其他人 ...
敏捷开发“松结对编程”实践之一：人员结构篇（大型研发团队，学习型团队，139团队，师徒制度）...
本文是"松结对编程"系列的第一篇.(之一,之二,之三,之四,之五,之六,之七,之八) 传说中的结对编程,大致结构是两个人共用一台电脑,一个开发,一个测试,以随时评审来抵消返工时间损 ...
敏捷开发“松结对编程”实践之一：人员结构篇（大型研发团队，学习型团队，139团队，师徒制度）
本文是"松结对编程"系列的第一篇.(之一,之二,之三,之四,之五,之六,之七,之八,此系列之九及之后文章请见栏目总目录.) 传说中的结对编程,大致结构是两个人共用一台电脑,一个开发 ...
敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）...
这是敏捷开发绩效管理的第六篇.(之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很"程序员".如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统 ...
敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）...
这是敏捷开发绩效管理的第七篇.(之一,之二,之三,之四,之五,之六,之七) 续前文-- 功能点估算第一级简化上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够. 谁能在刚拿出2页 ...
敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算）
这是敏捷开发绩效管理的第五篇.(之一,之二,之三,之四,之五,之六,之七) 度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容. ...

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

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

最新文章

热门文章