详情
本书是敏捷和迭代开发方法的权威指南。著名软件方法大师Craig Larman在书中不但说明什么是敏捷/迭代方法，其运作机制、实施策略以及原因，而且通过重要研究数据以及大规模的项目案例分析，为读者呈现了最具有说服力的采用迭代开发的有力证据。本书主要内容包括大量实用的敏捷和迭代技巧，面向敏捷/迭代项目主管的新管理技能，敏捷与迭代的价值与实践，Scrum、XP、UP和Evo的关键实践。
敏捷软件开发宣言
人和交互 重于 过程和工具
可以工作的软件 重于 面面俱到的文档
客户合作 重于 合同谈判
随时应对变化 重于 遵循计划
虽然右侧的各项也有价值，但我们认为左侧的项更加重要。
敏捷软件开发遵循的原则
我们遵循以下原则。
1.我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户需要。
2.我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。
3.经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。
4.在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
5.依靠斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成任务。
6.在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。
7.可以工作的软件是进度主要的度量标准。
8.敏捷过程提倡可持续开发。
9.出资人、开发者和用户应该总是保持稳定的开发速度。
10.对卓越技术和良好设计的不断追求有助于提高敏捷性。
11.简单——尽量减少工作量的艺术是至关重要的。
12.最好的构架、需求和设计都源自自我组织的团队。
13.每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
软件开发方法学精选系列
Agile and Iterative Development:A Manager’s Guide
敏捷迭代开发 管理者指南
[美]Craig Larman 著
张晓坤 译
人民邮电出版社
北京
图书在版编目（CIP）数据
敏捷迭代开发：管理者指南/（美）拉尔曼（Craig Larman,C）著；张晓坤译.--北京：人民邮电出版社，2013.5
（软件开发方法学精选系列）
书名原文：Agile and Iterative Development:A Manager’s Guide
ISBN 978-7-115-31642-4
Ⅰ.①敏… Ⅱ.①拉…②张… Ⅲ.①软件开发 Ⅳ.①TP311.52
中国版本图书馆CIP数据核字（2013）第074906号
内容提要
本书是敏捷和迭代开发方法的权威指南。著名软件方法大师Craig Larman在书中不但说明什么是敏捷/迭代方法，其运作机制、实施策略以及原因，而且通过具有统计意义的重要研究数据，以及大规模的项目案例分析，为读者呈现了最具有说服力的采用迭代开发的有力证据。本书主要内容包括：大量实用的敏捷和迭代技巧，面向敏捷/迭代项目主管的新管理技能，敏捷与迭代的价值与实践，Scrum、XP、UP和Evo的关键实践，以及常见问题的问答。
无论是对IT主管、项目经理，还是对软件开发人员，这都是了解敏捷和迭代开发最理想的一本书。
◆著 [美]Graig Larman
译 张晓坤
责任编辑 杨海玲
责任印制 程彦红 焦志炜
◆人民邮电出版社出版发行 北京市崇文区夕照寺街14号
邮编 100061 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
大厂聚鑫印刷有限责任公司印刷
◆开本：700×1000 1/16
印张：15.5
字数：290千字 2013年7月第1版
印数：1-3000册 2013年7月河北第1次印刷
著作权合同登记号 图字：01-2012-6494号
ISBN 978-7-115-31642-4
定价：49.00元
读者服务热线：(010)67132692 印装质量热线：(010)67129223
反盗版热线：(010)67171154
广告经营许可证：京崇工商广字第0021号
Authorized translation from the English language edition, entitled: Agile and Iterative Development:A Manager's Guide,9780131111554 by Graig Larman,published by Pearson Education, Inc., publishing as Addison-Wesley Professional, Copyright © 2004 Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD. and POSTS & TELECOM PRESS Copyright © 2013.
本书中文简体字版由Pearson Education Asia Ltd.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。
版权所有，侵权必究。
“过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。”[1]传统的瀑布型软件工程方法将软件业等同于传统的大规模制造业，试图回避软件领域固有的复杂性以及变化性，不顾及实际情况而套用一些所谓“银弹”的开发方法，以至于削足适履、南辕北辙，陷入泥潭中而不能自拔。事实上，软件开发属于新产品研发的范畴，你所面对的犹如一片混沌的海洋，需要因地制宜，根据实际情况对各种条件进行权衡与博奕，从而探索出一种行之有效的解决之道。
面对复杂与变化的软件开发，“敢问路在何方？”
UP、XP、水晶、Scrum、DSDM、FDD、ASD以及精益开发等都给出了相应的答案。然而，“忽如一夜春风来，千树成树梨花开”，一下子涌现出这么多琳琅满目的软件工程方法，让人眼花缭乱，无所适从。需要说明的是，许多标榜自己采用“敏捷与迭代方法”的组织，其实是在追逐时髦，并没有真正领会其要旨，甚至断章取义，陷入教条主义，甚至重蹈瀑布型的覆辙。
本书列举了大量的证据，溯根求源，将各种方法的缘由与适用性娓娓道来，令人茅塞顿开，许多积压在心里的困惑一下子释然。全书共分12章：在前6章的描述中，作者列举了大量的证据和文献，揭示了瀑布型的症结，以及敏捷与迭代开发的动机与成功案例；第7章到第10章，则具体讨论了Scrum、XP、UP、Evo等4种敏捷方法，它们的原理与适用性，以及成功的案例与历史，还在章节后面列出大量的参考文献。这4章内容的组织形式相仿，便于读者进行比较学习；第11章更具有操作性，介绍了许多行之有效的敏捷与迭代开发的实践技巧；第12章是FAQ，读者可以将它作为独立的章节，对实践中遇到的问题进行查询。
我们还注意到在本书英文版的封面上，是一名芭蕾舞演员。其寓意在于软件开发不仅是一门技术，同时也是一门艺术。作者希望通过他的努力，开发出漂亮的软件来。随便提一句，这本书在亚马逊网站上被评为五星[2]。
本书的作者Craig Larman先生相信大家不会陌生。他的《UML和模式应用：面向对象与设计导论》深受中国读者欢迎。Philippe Kruchten博士（国际著名过程大师， IBM Rational名士，前RUP产品总监）这样评价道: “Craig是一位杰出的授业者，一位卓越的方法学家，一位对象技术的精神导师(guru)。” Martin Fowler（国际著名OO大师，ThoughtWorks首席科学家）曾说过：“人们常常问我，哪本书是引领他们进入OO(面向对象)设计壮丽殿堂的最佳著作。自从幸获 Craig 的《UML和模式应用》，它就成为了我的倾力之荐。”。
阅读 Larman 先生的书可以说一种享受，而翻译他的书则是一种压力。2004 年我有幸接手这部书的翻译工作，并期望向读者呈现原汁原味儿的译著。翻译过程中，对于书中的一些疑惑之处，Larman先生给予了热情的帮助和鼓励，并欣然为本书的中文版作序。事隔8年，也就是2012年，人民邮电出版社期望再版，并请了冯春丽协助进行全文的审校。尽管大家都非常努力，也难免有疏漏之处，希望大家批评指正！此外，我要感谢我在北京魔笛创新科技发展限公司的团队，并给我试验敏捷方法的机会。最主要的还是要感谢读者朋友，只有你们的认同，才是这项工作最终成功的标志。
张晓坤
2013年5月于北京师范大学辅仁校区
[1].摘自Frederick P. Brooks，Jr.著，UMLChina翻译组汪颖译，清华大学出版社出版的《人月神话》。
[2].参见：Larman的个人网站http://www.craiglarman.com以及亚马逊网站http://www.amazon.com/exec/obidos/ASIN/0131111558/qid%3D1063687928/sr%3D11-1/ref%3Dsr%5F11 %5F1/103-3958085-8199045。
谢谢你阅读这本书！我真心希望这本书对你有用——优质信息，易于理解。
此外，访问 www.craiglarman.com 可以找到一些相关的文章和链接。如果你有什么问题，请与我联系，我的电子邮箱是craig@craiglarman.com。
排版约定
使用楷体排版的是强调的基本观点和需要引起重点关注的地方，我希望读者比较容易看到它，这样，就可以快速浏览，挑选关键思路。
在一句话中排成黑体的部分指的是术语。
类似于 [Bob67]的形式，是指在参考文献中列出的某本书。
作者简介
Craig Larman是Valtech公司的首席科学家。Valtech公司是一家国际化的咨询和技能转移公司，在欧洲、亚洲和北美洲都设有分支机构。同时，他还在全球范围内担任独立顾问、团队教练和演讲人。
Craig是Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design（《UML和模式应用：面向对象分析与设计导论》）的作者。此书是OOA/D和迭代开发方面全球最畅销的教科书，被译成多种语言，在全球业界和大学中被广泛使用。
Craig有过一段做街头音乐家的失败经历，从那之后，也就是20世纪70年代，他开始用APL语言、PL/I语言和第四代语言构建软件。20世纪80年代初期，经过全面的调整之后，他开始对人工智能和知识表示产生了浓厚的兴趣，并用Lisp机器、Lisp、Prolog和Smalltalk 构建了知识系统。他业余时间还在一支名为 Changing Requirements的业余乐队（这个乐队曾被称为Requirements，但有一些乐队成员已经有了变动……）中担任主奏吉他手。
Craig毕业于加拿大温哥华美丽的西蒙弗雷泽大学（Simon Fraser University），获得了计算机科学学士和硕士学位。
致谢
特别感谢我在 Valtech 的朋友和同事，他们都是世界级的迭代开发者，尤其是Tim Snyder。
非常感谢审读这本书的专家们，包括Alistair Cockburn、Claudia Frers、Tom Gilb、Jim Highsmith、Ron Jeffries、Philippe Kruchten、Niels Maloteaux、Gary Pollice、Ken Schwaber和Jeff Sutherland。
还要感谢Paul Petralia和Patti Guerrieri两位编辑的引导。
逻辑是一种用信心面对错误的艺术。
——约瑟夫·伍德·克鲁奇（Joseph Wood Krutch）
概述
本书中有哪些内容?
预见性开发与新产品开发。
本书介绍了迭代（iterative）和敏捷（agile）方法，你能从中获得哪些有用的知识呢？
第一，你会知道 4 种著名方法的关键实践：Scrum、极限编程（Extreme Programming，XP）、统一过程（Unified Process，UP）和Evo（一种早期的迭代方法）。本书提供了一些软件开发方法的思路和实践的总结，对于使用开发方法的管理人员、开发人员以及学生来说，每一章都会有一些有用的内容。（Scrum参见第7章，极限编程参见第8章，统一过程参见第9章，Evo参见第10章）。
第二，因为本书能够提供很好的帮助，所以可以缩短你的学习曲线。阐述这 4种方法的章节都具有相同的结构，便于快速理解与比较。此外，还有一章 FAQ（见第12章）和一章常见的实践技巧（见第11章）。
第三，你将了解到敏捷与迭代开发的动机（见第5章）和证据（见第6章）。有些组织重视迭代开发的价值，但是有一些组织则不以为然。如果你需要为一次迭代项目实验找到充分的理由，那么你会发现本书提供了迭代开发的关键原因、研究成果、大型项目示例、标准团体认可、商业案例，以及著名编程思想领袖们几十年以来的推动历程。研究成果与历史阐述部分也适合学习软件工程方法的学生进行研读。
注意 敏捷方法是迭代方法的子集，本书涵盖这两种类型。
阅读本书可以不按章节顺序，本书的大致内容是下面这样的。
第1章：介绍，以及预见性开发和创新性开发。
第2章：基本迭代和渐进方法实践。
第3章：总结敏捷原则和方法。
第4章：通过一个敏捷项目的故事，阐述一些理念。
第5～6章：迭代和敏捷方法的动机和证据，对某些人非常有用。
第7～10章：总结Scrum、XP、UP和Evo等4种方法。注意，实践中可能会混合使用。
第11章：技巧，扩展了某些方法实践，还加入了其他方法实践。
第12章：常问的问题（FAQ）。
最后，人终究胜于过程。每一种介绍过程的书籍可能都包括这样的标准免责声明：
过程的影响只是第二位的[1]。只有人、人的情感、品质和沟通能力才更有影响力。
有些问题真的很难，有些人真的很固执。方法不是救世主。
考虑在一个装配线上生产移动电话：在这种情况下，可以毫无二义性地定义规范和构造步骤。在生产一批电话之后，做一些相关的测量，就能够可靠地估算和规划未来电话的生产过程。
下面考虑另一个问题：建造一个定制的房屋。业主想要采用新型的环保材料和方法，但他们的实际需求并不明确，当他们看到房屋、成本以及工期时，还会逐步改变或者澄清他们的决策。
开发领域的一种极端的情况类似于生产电话，在整个过程中几乎没有创新或变动，只是大量地重复创造或者近乎雷同地创造——批量制造（mass manufacturing）或者预见性制造（predictable manufacturing）。
另一种极端的情况是变化频率很快、创新性很强。在这种情况下，没有以前的类似案例可供借鉴，无法进行估算或者计划。这就属于新产品开发（new product development）或者创新项目（inventive project）的范畴。
这两个领域极端的开发过程、管理理念、计划和估算模型是截然不同的（参见表1-1）。
当然，关键在于：
大多数软件都不是预见性制造或者批量制造，软件开发属于新产品开发范畴。
此外，许多工程采用新的带有bug的技术，这加剧了新颖性和不可预见性。同时还要注意，对于没有经验的人来说，它就是新产品，即使以前也有过这样的产品。
对于软件而言，预见性制造是错误的范例，因此基于这方面的实践和理念没有什么指导意义。
这种错误的匹配往往是许多难题的症结所在，而这些问题总是与运作软件项目的传统方式有关。
“瀑布型”的生命周期、大的前期规格说明、估算、推测性计划等适用于预见性制造，却无法套用在软件项目上，因为后者属于发明性质的、高度可变的、高度创新的工作。
拒绝采用那些“可靠的”前期规格说明的理由[CP86]包括：
客户或者用户不确定他们想要什么；
他们很难陈述所有的需求和所知道的；
他们想要的许多细节只能在开发过程中逐步展现；
细节对于他们来讲过于复杂；
当他们看到产品开发时，会改变想法；
外部压力（例如，竞争者的产品或者服务）导致需求变更或者增强。
更深入的认识——构建软件是复杂的新产品开发，修改频度很高，不是预见性制造——这就是敏捷和迭代方法动机的核心。
当然，另一种采用迭代和敏捷方法的动力是提高竞争力，成为竞争中的赢家。迭代和敏捷方法促进了灵活性和机动性——竞争优势。在 Agile Competitors and Virtual Organizations[GNP97]中，作者检讨了批量制造模型（mass manufacturing model）的局限性，以及敏捷必要性：
敏捷……意味着成功与收益：成功是指在竞争的对手中脱颖而出；收益是指在许多公司望而生畏的竞争风暴中，获得利润、市场份额和客户。
接下来的两章会概述迭代、渐进和敏捷方法的基本实践和观点。之后，第 4 章会通过具体的场景阐述这些实践。
各章都会分别列出相关的书籍或期刊文章。这里给读者推荐一些Web资源。
www.agilealliance.com——收集了许多有关敏捷方法的文章，也包含相关的链接。
www.cetus-links.org——多年以来，一直关注对象技术（Object Technology， OT）的网站。在“OO Project Management——OOA/D Methods”目录下，有许多链接指向了迭代和敏捷方法，尽管这些方法与OO没有直接关系。
www.bradapp.net——Brad Appleton拥有大量关于软件工程的链接，包括关于迭代方法的。
www.iturls.com——其中文主页有到英文网站的链接，通过搜索引擎收录了大量的迭代和敏捷方面的文章。
c2.com/cgi/wiki?FindPage——这个重要的大型 Wiki 网站收录了许多敏捷大师（和设计模式大师）在XP和其他敏捷方法上的原始讨论。
www.extremeprogramming.org——Don Well（早期的 XP 领袖）的介绍 XP的网站。
www.xprogramming.com——Ron Jeffries（早期的XP领袖）的介绍XP的网站。
www.agilemodeling.com——Scott Ambler的网站，包含了有关敏捷建模实践的许多文章。
sunset.usc.edu——记录了Barry Boehm博士的相关工作，他在迭代（如螺旋型）方法上进行了长期的研究。该网站收录了许多与迭代方法相关的文章。
www.cutter.com——Cutter 的网站，主要以敏捷项目管理（Agile Project Management）为主。
www.martinfowler.com——Martin Fowler 是早期的敏捷方法思想领袖（XP方法），这个网站包括他的文章和链接。
www.jimhighsmith.com——Jim Highsmith是早期的敏捷方法思想领袖（自适应软件开发方法），这个网站包括他的文章和链接。
alistair.cockburn.us——Alistair Cockburn 是早期的敏捷方法思想领袖（Crystal方法），这个网站包括他的文章和链接。
www.controlchaos.com——Ken Schwaber 是早期的敏捷方法思想领袖（Scrum方法），这个网站包括他的文章和链接。
jeffsutherland.com——Jeff Sutherland是早期的敏捷方法思想领袖（Scrum方法），这个网站包括他的文章和链接。
www.gilb.com——Tom Gilb是最早的迭代和渐进思想领袖之一（Evo方法），这个网站包括他的文章和链接。
www.craiglarman.com——本书作者的网站，包括相关文章和链接。
www.objectmentor.com——Robert C. Martin领导的公司的网站，Martin也是早期的敏捷方法思想领袖（有关XP方面），这个网站包括相关文章和链接。
www.nebulon.com——Jeff De Luca领导的公司的网站，Luca也是早期的敏捷方法思想领袖（特性驱动开发方法），这个网站包括相关文章和链接。
www.dsdm.com——DSDM[2]方法的官方网站。
www.rational.com——Rational统一过程（Rational Unified Process，RUP）迭代方法的官方网站。
name.case.unibz.it——这是一个介绍敏捷方法学经验的网络（Network for Agile Methodologies Experience，NAME）。这个欧洲网站记录了有关敏捷方法的研究，并且提供了到其他相关网站的链接。
[1].引自敏捷方法学家Alistair Cockburn。
[2].DSDM：动态系统开发方法（Dynamic System Development Method）。——译者注
经验的神奇之处在于：它能够提醒你不再犯同样的错误。
——F. P. 琼斯（F. P. Jones）
概述
迭代和渐进方法的基本实践，包括时间箱（timeboxing）和自适应计划。
采用迭代方法的一个常见错误。
特定的迭代和渐进方法，包括Evo和UP。
迭代和渐进开发不仅是现代软件方法的基础，也是早在20世纪60年代就使用的方法（有关这段历史参见6.3节）。敏捷方法是迭代和渐进方法的子集。本章总结了关键的实践方法：
迭代开发 渐进开发
风险驱动和客户驱动 渐进需求
时间箱 自适应计划
迭代开发（iterative development）是一种构建软件（或者其他东西）的方式，软件的整个生命周期依次由几个迭代组成（迭代计划技巧参见11.1节）。每个迭代（iteration）都是一个独立的迷你项目，它们由一系列活动组成，例如，需求分析、设计、编程和测试。每次迭代的最终目标是产生一个迭代发布（iteration release），一个稳定的、集成的、经过测试的部分完成的系统。要明确的是，每一个迭代版本都是将所有团队的全部软件整合在一起产生的。绝大多数迭代版本只对内发布，不对外发布，作为基线（baseline），主要供开发团队从中获益。迭代版本的最终版是完成的产品，面向市场或者客户进行发布，参见图2-1。
尽管在理论上迭代只能用于简化或者性能优化，但是这个部分完成的系统通常会在一次又一次的迭代过程中伴随着新特性的出现而逐渐成长，换言之，就是增量开发（incremental development）。通过迭代来增长系统的概念称为迭代和增量开发（Iterative and Incremental Development，IID），通常简称为“迭代开发”。有些旧的过程文献[Wong84]使用术语“增量开发”，意思是一系列的迭代开发，每次都先冻结预先定义的规格说明，随后围绕新特性进行开发。不过，这没有推广开来。时至今日，绝大多数开发方法都是 IID 方法，并且，IID 是所有敏捷方法（包括 Scrum和XP）的核心。
绝大多数项目在最终公开发布之前，至少需要进行 3 次迭代。我曾经看到过一个历时两年的Valtech项目，经历了将近20次迭代，每次迭代平均花费4周的时间。此外，我还听说过一个经历了45次迭代的长期项目。
在现代的迭代方法中，推荐的迭代周期是1～6周。
例如，每次迭代不仅包括需求分析，还包括产品级的编程。而且，每次迭代的结果不是一个原型或者概念性的试验，而是最终系统的一个子集。
概括地说，可将迭代视为一个独立的迷你项目，每次迭代中会出现许多规程下的活动（需求分析、测试等），参见图2-2。
下一个 3 周迭代的工作内容是什么呢？IID 方法提倡将风险驱动（参见 11.1.15节）和客户驱动优先级[1]进行组合。风险驱动迭代开发（risk-driven iterative development）为早期迭代选择最具风险（风险评级参见 11.1.29 节）、难度最大的元素。例如，客户可能会提出：“我希望Web页面是绿色的，并且系统能处理5 000个并发事务。”（第一次迭代参见11.1.21节，用例和迭代计划参见11.1.22节）绿色的页面可以放在后面，由此可以让最大的风险尽早而不是拖后被提出并加以解决。风险是一个广义的概念——可能你正在做一个新的 3D 模型工具，并且市场研究表明：市场的关注点在于是否有新颖的、更易于操作的用户界面隐喻设计。这时，最大的风险就不是获得UI的权限。
客户驱动迭代开发（client-driven iterative development）是指下一次迭代所依据的特性由客户来选择——这些选择对客户而言是最具有商业价值的（自适应和客户驱动计划参见11.1.4节）。通过这种方式，客户在一次又一次的迭代过程中，不断要求实现他们认为对当时而言具有价值的特性，从而掌控着项目的发展。需要注意的是，对于下一次迭代，顾客在其开始前不久自适应地规划（adaptively plan）他们的选择，选择的依据是他们最新的理解，而不是对项目初始阶段的预测。随着新信息的不断涌现，顾客持续地进行控制和选择。
就这两种模式的应用而言，对于技术上的难度或风险，顾客不可能都理解。同样，对于项目中商业价值比较高的部分，开发人员也不可能都领会。（混合和迭代目标评级参见11.1.17节开始的内容。）
时间箱（timeboxing）迭代是将迭代的结束日期固定下来并不允许改变的实践（多站点时间箱迭代参见11.1.1节）。整个项目可能也需要确定的时间箱。如果几经努力还是出现某次迭代的需求（范围）在其迭代周期的时间箱内无法实现的局面，也不要推迟迭代的最终日期，而是要减小范围（将较低优先级的需求放回期望表中）（跨时间箱的重叠活动参见11.1.3节），如此便可以使部分的、增长的系统总是能够在最初计划的迭代结束日期内实现，依然得到稳定的、经过测试验证的版本，参见图2-3。
重点是：时间箱方法不是用来向开发人员施压，让他们加班加点，力争在即将来临的最后期限内完成任务的一种手段。如果正常的工作步调不足以完成任务，那么就缩小工作范围。
在绝大多数IID方法中，并不是所有的时间箱长度都是相等的（迭代长度参见11.1.19节）。例如，首次迭代可能是4周；第二次迭代可能是3周，等等（哪一天结束时间箱参见11.1.5节）。另外，Scrum方法推荐每个时间箱采用30个日历日。如上所述，绝大多数IID方法建议每个迭代时间箱周期控制在1～6周。
一个3个月或者6个月的时间箱迭代周期过于漫长，并且总是抓不住关键。研究表明较短的步骤能够降低复杂性和风险，获得更好的反馈，同时提高生产力和成功率。也就是说，对于拥有几百名开发人员的项目，才会因为开销，采用 3 个月的迭代周期。
所有现代的IID方法（包括Scrum、XP等）都需要或者强烈建议采用时间箱迭代。
迭代和敏捷方法拥抱有序的变化，而不是无序的混乱。在一个持续的变化中，稳定性是关键。IID方法是通过下面的规则达到稳定性的：
一旦迭代的需求被选定，并且迭代开始运行，那么任何外部的利益相关者（stakeholder）都不能改变这一工作。
例如，在一个3周的迭代周期内，一周过去后，产品经理不应出来指手划脚：“你们还能把这个也做了吗？”他们只能等到下一个迭代周期。然而，如果在时间箱的最后期限内无法完成任务，团队可以缩小迭代的范围（范围缩小：主要和次要的迭代目标参见11.1.23节）。
渐进迭代开发（evolutionary iterative development）意味着需求、计划、估算和解决工作是逐渐展开的，或者说在各个迭代过程中逐步精化（refinement）的，而不是在迭代开发开始前，就通过先期的需求规格说明工作进行完全定义和“冻结”（渐进需求参见2.6节，自适应计划参见2.8节）。对于新产品的开发，渐进方法符合新产品不可预知的变化发展模式。
自适应开发（adaptive development）是一个相关的术语，它意味着在响应前一阶段工作的反馈方面，要求各个元素能够适应来自用户、测试、开发人员等的信息反馈。自适应开发的意图与渐进开发相同，但从名字上就能够看出，在渐进开发中更强调反馈响应机制。
一些方法或方法学家强调“迭代”这一术语，而另一些则使用“渐进”或者“自适应”。这些观点和意图都大同小异，尽管严格来说，渐进和自适应开发都不需要使用时间箱迭代。
渐进和自适应开发不属于那种需求总是不着边际或者高频率变化的情形。准确地说，绝大多数需求的发现和精化往往出现在早期的迭代中，并且最早受关注的是最具有架构性意义或者最具商业价值的需求（渐进需求技巧参见 11.3 节）。例如，在一个总共需要20次迭代的项目中，绝大多数需求可能在初期的三四个迭代周期中就被发现和精化了（其中同时也包括早期的软件开发）。
在每次迭代中，都有一到两天的需求研讨（参见11.3.6节），扩展和精化规格说明，以响应从正在开发的系统中得出的更进一步的分析和反馈，参见图2-4。例如，第一次需求研讨只集中详细分析需求中最具有架构性意义和最具风险的 20%，这就给了软件架构师足够的有意义投入，足以让其在较短的周期内启动开发和测试。
注意，在启动构建优秀的核心架构之前，需要知道100%的功能性需求，这种说法是不正确的。事实上，架构师需要知道的是绝大多数非功能性的需求或者质量方面的需求（例如，负载、国际化），以及功能性需求中很小的最有代表性的子集。
将渐进需求分析等同为“无早期需求”或者草率需求分析是一种误解。对于愿景声明、“排名前十”的高级需求表、架构性影响因素的早期分析（例如，负载、易用性和国际化）而言，现代IID方法鼓励尽早创建和设置基线。并且，这些方法在早期迭代中鼓励采用许多技巧性的分析技术，例如，一系列由目标用户和开发人员共同进行的需求研讨，编写用例，等等。（愿景箱参见11.3.3节，产品表参见11.3.5节，用例参见11.3.9节，各种启发方法参见11.3.11节开始的内容。）
同渐进需求一样，渐进和自适应计划并不属于那种估算和进度永远不确定或未知的情形（自适应计划和相关技巧参见 11.1.4 节开始的内容）。然而，由于早期需求的变更和其他一些因素，渐进和自适应计划的初始阶段具有高度的不确定性，这种不确定性随着时间的流逝和信息的积累不断降低。因而，这也被称为未确定性锥区（cone of uncertainty），参见图2-5 [McConnell98]。
渐进和自适应计划对这种不确定性的迭代响应，是为了延迟对估算的预期，直到项目经历了一些迭代，大约进行到整个项目10%或20%的地方时，才对成本、工作量或者日程安排进行有50%可靠性的估算。
这与其他新产品开发领域中的管理实践是一致的，它们都拥有相同的初始探索阶段。而且，与预见性计划（predictive planning）相比，更鼓励采用自适应计划（adaptive planning）的实践（自适应计划和预见性计划参见11.1.4节）。也就是说，只做短时间的详细日程安排，这样详细程度和承诺程度与信息质量就相当了。
固定价格的合同
关于固定价格的投标和渐进的估算，一些IID方法（如UP）建议分两个合同阶段运行项目，每个阶段都含有多个时间箱迭代。
第一阶段的固定价格合同有相对较短的固定时间，其目标是完成一些迭代，尽早介入部分的软件开发和渐进需求分析工作。这一阶段的关键在于它生产出了部分软件，而不仅仅是文档。
然后，第一阶段的输出（包括软件基础部分）与投标者共享，用于制定第二阶段的固定价格合同。对第一阶段的规格说明和代码进行的渐进式精化为第二阶段的估算者提供了更优质的数据，进一步改进了项目的软件（参见图2-6）。
增量交付（incremental delivery）是多次将一个系统交付为产品（或者投放市场）的实践，这需要一系列的扩展能力（参见图2-7）。IID和敏捷方法提倡这种实践。增量交付周期通常为3～12个月。
增量交付与迭代开发经常被混淆。一个6个月的交付周期可能由10个短迭代组成。交付市场的不是每次迭代的结果，而是增量交付的结果。
渐进交付（evolutionary delivery）是对增量交付实践的精化，它尽力捕获有关已安装产品的反馈，并用它指导下一次交付。很自然地，最大限度地满足某些难以预测的需求成为渐进的目标，例如，预测最常需要的新特性。比较特别的是， Evo方法提倡在可能的情况下使用非常短的渐进交付周期，通常为1～2周，如此便可使每次迭代都能将一些有用的东西交付给利益相关者。（Evo方法和渐进交付参见10.1节。）
“纯”增量交付与渐进交付相比，前者预先定义了一个包含几个未来交付的计划——但反馈并不驱动该交付计划。在渐进交付中，对未来的交付不存在计划（或者至少没有固定的计划），每次计划都是基于新出现的信息而动态地创建的。在实践中，将未来的预测与反馈两者相结合的情况比较普遍，因而这两个术语在使用中可以互换。
迭代和敏捷过程教练（coach）经常看到这样的场景：
Jill：当然，我们不能采用瀑布型——大家都知道它是无效的。我们已经采用了“迭代方法 X”，并且将其投入我们的第一个项目中。我们已经为此工作了两个月，用例分析工作即将结束，并且还形成了可以在每次迭代中指导我们如何工作的计划和日程安排。在最终的需求集和迭代进度获得审核和批准之后，我们就要启动编程工作了。
这是对迭代和敏捷过程极深的误解，仍然带有瀑布型的烙印——在迭代方法中采用大型预见性分析和计划（预见性制造），这是应用迭代和敏捷方法的新手们最常犯的错误之一。
特定的敏捷方法将在下一章中进行总结。本节只阐述一些迭代方法（Evo和UP），它们是最早的敏捷方法，是否将它们视为敏捷方法均可。
在本书描述的所有方法（Scrum、XP、Evo、UP、OPEN、DSDM 等）中，UP及其变种 RUP（Rational 统一过程）可能是应用范围最广的，成千上万的、遍布世界各地的开发组织都采用了它，但这并意味着它能够被很好地应用和理解。
始于20世纪60年代的Evo可能是最早的迭代和渐进方法（Evo的细节参见第10章）。Evo建议使用1～2周的短迭代周期，每次迭代产生一个渐进交付。Evo通过价值与成本的最大比，自适应地计划其迭代，而且Evo提供了量化和可度量的语句，倡导对质量需求的准确定义（如负载）。
UP或者RUP是在20世纪90年代中期开发的产品，它汇集了Rational公司及其客户中许多富有大型系统经验的架构师和过程领导者们的知识，形成了一个定义明确的IID方法（UP的细节参见第9章）。其中UP的一个关键主题是前期迭代中的风险驱动开发，前期迭代主要关注如何创建核心架构以及如何降低风险。UP也包括通用项目工件的定义，例如，愿景（Vision）、软件架构文档（Software Architecture Document）和风险清单（Risk List）。
除了UP和Evo之外，IID方法还包括以下几种。
微软解决方案框架（Microsoft Solutions Framework）过程，源自微软教育（Microsoft Education），这是有关微软所用的最佳实践的描述。
OPEN过程，源自Henderson-Sellers、Firesmith和Graham[FH01]。
双赢螺旋模型（WinWin Spiral Model）和MBASE螺旋模型（MBASE Spiral Model），源自Barry Boehm（20世纪80年代著名的迭代螺旋模型的创始人）及其同事[BEKPSM98][BP01]。
下一章将总结敏捷方法的实践和价值，之后的一个故事章节将通过一个具体的场景来阐述这些实践方法。
Steve McConnell的Rapid Development（《快速软件开发》）：剖析迭代开发的各种变体，引用了大量的研究数据。
Frederick Brooks的Mythical Man-Month（《人月神话》）：这部经典著作的25周年纪念版讨论了IID的好处，还收录了许多永恒的教训。
[1].在整本书中，客户（client）或者顾客（customer）可能意味着一个代名词。例如，顾客软件产品的市场经理或者产品经理、内部应用程序的真正最终用户等。
