近年来，项目管理、计算机科学和软件开发领域同时取得了快速发展。对企业的有效支持要求将这些成就有机地合并成为一门学科，将系统开发和项目管理生命周期两个领域的最佳实践整合起来。Robert K. Wysocki博士在本书中创立了这门学科，它既是专业人员和咨询师的一本实用参考书，同时也是针对计算机信息系统和项目管理学生的一本教科书。

　　软件项目的本质决定了它没有“万能(one size fits all)”的实现方法。在本书中，您将学习应用最佳实践的行为准则，同时又能保持软件开发取得成功必不可少的灵活性。

　

　　……全球2 000家公司将会把它们的系统开发生命周期(Systems Development Life Cycle，SDLC)策略和项目管理(Project Management，PM)策略融合起来，开发出具体领域的“集成生命周期和开发环境(Integrated Lifecycle and Development Environment，ILDE)”……如果大型公司在它们的项目管理办公室(Project Management Office，PMO)中运行项目管理协会(PMI)的指导，同时在IT组织中将Rational统一过程(Rational Unified Process，RUP)运行为它们的SDLC，那么这些公司会有何不良职能呢……最具有竞争力的公司是那些将两种思想学派合并起来，通过在项目管理过程和软件生命周期过程之间消除不良职能竞争而交付最佳价值和效率的公司。

　　我们正在经历两门学科的融合，并将会导致另一门学科的产生。这两门学科分别是软件开发和项目管理。出于需要，这两门学科的融合正在形成。我们将这一门新兴的学科称为“有效软件项目管理(Effective Software Project Management，ESPM)”。这便是本书的主题。

为什么本书是又一本关于软件项目管理方面的书籍

　　现代项目管理经历了大约50年的发展历程。它作为构造项目的一种管理方法，是从工程学科发展而来。与这一发展同时发生的是，计算机作为一种基本的业务工具出现了。项目管理、作为商业工具的计算机、以及软件开发这三者的同步发展，产生了将这三者融合成为一门学科以便为企业提供支持的需要。当今，由于下面这几个原因，这种需要甚至显得更加明显：

● 项目管理学科面临着很大的挑战，尤其是它在软件开发竞技场中的进展支持能力。

● 对软件开发人员来说，有将项目管理方面的知识集合成为一个统一体的需要。

● 项目管理和软件开发的实践，需要倾向于形成战略伙伴，以引导当代企业流程的形成。

● 需要一本实用的“how to(如何)”书籍，将系统开发生命周期(SDLC)和项目管理生命周期(PMLC)的最佳实践以均衡的架构合并起来。

　　这些因素都是促使我撰写本书的原动力。市场上还没有一本书能够完整全面且深度适中地介绍这两个主题，本书弥补了这一空白。

本书内容

　　虽然书店里关于信息技术项目管理方面的参考书很多，但是，这些参考文献中所讲授的有关项目管理过程如何适用于特定的系统开发方法学的内容均已过时。另外也有许多种关于特定的系统开发方法学的书籍，但是，这些书籍在论及系统开发方法学时并未深入讨论项目管理。还没有哪本书能够在将项目管理应用于特定的系统方法学时，以相同的程度来介绍项目管理。填补这一空白就是本书所要完成的一切任务。

本书目的

　　本书有3个目的：

● 成为软件专业人员的专业参考书—— 在本书中，随同项目管理最佳实践对这些项目管理的特定应用一起，讨论主要的软件开发模型。在一个地方，软件专业人员就可以找到他们成功地管理其软件开发项目所需要的所有东西。换句话说，本书对于软件开发项目经理来说，真可谓是一站式购齐。

● 为项目管理顾问提供软件开发项目管理原理和实践的唯一资料来源—— 对于其客户是信息技术行业的项目管理顾问来说，本书应该是其忠实的伙伴。对于信息技术客户的各种需要，本书是项目管理最佳实践的深入应用的唯一资料来源。

● 成为计算机信息系统和项目管理等专业的学生的教科书——Effective Project Management: Traditional, Adaptive, Extreme, Third Edition(Wiley, 2003)是本书的姊妹篇。它是尝试为专业参考书市场和学术市场而编写的一本书。这种尝试获得了成功，因为专业市场的销售持续保持良好的势头，且学术界的新读者在大学生和研究生的学分课程和非学分课程中采用本书作为教科书。在大学生、研究生和继续教育市场中，这本书已被50多个学院和大学所采用。许多培训机构也将这本书作为其课程内容的补充材料。期待我们的这本书在学术市场也将取得同样的成功。

本书读者对象

　　本书既是针对专业软件开发项目经理和有志成为软件开发项目经理的人而编写的综合性参考书，也是针对计算机和信息系统与项目管理等专业的大学生和研究生而编写的教科书。希望本书能够成为满足软件开发项目经理的所有工具、模板和过程所需要的资料来源。有志于成功地管理软件开发项目的任何人，或者有志于成为那些管理软件开发项目的任何管理者，都是本书的目标读者。下面几个部分逐一地列出了这些目标读者市场，并简短地讨论本书是如何满足这些市场需要的。

经验丰富的项目经理

　　大家可能有各式各样的作为项目经理的成功职业生涯，也许服务于软件开发人员的需要。在本书中，我将软件开发项目管理中的许多最佳实践收集在一本参考书中。如果您是一名项目经理，正在寻找关于软件开发项目管理的介绍性内容，那么本书可以满足您的要求。它既是一本介绍性读物，也是一本高级参考书，具有很长的使用寿命。

灰心丧气的项目经理

　　也许在软件开发项目的管理中，您曾缺少第一流的工作业绩。很多情况下，您都力图取得成功，哪怕是有限的成功，以使您当前的管理实践工具箱中有一抹成功的色彩，但均以失败而告终。毫无疑问，您一定正在寻求更多的指导，而本书正好可以满足您的需要。在本书中，许多最佳项目管理实践可以适应于各种不同的软件开发项目的特定管理需求。

初出茅庐的项目经理

　　对于软件开发项目管理的新手，本书提供了完整的基础知识，同时也为更复杂的软件开发项目的特定管理需要提供了更高级的主题。作为软件开发项目经理，要具有成功的职业生涯，则本书是您起步和成长所需要的一本快速入门书和一本深入讨论的书。

临时的项目经理

　　对于那些还不精通更复杂类型的软件开发项目管理情况，而又需要一本“指导诀窍”参考书的项目经理来说，本书是现成的参考资料。您所需要的是从软件开发项目开始之日到结束之日都可以得到指导帮助。本书就非常适合于您。

项目管理顾问和软件开发顾问

　　作为一名顾问，您并不是经常都可以奢侈地探索不常需要的解决方案。本书是适合于您的参考书，它提供了对软件开发和项目管理的每一个可行的集成。本书是您“一站购齐”的资料来源。

软件开发人员

　　许多软件开发人员依赖于系统开发生命周期，在许多地方，系统开发生命周期可以作为项目管理生命周期的替代品。在大多数情况下，其结果达不到预期效果。在本书中，您将会找到将软件开发和项目管理最佳实践集成起来的实用解决方案。其结果是获得使工作更加睿智而非更加艰苦所需要的技能和能力。

