敏捷宣言的签署者之一，Jim Highsmith 在他最近的博客“开发速度正在杀死敏捷”中描绘了对开发速度“饥渴”的经理会用开发速度作为生产率的衡量指标。他写道：“……他们通常狂热的衡量开发速度——团队开发速度、不同团队间开发速度的比较、组织级的开发速度、甚至是每个开发人员的开发速度（呸！）”
Highsmith 指出开发速度正被越来越多的用来衡量生产率。原因显而易见。任何衡量生产率的方法，可以帮助你了解什么方法有效、什么方法无效，以便调整。而且，开发速度数据容易获得、便于计算并被视为是大量输出的计量结果。但 Highsmith 警告说，这种度量太过关注交付故事点的数量。“这个数量降低了交付的客户体验的质量”，并在他所谓的“交付引擎”上投入过多。
让问题更加复杂的是，敏捷运动专注于高度客户参与——总的来说这是好事——但我们走得太远了。很多“敏捷主义者”公开抱怨他们不能让组织专注于技术实践——但为什么我们鼓励产品经理对优先级做出决定，然后当他们用速度来衡量工作情况时，而大吃一惊呢？在传统方法中，我们太过缺少客户参与——从而赋予产品经理安排优先级的控制权。
Highsmith 不是第一个质疑敏捷实践中开发速度的用法的人。 Mark Levison 在他去年的博客文章“敏捷项目中开发速度的误用”中，他定义了开发速度是团队完成的工作量除以完成时间。他写道“工作量通常以故事点数（一个相对大小的数量）计算。”
Levison 谈论了用开发速度比较两个团队的生产力。但 Levison 指出：
敏捷 /Scrum 团队使用相对大小的估算（比如，这个用户故事 / 功能是大于还是小于我们的“基准”用户故事？），而不是像传统方法中的绝对大小估算。互相比较、标杆对照、或者任何比较开发速度的尝试时，都会遇到这个问题：我的故事点数 ≠ 你的故事点数，因为不同的项目采用了不同的基准用户故事。不同的项目的问题域不一样，项目成员也不一样。
Scott Ambler 也在几年前写过有关“在不同团队间比较开发速度的危险”这一主题的文章，他建议不要计算每个团队的加速度。Ambler 认为，这种做法的优势在于：容易计算、易于自动化并难于博弈。缺点是，这种度量是间接的，很大程度上依赖于Ambler 称之为的“捏造因数”。
可能是Highsmith 标题党了，他和Levison 都不是说开发速度是完全邪恶的。Highsmith 写道，“开发速度的正确用法是一个校准工具，是一种有助于做基于能力的计划的方法”，Levison 说，“开发速度和发布计划的真正价值在于让产品经理清楚在下个发布时能得到什么。”
查看英文原文： Is Velocity Killing Agile?
评论