对于我来说，敏捷开发最吸引人，但是又没有明确说明的部分，就是去分析设计正好合适的要完成的工作量，从而使得我们能开始工作。你可以在需求梳理和在垂直 功能部分的概念中找到具体例子。 “明白一点，再做一点，再明白一点，再做一点”大多数情况下这都是很有效的，这种概念是最为基础的，当最终我真正明白他的含义的时候，它让我顿时茅塞顿 开。但是，明白了这个概念之后，我发现我自己又在另一个问题中挣扎。
为什么我们要花费多余的精力和金钱，去做那些过于精确的估计（准确来说是几个小时或者几十分钟）？去估计那些无论我们投入多少都不可能被完美定义的特性？
参考下面两句话：
1. ASTM A36型钢铁的（最大）张力是2.5亿帕斯卡。
2. 想要达到标准的鳕鱼角式房屋的美化标准，需要在屋外使用12加仑的浅棕色颜料，在室内使用20加仑的蛋壳涂料。
第一句话中，我们有一个非常详细的材料描述（A36型钢铁）和一个很清楚准确的性质测量量（2.5亿帕斯卡）。如果你的客户都明白A36是什么意思的话，他们就都会承认这份材料的所有细节。不管你拿它建什么，怎么建，A36就是A36。
不 过，在第二句话中，我们是想达到“标准的鳕鱼角式房屋”的“美化标准”。什么是“标准的鳕鱼角式房屋”？什么又是它的“美化标准？”你所有的顾客都会得到 完全相同的结论吗？一旦你开始涂颜料了，会不会有可能“美化标准”会改变呢？考虑到这些可能性，我会事先买下正好32加仑涂料吗？你会提前付款买好涂料然 后开工吗？
非常不幸的是，在软件工程中，很多时候的答案是肯定的。我们每天都错误地做出（或者被迫做出）这些承诺保证。我们发现自己想确定那些不 可能确定的问题，当我们错了的时候，我们就要付出代价。更差劲的是，我们经常把这种风险通过“变更请求”的方式转移到客户身上，最后双方妥协重新来过。
在几乎所有的特色开发案例上，事实很简单——在我们没有开始建造之前，就连客户也经常不知道他们究竟想要什么。
要 是用敏捷方法来想第一句话中的例子，我会大概估计需要30到40加仑涂料，不过一开始我只会买几加仑，然后把屋外的墙涂好一部分。接下来我们可以询问客户 感觉如何。当客户决定要做出些修改的时候，我们也可以很简单地改变一下原计划，再次更精确地估计一下需要，然后再买更多合适的涂料。在我们一步一步接近完 成的时候，我们会有一个更精确的估量，因为我们已经非常了解客户想要什么了（有些讽刺的是，这时候客户也更了解他们自己究竟想要什么了）。当我们完工的时 候，客户应该就会得到他们想要的效果了——虽然可能并不是他们一开始想到的。
在现今的软件领域，用户的经验变得更加重要，更加复杂，也更加易变。 当客户们只有一个大概的想法的时候，他们基本上一点都不清楚究竟想让它如何如何。在这些情况下，没有人能准确地预见成品会是什么样。我推荐在sprint 期间开几次需求梳理会议，这样能够让我们更加明确客户所需，对下一次sprint的内容也更加了解。如此一来，在Sprint计划会议上，Scrum团队 就可以多注重他们该如何建造东西，而不是注重它的含义是什么。
Scrum内含的“检查和改善”回馈表就是为了能够及时了解客户的最新需求。想要成 功的话，随着我们更多的了解，我们的估计就应该从一开始的不准确到越来越准确。过程中类似“估计Story point”、“story限制”和“需求梳理”等都是很重要的步骤，如果不能说是必要的话。
我们在这种环境中对待客户的方法也需要改变，但是本文中不会讨论这些范畴。
考虑到story估计更倾向于形式和风格的美学观念，而不是一些什么张力数据。一味地追求准确和详细数字不会把我们引领向这种美学观念，我们应该估计，建议，然后建造、精确，一点一点把头脑所想变为现实，小心谨慎，直到最后的完成。
原文地址：http://www.scrumalliance.org/articles/331-the-illusion-of-precision
菜单
菜单
