同行压力则融合了人与目标管理的长处。
在利用人来监督的方面，同行压力将监督者换为同行，从而解决了时间和空间问题；在利用目标来监督的方面，同行压力要求按照可交付结果的任务而非空洞的工时来跟踪工作。
如何用好同行压力
典型的同行监督场景是敏捷开发中的“（每月）计划会议”和“（每日）站立会议”。在计划会议中，团队在确认谁负责哪个任务之前，先共同估算每个任务的预计工时，之后才自由领取或指派负责人；而在站立会议中，任务的负责人则报告进展情况，如果和计划有大的偏差，需要说明遇到的困难，以便大家进行帮助。其中所使用的共同估计和共同跟踪是实施成功的关键活动。
不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。
1. 跨职能团队
如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队（如10个开发人员），但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完成。
使用小组而非个人作为接收任务的最小单元是建立跨职能团队的一种方法。
2. 先估计后分配
原因显而易见：若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。
3. 匿名估计
即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。
宽带Delphi和估算扑克是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。
4. 挑战和优化估计
为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。
5. 共同跟踪
共同估计是共同跟踪的前提。只有这样，在跟踪时（比如每日立会上）大家才会关心别人任务的实际情况，在遇到困难时（往往是发生了超出当年计划意料之外的事情），人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。
6. 团队绩效
即认为若某个工作没有完成，责任属于整个团队而不是具体负责人。这样既可以防止有任务没人接，也可以防止有些人把着任务不放。
7. 可完成的任务
若任务总是无始无终（比如“开发可重用库”）或很难有标准判断是否完成（比如“需求分析”），则很难估算和跟踪，也无法形成同行压力。
8. 开放空间
既包括物理上的开放空间即人们可以观察到每个人在做什么，也包括逻辑上的开放空间即人们可以观察到别人任务的进度。
扩展应用
在整个公司运营层面上，也适合使用同行压力。
比如在“人员各司其职”且有大量独立空间的部门最容易滋生工作拖沓问题。可以考虑让一组人负责一组事，且安排大家坐在开放空间，保证每个人的电脑都被很多人可以看到。
定期在会议室召开会议来报告进度常常被认为是产生压力的一种方法，但在开放空间中常常每周或每天直接召开现场会议，每人报告发生的事情。在笔者的公司里这种会议持续了两三个月，直到人们发现这种会议是没有必要的，因为由于在开放空间中人们几乎一直在交流，极少有事情需要单独传达。经理们也发现，要知道工作的忙闲只需要看谁在日常工作中很少沟通就可以了

本文来自CSDN博客，转载请标明出处http://blog.csdn.net/cheny_com/archive/2011/02/11/6179203.aspx
原帖地址：http://bbs.techexcel.com.cn/bbs/Tools/thread-233-1-1.aspx