可变的范围规约
Kent Back,First Class Software
Dave Cleal
用户现在就可以得到他们在项目结束时所要得到的东西，在他们学习以后，取而代之的是在项目开始时得到他们所想要的。
引言
“请计划一个系统以满足附件的需求规约、指定的交付日期和总共的开销”，这句话足以使程序员的心中感到兴奋或是恐惧。兴奋－如果你拥有被提议系统所在领域中的技术优势和经验，你就可以远离那些每天都存在的超支现象。恐惧－因为一旦一个固定的价格规约变得失败，完全失败，你最期望的将是紧张的商业会议，无法挽回的损失，声誉受损，或者一场诉讼官司将是最糟糕的。
Kent的经历
在smalltalk早期鲁莽的商业化过程中，我得到一份合同，交付一个电子表格产品给华尔街的投资银行。对于所涉及的东西我不能保证百分之百正确，但我确信我可以在六个星期内完成它，我和我的长期合作者Ward Cunninghum一起进行了两天的封闭式开发，最后基本完成了，我又用了两天或三天来进行一些细节上的修补，在虚度了四个星期之后，我们提前一个星期交付了产品，客户非常满意的和我签订了一份长期的合同。
这一次我非常兴奋，我又找了一个程序员来适应这些变化，这并不困难。随着时间的推移我慢慢的适应他，他似乎作的很出色，然而，在最后期限前的一个星期，不好的征兆出现了，然后，在最后期限的前两天，我接到一个电话，“对不起，我在医院，我得了阑尾炎，我都快被药给塞满了，希望一且还好。”
天呐，我的代码还差很多，在最终期限前的48小时的马拉松式的开发中，产品完成了，不用说，第二次交付的产品质量无法赶上第一次的，客户也不满意。
固定范围规约
上面的例子说明“固定范围规约”的利弊，全部的一个固定的成本/日期/范围规约以减少项目来自于供需双方的风险，最大的风险就是软件的实现要比预期来的要难，如果这个风险没有发生，供应方将获利，这样的规约是非常有利的，如果最坏的情况发生，无论如何，供应方处在这样的位置－损失大量金钱，终止合同或在极大的损失下完成软件。
固定的成本/日期/范围规约是存在的，因为它似乎服务于客户和供应商双方的需要，看起来客户将得到：
l 可预见的成本
l 可预见的交付
l 可预见的进度
供应商将得到：
l 可预见的收入
l 可预见的需求
这样的一副画面有什么毛病？刚开始，唯一可预见的部分就是客户付给供应商的钱，但是当某一个特征变的比预期难以实现时都发生了什么？客户或许不会再付给供应商更多的钱，但是如果工作完成的缓慢或基于一个较低的标准，接下来客户间接的开支将是巨大的。更糟的是，当有人意识到这个特征并不像预想的那样有价值，或者环境改变了优先级决定的最初的范围。重新开始谈判是非常困难的，要么暂时搁置起来，直到软件的下一个版本再解决，当这个版本发布时每个人都知道它并没有满足真正的需求。
或许供应商有可预见的需求，但是如果他们明白一旦需求变得错误，他们将面对一个不怎么让人羡慕的选择，他们或者进行额外的无偿劳动，或者进行激烈的争吵－对于规约的细节，好一点的将会失去客户，最糟糕的就是去请律师。
根本的问题就是一个固定的成本/日期/返回规约使供需双方都陷入与对方进行直接对抗的乐趣中，双方都为自己考虑。
|
客户 |
供应商 |
|
尽可能广泛的解释需求，以从他们所花的钱中得到更多 |
尽可能精确的解释需求，以节约成本 |
|
希望工作尽早结束 |
希望工作能够按时完成，以便为下一个合同争取时间 |
|
期望最高的质量 |
只要有足够的品质以是客户愿意付钱。 |
|
程序员的劳累不关我的事，除非他们威胁到交付 |
希望小组成员在这个项目中成功，而且在下一个项目中也一样 |
我们所需要的是一个不同的规约以使双方处在相同的位置上，项目管理中的四个可变的要素是：
l 时间
l 成本
l 范围
l 质量
固定范围规约在这四个中详细说明了三个：
l 时间
l 成本
l 范围
另一个要素－质量，在许多合同中留下了挥之即去的小麻烦，但它并没有给客户任何感觉，无论短期或长期，只要在事情明显已经结束后告诉“真正”的使用者，在短期内，他们需要一些东西来开展工作，而且非常急切。他们将找到一种方式生活－在没有复杂的报告和每月一次的形式（可能是会议或总结报告）的情况下。这并不象他们今天那样。在长期内，虽然他们将需要变化，软件将变得易于维护。
固定范围和质量
为什么不详细说明所有的四个要素？事实上，这是许多项目开始的方式。程序员时间上更喜欢作高质量的工作。所以他们常常制定一些漂亮的高标准。一个似乎是无法避免的事情发生了，引发冲突的是程序员开始努力工作，可怜的经理赞同他们这样作，而精明的经理在把这种行为看作是前面的困难的一个警告。最终，人类的精力达到极限，一些事情作出让步。有没有一个程序员告诉经理他们将错过星期五的最后期限？没有，因为可以找到许多方法完成这个如此紧张的最后期限：
l 宣布软件已经完成，尽管你知道它并没有捕捉到所有的情况。
l 不再浪费时间去进行测试
l 发表第一个版本以代替进行重构使软件更易于维护和理解。
l 通宵奋战直到你看不到能够作到最好的希望。
当四个要素都被详细定义，质量是第一个需要去面对的，因为他是最不可见的，或者，它是在软件交货前最不可见的。
可变的范围规约
如果固定的时间，范围，成本没有起作用，而且固定的四个要素都没有工作，怎样重新进行组合？如果我们已经固定了些什么：
l 时间
l 成本
l 质量
而且使范围变得不确定？而且我们使规约变得短小？
规约看起来会象这样：
接下来的两个月里我们将付给团队每月75000美元，无论他们交付一个什么样的软件，接下来他们将面对一个已经打印出来的质量标准。在附录A里有一些最初的估计，但是他们却认为这只是在开玩笑。
这是一个不可能的工作，客户并不知道他们将从他们的150000美元中得到些什么，供应商将会吊儿郎当的打发掉两个月的时间，然后作出一个漂亮的登录界面。
首先，这并不可能发生，供应商需要长久的声誉，如果所有的项目都拖到年底，供应商将在第一个合同后得到1/6的钱，在所有的情况里，我们尽量保持规约简短，所以客户在他们发现进展是否相当的快之前他们那两个月的钱是危险的，关于特征的最初的估计和一点数学知识就会给客户一个漂亮的好主意，这些他们都可以用在下一个规约中。
再者，当对需求的理解变得错误时都发生了什么？双方应该改变方向，供应商没有理由不作出反应，因为现有软件的废除不影响他们获得合同的能力。
让我们再来看看那些不同的乐趣：
|
客户 |
供应商 |
|
尽可能广泛的解释需求，以从他们所花的钱中得到更多 |
乐意接受客户改变对需求的说明 |
|
希望工作尽早结束 |
希望按时交付，乐意去达到尽可能的功能性，而且没有质量风险 |
|
期望最高的质量 |
质量是第一位的 |
|
想让程序员在下一个“两个月”中再回来 |
希望小组程序在这个项目中成功，而且在下一个项目中也一样。如果这是一个长达一年的合同，供应商在第一个合同完成后只能得到1/6的钱。 |
我们看到了更多的共同的目的，现在最有可能发生的冲突是供应商检查提高质量，而心急的客户希望将所以的东西都放进一个特征里。
固定非范围规约有下列好处：
客户将得到：
l 可预见的成本
l 可预见的交付
l 可预见的进度
供应商将得到：
l 可预见的收入
l 可预见的进度
可变的范围规约保留了这些益处，除了可预见的交付。客户对于在一开始得到的东西有合理的想法，但是现实很快的介入。他们得到的将是无法避免的困难－来自于他们一开始的想像。放弃控制一开始规约里的范围的幻想，他们加入了一些更有价值的东西，以代替他们在项目开始时所希望得到的。他们现在就可以得到他们在项目结束时要得到的，在他们完成了这个学习过程之后，他们将学会去期望无法避免的困难－来自于他们在规约一开始所想像的。
更重要的是，无论如何，可变的范围规约使质量成为固定的。团队将在固定的时间，固定的报酬下工作，以达到客户所要求的质量水平，不存在“已经完成了80％”，80％对于原先所想像的特征来说或许是完成了，但是对于他们中间的每一个人来说，都要做到100％，并且是由自动测试证明了的。
固定范围规约的一个重要的特征就是它并非由可变范围规约拷贝而来，供应商无法完成工作，在所有时间的议案下。如果供应商提前完成，他们会要求更多的工作，无论如何，可变范围规约对客户更有利，当拥有一个可变的范围规约是，我们可能会拥有额外费用的负担能力，因为我们所乐意接受的可能的利益是非常有价值的。
记录需求
好了，现在让我们想像一下将这个方法卖给供需双方，现在他们被锁在一个把功能需求排除在外的规约里。供应商现在可以开始进行的开发是什么？显然，我们仍然需要一些方法来记录需求，怎样才是合适的形式？
这个规约有一个，也是唯一的局限就是我们不能期望由用户来给我们递交“需求”，我们需要有需求来开始工作，这比我们意识到的还晚，所有我们需要使我们的需求以“块”的形式被记录下来，而且我们需要客户来确定这些“块”的优先顺序。
优先顺序列表可能会以不同的方式记录下来，但是每一个条目都必须描述出某些客户愿意为之付出的东西。有的人把这称作“用例”，有的人把这称作“用例的设置”，还有称作“故事”的，在这里我们用“故事”，这到底有什么重要的东西？
l 程序员必须有能力去想像怎样去检查系统确实实现了“故事”，自动测试用例是这类检查的一种简短而且客观的机制。
l 程序员必须有能力去估计这个“故事”将需要多少努力以及所有的相关联的“故事”，没有估计，客户不会有做出完备的优先顺序的决心。
l “故事”对于系统的使用者必须是可以理解的，如果客户比较这个“故事”和其它“故事”的优先顺序，他们会觉得物有所值。
l 我们必须有能力在时间允许的范围内写出更少或更多的代码，所有，小的“故事”是更好的，因为他们使开发工作成为平行的，而且我们可以使用所有可利用的时间，我们的规约迫使供应商交付高质量的软件，部分未完成的“故事”将不在交付的软件内，所以一个过大的“故事”就冒着投入了许多却未得到任何回报的风险。
现在在软件工程领域有一种趋势，试图在开始编写代码前尽可能的固定尽可能多的信息，以避免大量的下游成本，如果我们知道如何维持软件的适应性，无论如何，我们都会在30000英尺的高空跳伞前看看情况。
结论
这里有一些特征可以使可便的范围规约变得有价值：
l 客户将会改变他们的想法。
l 供应商在某些事情变得错误时不再鼓励牺牲质量。
l 供需双方的兴趣都是使双方变得平等。
l 双方的一个观点就是项目的“过程“能够影响到最终的产品。
所有的这些都围绕着管理的变化，想像一个在开始时客户就知道所有与问题有关的东西的项目，供应商作过一打类似的项目，双方都知道在项目过程中都不会有什么令人惊奇的事，也不会学到些什么。这个项目将不会加入来自任何机构的东西，而且传统的模式是最好的。
但是如果不是这种情况，在项目过程中将会出现一些意向不到的事。当这些发生时，你将希望供应商和客户一起去解决这些问题，而且你想要有能力去改变项目的形式以反应新的现实。在这种情况下，考虑可变的范围规约。
而且，再根本一些，可变的范围规约将使你不再需要意见－对于显而易见的事。我们将在什么时候完成，在许多的循环后我们开始启动，我们最终想从系统中得到什么？非确定的：我们将安排那些已经经过编码的很显然的东西。可变的范围规约使程序员做有用的提高以在对某些他们还并不是足够了解的东西推迟作决定。
与开发中的一个可变范围规约相关联的是对传统软件开发策略的挑战。
l 演化的设计：你不会投资在一个你用不到的特征上，所以你无法一次就完成所有的分析和设计。你可以准备在整个开发过程中使分析和设计不断的进行演化。
l 演化的提交：当你还在等待一个特征来解释自己的时候你不会投资在这个你还用不到的特征上，你必须先在产品中有一个系统，而且在你支持这个正在运行的系统时继续实现特征。
l 内在的和外在的质量：你期待改变系统，所以你在质量上投资以重写系统－贯穿整个项目而且对于重写和重新测试没有限定的成本。
l 自动化测试：当你完成了一个特征，你必须证明它已经结束了，而且如果你想要保证他不会出错，自动化测试可以为你证明。
如果可变范围规约的最大阻碍可能就是程序员们不相信客户会愿意接受这样一个规约，如果一个客户对于他和供应商直接的关心感到满意，这或许是，当然也是可行的，真的。无论如何，如果客户和程序员都不满意，有些东西将会改变。可变范围规约加入了有利的合适的环境，同时给固定范围规约添了一些麻烦：含糊不清和变化的需求。
