适应性项目框架概述

第1章 适应性项目框架概述第1章适应性项目框架概述It is a mistake to look too far ahead.Only one link of the chain ofdestiny can be handled at a time. Winston ChurchillThere is no data on the future. Laurel Cutler， FCB/Leber Katz Partners公司副董事长1 每章的开篇引言都选自Lewis D.Eigen和Jonathan P. Siegel所著的The Managers Book of Quotations (纽约：AMACOM，1991)一书。我们在通过项目管理创造更美好世界的旅途中到达了一个十字路口。在继续前行之前，我希望您停下脚步，思考一下前面的路应该怎样走。我希望与您分享的是我在过去40年与您同行的旅途中总结出来的结论，这并不是在主张颠覆项目管理世界，只是想让您停下来思考一下正在发生的事情，以及我们如何应对这些事情。是时候注意一下不断变化的商业环境所发出的信号；是时候学习如何适应当今商业世界中快速而不断变化的、复杂而不确定的需求；是时候学会如何最佳地管理这些项目。复兴项目经理的时代已经来临，创造一个新的项目管理流程模式的时机已经成熟。这个新模式不应该是静态的，而应该是对团队、外部支持人员和客户(似乎总是不断改变想法的人)动态变化的模式必须适应不断变化的项目特点、环境和文化的模式。甚至这些新模式在从项目开始到结束的过程中也很容易发生变化。因此，一个有效的项目管理方法必须是能够不断评估项目整体环境以及适应不断变化的条件和情况的方法。复兴项目经理是一个打破常规的思想家是把创新和勇气灌输给开发团队和客户团队的人员。建议：对最近才感受到缺少有效项目管理流程所带来的痛苦并极力把传统做法应用于非传统项目的企业，我要对它们说：“不要浪费时间！”我认为有效的项目经理更像是大厨(chef)，而不是普通厨师(cook)。普通厨师只会按照食谱做菜，从未受训于烹饪食谱外的菜肴，只要按照食谱按部就班地进行，一切就会安然无恙。而大厨接受的是创造食谱的训练，为了适应变化的情况和限制因素，他可以适应任何食谱。我想现在您应该已经是一名普通厨师。在这本书中，我将会带给您成为大厨所需要的工具！1.1 适应性项目框架的基础让我们面对这个事实：世界不会因为您在管理一个项目而变得静止。因此，我们面临的挑战是要采纳并适应一种方法，以管理总是会遇到难以预料的变化的项目，以期望该方法在不妨碍项目、团队、客户、企业和市场的情况下能够进行自我调整。1.1.1 客户与顾客的区别我们首先澄清一些词汇。顾客是我们卖给其产品或服务的人；而客户是我们要与其合作解决问题或者共同利用未开发的或新的商业机遇的人。客户一词适用于适应性框架的项目，也是整本书中一直使用的一个词汇。1.1.2 APF项目团队APF项目团队由客户团队和开发团队组成。对于某些APF项目，客户团队或许只是一个拥有决策权的个人。而对于大型APF项目，客户团队或许会有几个成员，这样才能满足业务流程或者功能部门的需要。客户团队的成员在整个项目周期可能会发生变化，但总有一个人负责决策，这个人会和开发团队的负责人一起共同管理整个项目。开发团队由负责产生可交付成果的专业技术人员组成。其团队人员在整个项目周期也很有可能发生变化，但项目中总会有一个核心开发小组保持不变。开发团队中也会有一个人负责决策，这个人与客户团队经理一起共同管理整个项目。这两个团队的经理共同分享成功和承担失败。他们都必须拥有该项目的决策权。如果客户经理事事都要获得公司管理层的准许，那么您的APF项目将会严重受损。这种项目经理模式是APF独有的特点，也是一个关键的成功要素。这种管理模式最重要的特点是双方平等赋权并共同承担项目责任。APF项目团队是非常特别的团队，其成员大多是不需要监督便能工作的高级专业人员。他们所从事的项目很复杂，且充满大量的不确定性。所以，如果想要找到可接受的解决方案，他们就必须是创新型人才。创新型人才往往很独立，有可能不具备良好的团队协作精神。这对于项目经理来说是一种挑战。伴随着创造性而来的是成员的相对独立以及不受组织限制因素和呆板流程的羁绊。当需要特别指出时，我会分别用“开发团队”或“客户团队”这两个词，但当我使用“项目团队”这个词时，指的是由开发团队和客户团队共同组成的团队。1.1.3 初步认识APF您已经知道，在这本具有开创意义的书中，您将要探索的项目策略我称之为适应性项目框架。这绝对与您父辈们的项目管理不同，它是全新的。我甚至都不用“管理”这个词来描述它。它是一个框架，在这个框架里产生有效管理。如果必须选一个词描述它，那么我更愿意用“领导”，而不是“管理”。您将会发现，APF代表着项目思维方式和运行方式的转变。有一点需要指出，那就是它减少了诸如计划、重新计划和从不执行的任务等所有的不增值的活动。为什么要计划我们一无所知的未来呢？您绝对不应该基于对未来的某个猜想来制订您的项目计划，这会浪费太多的时间和金钱！此外，这也会严重影响项目风险。在APF中，计划是随时制订的。听起来自相矛盾，是吗？这样的计划或者基于我们已知的信息制订，或者基于上次计划制订后我们已知的解决方案制订。所以，APF计划是增量的。APF需要创造性思维 这种思维方式因变化而蓬勃发展，而并非躲避变化。所有APF项目共有的一个特点是在项目启动时不知道完整的解决方案；它随着项目的执行逐渐被发现和认知。这个发现流程将需要一套新的工具，而这套工具在任何其他敏捷方法中都不存在。这意味着APF项目管理流程必须自备一些对策以供认知和发现这套工具。认知和发现的结果会转化为解决方案中的功能和特征。因此，解决方案会累积增长直到项目结束。这种解决方案的累积构成普遍存在于所有敏捷方法之中。在APF中，认知和发现流程是结构化的。而在其他敏捷方法中，它却是偶发的。在一个APF项目中，开始会对解决方案有一个不完整的定义。您对这个解决方案也许知道的很多，也许知之甚少。对其知道得越少，找不到能够获得可接受商业价值的解决方案的风险就会越大。所有APF项目的一个共同特点是，项目团队中客户成员和开发人员通过他们创造性的、协作性的工作以及他们的专业知识，最终都能在规定的时间和成本限制内找到最佳的解决方案。提供认知和发现的机制就是向您的项目管理流程注入传统方法所不具备的内容事实上，其他任何敏捷方法也不具备这些内容。您必须与客户一起及时地验证在那个时间点确定的各种可能的解决方案。将这些行动称为“检验泳道”，其内容会在第3章中进行详细讨论。检验泳道创建认知和发现。当该泳道成功确认出另外一部分解决方案时，该部分便在后来称之为“集成泳道”的周期中集成进解决方案。这两个泳道定义出了APF中独特的、不存在于其他任何敏捷方法中的关系。APF显然也不是一个万能方法。该方法只是通过在每个周期中学习和发现更多的解决方案，从而适应不断变化的商业环境和项目状态。APF基于形式服从功能的原则。它从传统的线性和极限方法中汲取工具、模板和流程，使它们在适当的时机及时满足项目需要。APF是基于做中学原则的一个框架，这一点能保证：“一旦您构建该框架，它便是这些工具、模板和流程所需要的，这些工具、模板和流程也会随之而来。”不像极限管理项目那样只寻求最后一刻的正确(它应该如此)，APF项目每时每刻都在寻求正确。每个周期都会及时产生在那个时刻所了解到的解决方案的可行版本。这与创建产品原型非常类似。无论何时终止一个APF项目，当时的解决方案总能交付商业价值。APF以客户为中心，以客户为驱动，立足于一套不变的核心价值观(本章后面讨论)。APF相对于花费的时间和金钱，确保了最大商业价值。APF是高效的：它去掉了所有可能出现的不增值的工作。APF是使客户成为有意义的决策者和完全的决策者的框架。APF在请求者和提供者之间创建了合作伙伴关系，并确立了他们共同的责任。APF是一个100%有效的框架，没有例外！最后，APF项目是高风险项目。这不是流程导致的，而是项目本身所固有的特性。这些项目的成功完成对于企业来说至关重要，但其解决方案迄今为止却找不到。这也许是因为问题根本无法解决，也许是因为没有人能成功地找到一个有待发现的解决方案。如果通过有效项目管理能够发现这一解决方案的话，那么也只能通过使用APF才能做到。1.2 目标、解决方案、功能和特征如前所述，APF是为目标明确并已编制成文档但解决方案仅仅部分已知的项目而设计的。图1-1(在前言中也出现过)指明了APF在项目景观中的位置。APF可以用于敏捷项目管理象限中的任何项目(明确的目标、不明确的解决方案)，它是一个适应性项目管理生命周期模型。该模型适用于多种情况从最简单的仅仅一小部分解决方案未知的情况到最复杂的仅仅一小部分解决方案已知的情况。或许该解决方案只是一个简单的配合决策的算法。另一个极端情况是解决方案完全未知，因为问题是第一次出现，关于该问题知之甚少；也或许是因为该问题经常出现，但却一直捉摸不透它的解决方案。APF也可以用于既没有明确的目标也没有可用的极限方法的项目。图1-1 项目管理景观使用定义每个需求的功能和特征可以客观地表示出解决方案的已知程度。这些功能和特征也正是需求分解结构(RBS)的组成模块，在第2章中会详细讨论。RBS中的第一级是需求，第二级是功能，最低一级是特征，如图1-2所示。图1-2 需求分解结构您或许已经注意到RBS和以可交付成果为基础的工作分解结构(WBS)之间存在相似之处。本质上讲，RBS回答这个问题：“我们将要交付什么？”，WBS是 RBS的拓展并回答这个问题：“我们将如何交付？”因此，RBS作为一个子集包含在WBS中。从RBS开始，您可以继续分解，在分解结构的最低一层上创建以可交付成果为基础的WBS的形式。 当然还有其他几种WBS能够遵循的体系结构。有关WBS体系结构的详细内容和如何建造完整的WBS，请参考本书作者的另一本著作Effective Project Management：Traditional,Agile,Extreme Robert Wysocki博士，Effective Project Management：Traditional,Agile,Extreme，Fifth Edition(纽约：John Wiley & Sons，2009)。如果客户团队和开发团队确信RBS能够完全描述项目的解决方案，那么传统项目管理(TPM)方法就是正确的选择，很有可能会选用一些传统的线性或者增量方法。如果RBS不够完整，或者怀疑其不够完整，亦或者感觉项目期间有可能会出现变化，那么选用敏捷项目管理方法(APM，如APF)就会非常合适。RBS中未知的部分可能是一个或多个特征(这会直接导致应用APF)，或者是一个或多个功能(这会使得APF的应用更具挑战性)。但是，假如RBS不够完整，可能您和客户团队却觉察不到。大多数项目管理学者认为在项目启动阶段产生完整的RBS是不可能的。如果您同意这个想法，那么为您的项目采用一些诸如APF的敏捷方法将会是明智的做法。极端情况下，在项目进展过程中甚至能确认需求。只要目标明确且编制成文档，APF方法会是正确的选择。项目经理再也没有必要拼凑一些线性或者增量方法并期待着该方法能奏效。APF甚至可以在已经使用了TPM的情况下使用。随后我们将讨论这种情况。APF之所以不同于其他方法，是因为它能确保有效100%的情况下。65%的项目失败的事实 Standish Group，Chaos Report 2007：The Laws of CHAOS(波士顿：Standish Group International，2007)。甚至也不会影响到APF项目经理，因为他们正在使用一种防止失败的项目管理方法！1.3 传统项目管理(TPM)正如我们已经讨论过的，TPM方法需要完整的、定义明确的RBS。原因是只有这样才能产生完整的WBS和创建完整的项目计划。完整的WBS将会把所有必须要做的、符合规定和范围要求的工作确定下来。人们想要获得完整计划的原因包括： 能够为要交付的产品精确地编制文档 估计人力资源需求 制定项目预算 构建完整的项目进度表，从而可以进行资源投入在项目初期拥有一个如此完整的计划列表是一件非常惬意的事情。然而，这种情形却很少出现。更经常的是，总是会有变更请求出现，而一旦这些变更得到准许，资源需求也会随之变化，项目计划也需要随之变化。您开始知道把最初的资源需求和项目计划攒在一起是多么的浪费时间和人力了吧？APF能够节省下所有那些浪费了的时间！TPM方法一般包括两种模型。所有其他TPM方法都是这两种模型中的一个的具体示例。这两种模型定义如下，并至少各举一个具体示例进行说明。1.3.1 线性模型这些模型包括很多阶段，这些阶段按顺序更替，但没有反馈环。读者如果对此感兴趣，详情可参考本书作者撰著的Effective Software Project Management Wysocki，2009。一书的第39章。图1-3和图1-4是两个常见的TPM模型。请注意：两种模型都是线性的没有反馈环。图1-3 标准瀑布模型1. 标准瀑布模型瀑布模型已经应用了50多年，凡是有关系统开发周期的优秀书籍对该模型都有所讨论。虽然它原意是应用在软件开发项目中，但在非软件开发中也有所应用。图1-4 快速开发瀑布模型2. 快速开发瀑布模型快速开发瀑布模型出现较晚，它利用平行和近乎独立的“泳道”进行开发工作，从而使得产品能够快速进入市场。不要混淆快速开发瀑布模型和快速应用开发(RAD)。二者截然不同。分组进行高效快速的开发很具有挑战性。它需要各泳道之间尽可能保持相互独立。这些平行泳道保留着线性流程。图1-4描述的是平行泳道。创建这样的开发时间表要考虑这样几件事情。首先是风险。把工作限定在一个较短的时限内会增加出错误的机会和员工工作时间的冲突。工作量并没减少，只是完成项目所用的时间缩短了。将工作分配到并存的泳道中虽然缩短项目周期，但会增加项目完成的风险。把更多的工作挤压到一个较短的时间框内，这种做法使得从错误中恢复的时间缩短。项目中使用平行泳道的做法很有可能使得原本就冲突的资源使用情况变得更加糟糕。最后完成的平行泳道决定了整个开发项目的完成日期。显然，快速开发瀑布模型的风险高于标准瀑布模型。1.3.2 增量模型增量模型虽然的确只是线性模型的一个变体，但也值得单独讨论一下。和线性模型一样，增量模型也需要明确定义和编成文档的目标和解决方案。但是线性模型一次构建和发布所有可交付成果，而增量模型随时间推移分阶段构建和发布可交付成果。出于市场和早期销售的考虑，往往会选用这样的增量模型。例如，为了测试市场接受程度和其他变量而分阶段发布产品时，就往往选用增量模型。增量模型的缺点是客户会试图在两次增量之间提出范围变更请求。没关系，只不过需要在原来设定的项目时限内让出时间以供客户提出那样的范围变更请求、评估这些请求并就此采取相应行动。管理储备(Management Reserve)是应急时间，作为一项任务添加在项目进度表的末尾，以备流程和变化的不时之需。这在增量模型中是一个经常被忽略的细节。同样，开发团队在两次增量之间设有停顿时间，会诱使资源经理临时安排团队成员到别处工作。尽管他们总是会承诺说在下次增量准备启动前会归队，但归队的情况却很少出现。作为一种保证形式，保护团队免受成员流失之苦，通常会备有交接文档。这又增加了线性模型中所没有的工作。1. 分阶段交付瀑布模型当考虑使用增量PMLC模型时，您需要考虑增加的风险。图1-5就是一个分阶段交付瀑布模型的实例。图1-5 分阶段交付瀑布模型分阶段交付瀑布模型所面临的风险和其他增量模型一样。这种模型的限制因素是每次增量的内容。增量N段的可交付成果必须含有增量N-1段的所有可交付成果。这就可能影响或延迟向最终客户或市场发布足够的有价值的增量产品。最好的情况下，因为流程是累积的，所以虽然并非每个增量产品都包含足够的商业价值，但最后几次增量或许能提供足够的商业价值以供发布。详情请参阅本书作者的Effective Software Project Management Wysocki，2009.一书的第1016章。增量模型鼓励范围变化，但增量模型不应该用来进一步确认解决方案的未知部分或用来改进现有解决方案。那应该是APF的工作。2. 特征驱动开发模型特征驱动开发模型(FDD)(参见图1-6)与分阶段交付瀑布模型除了“泳道”的定义是围绕每个泳道所分配的功能和特征之间的技术依存关系不同之外，其余部分是相似的。 因为FDD是以技术为中心，所以它不必每次迭代时都交付商业价值。FDD最早出现于Peter Coad、Eric Lefebvre和Jeff Deluca合著的Java Modeling in Color with UML：Enterprise Components and Process Peter Coad、Eric Lefebvre和Jeff DeLuca合著的Java Modeling in Color with UML: Enterprise Componentsand Process(Upper Saddle River，NJ:Prentice Hall，1999).一书中。更全面的内容请参阅Stephen R. Palmer和John M. Felsing合著的A Practical Guide to Feature-Driven Development Stephen R. Palmer和John M. Felsing合著的A Practical Guide to Feature-Driven Development(Upper Saddle River，NJ:Prentice Hall，2000).一书。图1-6 特征驱动开发模型需要注意的是，要想有效地应用FDD，解决方案必须已知。先开发解决方案模型，基于它再创建WBS。这个功能WBS包含一个非常详尽的特征列表。根据技术依存关系和开发优先顺序把这个功能列表分组，相似功能归为一组。FDD通过设计和构建一组特征实现迭代。和快速开发瀑布模型相似，FDD对各部分解决方案进行优先级排序。但是在FDD中，优先级顺序会根据特征的相互依存关系而排列。随着解决方案中特征代码的增加，解决方案的商业价值也逐渐增加。中间产品解决方案也可以发布。和快速开发模型一样， FDD模型也可以设有多个设计/构建泳道，以同时进行特征或功能的构建。FDD提供特征块的早期版本，这样顾客从一开始就能够感受到商业价值，而无需等到完整方案完成后的一次性发布。分阶段交付瀑布模型可能需要经历几个开发周期之后才能使客户感到满意，累积的特征列表才具有足够的商业价值以供发布。FDD模型或者使用并行的泳道或者使用序列阶段或者两者兼用。1.4 敏捷项目管理(APM)对于TPM项目，变化是例外。对于APM项目，变化是常态。两者之间差别巨大，是两种截然不同的项目管理方法。由前所述，TPM项目使用线性或增量PMLC模型，而APM项目使用迭代或适应的PMLC模型，如下所述。如果解决方案并非被明确而完整的定义下来，那么您必须把该项目当做某种敏捷项目来处理，并使用适合的敏捷PMLC模型。敏捷项目主要有两种： 大部分解决方案已知这些项目其目标已被明确定义并编制成文档，其解决方案也到了最后完成的阶段，只需把最后一个或多个特征具体化。这些项目称之为最低限度敏捷项目。这样的项目应该使用迭代PMLC模型，但也可以使用适应性PMLC模型，对此本章随后部分会进行描述和说明。 大部分解决方案未知这些项目其项目目标被明确定义和编织成文档，但其解决方案的特征和功能还没有被明确确定并编织成文档。换句话说，大部分解决方案还未明确。这样的项目称之为最高限度敏捷项目。这些项目应该使用适应性PMLC模型，对此本章随后会进行描述和说明。本书把演变开发瀑布模型和Rational 统一过程定义为最低限度敏捷方法。也就是说，当大部分解决方案已知时，使用这两种方法会更有效。Scrum和APF是最高限度方法，当大部分解决方案未知时，使用它们更有效。实际上，有些项目经理执意把最低限度方法用于最高限度适应性项目中。这样做，他们或许会有一些成功，但最好还是使用适合那种项目的最高限度敏捷方法。1.4.1 迭代模型迭代模型属于最低限度敏捷方法。当我们了解了所有功能，但并没有像客户所希望的那样明确了解所有特征时，使用迭代的PMLC模型是最有效的。演变开发瀑布模型很好地说明了这一点，如图1-7所示。图1-7 演变开发瀑布模型1. 演变开发瀑布模型 这种方法一开始和标准瀑布模型非常相像。基于当前需求开发解决方案的已知部分，通过演变开发瀑布模型迭代开发解决方案的细节部分。伴随满足需求所需的特征和功能得以开发，需求或许会变化，但是对于原来的需求几乎没有任何增加或删改。当前版本的WBS会随着项目的开发、成本和资源需求一同创建。这种模型与风行许多年的产品-原型方法非常相似。很明显，该模型和传统模型所不同的是客户的有意义的参与对于敏捷方法的成功至关重要。项目团队中的客户成员而不是开发人员，是项目的主题专家(SMEs)。客户共同参与制定解决方案，并就进一步改进解决方案和改变特征与功能提供反馈意见。这个过程会随着版本的更新而持续进行，直到所有需求得以实现，客户达到满意为止。同样需要注意的是，这种模型总是呈现给客户解决方案的准生产型版本。在EDW模型中(参见图1-7)，认知和发现的过程显而易见。随着每次迭代的进行，对于解决方案探索得越来越深。这种方法使得客户和开发人员有机会共同研究当时的解决方案。这种方法对于简单和明显的改进项目比较有效。这里有一个变体值得一提。可能会有这种情况，即通过解决方案设计进行迭代或许会在顺序上超过通过版本进行迭代。尽管这样似乎和自适应模型的早期工作类似，但在此处如此使用效果会很好。通过设计进行迭代有助于客户理解解决方案，符合学习曲线。一旦他们理解了方案，就能更好地参与到通过版本进行的迭代开发中。设计迭代进行的很快。如果您拥有正确的设计工具，以我的经验，设计迭代的进行就是几天的事情，而不是数周或数月。发现更多特征的过程是客户与开发人员有意义交流的过程。客户与开发人员一起开发原型有时独立开发，有时合作开发。合作时需决定在下一次和接下来的迭代中如何开发或重新定义新的特征。有关这方面的详情，请参照本书作者的Effective Software Project Managemnet一书的第1723章 Wysocki，2009.。演变开发瀑布模型比较适合那些仅有一小部分解决方案没有明确的项目。选择在解决方案中如何代表一个特征也就能说明哪一小部分解决方案未知。开发团队只向客户呈现备选方案并让客户决定出更喜欢的方案，然后再实施它。但是当解决方案未知的那一部分非常重要时，在确定如何做某一具体决策时，就需要采用更有力的方法，即需要采用某些适应性PMLC模型。2. Rational 统一过程(RUP)Rational 统一过程(RUP)是一个以迭代方式构建解决方案的有完整文档的软件开发流程。有人也许会说RUP属于最大限度敏捷方法。我也是这么归类的。有关该方法的书籍和网络资源非常丰富，但首选Krutchen的The Rational Unified Process: An Introduction，Third Edition Philip Krutchen，The Rational Unified Process: An Introduction，Third Edition(波士顿：Addison-Wesley，2004).。RUP(如图1-8所示)包含4个阶段：起始、细化、构建和转化。与图1-8有关的代表这4个阶段的视觉图请参阅Krutchen相关书籍中的图2-2。RUP很有可能是最为人所熟知的迭代软件开发流程。它适合从重量级文档到轻量级文档的各种类型流程方法。RUP的基础在于大量可供重新使用的代码、需求和设计等。这些大量资源的建立是基于对以前项目经验的累积。这也意味着RUP有很长的投资回收期。从投资回报率的角度来看，RUP必须保证有充足的项目数量的累积，从中获取充足的经验，才能确保累积的经验有价值。4个或5个完成的项目可能足以开始产生回报。图1-8 Rational 统一过程模型RUP的使用非常广泛。当复杂性和不确定性低而解决方案并未完全确定时，RUP是一个重量级的过程。它需要大量的文档，尤其是代码重用的文档。每次迭代都从需求收集会议开始。前提是上一次迭代对未来项目的进行和下一次需求收集过程的进行有明确具体的方向指引。RUP项目所遵循的方向往往是对需求收集活动的反应。而APF是通过检验泳道主动寻求未知解决方案的模型。APF并非完全依靠被动的发现解决方案，它还主动采取措施以探求解决方案。正是这一特点使得APF与其他所有敏捷PMLC模型区分开来。RUP包含有4个在所有迭代中同时运行的阶段。起始每次迭代时通过一系列的需求收集会议，您统一对开发工作的范围的理解，然后制定出就范围如何开发的累积解决方案。人们寄希望于在每次迭代开始的需求收集会议上能够发现未被实施的解决方案。细化起始阶段的焦点是做什么，细化阶段的焦点是如何做。这是一个技术设计活动。本阶段的成果是适当的技术规格和计划。RUP是以体系结构为中心的流程，所以这些技术规格必须与前面所有迭代产生的成果结合起来。 RUP不像APF一样以客户为中心。RUP的前两个阶段分别等同于APF的版本范围界定阶段和周期规划阶段。构建这是RUP迭代的构建阶段。等同于APF项目的周期构建阶段。转化如果客户对这样的版本满意，认为其具有商业价值并能被组织接受，那么当时的解决方案会被投入生产。这等同于APF项目中的发布决策阶段。1.4.2 适应模型如果说迭代PMLC模型非常适合那些仅有小部分解决方案(典型特征)未被实施的情况，那么适应性PMLC模型就最适合那种相当一部分解决方案还未被确定的情况。最复杂的情况下，甚至连需求都不完整。APF是适应性PMLC模型的一种。还有其他几种，此处将简单讨论您所熟悉的几种适应性PMLC模型： 适应性软件开发(ASD) SCRUM 动态系统开发方法(DSDM)这些行之有效的模型非常适合它们各自所对应的项目，但局限是它们都是专为软件开发项目而设计的。接下来会对每一种模型简要概括一下。APF既可以用于软件开发项目，也可以有其他更广泛的应用。尽管它是APM家族的一个成员，但最初APF是为非软件开发项目而设计的，这也是本书的重点。APF最初被确定为用于流程设计项目(见Kamikazi 软件系统案例研究)和产品设计项目(参见第五大道小亭子案例研究)。1. 自适应软件开发(ASD)自适应软件开发(ASD)在James A. Highsmith 的Adaptive Software Development:A Collaborative Approach to Managing Complex Systems James A.Highsmith ，Adaptive Software Development:A Collaborative Approach to Managing Complex Systems(纽约：Dorsett House，2000).一书中得到了充分的描述。ASD 包含3个阶段：推测、协作和学习。这3个阶段相互重叠，如图1-9所示。图1-9 自适应软件开发模型推测推测阶段是对最终目标和解决方案会是什么样子进行猜测的阶段。其猜测结果或许正确，也或许与正确结果相去甚远。但这两者在最后的分析中差别不大，因为ASD自我纠正的本质最终会引领团队找到正确的解决方案。“最后一次做对”是最重要的。协作推测阶段已经完成，就该研究一下目前团队和客户所处的位置，以期找出最终解决方案。客户团队和开发团队必须协作共同发现解决方案。整个项目团队有什么伟大的发现？项目在随后的迭代中应该朝什么方向进发？学习从刚刚完成的阶段中学习到了什么？这些新学到的知识如何引导下一个阶段的进行？ASD生命周期模型图1-9也显示出ASD的详细阶段。项目启动 项目启动阶段旨在项目发起人、客户、核心项目团队和任何其他利益相关者之间建立明确的预期。这也是您讨论、议定和批准项目综述的阶段。对于历时较长的(超过6个月)项目，举行一个为期23天的启动会议是个很不错的主意。在这段时间里，项目团队收集需求、编制文档和编写项目综述。作为项目启动的一部分，要为每次迭代准备一个简短的目标说明。尽管这些目标会随着解决方案的细节得以开发而发生改变，但至少能使项目发起人、客户和开发团队了解他们的工作方向。适应性周期计划 启动会议的可交付成果还包括项目时限、最佳周期数量以及每个周期的时间框和下一个周期的目标说明。每个周期都是从为下一个周期要做什么而制定计划开始。这些计划都是高级计划。功能计划分配给分队去做，细节的东西也留给分队去制定。这与传统项目管理不同，传统项目管理需要管理层监督制定详细的计划。ASD轻管理流程。并行组件开发 为每个功能组件建立几个并行的泳道。每个分队负责开发本周期计划完成的一部分功能。质量审核 这是客户对已经完成的解决方案进行审核并做相应修改的阶段。这个阶段或许也会出现新的功能，也会重新排列后面周期待开发的功能的优先顺序。最终品质保证和发布 在这时，客户会宣布需求已实现，然后进行最终的验收测试和产品发布。2. ScrumScrum一词来源于橄榄球(其本意是争球)。争球使得整个球队在球场上跑来跑去，让人看起来会很特别甚至有点混乱。在所有的迭代方法中，Scrum似乎确定的是一个无序的开发环境。Scrum软件开发团队自我引导、连续进行为期一个月的迭代、举行日常团队会议、不断向客户就现行解决方案做演示并在每次迭代最后调整开发计划。要想全面了解有关Scrum的软件开发方法，请参阅Ken Schwaber和Mike Beedle合著的Agile Software Development with Scrum Ken Schwaber和Mike Beedle，Agile Software Development with Scrum(Upper Saddle River，NJ: Prentice Hall，2001).一书。本书所讨论的所有开发模型中，Scrum显然是一种客户-驱动的方法。客户确定功能和特征并排列其优先级，团队再把它们按优先级排列到各个阶段，并一次构建一个阶段。这个流程允许客户随着对解决方案在前面迭代中的深度挖掘而改变功能和特征。Scrum流程图如图1-10所示。图1-10 Scrum流程图提出想法该系统的最初想法或许很模糊。或许用商业术语的形式来表示。作为范围界定阶段的一部分，该阶段会制定出对功能的描述，但不会像客户要求的那样详细，也不大可能用系统术语表示。产品拥有者开发功能清单和排列优先级产品拥有者负责制定这个叫做产品功能清单的列表。它能够帮助团队成员了解更多的有关该想法的细节并帮助他们构思如何处理这个项目。冲刺计划会议这是一个8小时会议，分为两个阶段，各含4个小时。在第一阶段中，产品所有人向开发团队提供已经排列优先级的产品功能清单。这也是团队提出问题以阐述清楚每个功能元素的机会。在会议的第一阶段，团队向产品主人承诺将在第一个30天的冲刺中交付这些功能。然后团队会利用剩下的4个小时制定如何完成这个冲刺的高级计划。要做的工作都记录在冲刺功能清单中。冲刺功能清单是当前冲刺阶段尚未完成的当前功能列表。冲刺功能清单这是为交付本次迭代的产品功能清单而必须完成的任务列表。演示冲刺功能本次冲刺结束时，团队向客户演示解决方案。或者增加功能或者改变功能，产品功能清单得以更新，并就下次冲刺重新排列优先级别。整个流程一直持续到功能清单清空；或者客户对现行冲刺版本非常满意，认定其为最终方案；亦或者超出预算。建议：Scrum经常被认为是不需要项目经理的方法。事实上，虽然项目经理的职位不存在，但其角色存在。其角色主要是由高级开发人员以自我管理的方式来承担。Scrum经理承担促进和遵循流程的责任。合作对于Scrum团队来说至关重要。超过10人的Scrum团队往往是多功能团队。我的一个客户曾提到过一个有关Scrum应用的有趣案例。您当法官，但请保持开放的心态。这个客户的所有软件维护项目都安排在一个产品维护功能清单文件中并由产品维护功能清单经理排列优先级顺序。该经理同时负责估计每个维护项目的工作量和资源需求。该经理是一个分配到他们的项目管理办公室的项目管理顾问。并非所有的开发人员都100%的去开发Scrum项目。在他们的Scrum项目分配中会有延迟。在这些延迟的时间里，开发人员负责定期检查产品维护功能清单和对在那儿发现的问题进行维护。其目的是清空功能清单列表。定期报告功能清单列表的大小和日期成为实现目标的措施。3. 动态系统开发方法(DSDM)动态系统开发方法(DSDM)和零重力世界的瀑布模型一样。反馈环是区分DSDM和标准瀑布模型的定义特征。DSDM的支持者声称该方法能比传统PMLC模型在更高质量、更少成本的情况下以更快的速度交付结果。DSDM是自适应模型。这些反馈环有助于引导客户和项目团队找到完整的解决方案。商业案例作为反馈环也被包括在内，这样即使是项目最根本的依据和理由都可能被重新审议。DSDM声称是唯一一个从头到尾涵盖整个系统生命周期的公共框架。以下是DSDM的8个主要原则。这些原则与我们前面所提到的好的做法非常相似。用户积极参与也十分必要。(1) DSDM团队必须拥有决策权。(2) 重点是频繁交付产品。(3) 满足商业目标是对可交付成果进行验收的根本标准。(4) 迭代和增量开发对于获得精确的商业解决方案十分必要。(5) 开发过程中所有的变化都是可逆的。(6) 需求基线处在较高水平上。(7) 测试贯穿整个生命周期。(8) 所有利益相关者之间的合作和协作必不可少。大部分敏捷PMLC模型都遵循这些原则。除了有轻微变化外，这些原则同样也适用于APF PMLC模型，对此下一小节将进一步讨论。图1-11显示的是DSDM方法。图1-11 动态系统开发方法DSDM方法的显著特征是在每个周期结束时增量发布和实施产品系统。请注意在实施阶段之后会围绕着设计和构建迭代进行数次迭代。DSDM把向客户交付商业价值作为其整个流程设计的一部分。其他方法有时可能也如此，但DSDM 把它作为本身设计的一部分。项目前期：想法产生这个阶段包括项目概况、项目章程或者旨在支持决定该项目可行的高级商业案例。批准项目进行的决定一经作出，项目就开始筹集资金，可行性研究也着手进行。可行性研究团队必须作出是否在该项目中使用DSDM的决定。在进行可行性研究时，会增加DSDM方法是否适合该项目的问题。要想回答这个问题，应着重考虑组织对DSDM的支持程度以及现有项目团队成员的能力。DSDM可行性研究虽然并非内容翔实的论文，但却要求其具有非常高的质量。可行性研究阶段最多花费两个星期的时间。记住：您只需决定是否使用DSDM方法即可。业务学习客户团队协同开发团队对受项目影响的商业流程做高级别调查并确认信息需求。调查最好在合适的中小型企业的车间里进行。高层次流程和数据流程图产生，需求被编织成文档。系统体系结构确定，但是它有可能会随着项目的进展而变化。最后，制定出高级计划。该计划将在功能模型迭代和设计与构建迭代阶段确定出预期模型(如果有的话)。功能模型迭代在这个阶段，通过一轮轮重复下列任务，功能模型和信息需求得以精炼： 确认这个周期做什么。 决定怎么做。 执行。 检查以确保做得正确。设计和构建迭代这些迭代会选择优先级别高的需求，对他们进行设计和构建。生产原型通常也在这个阶段得以开发。每次迭代交付部分解决方案，从这个阶段开始完整解决方案得以交付。实施产品由开发转到生产。所有典型的实施活动都发生在这个阶段，包括安装、培训、文档、运营支持和用户支持。项目后期产品经过一段适合的使用期后会被审计。产品接受修改意见和其他一些系统的改变，在新的版本中把这些修改和改变构建进去。DSDM在非IT项目中虽然很明显DSDM是系统开发框架，但也可以应用于与IT没有任何关联的项目。这也正是我们的兴趣所在。“Try&Buy百货公司”的案例能够说明DSDM在培训课程开发项目中的应用。信息系统部由184个顾客小组组织起来，每个小组都有适合自己项目管理方法的工具、模板和流程，所以课程开发是个很有挑战性的项目。最终的课程必须支持这个环境，因此应该选择使用DSDM方法。1.5 案例研究：Try&Buy百货公司DSDM方法可行性研究中对所有2000个项目经理的技能进行了评估和差异分析，从而确定技能开发的需要。系统体系结构定义提供了有关课程表、课程和它们的形式的整体结构。现有课程也被放入该结构。为了使员工能有意义的参与到开发工作中去，功能迭代完全在车间环境中进行。只需要进行几次迭代就能确定特定课程、课程内容、辅助材料、支持服务和开发进度。投入4个开发团队进行设计和构建迭代。每个团队以不同的项目经理职位为中心：团队领导、项目经理、高级项目经理和程序经理。每隔两周，每个团队开发一个课程模型。一旦模型稳定了，所有4个团队就聚在一起开发最终的课程模型。随之而来的是构建阶段。这些团队认为分阶段开展是最好的实施策略。解决方案的晚期版本包括建立培训和指导服务以及课程修订等内容。从这个示例可以看出，DSDM是一个可以应用于既定情况下的框架。1.6 适应性项目框架我确信在带您遍览各种项目方法并简单讨论其具体模型时，一定挑战了您的耐心极限，但这是很有必要的。现在您可以把APF与各种项目管理模型作对比并理解它是如何填补其他模型所留下的空白的。对于具有不明确解决方案的任务攸关型项目，APF呈现给您的是一个完全不同于其他敏捷PMLC模型的管理方式。主要区别是APF是一个主动寻求解决方案的模型，而其他所有敏捷PMLC模型基本上都是消极被动的。我这么说的意思是，其他所有敏捷PMLC模型的解决方案与其说是积极寻求的结果，不如说是该方案自动产生的结果。APF为了寻找解决方案的未知部分，使用检验泳道，该泳道与集成已发现的部分解决方案的泳道同时并行。检验泳道有多种类型。检验泳道对于APF来说是独一无二的。本小节随后会对此进行讨论。APF仍然处于发展过程中。它于2001年首次推出，是一个工业模型，为最大限度的适应性项目而设计。该方法包括5个阶段，是一个旨在每个周期在客户规定的时间和成本限制范围内向客户交付最大商业价值的方法。本小节主要讨论一下APF和其他模型的不同之处。我想讲述一下早期的思想和观念，以便于您理解后面相关的内容。在即将开始讨论APF的理念和做法时，请您保持开放的心态。不要让古老的做法和陈旧的原则束缚自己。APF将为您打开一个充满各种可能性的全新世界。1.6.1 APF的根源APF始于两个同时进行且碰巧有很多相似之处的咨询业务。第一个业务是与一个零售商合作，他要在他的店里面安装小亭子。这些小亭子提供最新的产品特价信息和产品在商店里的位置信息，以及提供其他顾客服务等。“第五大道小吃”项目是有关该公司应用APF的最初版本的案例研究。第二个业务是与一家软件开发公司合作，该公司为其客户设计和构建internet和intranet应用。Kamikazi系统开发公司是有关该公司应用APF的最初版本的案例研究。这两个案例研究都列在这里，但是为了保护两个公司的真实身份，名称和行业已经做了更改。尽管这两个项目很不一样，但却有一个共同之处：两家公司都知道最终目标，但都不知道详细的解决方案。这两个项目的问题是：“您将如何管理这些既没有完整的需求分解结构也没有完整的工作分解结构作为项目计划的基础的项目？”两家公司多多少少用的都是传统线性项目管理方法。两家公司都很清楚这个方法不再奏效，但是什么方法奏效呢？需要找一些不同的方法了。这个需要是开发APF的同时也开发项目本身的动力。两个项目都成功完成了，APF成为了现实。从那时起，APF在大量不同的组织中得以成功运用。我知道它曾应用于大型保险公司中，为其开发新的金融产品、设计和构建计算机广告和短期主题影片、为顾客产品公司进行产品研发、从事药物研究和其他应用等。我仍然认为APF是一个在制品，因此会通过自己的咨询业务和分享的别人的经验来继续扩展和美化APF。我所有有关APF的认知和发现最终都会编撰成文字。这本书是个开始。某种意义上说，开发APF本身就是一个APF项目！APF与较为传统的系统有某些偏离。1.6.2 范围是变量APF偏离传统思维的第一点是APF项目范围是可变的。这让许多具有传统思维的项目经理和客户感到很不安。APF通过在每个完整的周期调整解决方案的范围来实现商业价值最大化。它把客户放在中心位置，让客户决定怎样才能实现最大的商业价值，让客户负责决定应该做出什么变化，从而实现范围的调整。在每个周期结束时，客户基于前几个周期累积的知识可以对项目方向作出改变。这意味着APF项目的路线是不断修改的，其目的是确保交付最大的商业价值。在最后周期结束时，也就是钱或时间或两者都用光时，把所有客户团队和开发团队集体智慧和知识融于一体的最大商业价值也随即产生。范围银行(Scope Bank)已经成立，把所有前面周期还未实施的想法都吸纳进来，这样在APF项目结束的时候，范围银行内可能还有很多一旦时间、金钱和资源允许就可以被集成进解决方案中的额外的特征和功能。这些未经实施的特征和功能成为了“版本2”的素材。所以我们说通过学习和发现而实现的改变不仅可以被接受，而且还是所有APF项目成功的关键因素。1.6.3 APF即时(just-in-time)计划因为范围是可变的，APF项目计划承载的就是全新的意义。APF项目暗含的基本理念是不计划未来：未来是未知的。部分解决方案存在于未来，有待于去发现。一旦发现它，就集成进解决方案。APF计划不预测未来然后再计划未来。APF不是消极被动的模型。它试图通过称为“检验措施”(probative initiatives，有关它的更多内容请参见第3章)的方法来发现未来。试图预测未来是浪费时间，只不过是增加已存在于项目中的不增值的工作。APF以功能为