我认为敏捷社区要改变评测敏捷团队是否成功的方法。我们收集指标以及从这些指标中获取信息的方法实际上妨碍了我们做出能用的软件，而这才是最重要的东西。
强推个体指标有时会导致过于关注其他人，影响团队的协作。这会歪曲我们要评测的内容，摧毁我们的真实意图。
在我看来主要有两个问题：
观察者效应： 观察者效应是指对一个流程进行观测可能会影响它的输出。比如告诉一个团队你会密切关注他们的速度，该团队可能会为了加快速度而过度估算他们的工作内容。这在处理 故事点 时尤其危险，因为根本就没有依据可以判断估算是否有效。
尽管上面这幅漫画中的情况很有可能发生过，但并不是我理想中观察者效应的例子。我给你们讲一个我很久之前认识的技术支持工程师，我们叫他“杰森”好了，因为他的名字就是杰森。杰森是一位优秀的技术支持，在别人遇到特别困难的问题时他会施以援手，一般在客户打来第一个电话时他就能正确地把问题解决掉，而且客户对他的评价很高。问题是杰森接电话的时间太长，而这一指标对管理层来说非常重要。后来经过几次会议和一次考核之后，杰森明白他必须把时间缩短，否则就只能另谋高就了。很快几周就过去了，杰森的呼叫时长在整个支持团队中排到了前5名。他是怎么做到的呢？如果不是我有一天接他班时提前到了一个小时，他可能永远都不会跟人讲起其中的秘密，那天我发现他原来是接了电话之后马上就挂掉了。
这挺有点儿意思，如果杰森的呼叫时长没有他的真实绩效重要，他就不会干那种事。以呼叫时长为指标评测他对产出产生了负面影响。除了这个糟糕的指标之外，即便没碰到过杰森这么极端的情况，我们也都遇到过只想尽快让你挂上电话的技术支持。问题是你的团队为了让自己的数值更好看挂了哪些电话？
路灯效应：路灯效应是指我们人类倾向于寻找更容易的答案，而不是真实的信息。比如计算代码行数就很简单，但代码行数并不能告诉我们程序的质量如何，也不能表明程序提供的功能性甚至效率怎么样。
我想起以前曾经工作过的一个团队，我们做了几个产品，每个产品的质量标准都不一样。当时的情形是“产品A”的质量标准要难得多，而产品B、产品C或产品D的质量标准不会是什么太大的问题，除非管理层在下次审查临近时改变了对这些产品质量的要求。
问题是“质量”这个概念有点模糊，真的不太好评测。而错误率就容易测量得多，因此那些做产品A这个质量标准比较高的产品的人，在面对审查时就更加不利。那这份工作最终是由谁来完成的呢？大部分是实习生、临时工或做外包的那些人，或者其他任何人，总之没人愿意参与。
事实证明，即便是容易测量的错误率，也不能给出什么有价值的信息，因为出现错误的次数更多是由产品而不是员工决定的。我们反而赶走了几个不错的新员工，丢掉了客户，整个团队的士气也受挫了，因为他们工作时考虑更多的是在如何避免错误，而不是如何构建产品。
因为这两个都不是软件开发的例子，所以接下来我们把这些概念放到一些常见的、你所熟悉的“敏捷”指标上。容易测量的指标有哪些？
编写单元测试的数量： 大多数敏捷开发者都会写很多单元测试；测试驱动的开发创建的测试更多（两者都能带来更好的代码质量）。所以用一个开发人员编写的测试数量来评测他的生产率肯定是没错的！实际上观察者效应会把这个指标灭掉。告诉开发人员会用他们编写的测试数量来评测他，他们肯定会在不考虑质量的情况下写很多测试。我们不是为了交付测试代码；我们的目标是交付可用的软件。不管在什么时候，我对测试的态度都是宁缺毋滥。
个人的速度：观察者效应再一次把这个变成了一个糟糕的指标。如果开发人员知道他的绩效决定了他的个人等级，也知道只能通过他专职的工作得分，那实际上就是在打消他为团队做贡献的积极性。他被放在一个非常不敏捷的情境中，他要跟自己的团队竞争，而不是为团队做贡献。
在理想情况下，敏捷团队是相互协作的，彼此之间有互动，相互讨论和评审他们做的几乎所有事情。这有助于构建优质软件，快速解决问题，但如果把个人的生产率从团队里剥离出来，则几乎不可能形成这种层次的互动，所以不要做这种尝试，这样只会伤害团队做出优质软件的能力。
团队的速度： 这是Scrum中最容易被误解的指标之一。一个团队的速度是独一无二的。不能拿来跟其他的团队比较。比如团队A估计某项工作的工作量为一个50点的sprint，而团队B估计的sprint相同，不过是150点。如果两个团队都成功完成了sprint，那么团队A的速度是50点，而团队B的速度是150点。哪个团队效率更高？都一样。他们完成的工作是一样的。因为这个指标鼓励团队捏造估值，以影响他们规划下次sprint的能力，所以这个指标特别邪恶。如果团队不能正确规划sprint，那整体软件的发布就有被延迟的危险。我之前专门写过一篇博客讨论 Scrum 团队的速度，可供参考。
好吧，大才子，我们应该用什么指标？
问得好，我们用交付的可用软件评测团队生产率。我们要评测的是实际产出，而不是贡献因素。这种方法更敏捷，因为团队可以自由选择能够成功构建软件的方法，而不是可以得到更高指标得分的方法。这也更合理，因为我们能带到银行去的就是能用的软件（当然是在卖给他们之后）。
那么新指标究竟有哪些？
交付的价值： 这个指标需要产品所有者参与。让他给出每个故事的价值，能体现这个故事对利益相关者的影响程度。你可以用实际的金额或某种明确的数字表示这个价值。在每次sprint完成后，你会得到一个数值，表明从产品所有者的角度来看你交付给客户的价值是多少。
这个指标不评测绩效，而是评测影响。理想情况下，产品所有者会按backlog中的顺序从高到低给出每个条目的价值，这样每次sprint所交付的价值就会尽可能的最大化。对于明确限定了范围的项目，一开始的sprint会有非常高的交付价值，随着不断向backlog中深入，sprint交付的价值会逐级递减。有时会因为开发成本的原因消除再运行一次sprint的可能，通常这时开发团队就可以开始去做新的产品了。
交付的及时性： 有时我会听到有人跟我说他们公司推广敏捷开发方法的计划失败了，因为他们不能明确产品的交付日期。我不会认同这种说法。敏捷团队应该可以明确确定软件的具体交付日期。交付时可能会有些故事还没实现，但那通常是些低价值故事，对客户的影响不大。也就是说团队的速度应该是稳定的，如果速度加快或变慢，也应该是逐级变化的。如果不同sprint之间出现剧烈的速度波动，则很难做出长期规划。
接下来是我们的指标：如果团队预测接下来的sprint能完成5个故事，那他们完成 5个故事后能挣到2分。如果他们交付了4个故事，或者他们交付提前的时间不到2天（根据你的情况选择天数），那他们能挣到1分。如果他们交付提前的时间超过2天，或只交付了5个中的3个，则不得分。在季度末，或一次发布结束，或年末时，团队预测sprint的准确程度就是评判他们的标准。
所以我们评测的是交付给客户的价值以及交付软件的及时性。只有这两个跟收钱有关的真实指标。
最新内容请见作者的GitHub页：http://qaseven.github.io/
