敏捷开发绩效管理之三：个体动力之源——同行压力（松结对编程，师徒制度，跨职能团队，绩效考核）...

太过爱你忘了你带给我的痛 2023-08-17 15:52 88阅读 0赞

这是敏捷开发绩效管理的第三篇。（[之一][Link 1]，[之二][Link 2]，[之三][Link 3]，[之四][Link 4]，[之五][Link 5]，[之六][Link 6]，[之七][Link 7]）

如果有10个程序员，笔者相信至少有9个是勤奋的。但是如果有一个10人的程序员团队，其中1个人不是勤奋的，而且仍然拿到与其他人完全相同的报酬——大家猜这个团队会以90%的生产率运行，还是更低的生产率？不管大家信不信，我是相信后者的。

这个是敏捷开发中对个体管理的出发点，并非我们看到有人在白拿老板的钱而要劫贫济富，而是要**打造一个共进退的团队**。

本文的部分内容在之前的若干博文中提到过，因符合本系列的内容，在此处从另外一个角度加以说明。

--------------------

# 领导压力 #

领导压力指那种直接由领导监督产生的压力，在“每个毛孔都流着血和肮脏的东西”的时代或企业非常普遍。特征表现为：领导深度过问过程而不只是结果，领导现场监督（在计算机时代，则有人发明了一种软件可让领导直接监控员工屏幕）等等。

领导压力的问题在于：领导很难无处不在无时不在；领导很可能是外行；领导就算不是外行，对单个任务而言，了解程度也一般低于任务承担者。

领导压力一般是面向个体的，因为团队不会帮助领导管理个体，相反其整体上处于帮助个体而疏远领导的状态。

如果你所在的企业越来越关注大家的考勤，已经在办公室安装了摄像头，正在调研一款屏幕监控软件……那么，代打卡现象一定很普遍，坐在电脑前什么也不做的人一定很多，定期切换屏幕的习惯正在大家中间养成……

办公室是一个团队合力解决问题的场所，而不是内部博弈的场所，因此领导压力是一个不明智的选择。

# 同行压力 #

同行压力是一种由员工管理员工的方法，因而解决了时间、空间、知识差异的问题。

不过这种管理不是通过授权某人管理另外某人，而是通过为团队指明一个共同利益，从而使其在获取共同利益的时候互相管理。

典型的同行管理行为发生在敏捷开发中的“（每月）计划会议”和“（每日）站立会议”。在计划会议中，团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。

其中所使用的**共同估计**和**共同跟踪**是实施成功的关键活动。

# 同行压力的外在条件 #

不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。

1. **跨职能团队**

如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队（如10个都是开发人员），但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完成。

使用小组而非个人作为接收任务的最小单元是建立跨职能团队的一种方法。

采用师徒制度，采用[松结对编程方法][Link 8]，是明确小组责权的一种好的方法。

2. **先估计后分配**

原因显而易见：若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。

3. **匿名估计**

即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。

宽带Delphi和[估算扑克][Link 9]是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。

4. **挑战和优化估计**

为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。

5. **共同跟踪**

共同估计是共同跟踪的前提。只有这样，在跟踪时（比如每日立会上）大家才会关心别人任务的实际情况，在遇到困难时（往往是发生了超出当年计划意料之外的事情），人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。

在一个采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗透到[日常开发活动][Link 10]中。

6. **团队绩效**

即认为若某个工作没有完成，责任属于整个团队而不是具体负责人。这样既可以防止有任务没人接，也可以防止有些人把着任务不放。

在较大的团队里边由于有从众心理，往往很难让一个人在心理上承认自己应为另外9个人中的一个没有完成任务而负有责任。但当把他们切分成小组时，情况会有所改观。尤其是师徒制度下师傅的团队责任感会很强。

**7. 可完成的任务**

若任务总是无始无终（比如“开发可重用库”）或很难有标准判断是否完成（比如“需求分析”），则很难估算和跟踪，也无法形成同行压力。

**8. 开放空间**

既包括**物理上**的开放空间即人们可以观察到每个人在做什么，也包括**逻辑上**的开放空间即人们可以观察到别人任务的进度。

匿名性被心理学分析为引发违规的重要诱因，比如群体事件中的蒙面者更加胆大妄为。跨职能团队、共同估算、开放空间等均起到**破除个体匿名性**的作用。

在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。不过笔者放弃了所有拥有独立办公室的机会，坚持坐在团队的中间乃至正中央。因为工作并非永远令人兴奋、感觉顺畅，我非常担心自己会放弃自律而有所松懈。那时候产生的所有负面效果的**第一个受害者是我**，而不是公司或其他人。

上述内容在很大程度上已经替代个体考核管理了团队中的个体，帮助他们提升绩效，但如何最终考核他们的绩效（正如前言，工资和奖金毕竟是发放到个人账户上的），日后会有博文再议。

--------------------

若团队的个体绩效已经与团队的整体绩效对齐，那么他们一起去做什么呢？那就是我们的下一个话题：为团队设定外部目标。

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

![0_1311055886783t.gif][]![0_1311055987UN6B.gif][]

转载于:https://www.cnblogs.com/JPAORM/archive/2011/08/21/2510456.html

[Link 1]: http://blog.csdn.net/cheny_com/article/details/6705497
[Link 2]: http://blog.csdn.net/cheny_com/article/details/6705568
[Link 3]: http://blog.csdn.net/cheny_com/article/details/6705821
[Link 4]: http://blog.csdn.net/cheny_com/article/details/6713089
[Link 5]: http://blog.csdn.net/cheny_com/article/details/6721626
[Link 6]: http://blog.csdn.net/cheny_com/article/details/6723708
[Link 7]: http://blog.csdn.net/cheny_com/article/details/6723715
[Link 8]: http://blog.csdn.net/cheny_com/article/details/6581517
[Link 9]: http://blog.csdn.net/cheny_com/article/details/6587277
[Link 10]: http://blog.csdn.net/cheny_com/article/details/6590360
[Link 11]: http://blog.csdn.net/cheny_com/article/details/6616794
[0_1311055886783t.gif]: http://hi.csdn.net/attachment/201107/19/0_1311055886783t.gif
[0_1311055987UN6B.gif]: /images/20230810/54801472b29c4efb985a2dafc38ec6a3.png