从产品成果导向实践敏捷开发一：基于团队，沟通、人员组织的问题

【实践敏捷开发的目标】赋能一个团队进行自我适应和改进机制，从而让团队进行自我组织状态，群策群里解决问题，并推动组织的发展。

责任担当：打造一个共进退的团队
其中所使用的共同估计和共同跟踪是实施成功的关键活动。

同行压力的外在条件
不过有时一些应用敏捷开发很久的开发团队并没有真实感觉到“同行压力”的作用，原因是同行压力的实现需要一些先决条件来支持。
1. 跨职能团队
如果分工过于细化，技术壁垒太高，很难展开共同估计。有些团队本身是跨职能团队（如10个都是开发人员），但却往往因为过度进行模块分工而导致工作无法胡同。跨职能团队底线是：任何任务至少有两个人可以完成。
使用小组而非个人作为接收任务的最小单元是建立跨职能团队的一种方法。
采用师徒制度，采用松结对编程方法，是明确小组责权的一种好的方法。
2. 先估计后分配
原因显而易见：若任务已经分配，多数“无关人员”的兴趣和注意力将大大降低。
3. 匿名估计
即使是一个跨职能团队，如果第一个人首先说出估计结果时，其他人可能因为各种心理问题而导致无法客观地表达自己的意见，尤其当第一个人是最强或最弱一员的时候。
宽带Delphi和估算扑克是两种常见的匿名估算方法，其中后者因为简单快捷在敏捷开发中广为使用。
4. 挑战和优化估计
为了防止计划会变成一个无聊的监督行为，在匿名估计中数值相差较大的组员要进行“挑战（Challege）”，寻求最优化的估计。之所以称之为挑战，是因为团队不能简单地进行求均值、投票，而是大家分别说出理由（一般估计最低的先说），尝试确认是否有可重用的组件、额外的测试要求等诸多可能影响估计结果的因素，重新投票直至结果接近。优化估计的过程借助团队的知识和智慧澄清了很多个体似是而非的猜测，结果不但为大家所接受，也更客观。
5. 共同跟踪
共同估计是共同跟踪的前提。只有这样，在跟踪时（比如每日立会上）大家才会关心别人任务的实际情况，在遇到困难时（往往是发生了超出当年计划意料之外的事情），人们会更理解任务为何发生延期，且更容易激发热情去帮助任务负责人。
在一个采用师徒制度和松结对编程的团队，共同跟踪活动不限于每日立会，而是会渗透到日常开发活动中。
6. 团队绩效
即认为若某个工作没有完成，责任属于整个团队而不是具体负责人。这样既可以防止有任务没人接，也可以防止有些人把着任务不放。
在较大的团队里边由于有从众心理，往往很难让一个人在心理上承认自己应为另外9个人中的一个没有完成任务而负有责任。但当把他们切分成小组时，情况会有所改观。尤其是师徒制度下师傅的团队责任感会很强。
7. 可完成的任务
若任务总是无始无终（比如“开发可重用库”）或很难有标准判断是否完成（比如“需求分析”），则很难估算和跟踪，也无法形成同行压力。
8. 开放空间
既包括物理上的开放空间即人们可以观察到每个人在做什么，也包括逻辑上的开放空间即人们可以观察到别人任务的进度。
匿名性被心理学分析为引发违规的重要诱因，比如群体事件中的蒙面者更加胆大妄为。跨职能团队、共同估算、开放空间等均起到破除个体匿名性的作用。
在开放空间和个人空间之间有由来已久的纷争，仁者见仁智者见智。不过笔者放弃了所有拥有独立办公室的机会，坚持坐在团队的中间乃至正中央。因为工作并非永远令人兴奋、感觉顺畅，我非常担心自己会放弃自律而有所松懈。那时候产生的所有负面效果的第一个受害者是我，而不是公司或其他人。

进度：
“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。
“响应分销商需求的时间”适合渠道比较强势的情况。
这些外向型绩效应该作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得到底的绩效。从而促使整个团队一起思考如何提升绩效。
需求和设计人员为了能让开发人员提前开工，可以采取分段写需求和设计的方法，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前开工干活；而开发人员也可能会采取同样的策略，阶段式地发布产品，让测试人员可以提前测试，防止最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应该消减功能换取上市时间，还是增加更多功能以换取竞争力。
可见一个为外部目标奋斗的团队，会很容易地团结起来，共同思考提升绩效的最佳策略。

质量：
“每月待处理质量问题数”咨询过的一家ERP公司的实际数据（但他们尚未用这个数据考核），此数据一般符合瑞利分布，因此可预测未来的质量问题数量。
“每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。
“每月分销商投诉数”适合渠道比较强势的情况。
“每月论坛缺陷提出数”适合……我在的一家企业使用BBS免费处理缺陷。
用最终用户提出的抱怨作为外部质量目标的策略，不是说大家不用测试了，把缺陷留给用户。而是：用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的认识，修订发现缺陷的方法。
有很多产品，收到的客户关于易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应该将“易用性差”作为核心的质量问题，进而作为质量重点。我在下载一款总体评价4星半的Android短信软件时，发现近期的评价很多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了（给了1星）”等等，最近的一些评分平均估计会下降到4星以下。这些抱怨应该当作质量管理的最终考核标准，因为下载者无疑会根据这些评价来决定是否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。
成本：
“产品实际投入产出”适合很长的战线。
试想如果是手机研发，应该在开发阶段就做好测试、维护、重刷系统等接口，另外应该优化性能以选择低端硬件，否则整个产品极难保障盈利。
而且还会发生若软件做得好（但软件的研发成本要上升），则可以节省一些硬件资源或减免某些专用硬件的情况。这时候若要分别考核软件部门和硬件部门，就很难实现了。
需求：
“每月待处理需求数”咨询过的一家ERP公司的实际数据，如果产品试销售过程中此数据很大而且消退很慢（符合瑞利分布），则表明产品与客户的需求不符。估计也能呈现一些易用性方面的因素。
“客户尖叫度（Customer Screaming Rate）”苹果成功的标志性绩效指标，不谈需求，因为他要超越需求。要学习这个很难，但要理解并体现其精神。
“软件与硬件需求匹配度”适合消费电子，比如若硬件与软件研发平行，则最终交付产品中交付的软件和硬件应该匹配，而不能“18个功能中，硬件完成了12个，软件完成了13个，但其中6个不重合（就是说这些功能交付不了）”，这样软硬件部门才会共同配合。
某手机厂商很擅长上一条，他们一年的200个项目中，只有3个延期，就是很好地利用了功能排序-软硬件对齐的方法，牺牲次要功能保证上市时间。

项目开发型
产品做的多，项目做的少，不敢多说，请各位补充吧！

为团队设立外部绩效目标的目的，是对齐团队的不同角色、工序、人员的目标，从而互相帮助提升共同的绩效。
外部目标多数可以被客户、用户或市场明确感知，其提升几乎意味着带来收入的增加。如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱，那就改到客户很少抱怨的时候发吧，那时候账上肯定有钱。

---