作为一个被广泛接受的现代迭代开发过程，IBM Rational Unified Process，6 为一个更为平衡的发展提供了一个框架，这一发展是鼓励对不确定性和风险进行管理的。它的生命周期包括四个阶段，每个阶段都有可演示的结果：

　　1.起始：远景和商业案例的定义和原型设计
　　2.细化：对架构基线进行集成、论证和评估
　　3.构建：对有用的增量进行开发、论证和评估
　　4.产品化：可用性评估、终产品以及发行

　　阶段的名称表现了项目的状态，而不是从需求到设计到编码到测试到发行的基于顺序性活动的项目进展。

　　我们把这一迭代管理方式称为基于结果的，而不是基于活动的。在软件世界中，真正的结果是可执行程序。其他的任何东西（需求文档、用例模型、设计模型、测试用例、计划、过程、文档、检查）都是次要的，而且只是实现目标——一个可执行的软件程序——的手段的一部分。回想你做程序员的日子：当你在建立一个模型、画流程图草图、推理一个状态机的逻辑或是写源代码的时候，你知道你只是在思考和集成一个抽象方案。只有当你编译、链接和执行时方案才变得切实可行。项目管理者应该有同样的感觉。当你评估一个计划、模型、文档或一些其他不可执行的表现物的美好和出色之处时，你只是在推测项目质量和进度。电影制作人对剧本、情节串连板、背景设置以及服装设计的感觉也是如此。他们着力于影片的每一个镜头，使得电影成为可以判断总体集成效果的实体。

　　精确度与准确度

　　在一个成功的软件项目中，每一个开发阶段都加深了对发展计划、规格说明和完整解决方案的理解，因为每一个阶段都延伸了可执行序列和团队对竞争目标的认识。在生命周期中的任意一点，次要工件的精确性应与这种理解相平衡，在详细程度上保持一致，相互之间保持一定程度的可追踪性。

　　精确度与准确度之间的区别（在软件管理的上下文中）并不是它们看起来那样小。软件管理充满灰色的区域、情景依赖性以及不明确的折衷。对的软件管理者来说，理解精确性与准确性之间的区别是一种基本技能，因为他们必须准确地对投资、风险以及变化带来的影响进行预测。未被证实的精确度——在需求或是计划内的——实际上是造成阻碍成功的潜在而微妙的因素。大多数时候，早期的精确性是不诚实的，造成了有比实际上更多的进展和更高的质量的假象。不幸的是，很多项目发起者和涉众要求这种早期精确性和详细性，因为这给了他们对已经取得的进展的（虚假的）安慰。

　　我在软件工业中所见的常见的失败模式之一是开发有五位数精度的规格说明，而涉众其实对问题、方案或者计划只有一位数精度的理解。延长建立一个精确的需求理解或详细的计划的时间实际上耽误了对架构上更重要的问题的理解。你曾经做过、修改过、痛苦地回顾过多少厚度吓人的需求文档或是详细的管理计划呢？而几个月后当项目取得了有实际意义的可演示的进展，加快了涉众对实际的权衡的理解时，你又要全部重新检查这些文档和计划了。这种普遍现象在我们的行业里被称为刨光废物。

　　一些成功的指导模式

　　迭代过程大多是由解决不确定性和管理软件风险的需要而发展的。这里的指导需要动态控制以及中间的检查点，这样涉众可以评估到目前为止完成了哪些工作，应该对目标作出什么修改，以及如何重新分配他们的工作以使目标按照为经济的方式组合。我曾观察到成功的软件集中型项目典型的四种模式。这些模式表现了一些“抽象规格”，对指导评估、范围管理、过程控制、进展和质量控制有所帮助。我有预感，多数在项目管理中“被鉴定过的”项目管理者对此都会作出消极的反应，因为这些理念在一定程度上是与传统相悖的。

