当敏捷团队遇上固定价格合同.pdf

Collected by Harrison.Ma 2010-09-06 当敏捷团队遇上固定价格合同 作者 Marcin Niebudek 译者 鲍央 发布于 2010年8 月27日 上午12 时0分 固定价格合同很有害，这是敏捷实践者经常说的。从另一个角度来说，这些合同 是很多敏捷团队必须面对的现实。但是，如果我们试着去驯服它而不是去反对它， 那结果又会如何？一个公司如何用敏捷实践执行这种合同来达到更佳效果和更 低风险？这篇文章试图回答这些问题。那让我们从合同本身开始。 固定的价格、时间和范围 固定价格合同同时冻结了全部三个神奇因素：资金、时间和范围。资金和时间对 敏捷团队来说是个问题吗？应该不是。事实上，时间盒是很普遍的敏捷实践。限 制资金投入只不过使时间盒工作得更好而已。 固定价格合同的真正问题是范围，需要构建的东西也是固定的，而不是可以选择 构建的范围。 为什么客户这么执着于固定范围？我们理解他们想知道他们需要付多少钱（谁都 想知道）以及什么时候可以交付。他们唯一不知道的是自己真正想要什么（即使 他们坚持说他们知道）。 固定范围的根本问题是：  签约人互相之间缺乏信任  缺乏对软件开发流程的理解  对范围的误解 每份固定价格合同都伴随一份文档，类似于“需求分析”之流。这份文档试图降 低忘记重要事件的风险，也试图建立需要完成事件的共同理解，让人们产生存在 可预测性的假象。 固定范围的关键错误假设是：  前期的范围定义越仔细，我们越能彼此理解  定义良好的范围可以防止发生改变  范围需要固定，以便更好地预估价格和时间 从固定范围转移到固定预算 敏捷思维方式的应用和固定价格合同的主要差异在于固定范围，如果我们理解了 这一点，那我们就可以把焦点从固定范围转变为固定预算上。 - 1 - Collected by Harrison.Ma 2010-09-06 这意味着我们需要使用用户故事形式，捕获尽可能多详细需求规范，而不是提供 它们。我们需要构建一个初始的产品待办事项列表，然后尝试用故事点技术和诸 如规划扑克这样的团队整体预估技术进行预估。 首先，我们需要理解：软件需求规范中的更高层次细节对合同双方意味着完全不 同的东西。软件公司通常会专注在技术细节上，而另一方则会更注重业务导向。 规范通常由软件公司制定，会很有保护性。这是三个关键因素发挥作用的舞台。 用户故事，作为表达需求的一种方法，同时能被客户和供应商理解。这种理解能 建立信任和共同的远见。用户故事可以快速写出也能快速消灭，特别是写在索引 卡上的用户故事。它们同时也是特征功能驱动的，所以能对实际项目的范围提供 很好的参考。我们也可以比较它们的大小和工作量。 故事点数，作为估计故事的一种方法，在开始阶段给客户解释起来更难，因为这 不是表达工作量的常用方法。但是从回报看来，使用故事点数降低了低估范围的 风险。如何做到的呢？故事点数从本质来说是相对的，着眼点放在整个范围或者 一组故事。而传统的估计（通常以“人-小时”做单位）试图逐个功能单独分析。 “完成”的定义，是另一种建立信任的方法，使双方对流程和今后项目计划有共 同的理解。通常这会是客户第一次看到用户故事。虽然他们也许会喜欢这种写故 事的方法，但是如何实现故事却并不明显。要和客户一起讨论“完成”的定义的 团队更了解客户的期望。它们也能更好地被估计。另外，从客户角度来说，“完 成”的定义建立了验收用户故事的高层标准。 比如说，对一个新建网络应用的故事，“完成”的定义可能引入以下标准  在IE 7/8、Firefox 3.x以及Chrome里做过测试  在“用户指南”里有相应的章节 之后，团队可以在“完成”的定义中加入其他偏重技术实现的元素。不过在建立 合同阶段，概要指导在客户和团队间提供了共同理解的基础，为在选定范围内需 要做的工作达成共识。 希望在有了“完成”的定义之后，我们可以给出一些价值，体现为以点数定义预 算范围。而这价值，不是价值背后的用户故事，是在合同中需要确定下来的第一 件事情。这使变化变得可能。 虽然我们（