迭代和增量

1. 迭代和增量

“迭代”和“增量”是敏捷软件开发中的两个重要概念。弄清楚“迭代”和“增量”以及其依据，我们就可以在实际的操作中有章法可循。
  
  为什么要迭代？ 
  
 我们为什么要进行迭代开发呢？您一定遇到过这样情况： 
  
 “我们知道想要什么。但你能估算出构建它需要多长时间吗？” 
  
 “在启动开发之前，我们必须将这些需求明确下来。” 
  
 “客户不知道他们想要什么” 
  
 “客户时常改变想法”
  
 “我虽然不知道客户想要什么，但我却知道怎么得到它。”怎么得到客户想要的东西呢？——迭代！我们不指望我们所构建的软件正是客户（或用户）所想要的，但我们可以先构建后修改，通过多次迭代找到真正适合客户（用户）的软件。当然，我们必须保证我们初次确定的方案是正确的、行得通的，那么后继的迭代就是反复求精的过程，是不断地对备选方案改进并选择更优方案的过程，是以更优方案取代之前勉强行得通的方案的过程。
                                          
  迭代的依据 
  
 迭代开发的过程就是对软件功能不断细化的过程，所以，迭代的依据就是“功能细化原则”：必要性–>灵活性–>安全性–>舒适性/趣味性。
  
 必要性：能支持用户完成任务的最少功能特性；
  
 灵活性：支持用户使用多种方式完成任务或者支持用户做出额外选择的功能特性；
  
 安全性：为了避免用户犯错，确保用户在软件使用过程中所做操作安全的功能特性；
  
 舒适性/趣味性：就是可以使用户更简单、更快捷、更有趣地完成任务的功能特性。
  
 每个迭代可能包含多个用户故事，但是在同一个迭代中，我们对每个用户故事开发的完善程度是不一样的。如下图所示：
                                          
 随着软件开发工作的深入进行，我们会在每个用户故事中发现更多的功能可能是舒适性/趣味性方面的功能，也可能是必要的功能。或者，在软件开发的过程中，竞争对手的软件产品有了新的功能、市场销售情况有了新的反馈、用户有新的需求等，我们需要不断地丰富、细化我们的软件所支持的用户故事，增加/改善新的功能。经过多次迭代，我们就可以完成所有的功能，从多个层次（必要性、灵活性、安全性、舒适性/趣味性）满足用户需求、支持用户故事。
                                          
 在迭代过程中，功能的不确定性逐渐减小，我们对功能的描述越来越明确。
                                                                                  
  为什么要增量？ 
  
 不论是哪种类型的软件，其业务目标或用户（用户目标）一旦确定下来，我们都会为此准备好“理想”的解决方案和实现手段。但是，项目工期是有限的，资金预算也是有数的，人手也不可能无限增加。为什么项目工期总是很短？资金紧张？人手不够？因为我们“理想”的解决方案是需要很大的代价的！并且，“理想”的解决方案也有很大的风险：在这么漫长的“完美”解决方案实现过程中，市场情况、用户需要等外部因素都会发生改变；不及时发布、不从市场/用户处得到及时的反馈，我们“理想”的解放方案是否真的完美也就无法得到验证。如果说迭代开发是为了应对软件产品内部的不确定因素的话，那么，增量地发布软件产品，为的就是应对软件产品之外的其他不确定因素。
                                          
  增量的依据 
  
 既然增量地发布软件产品是为了应对软件产品之外的不确定因素，那么，我们确定增量发布版本的过程，也就是项目风险控制的过程。在确定版本计划的时候，我们采用什么样的尺度呢？考虑的太粗，我们的版本规划就不会太准确，在项目实施的过程中，就会存在较大的风险；“那我们就多考虑点”，要想考虑的很周到，我们必定会在规划上花太多的时间。这其中的“度”在哪里呢？我们首先并且只会想到的就是对功能的优先级进行排序，然后看情况，到项目工期截止的时候，我们的功能完成多少我们就交付多少。Yes，我们大多数的软件项目就是这么死的，都是在产品发布日的时候给它开追悼会！
  
 按重要程度办事，有错吗？让我们打个比方吧，我们要造一辆轿车。先对轿车的功能物件排序：发动机、车底盘、传动轴、车轮子、刹车、方向盘……。车迷朋友们还会列出更长、更详细的按优先级排序的轿车功能清单。有半年的工期，我们头一个月造了个发动机，不错很好很强大的发动机，第二个月，我们不但按计划把车底盘搞定了，还有1周的时间，我们可以提前把传动轴也弄弄……（黑底白字的电视屏幕上淡入又淡出几个字“4个月后……”）还有1个月就要交付我们的轿车了，我们的车轮子怎么上不好啊？方向盘也不转，对了，还有挡风玻璃也没弄，车门还没把手，转向灯能亮，但是它们前后左右4个一起亮……马上，半年的交付工期到了。我们“预想”的完美轿车出厂了：绝美的流线型、强劲的引擎动力、4轮驱动、XYZ安全系统，可是、可是、、、昨天说安装的挡风玻璃怎么没安啊，好办：在领导验收之前还来得及蒙一块塑料布！想必，这么“拉风”的轿车，定会被老板拍死、被客户拍死。
  
 现在，有点明白了吧，来感觉了？对，我们可以按照重要程度来做事情，但是，在全部必要的功能全部实现之前，你我所实现的再重要的功能都无人买单，无法体现其价值。这也是在做软件需求工作时，普遍存在的问题：功能考虑的很多、优先级排的挺有水平、对每个功能的描述也很详尽，但是，各个功能各自为战、不成体系，甚至还缺少许多必要的功能，所以，我们软件产品的用户就因此疯掉了，由此也引发了众多无聊的忧国忧民的砖家们来“反思”这样的话题：“科技创新是否真正改善了人类的生活”。（善哉，善哉，我又不小心提到“砖家”这么不吉利的人物了）
  
 规划版本时，在第一个版本中，我们必须实现所有的“必要性”功能，否则，我们的软件是无法体现出价值的。在之后的每个版本中，我们都要参考“功能细化原则”，使得我们的软件产品的所有功能都达到相同的用户体验水平。（关于用户体验的“境界”，我们会在UCD思想中作详细的介绍）如果每个版本中的各功能的用户体验“境界”不一致，很容易出现“用塑料布当挡风玻璃的豪华奔驰轿车”。我们可以用如下图所示的“版本地图”的形式来展示软件产品增量发布的依据——版本计划。
                                          
 当然，我们也会在完成前一个软件版本后，发现新的市场/用户需求，新增用户故事。增量版本发布的过程，如下图所示：
                                                                                  
  小结：迭代vs.增量 
  
 要想比较彻底地理解“迭代”和“增量”，我们最好将其对比一下。
  
 迭代，就是在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程；而增量，则是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。二者的对比如下图所示：
                                          
 This entry was posted on 星期日, 07月 26th, 2009 at 22:30 and is filed under Agile, 指导思想. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2. 迭代模型的优缺点是什么

