摘要: 我认为敏捷社区要改变评测敏捷团队是否成功的方法。我们收集指标以及从这些指标中获取信息的方法实际上妨碍了我们做出能用的软件，而这才是最重要的东西。 强推个体指标有时会导致过于关注其他人，影响团队的 ...
| 编写单元测试的数量： 大多数敏捷开发者都会写很多单元测试；测试驱动的开发创建的测试更多（两者都能带来更好的代码质量）。所以用一个开发人员编写的测试数量来评测他的生产率肯定是没错的！实际上观察者效应会把这个指标灭掉。告诉开发人员会用他们编写的测试数量来评测他，他们肯定会在不考虑质量的情况下写很多测试。我们不是为了交付测试代码；我们的目标是交付可用的软件。不管在什么时候，我对测试的态度都是宁缺毋滥。 个人的速度：观察者效应再一次把这个变成了一个糟糕的指标。如果开发人员知道他的绩效决定了他的个人等级，也知道只能通过他专职的工作得分，那实际上就是在打消他为团队做贡献的积极性。他被放在一个非常不敏捷的情境中，他要跟自己的团队竞争，而不是为团队做贡献。 在理想情况下，敏捷团队是相互协作的，彼此之间有互动，相互讨论和评审他们做的几乎所有事情。这有助于构建优质软件，快速解决问题，但如果把个人的生产率从团队里剥离出来，则几乎不可能形成这种层次的互动，所以不要做这种尝试，这样只会伤害团队做出优质软件的能力。 团队的速度： 这是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的准确程度就是评判他们的标准。 所以我们评测的是交付给客户的价值以及交付软件的及时性。只有这两个跟收钱有关的真实指标。 |
