目录 |
计划驱动开发指软件开发过程中，前一阶段的输出作为规划随后过程活动的基础。
计划驱动开发起源于系统工程和质量规范，建立系统工程的原则，协调大量需要精确协同工作的组件。通过从需求到已完成的代码等一系列代表物来推动软件开发的过程，计划驱动开发非常精确地依赖于明确的步骤。典型地，瀑布模型，软件开发周期划分成若干个阶段：问题定义、可行性研究、需求分析、总体设计、详细设计、编码与单元测试、综合测试、软件维护，各阶段的工作自项向下，从抽象到具体顺序进行，每个阶段都必须完成规定的文档，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果，就好像奔流不息的瀑布，从概念直到最终产品。
计划驱动开发的关键是过程的定义和管理，和过程改进联系在一起，强势在于标准化所带来的可比较性和可重复性。过程需要进行定义、标准化并需要逐步改进以提供控制、管理其操作所需的数据。定义过程执行的方法，和工作产品形式化的方法，对过程的实施者进行良好的培训。需要管理层的支持、组织化的基础设施以及良好的环境。
从以下特征中比较敏捷软件开发和计划驱动开发之间的不同：应用：项目的主要目标、项目环境和应用环境；管理：客户关系、计划和控制，以及项目沟通；技术：需求定义、开发和测试的方法；人员：客户特征、开发人员的特征，以及组织的文化。
1.应用
(1)主要目标：敏捷软件开发的目标是快速交付价值和响应变更，在快速变更的环境中，反应式的态度具有优势，但有一些风险。计划驱动开发的目标是可预见性、稳定性和高可靠性，提前行动的态度对于稳定的环境非常有效，认证需要有计划和规格说明：
(2)规模：敏捷软件开发最适合规模比较小的项目，事实证明，敏捷项目的规模难以扩大。传统的严格性对大型项目更有效，对于大型、复杂的项目来说，计划驱动开发是必需的；
(3)环境：敏捷软件开发适用于频频变更的环境，但有一些风险，关注于眼前的产品，成功主要出现在内部环境，假设用户系统是灵活的，足以进行演化。计划驱动开发需要稳定性，范围包括系统工程、组织结构、外包。
2.管理
(1)客户关系：敏捷软件开发提倡专职的、在一起工作的客户，重中之重是客户代表和用户之间的接口，敏捷开发者通过可以工作的软件来建立客户信任。计划驱动开发依赖于合同和规格说明，重中之重是开发者和客户之间的接口，计划驱动开发者使用已形成的过程成熟度来建立客户信任；
(2)计划和控制：敏捷者把计划看作一种达到目标的手段，敏捷软件开发是“计划行为驱动”而非“计划驱动”。计划驱动开发用计划来进行沟通和协调。两种方法都使用过去的经验来使计划变得准确；
(3)项目沟通：敏捷软件开发依赖于隐式知识，依赖于频繁的、人和人之间的沟通，依赖于隐式知识是有风险的，隐式知识的规模难以扩大。计划驱动开发依赖于显示的、文档化知识。敏捷软件开发和计划驱动开发中都同时使用了这两种知识。敏捷软件开发在需要时会编写文档。计划驱动开发则通常是去掉一些不必要的内容，一旦指定，再去除文档就很难了，会遭遇“裁剪”综合症。
3.技术
(1)需求：敏捷软件开发把非正式的、由用户指定优先级的素材作为需求。计划驱动开发偏爱明确的、形式化的需求，计划驱动开发中没有广泛使用优先级这一概念。计划驱动开发可以更好地处理非功能需求(比如：可靠性、吞吐量、满足实时限制和可伸缩性)；
(2)开发：敏捷软件开发提倡简单设计，简单设计依赖于低成本的改写和快速变更，但无法保证低成本的改写，低成本的改写无法伸展，简单设计意味着你不会需要它的(You are’t going to need it)。计划驱动开发提倡使用架构来预测变更，在快速变更的环境中，架构会造成一些资源的浪费；
(3)测试：敏捷软件开发在编码之前开发测试，然后增量地测试。计划驱动开发测试的是规格说明。
4.人员
(1)客户：敏捷软件开发非常强调专职的、工作在一起的客户代表，成功依赖于客户代表必须易于协作、有代表性、有授权、尽责和在行(collaborative，representative，authorized，committed，knowledgeable，CRACK)。而计划驱动开发则依赖于大量预先的，客户和开发者之间的合同计划和规格说明方面的工作，也需要CRACK型的客户，但可以不是专职的，计划驱动开发中最大的客户挑战是不要让项目控制落入过度官僚(他们认为遵守合同比取得项目成果更重要)的合同管理者手中；
(2)开发人员：敏捷开发者需要具备更多的技能。不管是敏捷团队还是计划驱动团队，都应该尽快识别出也许具有一些技术能力，但是不能或者不愿意，合作或者遵循公共的方法的人员，让他们从事一些非决策性质的工作。通过培训能够完成程序性的方法步骤(例如，对简单的方法进行编码，进行简单的重构，遵循编码规范和CM规程，运行测试)的人员，经过相当多的指导，可以在计划驱动环境中很好地工作。而通过培训能够完成任意的方法步骤(例如，把素材分解成适合增量开发的大小，组合使用模式，进行复杂的重构，进行一些复杂的商品成品集成)的人员，经过一些指导，可以很好地在敏捷团队中工作。能够对方法进行裁剪以适应有先例可循的新情况的人员，可以很好地管理一个小型、有先例可循的敏捷或者计划驱动项目。但对于大型或无先例可循的项目，需要能够对方法进行修订(违背其规则)以适应无先例可循的新情况的人员；
(3)文化：敏捷者喜欢更多的自由度，计划驱动者需要清晰的过程和角色。一旦一种文化已被良好地建立，改变就会非常困难和耗时，文化的惯性是集成敏捷软件开发和计划驱动开发时面临的最大挑战。