迭代模型的优点 
传统的瀑布模型相比较，迭代过程具有以下优点： 

　　1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。 

　　2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。 

　　3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。 

　　4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。 

缺点是：在项目早期开发可能有所变化 ，需有一个高素质的项目管理者和一个高技术水平的开发团队

3. 增量和迭代的区别

　　今年一月的时候，PBA群里有同学在问增量和迭代这2种模型的区别，确实，书中多次提及这2个词语。
  
  
 　　软件生命周期的选型，是软件项目开始的第一要务，这2种模型有一定的相通之处，也容易混淆。所以下面针对这2种模型的异同，进行一个简单地分析，以期和大家交流一下心得。
  
 　　这2种模型都是从功能的分期交付角度出发进行设计的。
  
 　　增量，就是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。
  
 　　而迭代，就是在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程。
  
 
  
 
  
 
  
 
  
 增量模型
  
 迭代模型
  
 需求
  
 确定的
  
 不确定的
  
 交付方式
  
 强调功能数量的分时交付
  
 每次交付的功能质量相同
  
 
  
 强调功能质量的分时交付
  
 每次交付的功能质量不同
  
 
  
 周期划分
  
 
  
 增量模型
  
 迭代模型
  
 需求
  
 确定的
  
 不确定的
  
 交付方式
  
 强调功能数量的分时交付
  
 每次交付的功能质量相同
  
 
  
 强调功能质量的分时交付
  
 每次交付的功能质量不同
  
 
  
 周期划分

4. 迭代模型的介绍

 对众多的开发模型和过程方法，及权威机构的看法，企业应选择什么样的开发模型，应慎重对从以下几方面进行考虑：1、RUP虽然内容极其丰富，定义了选起、精化、构建、产品化4个阶段和业务建模、需求、分析设计、实现、测试、部署等9个工种，提供了一大堆的文档模板，但极易让人误解是重型的过程，实施推广有一定难度。2、再次，在质量管理方面：以实现系统架构、核心功能目标的迭代产品生的工作成果作为质量控制重点。每次迭代进行系统集成、系统测试，达到对软件质量的持续验证。每次系统测试，需要回归测试前一次迭代遗留发现的问题。每次迭代发布的小版本组织客户（包括内部客户、外部客户）进行评价，通过演示操作等方式，评价该次迭代是否达到预定的目标，并以此为依据来制定下一次迭代的目标。3、最后，在其他方面：每次迭代成果须进行配置管理，版本控制很重要。在整个迭代过程中风险无处不在，建议每周作一次风险跟踪。同时通过重点关注进度、工作量、满意度、缺陷等数据收集，关注每次迭代情况。总之，选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项目的成功是至关重要。企业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。 与传统的瀑布模型相比较，迭代过程具有以下优点：1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。3）加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

5. 迭代模型的使用条件

1、在项目开发早期需求可能有所变化。2、分析设计人员对应用领域很熟悉。3、高风险项目。4、用户可不同程度地参与整个项目的开发过程。5、使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。6、使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。7、具有高素质的项目管理者和软件研发团队。

6. 迭代模型的介绍

早在20世纪50年代末期，软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型（stagewise model）”。迭代模型是RUP推荐的周期模型。被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。