　　范围管理：方案从用户具体的要求发展而来，而用户的具体要求从候选方案发展而来。与从开始确定所有需求不同。
　　过程控制：过程和工具的使用从轻到重渐变。与把整个项目的生存周期过程定义为轻或重不同。
　　进展：健康的项目展示出一个进展和背离的序列。与按照预期计划实现价值，没有明显的背离不同。
　　质量控制：测试可演示的发布版本是一个头等重要的、贯穿全生命周期的活动。与认为它是次要的，生命周期晚期的活动的观点不同。

　　我承认在实际软件项目中，上述四点都是说起来容易做起来难，而且对不同领域它们应该被不同地应用。网络应用程序开发团队与嵌入式应用程序开发团队实现这些模式的方法应该是不同的，但是对他们来说模式都是可用的。方法、模式和技术的书籍和论文的写作，（工业界称为思想领导），是相对简单的。尽管如此，我们中的多数人并不是在寻找好的思想，而是在寻找好的实践方法。管理实际项目需要实践的领导力，而在实际项目条件下应用和执行这些理念是相对困难的。我们应当珍惜懂得实践的领导力的项目管理者：他们可能是每个公司中稀有的资源。的项目管理者，像的电影制作人一样，不只是常常创造出的产品，他们还是年轻团队成员的良师益友，这些年轻人能够学习有效的技术并发展他们自己在多维权衡、持续性沟通、风险管理、模式识别以及指导式领导等方面的技能。项目管理训练课程是学习的良好催化剂，但是学徒期是不可或缺的。

　　范围管理

　　传统软件过程的比较微妙的挑战之一是如何把生存周期表现为一系列顺序的活动：从需求分析到设计，编码，测试，后发行。成功的项目确实用一种抽象的方式实现了这种进展路线，但是活动之间的界限是模糊不清的，只能被合作的涉众所接受。另一方面，不成功的项目则陷入了挣扎着寻找活动间清晰的界限的误区。比如，在过渡到设计前追求固定的需求基线，或是在过渡到编码前追求非常详细的设计文档，都是严格的中间目标，造成了注意力被琐碎细节所分散，而重要工程决定的进展却被放缓甚至停止。

　　当我们建立一个全新的软件方案时，从需求到设计的连续的详细规格说明流也许是有一定意义的。但是现在，我们通常是升级一个已有系统或者根据已有部件（操作系统、网络服务、网络、图形用户界面、数据管理、封装的应用程序、中间件、计算平台、遗留系统等）建立新的系统。改造或复用已有财产的经济效益迫使我们考虑在这些已有财产的环境和限制下的用户具体需要。

　　我前面曾经说过，需求可能是我们的工业中被严重误用的词。需求意味着不可协商，但我们却在几乎所有成功项目中看到需求的变化，妥协和让步。改变一个需求需要进行大量严格的审查，因为这通常对涉众间的合同有很大影响。我建议我们使用规格说明来代替需求。规格说明是可以更改的，而且可以理解为我们现阶段对项目的认识状态。

　　我所见过的而言，用户规格说明有两种重要形式。第一种是观点陈述（或用户需要），它抓住了开发团队和买方或说用户之间的合同。这些信息应以用户可理解的形式（一种包括了文本、原型、用例，电子表格等等的特殊格式）表现。一个支持观点陈述的用例模型起到了用户或买方可以理解的语言表达可操作的概念以及期望的行为的作用。

　　规格说明的第二种形式与需求非常不同。我倾向于使用评估标准这种说法，它被自然理解为目标的瞬间快照，而目标是一个生存周期的中间检查点，比如一个可演示的版本发布。评估标准是从观点陈述或者其他资源（制作/购买/复用分析、风险管理相关、架构方面的考虑、隐藏问题、实现限制、质量极限等等）中派生出来的中间的指导目标。它们与用例模型一起，为早期测试，而不是为传统的需求表达提供了更好的框架。一个计划的发布内容序列和计划的评估标准的初始提议是一个风险管理计划的很好的形式。