软件开发经理

　　如果您是一名软件开发经理，那么，通过将项目管理最佳实践集成到软件开发生命周期中，您会拥有可重复的架构，在此架构内，可以更好地管理业务单元。本书包含许多这样的管理助手，以满足您的特定需要。

项目管理指导者与培训者和软件开发指导者与培训者

　　因为本书是面向应用的，所以它可以作为项目管理和软件开发课程与培训会议的完整参考书与配套文本。每一章都包含许多需要思考的讨论题。若想获得思考题的答案，则可以通过rkw@eiicorp.com与本书作者取得联系。通过网站www.wiley.com/go/espm可以获得本书的相关内容，同时也可以得到更多的支持材料。

计算机信息系统的学生

　　软件开发与项目管理的集成是不可避免的，本书旨在成为关于这一主题的事实上的书籍。如果您是一名对ESPM感兴趣的学生，则会想要收藏此书。

学生

　　无论您是一名自学人员，还是将软件开发与项目管理作为学分课程或者非学分课程的人员，本书都有您所需要的一些内容，也许还会是您不可缺少的一本书。本书既可以作为软件开发或者软件项目管理的入门书，也可以作为补充参考书。

阅读本书有何收获

　　在本书的某一部分，软件开发人员可以了解项目管理最佳实践如何能够支持他们的项目有效地完成。

　　在本书的某一部分，项目经理可以看到他们的学科与有效软件开发之间的联系。

　　总体上，作为项目经理的软件开发人员能够可靠地和重复地交付软件开发项目。

本书组织结构

　　本书分为7大部分。第Ⅱ～Ⅵ部分尽可能按照并行结构来组织内容，以方便对不同类型的软件开发项目及其项目管理基础结构的有关信息进行查找、解释和比较。

　　注意：

　　当您读完下面对本书组织结构的介绍时，如果不清楚所提到的全部术语和概念，请不要气馁。随着您继续向前阅读本书，所有这些思想、过程和模型都会得到充分的解释。

第Ⅰ部分：ESPM的演化

　　这一部分是介绍部分，概括性地介绍了项目管理全景和软件开发全景，这二者的演化是彼此独立的。在介绍项目管理全景时也简单介绍了还不满足消费者和客户期望的方法。项目的失败率超过了合理的期望，但是，好像几乎没有采取什么措施来减少这无法接受的高失败率。同时，在介绍软件开发全景时，也简单地对所能想到的每一种类型的软件开发情况介绍了许多方法。有些方法取得了成功，但有些方法则遭到失败。在两种情况之间似乎存在差距。软件开发项目管理的集成方法则不存在这一差距。

　　文献资料中不乏有强烈关注软件开发，而对项目管理却轻描淡写的书籍。本书填补了这一空白。它平等地对待两个主题，并以以前的文献资源中所没有的深度和广度将它们集成起来。

　　本书的基本结构基于确定性到不确定性的连续区，这是本书的独特之处。所有软件开发模型都能够排列在此连续区上。第Ⅱ部分的线性模型排在此连续区的确定性这一端。第Ⅲ～Ⅵ部分讨论的模型则沿着从确定性这一端到不确定性这一端的方式排列在此连续区上。

　　第Ⅰ部分包括两章。

　　第1章：软件开发的变化全景

　　本章从概念上为整个软件开发项目管理(SDPM)学科提供了基础知识。它根据目标的清晰程度和解决方案的清晰程度对项目进行分类。它定义了一个四象限模型，作为讨论风险、团队凝聚力、交流、客户参与、变更、规格说明和业务价值的基础。

　　第2章：SDPM路线图

　　本章高度概括了5种SDPM策略以及能够在每种策略中找到的特定模型。对于每种策略，都讨论了其特性、优点和缺点。

第Ⅱ部分：线性ESPM

　　软件开发的线性方法是从瀑布模型的定义开始的。尽管瀑布模型的设计是从想法到部署顺序推进的，但它是一种不能倒退的方法。一个阶段一旦完成并得到批准，就不能再访问它了。只要需求被清晰完整地编档，且客户不再有变更请求，则瀑布模型就有效。

　　第Ⅱ部分包括7章。

　　第3章：线性SDPM策略

　　在第Ⅱ～Ⅵ部分中，每一部分都有一章是介绍性的，该章定义了那一部分中涵盖的项目类型的软件项目管理生命周期。被管理的软件开发过程本身的性质决定了对范围确定、计划、启动、监督/控制和收尾等各阶段有一些变化。线性SDPM类型的项目由标准瀑布模型和快速开发瀑布模型组成。

　　第4章：线性SDPM范围确定阶段

　　线性软件开发项目的本性决定了需求被完整而清晰地识别并编档。被称为“项目综述”的一种简短文档由客户和项目经理准备并签署同意。

　　第5章：线性SDPM计划阶段

　　纵观所有软件开发项目类型，计划阶段的运作方式可以从非常正式到非常不正式。尽管这样，所有的工具、模板和过程在计划阶段的某部分中还是明显的。这里的焦点将是工作分解结构(WBS)、进度和资源需求。

　　第6章：线性SDPM启动阶段

　　不管采用何种软件开发方法，团队都需要搞清楚他们如何共同工作并建立规则对工作进行操控。使用并发开发路径是快速开发瀑布模型的独特之处。这些并发开发路径称为“泳道(swim lanes)”，它们是本章的中心焦点。

　　第7章：线性SDPM监督和控制阶段

　　项目工作在进行中。本章的焦点是度量项目的进展和执行情况。其中的部分内容包括项目评审会议和范围变更管理。

　　第8章：线性SDPM收尾阶段

　　通过验收过程，客户将确认需求已得到满足，是向用户部署软件的时候了。与团队庆祝成功一样，吸取的教训也是收尾活动的很大一部分。

　　第9章：线性SDPM策略总结

　　每一部分的最后一章都对所介绍的模型进行比较和对照。本章讨论风险、模型的变更容忍性以及团队结构。

第Ⅲ部分：增量型ESPM

　　接下来介绍的一组变体集涉及增量模型。在这里，将完整的功能分块引入。可交付成果按顺序投入生产状态—— 每个块都比上一次增加更多的功能，以便系统逐渐增长。除了较早获得业务价值外，客户可能会发现能够合并到以后块中的改进。尽管线性模型不允许有变更，但是，增量模型至少允许某种变更。

　　第Ⅲ部分包括7章。

　　第10章：增量型SDPM策略

　　增量型SDPM只不过是多了一串线性SDPM。每个线性块都另外再添加一部分解决方案，直到最终形成完整的解决方案。除此之外，唯一的差别就在于较早地将部分解决方案投入生产，并生成业务价值。也可以以另一种方式来看待这种差别，即线性模型是只有一个增量的增量模型。分阶段交付瀑布模型和特性驱动开发模型是第Ⅲ部分讨论的两种变体。

　　第11章：增量型SDPM范围确定阶段

　　增量模型的范围确定阶段与线性模型是相同的。它们以相同的方式收集需求并将它编写成文档。这就意味着选择线性还是增量型可以推迟到需求被收集时。对需求可能不完整和不清晰的任何担心都可能导致您决定使用增量模型而不使用线性模型。

