一些成功的指导模式

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

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

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

范围管理

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

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

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

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

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

过程严格性

多年来，我一直尝试着调解敏捷阵营（软件过程观点的自由主义左翼）和过程成熟阵营（软件过程观点的保守派右翼）之间狂热的争论。他们都有有益的观点和适当的技术。但是经过老于世故的努力，在需要解决方案的范围内没有清晰的正确或者错误的处方。上下文环境是极为重要的，而且几乎所有不是太过普通的项目和组织都需要结合技术、常识、领域内的经验来取得成功。多数项目管理者会同意下述观点：

在我看来，后一个观点描述了决定敏捷方法的速度和自由度，严格方法的质量和说明性指导的决定性因素。过程严格性应该与重力作用很相似：你越接近产品的发布，过程、工具、员工每天的活动使用仪器的影响越大。你离发布日期越远，这种影响越小。这个公理在过程里似乎完全被忽略了，或者至少是不受重视的，但是它在成功的软件项目中通常是非常引人注目的。

大多数成功的软件开发过程的一个标志性特征是详细定义的从创造阶段（初始和细化）到生产阶段（构建和产品化）的过渡过程。当软件项目无法成功时，一个主要的原因是对过程严格性不合适的强调（过多或者过少）。这种现象在传统过程和迭代过程中都是存在的。多数不成功的项目带有下列特征之一：

生存周期早期阶段（创造性方面）的过度设计。你需要有机动性的过程，该过程容易适应新发现、适应对几个主要风险和原型方案造成攻击的一定程度上的不确定性，并且建立早期的粗糙工件。你能想到哪些创造性原则，根据这些原则过程严格性对帮助人类思考被认为是有益的？
生存周期晚期阶段（生产方面）的设计不足。详细工件的广泛的变化管理基线需要带有富有洞察力的实现方法，对连贯性的密切关注，以及自始至终对产品质量聚焦的工程过程。