这个目标很美好：评估个人能力，帮助开发人员成长。
指标经过层层分解，来到我们团队，经过经理的认真讨论，决定不使用代码行数和Bug数这样的指标，因为它们太容易被玩坏了。
那用什么呢？用Story Point(用户故事点数)。
这是一个敏捷软件管理和开发中的一个度量单位，用于估计实现一个用户故事的复杂度。
因为用户故事代表了给用户带来的商业价值，所以记录下每个开发人员实现了哪些用户故事，评估他们的绩效是很合理的。
我们使用Jira，每个人都可以把自己的名字和用户故事关联，从而认领一个用户故事，并且统计每个人的生产率也超级方便。
很快，经理就在统计报表中发现了一个最糟糕的程序员，Tim。
Tim这个人的“得分”（用户故事点数）一直为0！
他的得分并不是从高到底降下来的，而是一直保持着0的记录。
很明显，绩效低下的Tim必须得走人。
经理让我安排人去接手Tim的工作，但是我坚决拒绝了。
Tim的“分数”一直为零，是因为他从来没有认领过任何的用户故事！
相反，他的工作方式非常独特，他把他的时间都花在了和别人进行结对编程上。
对于经验不足的开发人员，Tim会让他们充当结对编程中的导航者角色，帮助他们来找到解决方案，Tim不会嘲弄，压迫这些新手，而是采用苏格拉底的启发式来引导他们，给他们带来顿悟时刻。
和有经验的开发人员结对时，编程就是充满争吵的共同创造，用不同的视角来解决问题，创造出比单个人能想象的更好的东西。
Tim是一个出色的程序员，和他结对你总能学到新的东西。
所以Tim的名下没有交付任何用户故事，但是他交付了一个团队，这个团队变得更加高效，有生产力，更加卓越，更加有趣。
这一切，都是因为Tim在团队中。
我向经理解释了Tim的情况，邀请他时不时到团队来看一看。
每当经理出现的，他都能看到Tim和不同的程序员坐在一起，帮助这些程序员完成他们的事情。
你可以肯定，代码质量在显著变好，开发时间在显著缩短。
是的，更好，更快，并且更加省钱。
最后，我们留下了Tim，并且悄悄地干掉了衡量个人生产力的指标，取而代之的是衡量团队的绩效，即我们这个高效的团队能给整个组织带来什么价值。