　　第12章：增量型SDPM计划阶段

　　为增量模型编制计划所要求的策略能够将功能分块，分成独立的和依赖的块。每个功能块都应该有足够的功能内容，以便使它成为有用的部分解决方案，当等待增加下一功能块时，能够将此部分解决方案投入生产。本章介绍了功能/特性分解结构，作为分块的辅助方法。

　　第13章：增量型SDPM启动阶段

　　项目团队在每个增量都可能有变化，线性模型则不是这样。这额外地加重了每个团队的负担。当项目从增量向增量推进时，他们将不得不确保从团队到团队的彻底移交。

　　第14章：增量型SDPM监督和控制阶段

　　在每个增量内，监督和控制活动与线性模型是相同的。关心的主要领域是范围变更管理。在一个增量中批准的范围变更可能会影响以后的增量，在范围变更管理过程中需要考虑到这一点。

　　第15章：增量型SDPM收尾阶段

　　每个增量内的收尾阶段是从一个团队向另一个团队的移交活动。这种移交需要一些与线性模型不同的文档。

　　第16章：增量型SDPM策略总结

　　这里只比较和对照了三个要点。第一点是与线性模型相比在每个增量发布中间版本，第二点是范围变更管理过程，第三点是增量之间的移交。

第Ⅳ部分：迭代型ESPM

　　增量模型与迭代模型之间的差别是很大的。当在项目开始时只知道一部分功能、需求和特性时，则使用迭代模型，选择此模型可以澄清这些信息。在迭代型ESPM中，解决方案按照在每次迭代知道的情况进行构建和部署。然后在下次迭代中使用它进行修改。这一过程一直持续到要求的解决方案构建完成。

　　第Ⅳ部分包括7章。

　　第17章：迭代型SDPM策略

　　这里的迭代被定义为一个开发周期，它向不完整的解决方案添加更多的功能和/或特性，以便使它逐渐趋于完整的解决方案。尽管迭代定义起来比较容易，但是必须考虑它有许多变体。例如，您可以对下面任何一种需求进行迭代：设计、功能、特性、易使用性或者编码。有四种模型适合于迭代型SDPM策略：动态系统开发方法(DSDM)、演化系统开发、Rational统一过程(RUP)和SCRUM(不是缩略语，而是来自橄榄球运动的一个术语)。

　　第18章：迭代型SDPM范围确定阶段

　　这里与前两种软件开发项目类型的主要差别是缺少完整的需求规格说明。其余三种软件开发项目类型都有此共同特点，只是不完整的程度不同而已。这三种类型合起来称为“敏捷软件开发”，它们使用“敏捷项目管理”方法来进行管理。迭代型SDPM策略是我们将要讨论的这三种策略中的第一种策略。从定义上来说，在迭代型SDPM策略中，需求收集不能在项目初期全部完成。您只能够完成其中的一部分，且必须依赖所采用的软件开发方法以及项目管理基础结构来识别其余的需求。换句话说，学习和发现的过程是这种策略和接下来两种SDPM策略的特点。

　　第19章：迭代型SDPM计划阶段

　　所有迭代软件开发方法都依赖于“即时计划”。只计划下一次迭代，且在直接相邻的前一次迭代完成时计划。

　　第20章：迭代型SDPM启动阶段

　　与到现在为止已经研究的那些SDPM项目相比，迭代型SDPM项目的团队领导模型和团队运作规则有很大的不同。甚至对于不同的迭代型SDPM模型，领导和团队运作规则也有很大的不同。

　　第21章：迭代型SDPM监督和控制阶段

　　在项目不确定性方面走得越远，项目状态报告的形式就越不正规。在不确定的项目环境中，书面报告变得相当罕见。在这些项目类型中，您主要寻找项目正在逐渐趋于一个可接受解决方案的迹象。

　　第22章：迭代型SDPM收尾阶段

　　每一次迭代都有它自己的收尾阶段。这一阶段包括的活动是，与客户一起确定如何前进到(甚至是否前进到)下一次迭代以及下一次迭代将包含什么。

　　第23章：迭代型SDPM策略总结

　　迭代型SDPM类别的四种模型之间存在相当大的差别。本章介绍这些差别，并讨论选择策略。

第Ⅴ部分：适应型ESPM

　　这一部分为目标清晰但解决方案不明确的那些项目介绍两种软件开发项目管理方法。在非正式调查中，绝大多数回答问题者证实，在多于75%的软件开发项目中应该使用适应型方法。遗憾的是，许多软件开发人员在线性方法明显很不合适的情况下，仍然试图采用线性方法。结果是很高的失败率伴随着这些项目。迭代型和适应型方法之间最值得注意的差别是有意义的客户参与。尽管迭代方法也需要一定程度的客户参与，但是，当转移到适应型ESPM时，则客户参与程度大大增加。

　　第Ⅴ部分包括7章。

　　第24章：适应型SDPM策略

　　从概念上来讲，适应型SDPM策略与迭代型SDPM策略有非常大的区别。首先要认识到，在适应型SDPM项目工作开始时，解决方案只有一部分是知道的，且必须发现和集成。而迭代型SDPM策略的用户也许不必处理这种情况。尽管两种生命周期都是迭代形式，但是，在适应型SDPM策略中，客户的作用是确定项目方向在哪里，而在迭代型ESPM生命周期中则没有这种作用。有两种模型遵循适应型SDPM策略：适应型项目框架(Adaptive Project Framework，APF)和适应型软件开发(Adaptive Software Development，ASD)。APF是一种健壮的模型，因为它不限于软件开发，而ASD则只限于软件开发。本章也讨论APF的两种变体—— 业务情况合理性论证和原型建立—— 以及如何将APF嵌入到其他SDPM模型中。

　　第25章：适应型SDPM范围确定阶段

　　确定适应型SDPM项目的范围经常是一个高层次的活动。因为解决方案不知道，或者最多知道一部分，所以详细层次确定范围会发生在整个项目生命周期中。这就意味着需求收集和计划也是即时活动。

　　第26章：适应型SDPM计划阶段

　　当您进一步移到不确定域时，适应型过程就变得比较轻松。我的意思是在项目管理方法中，文档和正式性所占的分量比较少。这种转变是从非增值工作向增值工作的转变。在适应型项目中，因为变更频繁，所以时间框架很紧。日常面对面的团队会议代替了内部状态报告。项目中的团队气氛更浓。WBS成为即时活动，依赖图和正式的项目进度表让位于白板上小幅度的团队进度安排。在适应型项目管理中，关键路径是没有意义的。

　　第27章：适应型SDPM启动阶段

　　在适应型SDPM中，保持团队坚实而有效是很重要的。必须清楚地理解角色和职责。团队领导有更多的协调活动，因为将有许多子团队工作于软件系统的某一个小小的方面。当项目从一个阶段过渡到另一个阶段时，团队领导可能会变更。

　　第28章：适应型SDPM监督和控制阶段

　　与以前的生命周期相比，这里的主要区别是变更成为生命周期不可缺少的有机部分。变更不再是附加物，而是必不可少的。解决方案将不会被发现，除非由变更来推进过程。

