神马文学网迭代和增量以“急你所需”
来源：百度文库 编辑：神马文学网 时间：2024/04/28 20:34:12
作者 Geoffrey Wiseman 译者 苑永凯 发布于 2008年1月24日 上午6时46分
在《我虽不知想要什么，但却知道怎样得到它》一文中，Jeff Patton谈及了敏捷团队与商业用户在沟通中造成彼此误会的几个方面，并主张敏捷社区应当正确的使用术语“迭代（iterating）”、“增量（incrementing）”和“可交付（shippable）”。
Jeff在文中首先罗列了一些句子，来凸显对商业用户和软件开发团队更准确的阐明迭代概念的必要性。
- “我们知道想要什么。但你能估算出构建它需要多长时间吗？”
- “在启动开发之前，我们必须将这些需求明确下来。”
- “客户不知道他们想要什么”
- “客户时常改变想法”
接下来，Jeff记述了迭代和增量两个截然不同的概念——虽然两者常常被混为一谈，但都被敏捷团队用于交付价值（deliver value）——以及使用它们的原因。
就增量开发来说，我的意思是每次递增的添加软件功能。每一次增量都会添加更多的软件功能——这与往墙上添砖加瓦有几分相似。在多次增量之后，你将得到一面大墙。
- 我们使用增量法逐渐地增进功能，那么如果开发花费的时间多于预期，我们可以将迄今为止已经增量构建的功能发布出去。（之所以使用黑体的“如果”，是因为我实在不记得有哪个我参与过的项目开发花费的时间少于预期。）
- 增量地释放版本，所以我们可以实际地得到我们已创造的商业价值。因为在人们开始使用我们构建的软件之前，我们是不会真正地得到投资回报的。在那之前，预期的商业价值只是一种估计。如果你认为估算软件开发是困难的，那么就尝试估算投资回报率吧。
对迭代开发的描述如下：
我对迭代开发的理解是我们构建软件，然后评估它是否能够正常的工作，然后对其作出修改。我们构建软件然后期望对其作出修改。我们从不指望构建结果正是所需的。如果是的话，那这是一个幸运的意外。正因如此，我们至少要做到常常构建，然后校验其构建是否是正确的。
- 我们通过迭代找到正确的解决方案。
- 然后给出一些好的候选方案，可能而后我们在迭代中改进某个候选方案。
在敏捷开发中，当没有人计划迭代时，那么一切都会瘫痪。
他接着争论道，术语“可交付”的使用进一步混乱了局面：
对于想要出售或者使用软件的客户，可交付就意味着他们可以明确地出售或者使用软件。这意味着软件要保证最小功能集可用。软件必须达到计划中的目标——至少 要做到与旧软件或者被替代的文件流程功能相同。软件必须有良好的外观和功能——保证高质量的精确度和完整度（fit and finish）——特别对于商业软件，而你的竞争对手正在对你造成威胁。
可交付意味着已经完成了。彻底地完成并扫尾。不再需要为一些事情进行迭代——真正的可交付了。
对客户们说“可交付”就意味着暗示他们最好确保提出的需求都是正确的，因为这就是敏捷开发工作的方式。
那么，为了帮助客户理解迭代的含义，他建议：
我们应该对客户和产品所有人（product owner）解释说，将那些他们不打算发布的需求写到用户故事（user story）中也是重要的。将他们打算评估、学习、改进或者作为失败的实验品丢弃的需求都写到用户故事里。
在与我的朋友Alistair交谈中，他提议为每个需求编写三份故事卡片而不是一份。第一个故事卡片上描述了真实的故事。第二个卡片是为了我们了解故事之后作出不可避免的修改而准备的。第三个卡片用于修改之后的微调。这是一个规划迭代的例子。它能缓解客户大部分的压力——由于担心其描述的故事是否正确（因为必须保证这些故事“可交付”）而极度苦恼、战战兢兢。
他还创造了一个新的缩写词：“YAGRI：你将不会发布它（You aint gunna release it）”。
Patton风趣地说：“在一次演讲中同时引用到Johnny Rotten、Roger Waters、Paul Simon、Pete Townsend、John Lennon和辣妹，是非常难得的。”这是篇有趣的文章，他鼓励读者去参考他的blog文章，或者下载最初的带有或者不带有音乐剪辑的演讲稿并使用它，当然是在注明出处的前提下。查看英文原文：Iterating and Incrementing to 'Get What You Need'