迭代vs增量资料讲解.docVIP

迭代vs增量 精品文档 精品文档 收集于网络，如有侵权请联系管理员删除 收集于网络，如有侵权请联系管理员删除 精品文档 收集于网络，如有侵权请联系管理员删除 迭代和增量 “迭代”和“增量”是敏捷软件开发中的两个重要概念。弄清楚“迭代”和“增量”以及其依据，我们就可以在实际的操作中有章法可循。 为什么要迭代？ 我们为什么要进行迭代开发呢？您一定遇到过这样情况： “我们知道想要什么。但你能估算出构建它需要多长时间吗？” “在启动开发之前，我们必须将这些需求明确下来。” “客户不知道他们想要什么” “客户时常改变想法” “我虽然不知道客户想要什么，但我却知道怎么得到它。”怎么得到客户想要的东西呢？——迭代！我们不指望我们所构建的软件正是客户（或用户）所想要的，但我们可以先构建后修改，通过多次迭代找到真正适合客户（用户）的软件。当然，我们必须保证我们初次确定的方案是正确的、行得通的，那么后继的迭代就是反复求精的过程，是不断地对备选方案改进并选择更优方案的过程，是以更优方案取代之前勉强行得通的方案的过程。 迭代的依据 迭代开发的过程就是对软件功能不断细化的过程，所以，迭代的依据就是“功能细化原则”：必要性–>灵活性–>安全性–>舒适性/趣味性。 必要性：能支持用户完成任务的最少功能特性； 灵活性：支持用户使用多种方式完成任务或者支持用户做出额外选择的功能特性； 安全性：为了避免用户犯错，确保用户在软件使用过程中所做操作安全的功能特性； 舒适性/趣味性：就是可以使用户更简单、更快捷、更有趣地完成任务的功能特性。 每个迭代可能包含多个用户故事，但是在同一个迭代中，我们对每个用户故事开发的完善程度是不一样的。如下图所示： 随着软件开发工作的深入进行，我们会在每个用户故事中发现更多的功能可能是舒适性/趣味性方面的功能，也可能是必要的功能。或者，在软件开发的过程中，竞争对手的软件产品有了新的功能、市场销售情况有了新的反馈、用户有新的需求等，我们需要不断地丰富、细化我们的软件所支持的用户故事，增加/改善新的功能。经过多次迭代，我们就可以完成所有的功能，从多个层次（必要性、灵活性、安全性、舒适性/趣味性）满足用户需求、支持用户故事。 在迭代过程中，功能的不确定性逐渐减小，我们对功能的描述越来越明确。 为什么要增量？ 不论是哪种类型的软件，其业务目标或用户（用户目标）一旦确定下来，我们都会为此准备好“理想”的解决方案和实现手段。但是，项目工期是有限的，资金预算也是有数的，人手也不可能无限增加。为什么项目工期总是很短？资金紧张？人手不够？因为我们“理想”的解决方案是需要很大的代价的！并且，“理想”的解决方案也有很大的风险：在这么漫长的“完美”解决方案实现过程中，市场情况、用户需要等外部因素都会发生改变；不及时发布、不从市场/用户处得到及时的反馈，我们“理想”的解放方案是否真的完美也就无法得到验证。如果说迭代开发是为了应对软件产品内部的不确定因素的话，那么，增量地发布软件产品，为的就是应对软件产品之外的其他不确定因素。 增量的依据 既然增量地发布软件产品是为了应对软件产品之外的不确定因素，那么，我们确定增量发布版本的过程，也就是项目风险控制的过程。在确定版本计划的时候，我们采用什么样的尺度呢？考虑的太粗，我们的版本规划就不会太准确，在项目实施的过程中，就会存在较大的风险；“那我们就多考虑点”，要想考虑的很周到，我们必定会在规划上花太多的时间。这其中的“度”在哪里呢？我们首先并且只会想到的就是对功能的优先级进行排序，然后看情况，到项目工期截止的时候，我们的功能完成多少我们就交付多少。Yes，我们大多数的软件项目就是这么死的，都是在产品发布日的时候给它开追悼会！ 按重要程度办事，有错吗？让我们打个比方吧，我们要造一辆轿车。先对轿车的功能物件排序：发动机、车底盘、传动轴、车轮子、刹车、方向盘……。车迷朋友们还会列出更长、更详细的按优先级排序的轿车功能清单。有半年的工期，我们头一个月造了个发动机，不错很好很强大的发动机，第二个月，我们不但按计划把车底盘搞定了，还有1周的时间，我们可以提前把传动轴也弄弄……（黑底白字的电视屏幕上淡入又淡出几个字“4个月后……”）还有1个月就要交付我们的轿车了，我们的车轮子怎么上不好啊？方向盘也不转，对了，还有挡风玻璃也没弄，车门还没把手，转向灯能亮，但是它们前后左右4个一起亮……马上，半年的交付工期到了。我们“预想”的完美轿车出厂了：绝美的流线型、强劲的引擎动力、4轮驱动、XYZ安全系统，可是、可是、、、昨天说安装的挡风玻璃怎么没安啊，好办：在领导验收之前还来得及蒙一块塑料布！想必，这么“拉风”的轿车，定会被老板拍死、被客户拍死。 现在，有点明白了吧，来感觉了？对，我们可以按照重要程度来做事情，但是，在