　　第29章：适应型SDPM收尾阶段

　　当适应型SDPM项目的每次迭代完成时，都有一个客户检查点。这一阶段决定项目的阶段性成功或不成功。对于到目前为止已经完成的东西，有一个质量检查，当新近发现的需求、功能和特性集成到优先方案中，并形成下一次迭代的计划时，有一个计划编制活动。

　　第30章：适应型SDPM策略总结

　　对第Ⅴ部分所讨论的两种模型做了比较和对照，并讨论何时使用它们，何时不使用它们。

第Ⅵ部分：极限型ESPM

　　在第Ⅵ部分中，您使用的模型所处理的情况是，关于目标，知道得非常少，关于解决方案，也许什么也不知道。关于什么可能会生成一个解决方案，也许脑际会浮现出若干想法，但您也许几乎没有证据来论证这些观点。将它视为纯粹的研究和开发(R&D)情况，离这种标志就不会太远。

　　第Ⅵ部分包括7章。

　　第31章：极限型SDPM策略

　　生命周期与适应型SDPM生命周期非常相似。只有查看到每个阶段内部时，才会出现差别。第Ⅵ部分涵盖了几种极限类型的模型，包括INSPIRE和极限编程。

　　第32章：极限型SDPM范围确定阶段

　　在大多数情况下，范围确定涉及到对项目在时间和成本、周期长度以及其他总体参数等方面的边界设置。

　　第33章：极限型SDPM计划阶段

　　计划是即时编制的，且不很详细。团队及其子团队认为怎么合适，就怎么指导他们的项目部分。几乎没有什么标准，因为这些标准容易压制创造性。

　　第34章：极限型SDPM启动阶段

　　这些活动使团队开始进行下一次迭代。当前一个周期的团队被新的团队所取代时，可能会有一些移交工作。

　　第35章：极限型SDPM监督和控制阶段

　　正如在适应型SDPM中一样，这是团队在其日常会议中执行的一个非正式过程。客户参与程度很高，且由于能完成的东西非常少，因此会偏离项目方向。不断地重新确定发展方向和重新制订计划是不可避免的事情，甚至在一次迭代内也是如此。

　　第36章：极限型SDPM收尾阶段

　　这里的收尾阶段有两个。一个是与刚刚完成的迭代相关的收尾活动，另一个是与项目本身相关的收尾阶段。迭代收尾活动包括，评审已完成的东西、评估可交付成果是否逐渐趋于一个解决方案以及考虑下一次迭代(假设有下一次迭代)应该做些什么。项目收尾活动包括的标准任务有：业务价值验证、实施后审计、以及吸取的教训。

　　第37章：极限型SDPM策略总结

　　对第Ⅵ部分所讨论的两种模型做了比较和对照，并讨论何时使用它们，何时不使用它们。

第Ⅶ部分：总结

　　这一部分综合回顾每种SDPM策略中的模型。包括进行总体比较、讨论仍然要面临的难题、以及对您可能如何逼近每种模型提出建议。

　　第Ⅶ部分包括2章。

　　第38章：您在何处

　　这一章比较仔细地考察软件开发项目管理的状态，它的优点和缺点，以及仍然要面临的难题。

　　第39章：您想要到达何处以及如何到达

　　这一章努力为软件开发项目管理构想一个结束状态，并试图构想到达此结束状态的一个计划。

附录

　　除前述各章外，还有两个附录会有助于您进一步获取信息和资源。附录A“网站上有什么”说明当您在与本书相关的网站www.wiley.com/go/espm上冲浪时将会发现哪些内容。附录B“参考文献”提供了进一步阅读的相关材料列表。

　　这两个附录之后还有许多附录，它们可以作为想要复习项目管理基础知识的那些人的介绍性材料。这些附录包括“项目综述”、“需求收集”、“工作分解结构”、“估计”、“项目网络图”、“资源进度”、“组织项目团队”、“项目绩效报告”和“业务过程流程图”。

本书特色

　　本书的编写风格和标准与我以前所撰写的畅销书Effective Project Management: Traditional, Adaptive, Extreme, Third Edition(Wiley, 2003)是相同的。这就意味着本书具有下面一些特色：

● 面向实践和面向应用。

● 可读性强。

● 提供了能够激起兴趣的实用讨论题。

● 为教师/导师提供了可用的图形和表格。

面向实践和面向应用

　　尽管我以前撰写的所有书籍都以概念和理论为基础，但它们也都是面向实践和面向应用的。我在所有书籍中都努力保持研究传统，同时为您减少从理论到实践的转化任务。与此同时，我设法对一个问题的不同方法进行比较，以便您总能明白采用哪种方法和为什么采用这种方法。对一些陷阱，我会向您发出警告信息。我的预想是，当您试图项目实现中需要的时候，您会打开我的书，翻到讨论工具、模板或过程如何使用的那些页。

可读性强

　　与面向实践和面向应用相一致，我的编写风格通俗易懂。我想要您感觉到我们好像彼此面对面坐着，就某一问题或主题进行交谈。我力图避免您只为获取一点有价值的信息就阅读整本书。

讨论题

　　Effective Project Management: Traditional, Adaptive, Extreme一书的第三版与第二版稍有不同，在第三版中，我力图使它对学术领域的人具有更大的吸引力，同时不减少第二版已经建立起来的专业人员市场。通过各种措施，这种方法取得了成功，这里采用与此相同的风格。

　　每章结尾处都有几道讨论题，老师可能在班上组织讨论这些题，或者也可能将它们布置成书面作业。这些讨论题不是您所喜欢的“列举出内战爆发的10个原因”这种类型的问题，我希望它们是耐人寻味的问题。虽然有许多错误的回答，但是它们也没有正确答案。我已经为老师生成了一个答案文件，只要给我发电子邮件到rkw@eiicorp.com，确定您是合法老师或者大学成员之后，我会将此答案文件发送给您。我很愿意收到您的来信，并了解您如何使用本书及其内容。

图文件和表文件

　　为了老师和其他可能想要使用本教材中图形和表格的人的利益，我准备了包含这一信息的文件。我只是要求在您的材料中标明出处。

网站上有什么

　　已经为本书读者构建起了一个注册网站。在此网站，您会发现以前曾提到的图形和表格文件。此网站的访问网址是www.wiley.com/go/espm。

本书应该如何阅读

　　本书可以简单地从前往后顺序阅读，这可以满足学术领域的需要。典型的学分课程可能涵盖本书的第1～39章。然而，如果您或您的学生需要了解项目管理的背景知识，则可以快速浏览附录部分。

　　但是，如果您有更加具体的需要，也可以单独阅读和参考每一部分，其他任何部分都可以跳过。每一部分都以一种特定的模型类型为目标，以适应专业人员市场的参考和应用需要。每一部分是彼此独立的，因此从业的专业人员只需要参考适合于他们项目应用的那一部分。如果您只需要一种特定的策略，则不需要阅读整本书。

小结

　　我撰写本书的目的是将软件开发生命周期和支持它们的项目管理工具、模板和过程的相关内容以一定的广度和深度整合在一起。我已经实现了这两门学科的整合。就我所知，这是第一本能够声明这么做的书籍。请大家来判断本书是否实现了这一目标，是否是关于软件开发项目管理这门正在出现的崭新学科的一本独特参考书。祝好运！也祝所有软件开发项目都有效并取得成功！

　　

　　

　　

　　

　　

　　

　　

