今日洞见
文章作者、部分图片来自ThoughtWorks：冉冉。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
作为BA，估算会议是我目前所在项目的日常工作之一，其目的是对近期即将开发的story进行大小的预估。组织了几次估算会议后，我发现会议常常超时很久，team会花大量时间去讨论估计结果是否足够准确。实际上既然是估算，就意味着误差，那么花过多的时间在确保准确性上很可能意味着浪费时间。下面的曲线是根据《敏捷软件开发实践－估算与计划》一书作者Mike Cohn的经验所得，进一步说明了这个结果：当估算会议用时超过一定时长后，其准确度反而下降了。
图1-1 在特定点之后，在估算中投入额外的工作量不会产生多少价值（第40页）
道理我都懂，可是……
既然如此，为什么在估算时，team依然倾向于谨慎的再花时间“多想想”？让我们去回顾日常工作的一些场景中，看看能否找到一些可能的答案：
“在咱们项目，1个点的story大概需要花费一对Dev两天的时间来完成。” “这个story虽然简单，但是AC很多，工作量大，2个点恐怕做不完。” “这个story是2个点的，已经做了5天了，已经超一天了。” “这个story估小了，重估吧，否则velocity会下降。” “这批story整体都估小了，总是超时完成，team估点还是不够准。” “这个月的velocity下降了，我们需要多计划几个story进来。” ……
读一遍这些曾经出现过的相关对话，我们不难发现，story的估点结果总是跟另外一个词紧密的联系在一起：Velocity速度。
“速度”是隐藏在“估点不准”这个担忧背后真正的压力。我们意识到team每次伸出手指，不再是单纯的示意一个估算结果，而是变成了一个承诺——“当给出两个点的结果时，意味着我承诺了在4天内完成它，我必须更谨慎些。”
这是一种解释，也是另一个疑问的开始：如果1个点＝2天，那么故事点和传统项目管理中的“人天”有什么区别？使用velocity的初衷真的是作为敏捷团队生产率表现的小鞭子吗？如果是这样，如此使用velocity作为敏捷的一项实践工具，是否违背了敏捷思想更多在于提升团队应对变化的响应力而非纯粹提高效率的价值取向？
敏捷实践引入Velocity的初衷是什么？
带着上一小节留下的一系列问题，我们首先来看一看 “velocity” 在敏捷实践中的定义是什么，Wikipedia对velocity是这么描述的：
“Velocity is a capacity planning tool sometimes used in Agile software development. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project...”
即： 速度 = Σ(单次迭代中完成的story所分配的故事点数) ［V1］
如果只看到这里，跟我们说 “一个点大概等于两天”［V2］去表示速度，区别是微妙的。但是如果有人告诉你：根据“速度”的大小变化，我们可以不断调整项目的发布计划。那么这种微妙的区别就变得很重要了，因为这代表着两种完全不同的使用目的：V2强调工作规模与工作时长的直接对应，且期待“速度”值保持不变甚至更高；而V1强调对制定计划的参考价值，且不主张刻意保持“速度”值的恒定。实际上，Kent最初在他那本经典的小册子《Extrem Programming: Embrace Change》中，就是将velocity作为协助制作发布计划的 “均衡器” 来使用的：
The proper use of velocity is as a calibration tool, a way to help do capacity-based planning." - Kent Beck, Extreme Programming: Embrace Change
均衡器的理想用法是怎样的？
如果看到上一节后你开始好奇 “速度” 到底怎么发挥 “均衡器” 的作用，我们就具体来看一看，下图中的模型说明了 “速度” 在项目中起作用的节点以及如何协助制定发布计划：
开始计划时，如果将从客户那儿获得的需求拆分成story并分别估点加总，我们就会得到对项目总体大小（或者下一阶段工作总体规模，针对那些长期的项目）的估算。如果知道team的速度，就可以通过用 “加总的大小/速度” 来推算出迭代的次数，再把这个持续时间映射到日历上，就可以得到最初的进度表。
我们举个具体的例子来看。例如，假设下一阶段总体工作规模估算值为200个故事点，又根据过去的经验知道，team的的速度是每次2周的迭代可以完成25个故事点。那么200/25=8，我们可以估算出项目需要8次迭代，因为每次迭代的周期是2周，那么我们可以推算出一个16周的发布计划，再在日历上往后数16周，就得到了具体的进度表。
接下来我们就来看看如何使用 “速度” 完成对计划误差对自我修正：
在初始的计划中，team选用了［25点/迭代］作为历史速度，因为team一开始认为能在每次迭代中完成25个点的story，但是在项目开始后，他们发现速度只能达到［20点/迭代］，那么200/20=10，在计划工作总量不变的情况下，不需要对任何story进行重估，team就能正确地仪式到项目需要10次迭代，而不是8次。
再举一个生活中的例子来帮助我们理解上面的内容。假设team受雇去粉刷一套不知道具体面积的房子，并且他们只有房子的平面图，看不到实际大小，但是我们仍然希望知道他们多久能够完工，这就需要team对其进行估算。如果team估计粉刷两个卧室的工作量都是5个点，这里 “5” 本身没有任何意义，它不直接意味着 “3天” 或是 “5天” 完成，但是它能说明两间卧室的大小大约是一致的，从平面图上能看到车库大概是卧室的两倍大，于是team估算车库的工作量是10个点。
team估算的是粉刷墙壁的“相对工作量”。
因为看不到房子的面积，team只能大概估计一个，比如猜测卧房是2mx3.5m，预测完成粉刷的速度，然后用整体的工作量/预测速度得出我们想要知道的完成时间。真正开工后，如果进度比想象的慢，是不是说之前的估算就没有任何用了呢？不是的，因为他们估算的是粉刷每个房间的 “相对工作量”， 如果team发现卧室的尺寸是他们假想值的2倍， 那么主卧的尺寸也会是假想值的两倍。对于工作量的相对值是不变的，但是由于房间的面积是预期的4倍，因此team的生产率会变慢。如果你还记得第二节中的那句质疑 “这批story整体都估小了，总是超时完成，team估点还是不够准”，在这个例子之后，是不是有了新的解读？
最后一个例子真正重要的意义在于，如果我们希望有效的使用 “均衡器”，前提是我们要意识到story的故事点是相对的，原始点值本身并不重要，重要的是点值的相对大小。在 “一个点大概等于两天” 这样的描述下，我们则无法体现这种相对性。
这一小节中使用的例子引用了《敏捷软件开发实践－估算与计划》（Mike Cohn著，金明 译）一书第四章的内容，感兴趣的读者可以在书中看到更多的详细内容。
看似很美好，问题出在哪儿？
如果一个工具能估快速有效的修正计划的误差，提高项目对变化的响应能力，那么这个工具当然值得被引入到敏捷实践中。然而现状是team依然承受着来自velocity的压力，好像只有那些有幸在 “愉快的敏捷实践乐园” 中工作的人们才会把速度当作均衡器来使用。但是我们不要忘记还有一位重要的角色，那就是客户——他们可不是乐园的股东。
Oh no，客户来了！
作为客户，首要天然的诉求当然就是追求收益，任何跟生产力相关的信息都会成为他们关注的重点。不得不说，相比在敏捷项目中作为“均衡器”的工具，“速度”更普遍的是作为度量生产率的工具而被广泛应用于众多行业和领域中。如果没有任何的解释，在客户眼中，velocity就是衡量team生产效率的度量工具，这很直观也很容易理解。在经历初期的几次迭代后，客户发现2个点的story，大概需要一对dev耗费两天的时间去完成。于是客户开始要求我们统计team的velocity，并且将velocity能否保持在一个恒定的水平上（其实更希望越来越高），作为验收team工作表现的主要度量维度。
那么很容易想象，当我们告知客户team的速度“下降”了，客户看到的不会是一个 “均衡器” 正在起调节作用，而是team “懈怠了”，于是在站会上，我们往往就会收到来自客户的质疑。
结果：均衡器 “失效” 了
应对客户的质疑，一个最简单有效的方法就是顺应客户的要求，用 “平稳的速率曲线”构筑起抵御客户质疑的边境长城。
当速度被期待恒定后，为了保证计划的有效，常见的 “承诺” 模式就代替 “均衡器” 起作用了，那么计划的误差则通过team不断提高估算的准确性来修正，故事变得越来越熟悉，于是一次超长时间的估点会议开始了。
点之殇：不只是“失效”
说了这么多，回到文章一开始提出的疑问：使用velocity的初衷真的是作为敏捷团队生产率表现的小鞭子吗？答案是否定的。那么“速度” 失去调节作用转而成为只专注度量团队效率是否会有副作用呢？这时候起码产生了两个困惑：
- 交付业务特性的优先级永远高于技术优化？
- 重构变成 “浪费时间” ？
都是客户的错？Any Action？
当我们认为上一节提到的那些 “副作用” 产生负面影响力时，我们常常会听到 “没办法，客户就是这么要求的” 这样看似无奈的声音。真的是这样吗？都是客户的错？
反思一下我们应对客户的方法，当我们努力去维护那条稳定的 “速度” 曲线时，站在客户角度去看，其实是在不断的向客户强化一个信息：Velocity＊时间＝工作量
然而我们知道，在软件行业这个等式是不成立的，我们并不是在做重复简单的体力工作，我们需要抵御的也不是客户的质疑，而是应该跟客户站在统一战线上，共同去应对外界不断发生的变化和知识工作本身带来的复杂度。而应对复杂度表现的度量，只依靠 “生产率” 这个单一的维度是远远不够的。
于是当我们去抱怨客户只看收益的时候，反过来想想我们是否为客户提供了更有价值的信息？那些有价值的信息是否都被那道高高的 “velocity” 曲线挡住了？ 是否能够构向客户展现其它更立体的维度来度量team的performance？
所以，“愉快的敏捷时间乐园”本来就不会存在，而客户也并不是那边境以北我们需要抵御的 “异鬼”。
