预计阅读本页时间：-
17.使用短迭代，增量发布
“我们为后面的3年制定了漂亮的项目计划，列出了所有的任务和可交付的时间表。只要我们那时候发布了产品，就可以占领市场。”
统一过程和敏捷方法都使用迭代和增量开发。使用增量开发一次开发应用功能的几个小组。每一轮的开发都是基于前一次的功能，增加为产品增值的新功能。这时，你就可以发布或者演示产品。
迭代开发是，在小且重复的周期里，你完成各种开发任务：分析、设计、实现、测试和获得反馈，所以叫做迭代。
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
迭代的结束就标记一个里程碑。这时，产品也许可用，也许不可用。在迭代结束时，新的功能全部完成，你就可以发布，让用户真正地使用，同时提供技术支持、培训和维护方面的资源。每次增加的新功能都会包含多次迭代。
根据Capers Jones的格言：“…..大型系统的开发是一件非常危险的事情。”大型系统更容易失败。它们通常不遵守迭代和增量开发的计划，或者迭代时间太 长（更多关于迭代和演进开发的讨论，以及和风险的关系、生产率和缺点，可以查阅Agile and Iterative Development:A Manager’s Guide[Lar04]一书）。Larman指出，软件开发不是精细的制造业，而是创新活动。规划几年之后客户才能真正使用的项目注定是行不通的。
对付大项目，最理想的办法就是小步前进，这也是敏捷方法的 。大步跳跃大大地增加了风险，小步前进才可以帮助你很好地把握平衡。
在你周围，可以看到很多迭代和增量开发的例子。比如W3C（万维网联盟）提出的XML规范DTD（Document Type Definitions,文档类型定义），它用来定义XML文档的词汇和结构，作为原规范的部分发布。虽然DTD设计的时候就解决了很多问题，但是在真正使用的时候，又显现出很多问题和限制。基于用户的反馈对规范就有了更深一层的理解，这样就诞生了更加高效的第二代解决方案，例如Schema。如果他们一开始就试图进行一些完美的设计，也许就看不到XML成为今天的主流了——我们通过提早发布获得了灼见和经验。
大部分用户都是希望现在就有一个够用的软件，而不是在一年之后得到一个超级好的软件（可以参见《程序员修炼之道——从小工作专家》“足够好的软件”一节[HT00]）。确定使产品可用的核心功能，然后把它们放在生产环节中，越早交到用户的手里越好。
根据产品的特性，发布新的功能需要几周或者几个月的时间。如果是打算一年或者两年再交付，你就无法应该重新评估和重新计划。也许你要说，构建复杂的系统需要发费时间，你无法用增量的方式开发一个大型的系统。如果这种情况成立，就不要生产大的系统。可以把它分解成一块块有用的小系统——再进行增量开发。即使是美国国家航空天局（NASA）也使用迭代和增量开发方式开发用于航天飞机的复杂软件（参见Design,Development,Integration: Space Shuttle Primary Flight Software System [MR84]）.
询问用户，哪些是使用产品可用且不可缺少的核心功能。不要为所有可能需要的华丽功能而分心，不要沉迷于你的想象，去做那些华而不实的用户界面。
有一堆的理由，值得你尽快把软件交到用户手中：只要交到用户手里，你就有了收入，这样就有更好的理由继续为产品投资了。从用户那里得到的反馈，会让我们进一步理解什么是用户真正想要的，以及下一步该实现哪些功能。也许你会发现，一些过去认为重要的功能，现在已经不再重要了——我们都知道市场的变化有多快。尽快发布你的应用，迟了也许它就没有用了。
使用短迭代和增量开发，可以让开发者更加注于自己的工作。如果别人告诉你有一年的时间来完成系统，你会觉得时间很长。如果目标很遥远，就很难让自己去专注于它。在这个快节奏的社会，我们都希望更快地得到结果，希望更快地见到有形的东西。这不一定是坏事，相反，她会是一件好事，只要把它转化成生产率和正面的反馈。
图4-2描述了敏捷项目主要的周期关系。根据项目的大小，理想的发布周期是几周到几个月。在每个增量开发周期里，应该使用短的迭代（不应该超过两周）。每个迭代都要有演示，选择可能提供反馈的用户，给他们每人一份最新的产品副本。
增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1 ~ 4周左右迭代周期。
切身感受
短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。
平衡的艺术
? 关于迭代时间长短一直是一个有争议的问题。Andy增经遇到这样一位客户：他们坚持认为迭代就是4周的时间，因为这是他们学到的。但他们的团队却因为这样的步伐而垂死挣扎，因为他们无法在开发新的代码的同时又要维护很多已经完成了的代码。解决方案是，在每4周的迭代中间安排一周的维护任务。没有规定说迭代必须要紧挨着下一个迭代。
? 如果每个迭代的时间都不够用，要么是任务太大，要么是迭代的时间太长了。用户的需要、技术和我们对需求的理解，都会随着时间的推移而变化，在项目发布的时候，需要清楚地反映出这些变化。如果你发现自己工作时还带有过时的观点和陈腐的想法，那么很可能你等待太长时间做调整了。
? 增量的发布必须是可用的，并且能为用户提供价值。你怎么知道用户会觉得有价值呢？这当然要去问用户。