目    录

　　

　　

第Ⅰ部分  ESPM的演化

第1章  软件开发的变化全景 3

1.1  什么是软件开发项目 4

1.2  什么是软件开发项目管理 5

1.2.1  要开发的软件的特性是什么 6

1.2.2  什么软件开发方法适合

于构建软件 9

1.2.3  什么项目管理方法适合

于管理软件开发过程 10

1.3  SDPM的复杂性/不确定域 11

1.3.1  风险与复杂性/不确定域 13

1.3.2  团队凝聚力与复杂性

/不确定域 14

1.3.3  交流与复杂性/不确定域 14

1.3.4  客户参与与复杂性

/不确定域 15

1.3.5  规格说明与复杂性

/不确定域 17

1.3.6  变更与复杂性/不确定域 18

1.3.7  业务价值与复杂性

/不确定域 19

1.4  平衡人员、过程、技术 20

1.4.1  人员驱动的环境 23

1.4.2  过程驱动的环境 23

1.4.3  技术驱动的环境 24

1.5  讨论题 25

第2章  SDPM路线图 27

2.1  当代软件开发全景 27

2.1.1  线性 28

2.1.2  增量型 32

2.1.3  迭代型 35

2.1.4  适应型 39

2.1.5  极限型 42

2.2  用于讨论SDPM策略

     的通用模板 44

2.3  讨论题 44

第Ⅱ部分  线性ESPM

第3章  线性SDPM策略 49

3.1  线性SDPM策略 49

3.1.1  范围确定阶段 50

3.1.2  计划和启动阶段 50

3.1.3  监督和控制阶段 50

3.1.4  收尾阶段 50

3.2  线性SDPM策略的类型 51

3.2.1  标准瀑布模型 51

3.2.2  标准瀑布模型的变体 52

3.2.3  快速开发瀑布模型 54

3.3  讨论题 59

第4章  线性SDPM范围确定阶段 61

4.1  解决方案定义 61

4.1.1  定义问题 61

4.1.2  确定原因 62

4.1.3  生成对解决方案的想法 62

4.1.4  确定想法的优先级 63

4.2  需求收集 63

4.2.1  定义和管理客户需求 64

4.2.2  收集客户需求 64

4.2.3  什么是需求 64

4.2.4  有哪些需求类型 65

4.3  客户签署同意需求 69

4.3.1  客户愿意签署同意 69

4.3.2  客户不愿意签署同意 69

4.4  项目综述 70

4.5  确保线性SDPM策略

     是正确的 71

4.6  讨论题 71

第5章  线性SDPM计划阶段 73

5.1  工作分解结构模板 73

5.2  依赖图 76

5.3  项目进度 79

5.3.1  标准瀑布模型 79

5.3.2  快速开发瀑布模型 79

5.4  资源需求 79

5.4.1  标准瀑布模型 79

5.4.2  快速开发瀑布模型 80

5.5  讨论题 80

第6章  线性SDPM启动阶段 81

6.1  团队领导模型 81

6.1.1  分层领导模型 81

6.1.2  团队负责人模型 82

6.2  组织线性SDPM策略

     项目团队 82

6.2.1  职权 82

6.2.2  职责 83

6.2.3  RASCI矩阵 83

6.2.4  团队会议 84

6.3  管理并发泳道 85

6.4  讨论题 86

第7章  线性SDPM监督和控制阶段 87

7.1  项目评审会议 87

7.1.1  标准瀑布模型的线性

SDPM策略 88

7.1.2  快速开发瀑布模型的

线性SDPM策略 89

7.2  范围变更管理 90

7.2.1  标准瀑布模型 90

7.2.2  快速开发瀑布模型 90

7.2.3  保护线性SDPM策略项目

不受范围变更的影响 91

7.3  里程碑趋势图 92

7.4  讨论题 94

第8章  线性SDPM收尾阶段 95

8.1  需求确认 95

8.2  验收测试过程 96

8.3  客户签署同意 96

8.3.1  仪式性验收 96

8.3.2  正式验收 97

8.4  收尾阶段 97

8.4.1  部署策略 97

8.4.2  项目文件 97

8.5  吸取的教训 98

8.6  讨论题 98

第9章  线性SDPM策略总结 99

9.1  比较和对照SDPM模型 99

9.2  需要牢记的要点 99

9.2.1  风险情况 100

9.2.2  变更的不能容忍性 101

9.2.3  团队结构 101

9.3  讨论题 102

第Ⅲ部分  增量型ESPM

第10章  增量型SDPM策略 105

10.1  增量型SDPM策略 105

10.1.1  范围确定阶段 106

10.1.2  计划和启动阶段 106

10.1.3  监督和控制阶段 106

10.1.4  收尾阶段 107

10.2  增量型SDPM策略的类型 107

10.2.1  分阶段交付瀑布模型 107

10.2.2  特性驱动的开发 109

10.3  讨论题 111

　　

第11章  增量型SDPM范围

          确定阶段 113

11.1  增量型SDPM策略的

范围确定阶段 113

11.2  对分阶段交付瀑布模型的

增量型SDPM策略的范围

确定阶段 114

11.2.1  开发项目的

“项目综述” 115

11.2.2  定义每个增量的编号

       和持续时间 115

11.2.3  识别要在每个增量中

       发布的功能 116

11.2.4  规划构建基于可交付

       成果的工作分解结构 117

11.2.5  确保可交付成果之间

       依赖结构的完整性 117

11.2.6  分配管理储备 117

11.3  对特性驱动开发模型的

增量型SDPM策略的范围

确定阶段 117

11.3.1  形成建模团队 118

11.3.2  指导领域走查 118

11.3.3  研究文档 119

11.3.4  开发小分组模型 119

11.3.5  开发团队模型 119

11.3.6  细化总的对象模型 119

11.3.7  编写模型注意事项 119

11.4  RBS的作用 119

11.4.1  在分阶段交付瀑布

       模型中的作用 120

11.4.2  在特性驱动开发模型

       中的作用 120

11.5  前导图的作用 121

11.5.1  在分阶段交付瀑布

       模型中的作用 121

11.5.2  在特性驱动开发

       模型中的作用 121

11.6  讨论题 121

第12章  增量型SDPM计划阶段 123

12.1  增量型SDPM策略的

计划阶段 123

12.1.1  分解需求分解结构 124

12.1.2  排定开发工作的顺序 125

12.2  对分阶段交付瀑布模型的

增量型SDPM策略的计划

阶段 126

12.2.1  构建完整的WBS 126

12.2.2  估算任务的持续时间 127

12.2.3  估算资源需求 127

12.2.4  构建前导图 127

12.2.5  分配功能和特性以

       确定各阶段编号 127

12.2.6  创建初始的项目

       进度表 128

12.3  对特性驱动开发模型的

增量型SDPM策略的

计划阶段 129

12.3.1  建立解决方案模型 129

12.3.2  构建特性列表和

       汇聚特性集 129

12.3.3  开发特性计划 130

12.4  讨论题 130

第13章  增量型SDPM启动阶段 131

13.1  增量型SDPM策略的

启动阶段 131

13.1.1  处理范围变更 131

13.1.2  增量移交 133

13.1.3  调度资源 133

13.1.4  安排增量进度 133

13.2  对分阶段交付瀑布模型

的增量型SDPM策略的

启动阶段 133

13.2.1  处理范围变更 134

13.2.2  增量移交 134

13.2.3  调度资源 134

13.2.4  安排增量进度 135

13.3  对特性驱动开发模型的

增量型SDPM策略的

启动阶段 135

13.3.1  范围变更会受到

       前导关系的影响 135

13.3.2  尚未开发的特性也许

       递不必要的范围变更

       请求 135

13.4  讨论题 136

第14章  增量型SDPM监督和

          控制阶段 137

14.1  增量型SDPM策略的

监督和控制阶段 137

14.2  项目评审会议 138

14.2.1  分阶段交付瀑布模型

       的增量型SDPM策略 139

14.2.2  特性驱动开发模型的

       增量型SDPM策略 140

14.3  范围变更管理 141

14.4  讨论题 142

第15章  增量型SDPM收尾阶段 143

15.1  增量型SDPM策略的

收尾阶段 143

15.2  对于分阶段交付瀑布模型

的收尾阶段的增量型

SDPM策略 144

15.2.1  验收标准 145

15.2.2  吸取的教训 145

15.3  对于特性驱动开发模型

的收尾阶段的增量型

SDPM策略 146

15.3.1  验收标准 147

15.3.2  吸取的教训 147

15.4  讨论题 148

第16章  增量型SDPM策略总结 149

16.1  比较和对照SDPM模型 149

16.2  需要牢记的要点 149

16.2.1  风险情况 149

16.2.2  变更的不能容忍性 151

16.2.3  团队结构 151

16.3  讨论题 152

第Ⅳ部分  迭代型ESPM

第17章  迭代型SDPM策略 155

17.1  迭代型SDPM策略 155

17.1.1  范围确定阶段 156

17.1.2  计划和启动阶段 156

17.1.3  监督和控制阶段 156

17.1.4  收尾阶段 157

17.2  迭代型SDPM策略的类型 157

17.2.1  演化开发瀑布模型 157

17.2.2  SCRUM 159

17.2.3  Rational统一过程 161

17.2.4  动态系统开发方法 163

17.3  讨论题 165

第18章  迭代型SDPM范围

          确定阶段 167

18.1  迭代型SDPM策略的

范围确定阶段 167

18.2  演化开发瀑布模型的

迭代型SDPM策略的

范围确定阶段 168

18.2.1  收集需求 168

18.2.2  生成RBS 169

18.2.3  定义初始解决方案的

       功能和特性 169

18.2.4  确定迭代的次数和

       时间箱 170

18.3  SCRUM模型的迭代型

SDPM策略的范围

确定阶段 170

18.3.1  想法生成 171

18.3.2  收集需求 171

18.3.3  定义要求的功能 171

18.3.4  划分功能的优先级 171

18.4  Rational统一过程模型的

迭代型SDPM策略的范围

确定阶段 171

18.4.1  建立业务模型 172

18.4.2  通过功能和特性列表

       描述核心需求 172

18.4.3  收集从功能和特性

       列表产生的所有用例

       的文档列表 172

18.4.4  制作各阶段和各迭代

       的高级概述 172

18.5  动态系统开发方法的

迭代型SDPM策略的范围

确定阶段 173

18.5.1  概述计划，以构建基于

       可交付成果的WBS 173

18.5.2  构建快速原型 174

18.5.3  定义受此项目影响的

       业务过程 174

18.5.4  划分功能优先级 174

18.5.5  开发功能之间的

       依赖结构 174

18.6  讨论题 174

第19章  迭代型SDPM计划阶段 175

19.1  迭代型SDPM策略的

计划阶段 175

19.2  演化开发瀑布模型的

迭代型SDPM策略的

计划阶段 176

19.2.1  识别也许缺少特性的

       那些功能 177

19.2.2  对缺少特性的功能

       划分优先级 177

19.2.3  将功能分配到迭代 177

19.2.4  创建此迭代的项目进度 177

19.3  SCRUM模型的迭代型

SDPM策略的计划阶段 178

19.3.1  当前的产品待

       完成工作 178

19.3.2  划分了优先级的

       待完成工作 178

19.3.3  Sprint待完成工作 179

19.4  Rational统一过程模型的

迭代型SDPM策略的计划

阶段 179

19.4.1  总体计划 180

19.4.2  迭代计划 180

19.5  动态系统开发方法的迭代

型SDPM策略的计划阶段 181

19.5.1  概述项目计划 181

19.5.2  识别功能并划分

       优先级 181

19.5.3  编档构架规格说明 182

19.6  讨论题 182

第20章  迭代型SDPM启动阶段 183

20.1  迭代型SDPM策略的

启动阶段 183

20.1.1  处理范围变更请求 184

20.1.2  处理解决方案移交 185

20.1.3  处理解决方案的

       首次展示 185

20.1.4  安排迭代 185

20.2  演化开发瀑布模型的

迭代型SDPM策略的启动

阶段 185

20.2.1  处理范围变更请求 186

20.2.2  处理解决方案移交 186

20.2.3  处理解决方案的首次

       展示 187

20.2.4  安排迭代 187

20.3  SCRUM模型的迭代型

SDPM策略的启动阶段 187

20.4  Rational统一过程模型的

迭代型SDPM策略的启动

阶段 188

20.5  动态系统开发方法的

迭代型SDPM策略的启动

阶段 189

20.6  讨论题 190

第21章  迭代型SDPM监督和

         控制阶段 191

21.1  迭代型SDPM策略的监督

      和控制阶段 191

21.1.1  项目进展报告 192

21.1.2  新特性/修订特性

       的发现 193

21.1.3  处理范围变更请求 195

21.2  演化开发瀑布模型的

迭代型SDPM策略的

监督和控制阶段 196

21.3  SCRUM模型的迭代型

SDPM策略的监督和控制

阶段 197

21.4  Rational统一过程模型的

迭代型SDPM策略的监督

和控制阶段 198

21.5  动态系统开发方法的

迭代型SDPM策略的

监督和控制阶段 199

21.6  讨论题 200

第22章  迭代型SDPM收尾阶段 201

22.1  迭代型SDPM策略的

收尾阶段 201

22.2  对于演化开发瀑布模型

的收尾阶段的迭代型

SDPM策略 202

22.2.1  迭代吸取的教训 203

22.2.2  项目完成吸取的教训 204

22.3  对于SCRUM模型的收尾阶

段的迭代型SDPM策略 204

22.3.1  Sprint计划会议吸取

       的教训 205

22.3.2  Sprint吸取的教训 205

22.3.3  项目完成吸取的教训 206

22.4  对于Rational统一过程

模型的收尾阶段的

迭代型SDPM策略 206

22.5  对于动态系统开发方法

的收尾阶段的迭代型

SDPM策略 207

22.5.1  接受解决方案 208

22.5.2  修订解决方案设计 208

22.5.3  修订功能模型 208

22.5.4  重复业务研究 208

22.6  讨论题 208

第23章  迭代型SDPM策略总结 211

23.1  传统项目与敏捷项目 211

23.2  传统项目经理与敏捷

项目经理 212

23.3  传统团队与敏捷团队 212

23.4  传统项目计划与敏捷

项目计划 212

23.5  传统范围变更管理与

敏捷范围变更管理 213

23.6  讨论题 213

第Ⅴ部分  适应型ESPM

第24章  适应型SDPM策略 217

24.1  适应型SDPM策略 217

24.1.1  范围确定阶段 218

24.1.2  计划和启动阶段 218

24.1.3  监督和控制阶段 219

24.1.4  收尾阶段 219

24.2  适应型SDPM策略的类型 219

24.2.1  适应型项目框架 219

24.2.2  适应型软件开发 228

24.3  讨论题 230

第25章  适应型SDPM范围

          确定阶段 231

25.1  适应型SDPM策略的

范围确定阶段 231

25.2  适应型项目框架模型的

适应型SDPM策略的范

围确定阶段 232

25.2.1  适应型SDPM范围

       确定阶段概述 233

25.2.2  什么是版本预算

       和时间箱 234

25.3  适应型软件开发模型的

适应型SDPM策略的范

围确定阶段 234

25.3.1  项目前景陈述 235

25.3.2  项目数据表 235

25.3.3  项目任务大概情况 235

25.3.4  项目规格说明大纲 236

25.4  讨论题 236

第26章  适应型SDPM计划阶段 237

26.1  适应型SDPM策略的

计划阶段 237

26.2  适应型项目框架模型的适应

型SDPM策略的计划阶段 238

26.2.1  完成项目综述 239

26.2.2  评审RBS的已知部分 240

26.2.3  确定周期长度 240

26.2.4  确定周期数量 240

26.2.5  划分已知功能的

       优先级 240

26.2.6  确定要构建的功能 240

26.2.7  确定要构建的试验

       性倡议 241

26.2.8  为要构建的功能和

       试验性倡议创建WBS 242

26.2.9  估计任务持续时间 242

26.2.10  创建一个资源受控的

        周期进度表 242

26.3  适应型软件开发模型的适应

型SDPM策略的计划阶段 242

26.3.1  项目启动阶段 244

26.3.2  项目时间箱 244

26.3.3  最佳周期数量和每个

       周期的时间箱 244

26.3.4  每个周期的目的陈述 244

26.3.5  将主要组件分配

       到周期 244

26.3.6  将技术支持和组件

       分配到周期 244

26.3.7  项目任务列表 245

26.4  讨论题 245

第27章  适应型SDPM启动阶段 247

27.1  适应型SDPM策略的

      启动阶段 247

27.1.1  处理范围变更请求 248

27.1.2  处理解决方案移交 249

27.1.3  处理解决方案的

       首次展示 249

27.1.4  安排迭代 249

27.2  适应型项目框架模型的

      适应型SDPM策略的

      启动阶段 249

27.3  适应型软件开发模型的

      适应型SDPM策略的

      启动阶段 250

27.4  讨论题 252

第28章  适应型SDPM监督和

          控制阶段 253

28.1  适应型SDPM策略的监督

      和控制阶段 253

28.1.1  项目进展报告 254

28.1.2  新功能/修订功能

       的发现 254

28.1.3  新特性/修订特性

       的发现 254

28.1.4  处理范围变更请求 255

28.2  适应型项目框架模型的

适应型SDPM策略的监督

和控制阶段 255

28.3  适应型软件开发模型的

适应型SDPM策略的监督

和控制阶段 258

28.4  讨论题 259

第29章  适应型SDPM收尾阶段 261

29.1  适应型SDPM策略的

收尾阶段 261

29.2  对于适应型项目框架模型

的收尾阶段的适应型

SDPM策略 262

29.2.1  刚刚完成的周期 263

29.2.2  最后的周期 264

29.3  对于适应型软件开发模型

的收尾阶段的适应型

SDPM策略 264

29.3.1  刚刚完成的周期 265

29.3.2  最后的周期 265

29.4  讨论题 265

第30章  适应型SDPM策略总结 267

30.1  传统项目与适应型项目 267

30.2  传统项目经理与适应型

项目经理 268

30.3  传统团队与适应型团队 268

30.4  传统项目计划与适应型

项目计划 269

30.5  传统范围变更管理与适应

型范围变更管理 269

30.6  讨论题 270

第Ⅵ部分  极限型ESPM

第31章  极限型SDPM策略 273

31.1  极限型SDPM策略 273

31.1.1  范围确定阶段 274

31.1.2  计划和启动阶段 274

31.1.3  监督和控制阶段 274

31.1.4  收尾阶段 275

31.2  极限型SDPM策略的类型 275

31.2.1  INSPIRE 275

31.2.2  灵活模型 282

31.3  讨论题 284

第32章  极限型SDPM范围

          确定阶段 285

32.1  极限型SDPM策略的

范围确定阶段 285

32.2  INSPIRE模型的极限型

SDPM策略的范围确定

阶段 286

32.3  灵活模型的极限型SDPM

策略的范围确定阶段 288

32.3.1  赞助者的前景 288

32.3.2  集体前景 288

32.4  讨论题 291

第33章  极限型SDPM计划阶段 293

33.1  极限型SDPM策略的

计划阶段 293

33.2  INSPIRE模型的极限型

SDPM策略的计划阶段 295

33.2.1  下一个周期的功能 295

33.2.2  下一个周期的试验性

       倡议 296

33.2.3  下一个周期长度的

       确认 296

33.3  灵活模型的极限型SDPM

策略的计划阶段 296

33.3.1  步骤1：评审和更新

       集体前景 296

33.3.2  步骤2：评审项目不

       确定性轮廓 297

33.3.3  步骤3：将项目分解到

       一组可交付成果集中 297

33.3.4  步骤4：估计每个可

       交付成果的大小 297

33.3.5  步骤5：以人/天为单位

       估算产生每个可交付

       成果的劳动量 297

33.3.6  步骤6：选择开发

       生命周期 297

33.3.7  步骤7：安排可交付

       成果的进度表 297

33.3.8  步骤8：商定时间箱 297

33.3.9  步骤9：评估技术需求

       和支持需求 297

33.3.10  步骤10：评估团队

        需求 298

33.3.11  步骤11：确定开发

        工具 298

33.3.12  步骤12：生成风险

        管理网格 298

33.4  讨论题 298

第34章  极限型SDPM启动阶段 299

34.1  极限型SDPM策略的

启动阶段 299

34.2  INSPIRE模型的极限型

SDPM策略的启动阶段 300

34.3  灵活项目模型的极限型

SDPM策略的启动阶段 301

34.4  讨论题 302

第35章  极限型SDPM监督和

          控制阶段 303

35.1  极限型SDPM策略的

监督和控制阶段 303

35.1.1  项目进展报告 304

35.1.2  处理范围变更请求 305

35.2  INSPIRE模型的极限型

SDPM策略的监督和控制

阶段 305

35.2.1  推测阶段 306

35.2.2  酝酿阶段 307

35.2.3  评审阶段 307

35.3  灵活模型的极限型SDPM

策略的监督和控制阶段 307

35.3.1  与最初的目标相比，迄

       今为止的结果是什么 307

35.3.2  项目优先级改变了吗 308

35.3.3  您打算如何重新调整

       最初的目标呢 308

35.4  讨论题 308

第36章  极限型SDPM收尾阶段 309

36.1  极限型SDPM策略的收尾

阶段 309

36.1.1  新的试验性倡议 310

36.1.2  扩展的试验性倡议 310

36.1.3  放弃的试验性倡议 311

36.2  对于INSPIRE模型的收尾

阶段的迭代型SDPM策略 311

36.2.1  吸取的教训 312

36.2.2  解决方案类型 312

36.3  对于灵活模型的收尾阶段

的极限型SDPM策略 313

36.3.1  解决方案的部署 313

36.3.2  吸取的教训 313

36.3.3  益处和识别 313

36.3.4  跟踪和收获的好处 314

36.4  讨论题 314

第37章  极限型SDPM策略总结 315

37.1  传统项目与极限型项目 315

37.2  传统项目经理与极限型

项目经理 315

37.3  传统团队与极限型团队 316

37.4  传统项目计划与极限型

项目计划 316

37.5  传统范围变更管理与极限

型范围变更管理 317

37.6  讨论题 317

第Ⅶ部分  总    结

第38章  您在哪里 321

38.1  企业的观点 321

38.2  客户的观点 322

38.3  项目经理的观点 322

38.4  开发团队的观点 323

38.5  跟踪您在哪里 324

38.5.1  过程跟踪 324

38.5.2  实践跟踪 327

38.5.3  项目跟踪 330

38.6  讨论题 343

第39章  您想要到哪里及如何

          能够到达那里 345

39.1  您想要到哪里 345

39.1.1  评审POS 346

39.1.2  收集需求 347

39.1.3  评估解决方案

       完全性状态 348

39.1.4  选择SDPM策略 348

39.1.5  不停地监督项目 350

39.2  您如何到达那里 350

39.2.1  评估过程的有效性 351

39.2.2  确定过程目标 351

39.2.3  确定过程目标的优先级 352

39.2.4  选择改进过程 352

39.2.5  识别改进倡议 352

39.2.6  启动改进项目 352

39.2.7  对照目标比较结果 352

39.3  讨论题 352

附录A  网站上有什么 355

A.1  快速交付比萨(PDQ)

     案例研究(MS Word文件) 355

A.2  图形主文件 355

附录B  参考文献 357

B.1  改变SDPM全景 357

B.2  传统项目管理 358

B.3  敏捷项目管理 361

B.4  综合在一起 363

附录C  项目综述 365

C.1  POS的组成部分 365

C.1.1  陈述问题/机会 367

C.1.2  建立项目目标 367

C.1.3  定义项目目的 367

C.1.4  识别成功标准 367

C.1.5  对假设、风险和障碍

      进行列表 368

C.2  附件 368

附录D  需求收集 371

D.1  满意条件 372

D.1.1  业务成果 373

D.1.2  里程碑评审 373

D.2  Volere过程 373

D.2.1  收集客户需求 374

D.2.2  Volere需求过程 376

D.2.3  可重用性 385

附录E  工作分解结构 387

E.1  生成WBS 389

E.1.1  自顶向下的方法 389

E.1.2  自底向上的方法 390

E.1.3  用于大型项目的

      中间WBS 391

E.2  测定WBS完全性的

     6个标准 391

E.2.1  状态/完成是可度量的 391

E.2.2  开始/结束事件被

      明确定义 391

E.2.3  活动有一个可交付成果 392

E.2.4  时间和费用容易估算 392

E.2.5  活动持续时间在可

      接受期限内 392

E.2.6  工作安排是独立的 392

E.3  构建WBS的方法 392

E.3.1  名词型方法 393

E.3.2  动词型方法 393

E.3.3  组织型方法 393

E.4  名词型方法 393

E.5  动词型方法 394

E.6  其他方法 394

E.6.1  地域 394

E.6.2  部门 394

E.6.3  业务职能 395

附录F  估计 397

F.1  估计时间、费用和资源需求 397

F.1.1  资源负荷与任务持续时间 397

F.1.2  任务持续时间的变化 398

F.1.3  估计任务持续时间的

      6种方法 399

F.2  估计的精确度 401

附录G  项目网络图 403

G.1  构造软件开发项目进度 403

G.1.1  项目网络图 403

G.1.2  构建前导网络图 404

G.1.3  依赖关系 405

G.1.4  创建初始项目网络进度 406

G.1.5  关键路径计算 408

G.1.6  近关键路径 409

G.2  分析初始的项目网络图 410

附录H  资源进度 411

H.1  构建资源进度 411

H.2  资源进度的范例 412

附录I  组织项目团队 415

I.1  问题解决 415

I.1.1  步骤1：描述机会和

      定义问题 416

I.1.2  步骤2：编译有关数据 416

I.1.3  生成想法 416

I.1.4  评估想法，并进行

      优先排序 416

I.1.5  开发实施计划 417

I.2  决策制订 417

I.2.1  命令型 417

I.2.2  民主型 417

I.2.3  咨询型 417

I.3  冲突解决方案 418

I.3.1  回避 419

I.3.2  斗争 419

I.3.3  协作 419

I.4  构建共识 419

I.5  自由讨论 420

附录J  项目绩效报告 421

J.1  监督和控制软件开发

     项目进度 421

J.1.1  进展报告系统 421

J.1.2  项目状态报告的类型 422

J.1.3  度量偏差 423

J.1.4  如何更新信息以及

      更新哪些信息 424

J.1.5  项目进展的收集和

报告频率 426

J.1.6  偏差 426

J.2  图形报告工具 427

J.2.1  甘特图 427

J.2.2  里程碑趋势图 428

J.2.3  挣值分析(也叫做成本

      进度控制) 429

J.3  详细程度 430

J.3.1  活动经理 430

J.3.2  项目经理 430

J.3.3  高级管理层 431

J.4  项目状态会议 431

J.4.1  什么是项目状态会议 431

J.4.2  哪些人应该出席会议 431

J.4.3  会议何时召开 432

J.4.4  会议的目的 432

J.4.5  会议议程 432

J.5  问题管理会议 433

J.6  变更管理 433

J.6.1  项目变更请求 433

J.6.2  项目影响陈述 434

J.7  问题升级 436

J.7.1  基于项目经理的策略 436

J.7.2  基于资源经理的策略 437

J.7.3  基于客户的策略 437

J.7.4  升级策略的层次结构 437

附录K  业务过程流程图 439

K.1  什么是业务过程 440

K.1.1  业务过程的特性 440

K.1.2  流线化工具 442

K.2  什么是业务过程改进项目 444

K.3  业务过程图形表示 445

K.4  业务过程流程图的形式 446

K.5  环境图 449

K.6  业务过程工作流程图 449

K.6.1  编档“As Is”业务过程 450

K.6.2  预想“To Be”状态 450

K.6.3  定义“As Is”与

      “To Be”的差距 451