敏捷项目管理

敏捷更多的是一种态度而不是一个流程，是一种氛围而不是方法。1994年，作者吉姆•柯林斯和杰瑞•珀拉(1994)基于他们的调查研究，写了名为《基业长青》(Built to Last)一书，其本意是想解答这样一个问题：“那些卓越不凡的公司与其他公司的差别究竟何在？”他们的一个重要发现是那些卓越不凡的公司往往创立一个永恒不变的基础，但其策略和做法是变化的，“有远见的公司将业务实践和商业策略(这些将不断地改变，以适应变化的世界)与永恒的核心价值和持久的目的(这些是永不改变的)区别开来。”

我认为敏捷软件开发在最近几年逐步得到认可并运用的一个原因是，该运动的发起者在《敏捷软件开发宣言》(Manifesto for Agile Software Development)中明确地表明了所信仰的东西，说出了我们的核心价值观和持久的目的。团队为何存在、我们要创造什么产品、为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。如果我们想要创造优秀的产品，我们就需要有优秀的人；如果我们想要吸引并留住优秀的人，我们就需要有优秀的组织，平等的精英这个核心价值观深深扎根于敏捷运动中。当然，这个唯一的核心价值观并不能制造产品，但核心价值观定义了大多数敏捷主义者对自己的认识。

我们生活在一个信息容量足以令我们茫然的时代。对于任何感兴趣的课题，我们都可以查找到成千上万的网页、数以十计(即使不是数以百计)的书籍、一篇接一篇的文章。但我们如何过滤所有这些信息呢？如何处理这些信息呢？核心的思想和原则提供了一个处理和过滤信息的机制，引导我们区别重要的和不重要的信息，帮助我们做出产品决策，并评估开发实践。

原则，或者说复杂性理论术语“规则”(rules)，对于工具和实践的实施方式会产生影响，实践则是将原则付诸于行动的方式。没有行动的宏伟原则纯属幻想，相反，具体的实践如果没有指导原则通常会被不恰当地处理。尽管实践的运用在各个项目团队之间可能是不同的，但其原则是不变的。原则就是简单的规则，是复杂的人类适应系统的生成规则。

《敏捷软件开发宣言》(Manifesto for Agile Software Development)[4]制定了4个核心价值观，其核心就是一个词：变革，这些价值观组成了敏捷项目管理的核心价值观：

我们通过实践和帮助他人实践，发掘出更好的[产品]开发方法，通过上述工作，我们形成如下价值观：

人和相互交流胜于流程和工具

致力于[产品][5]胜于编制综合性文档

与客户协作胜于合同谈判

适应变化胜于按部就班

也就是说，虽然右边的条目有价值，但我们更看重左边的条目。[6]

“这不应该理解为工具、流程、文档、合同或者计划不重要，一件或许重要的事情与一件重要的事情之间是有巨大差别的”(海史密斯2000)。工具对于加快开发和减少成本至关重要，合同对于建立开发者和客户之间的关系非常重要，而文档可以帮助交流，但左边的条目是最重要的。没有有技能的人、不致力于产品、不与客户密切交流以及不适应变化，产品交付几乎是不可能实现的。

尽管这些核心价值观宣言最初是为敏捷软件开发制定的，但只需稍作阐释和重新排序，它们就可以直接应用到敏捷项目管理中。

适应变化

适应变化胜于按部就班。这条宣言反映了敏捷方法的观点，它可以进一步归纳为：

●       构想—探索与计划—执行；

●       探索与生产；

●       适应与预见。

每个项目都有已知的和未知的条件、有确定因素和不确定因素，因此，每个项目都必须在计划和变化之间找到平衡，而且，这个平衡是必需的，因为项目多种多样，从不确定性较低的生产型项目到不确定性很高的探索型项目。探索型项目的特征是，其流程强调构想，然后根据该构想探索，而不是依照详尽的计划并相对严格地执行任务。两种风格并无对错之分，每种都或多或少适用于某个特定类型的项目。

影响项目管理类型的另一个因素是迭代的成本，即试验成本。即使非常迫切需要创新，但如果迭代的成本非常高，可能会导致某个流程有较多的预见性工作。而如前所述，低成本的迭代可以产生适应风格的开发，这种开发就是计划、体系结构和设计与实际的产品同时演变。

那些试图在如今动荡的经济中兴旺发达的公司必须改变他们的流程以及他们对于变化的看法。我们不再谈论项目15%到20%的变化范围，我们谈论的是在几个月的时间里都在变化的所有事情—— 范围、功能、技术、体系结构(但不是构想)。我一直惊讶于产品和项目的巨大变化，“按计划行事”这个项目管理的普通目标在这些情况下都以失败而告终。

在《人工制造》(Artful Making)一书中，哈佛商学院教授、我的同事罗布·奥斯汀及其合著者李·德温(2003)探讨了一个1.25亿美元的信息技术项目灾难，其中那家公司拒绝临时准备和改变在项目启动之前制订的详细计划，他们在书中写道：“制订并实施工作计划对他们来说就像是绝对的咒语一样不可改变，但它直接导致了该公司代价昂贵的、毁灭性的行动……。我们多么希望这种问题在商界是极少数的，但事实并非如此。”

致力于产品

致力于产品胜于编制综合性文档。创新推动公司的发展。3M公司的核心思想总是强调创新，摩托罗拉公司最近推出了新的移动电话创新方案，2003年初，通用电气公司将其格言改为：“拓展想象力”，该公司的董事会主席兼首席执行官杰弗里·伊梅尔特将创新和新业务作为最优先考虑的事情，他说：“懂得如何开发产品的公司也会尽力创造最大的股东价值，事情就是这么简单”(布德尔2003)。许多公司都有创新方案，很少公司愿意建立直接支持那些方案的流程和实践，从提供文档(顺序开发风格的特征)转变为提供迭代开发的真正产品是支持创新思想和做法的转变之一。

大型的、先投入的项目需要花费几个月，甚至几年。收集需求信息、提出体系结构然后设计产品，这个流程很容易造成大规模失败。为什么呢？因为团队以一种线性的方式前进，很少有可靠的反馈信息—— 他们有好的想法，但他们没有在现实这个大熔炉内检验那些想法。文档起不了什么作用，而产品可以。

敏捷开发和项目管理强调提供实际产品的重要性，或者在材料成本很高的情况下，提供实际产品的有效模拟或模型。完成需求文档只是证明团队收集了一组需求，而完成并演示一套产品功能可以证明开发团队可以提供一些实在的东西给客户。致力于功能可以向正在进行的开发流程提供可靠的反馈信息，而文档却不能。

同时，致力于产品并不排除对文档的需要，文档可以支持交流和协作、增强知识传递、保留历史信息、帮助改进产品并完成规定的和法定的要求。它们并非不重要，只是没有致力于产品重要。

然而，许多人在理解文档时存在一个基本的错误观念，即文档不是相互交流的替代品。当客户和开发者相互交流，共同制定技术规范，并作一些形式的永久记录(文档、笔记、草图、功能卡片和图纸)时，文档是这种相互交流的副产品。当客户与产品经理坐下来交流，他们写下需求文件，送到开发组，那么这个文件就变成了相互交流的替代品。第一个例子中的文档可能对于开发团队很有价值；而在第二个例子中，它变成了前进的障碍，几乎没有得到或者传递什么知识，而且，随着交流的减少，文档的数量通常会徒然地增加。

与客户协作

与客户协作胜于合同谈判。客户和产品经理也是敏捷开发的推动力。客户团队(取决于产品类型，参与者可能包括实际的客户、产品经理、产品拥护者或者其他客户代表)和开发团队结成伙伴关系，各方都有具体的任务、职责和责任。在高度不稳定、不明确和不确定的新产品开发工作中，客户和开发者的关系必须是协作的，而不应是敌对的合同谈判对手。

项目团队的目标是向客户提供价值。尽管在大企业里，有各种各样的利益相关方，但客户应该排在第一位。客户的定义可以用这样一个简单的句子表述—— 客户是用创造的产品生成商业价值的个人或群体，或者如果是零售产品，它指使用产品的个人。客户决定价值，其他利益相关方确定各种限制。如果我们混淆客户和其他利益相关方，我们的项目就会变得混乱。

客户规定提供价值的要求(功能)并帮助量化价值的商业目标(进度、成本)。现今，价值通过执行符合要求和限制的功能而体现出来，这些要求和限制在项目过程中不断演变；一旦交付某个产品，以后的问题就是如何迅速而又经济成本地使该产品适应未来出现的新要求和限制。成功的公式非常简单：今日交付，明日适应。

人和相互交流

人和相互交流胜于流程和工具。独特的、有才华的和熟练技能的个人，无论是单个或是群体，能最大限度地创造产品和服务。流程提供指导和支持，工具可以提高效率，但如果没有适当的、具备适当技术和技能的人，世界上所有流程和工具都不会产生任何结果，(适度的)流程和工具有用处，但如果要作重要决策，我们依赖的是个人和团队的知识和能力。

公司通常会发表词藻华丽的言论，说他们的人员是如何的重要，但却把他们束缚在呆板的程序和形式上。20世纪90年代，商业界曾有一段时期痴迷于流程，大部分的流程都是以业务流程重组为幌子。从表面上看，流程比人员更重要。业务流程重组支持者认为，结构化的流程可以在某种程度上弥补普通个人的能力，但任何流程都不能克服缺少优秀工程师、产品经理、客户、供应商和主管人员这个缺点。好的流程应该支持团队而非规定它的行动，流程应该适应团队而非反其道而行之。

敏捷项目管理支持的是创造者，而不是干事。我的同事罗布·奥斯汀定义了这两种类型个人的差别：

创造者的问题是他们想努力获取巨额奖励，以完美的方式实现他们的理想，否则他们认为不算成功；而另一方面，干事在弄清某项创新将创造多么大的经济价值(利润)之前，不会为之感到兴奋(奥斯汀2003)。

干事是企业成功的关键，他们计算着数字，谨慎地投资，没有干事的企业通常无法完成它们对员工、客户和投资者的责任。但如果没有创造者，干事就没有什么事可做。没有创新—— 新产品开发、新流程和实践、新的创造商业价值的方式—— 干事只有保管毫无价值的空壳，而没有干事提供的稳定基础，创造者可能会失去控制。

敏捷运动通过致力于自我组织、自律、平等主义、尊重个人和能力等观念，支持个人及其相互交流。“敏捷”是社会运动，它的两个推动力是：创造特定工作环境的意愿，以及认为“适应性强的”环境是向客户提供创新产品这一目标的关键这个信念。

4  2001版权属于肯特·贝克、迈克·彼德尔、阿雷·范·本内卡姆、阿里斯特尔·科克巴姆、沃德·坎宁安、马丁·福勒、詹姆斯·格雷宁、吉姆·海史密斯、安德鲁·亨特、荣·杰弗雷、布赖恩·马里克、罗伯特C.马丁、斯蒂夫·梅勒、肯·斯瓦布、杰夫·萨瑟兰和戴夫·托马斯。

5   宣言中针对的是“软件”，而我在这里使用了更为广泛的“产品”一词。

[6]  关于敏捷宣言的更深入解释，请参看(福勒和海史密斯2001的作品)。

 

项目经理、项目团队成员和高级主管面临的中心问题是：“项目管理如何为一个项目增加价值？”不幸的是，许多开发工程师认为项目管理是一个路障—— 是阻碍而不是帮助。项目经理被看作是行政管理人员，他们将所有详细的任务进度信息收集在一起，做上彩色的封面，不时用细小的任务折磨团队成员，并写下大量的工作进度报告交给高层管理人员，他们没有被看作是向客户提供价值的直接贡献者。开发团队通常认为项目管理是日常管理。正如《精益企业的产品开发》(Product Development for the Lean Enterprise)一书的作者迈克尔·肯尼迪(2003)所说的那样：“我们的产品开发原理更多的是基于出色的行政管理而不是卓越技术，而现在情况变得越来越糟。”

“买了比萨饼，然后走开”表达了许许多多的产品设计团队对于“好的”项目管理的观点。项目管理应该看作是激发灵感、集中提供客户价值的领导，而不应看作是日常管理。我们未能看到这点，是因为许多项目管理做法和项目经理将精力集中在合规活动，而不是提供价值，他们是项目行政管理人员，而不是项目经理。客户购买的是价值；所有其他事情都是日常管理—— 虽然有的是必要的，但终究还是日常管理。帮助符合政府条例的团队活动是必要的，但它们很少增加客户价值；符合法律要求的文档也是必要的，但也不能增加价值，至少不是直接地增加价值；工作进度报告帮助经理完成其受托的责任，但它们也不能增加价值；无数重要事件的审批权会迷惑管理人员，让他们以为一切都在控制之中，但它们也不能增加价值。

但我们如何衡量客户价值以及项目管理对该价值的贡献呢？摩托罗拉公司数10亿美元的铱星项目在市场上是一个悲壮的失败例子。相反，电影《泰坦尼克号》，严重超出了预算和时间，早期被批评家认为是2亿美元打了水漂，却成为全球第一部票房收入超过10亿美元的电影。从一般的依据遵从原则的项目管理惯例看，泰坦尼克号在预算、范围和进度等方面是一个失败；而在某些范围，铱星项目被认为是一个成功，因为它达到了起初的规定。

所有产品面临类似的要求：客户需要、利润、开发速度、持续的变革、高质量，它们都要求在多个专业领域内具备高水平的能力。产品开发中通常存在对立的限制和要求—— 速度与质量、功能齐备与低成本、不确定性与可预见性、机动性与稳定性，这些为那些集中精力提供价值的项目经理和项目管理实践提供了舞台。

敏捷项目管理是价值、原则和实践的结合，它协助项目团队与当今这个变化多端的环境进行搏斗。敏捷项目管理的核心价值观同时提到两个需要：创造敏捷、适应能力强的产品，以及创建敏捷、适应能力强的开发团队。

敏捷的定义

世上没有轻而易举得来的敏捷，敏捷不是银弹，你不能指望用简单的5步就实现它。那么敏捷是什么呢？我将敏捷归纳为以下两句话：

敏捷是促进变革并响应变化以便在动荡的商业环境中创造利润的能力。

敏捷是平衡灵活性和稳定性的能力(海史密斯2002)。

在如今不确定和动荡的世界里，成功属于那些有能力为竞争对手制造变化、甚至混乱的公司，制造变化能破坏竞争对手(及其整个市场系统)，适应变化能防止竞争冲击。制造变化需要创新：开发新产品、建立新的销售渠道、缩短产品开发时间、为日益增长的小市场定制产品。此外，你的公司还必须能够迅速适应竞争对手和客户制造的可预见的和不可预见的变化。

将敏捷的所有方面都发挥到极致的一个产品开发例子是小型便携式脱氧核糖核酸分析器。这些仪器投入商业使用仅仅5年多一点的时间，可以用来迅速分析疑似的生物恐怖病原体(如炭疽热)，迅速进行医疗诊断，或者进行环境细菌分析。这些仪器必须准确、简单易用，以及在各种条件下保持稳定，它们的开发得益于纳米技术、基因组研究和微流体学的突破。当时，6家公司参与了制造脱氧核糖核酸分析器的竞赛，得到了政府机构的批准，如美国国立卫生研究院(加德纳2003)，开发这些前沿的产品需要将灵活性和组织结构有效地结合、探索各种新技术以及通过缩短交付时间，为竞争对手制造变化。这些都不是传统的、常规性项目管理方法所能做到的。

一些人错误地认为，敏捷意味着组织结构松散，而组织结构松散或者缺少稳定性会造成混乱。相反，结构过于严密会产生僵化。复杂性理论告诉我们，创新即创造一些我们不能完全预见的新东西、突发的结果，通常在混乱和秩序、灵活性和稳定性之间的平衡点时最容易出现。科学家认为，突发事件、新奇事物的创造最容易在“混乱的边缘”发生。我们需要保持足够的组织结构，但不要太多，敏捷经理经常会问这样一个问题：“最少应该保持多少组织结构？”组织结构太多会抑制创造性，而结构太少会导致效率低下。

这种要求在混乱边缘保持平衡以鼓励创新是以流程为中心的方法通常失败的原因，它们以创新为代价，过于优化组织结构。敏捷组织不会迷失于一些灰色的中间地带，他们明白哪些因素需要稳定，哪些因素鼓励探索。例如，在高度变化的产品开发环境中，严格的配置管理可以保持稳定并促进灵活性，就像集中精力于卓越技术可以稳定开发努力一样。本书中描述的概念和做法的目的是帮助项目团队理解灵活性和稳定性之间的平衡，帮助解答如何保持稳定和如何制造变化这一问题。

敏捷意味着在一定的框架或背景下做出响应或者保持灵活。正如我在其他地方所说的那样，“许多传统的软件开发和项目管理方法的问题在于它们将背景定义得非常狭窄，即它们将项目的任务制定得太细，几乎没有任何空间来适应实际发生的变化。”(海史密斯2002)

在混乱边缘保持灵活性和稳定性之间的平衡需要有优秀的改进人员，他们需要具备这样的能力：立即有效处理因追求两个似乎不相干目标所造成的不明确事件和矛盾。支持这些改进人员的组织有如下3个主要特征：

●       欢迎变化的适应性强的文化；

●       最低限度的规则，鼓励自我组织，并结合自律以遵守那些规则；

●       在项目团体内紧密协作和相互交流。

在后面关于敏捷项目管理指导原则的章节，我将对每个特征作进一步的论述。

敏捷项目管理构架

项目管理流程和绩效评估对于基于探索和试验的方法和基于生产和技术规范的方法是不同的。以生产为导向的项目管理流程和做法强调完整的早期计划和要求说明，以后将尽量不会改动；而基于探索的流程也强调早期计划(但仅是名义上的)，也强调足够的要求和试验设计，但在随后，通过不断学习，做出重大改动。每个方法各有各的市场，但后者的周期与前者大不相同，敏捷项目管理构架包括5个阶段：构想、推测、探索、适应和结束，而每个阶段都有各自的做法。

这些阶段更近似于科学调查过程，而不是生产管理流程。构想阶段产生一个清晰明白的业务或者产品构想，为后面的阶段划出边界；在推测阶段，团队推测产品的规格，知道随着项目的不断进行，技术要求和客户要求会随着新知识的获得不断演变；然后是探索阶段，它是平行和迭代作业，其中要完成初步说明和设计，标上“不确定”的部分需要比那些较确定的说明或设计作更多的试验；在适应阶段，这些试验的结果需要经过技术、客户和企业的个案审查，适应性强的行动将融入到下一次迭代。

关于敏捷项目管理最常见的一个问题是：“如果分成计划、体系结构和要求3个阶段，情况会怎样呢？”简单地说，这些事情是活动而不是阶段，敏捷方法同传统的序列阶段方法一样，可以很容易地为这些活动提供非常多的时间，但这些活动将分散在多次迭代中。

第二个比较关心的领域是在敏捷开发中如果最初的体系结构工作(有关这部分的论述可以参看体系结构、计划或要求部分)中缺少了一个关键的部分所带来的重做风险，其实这个风险并不比顺序开发的风险高，只不过顺序开发没有提到而已，有的从最开始的体系结构就是错误的。在顺序开发流程中，早期体系结构决定是否有效要在项目周期的后期才能判断，而到那时，实际的开发已经进行，已经花费了大量的时间和金钱。即使还可能改变体系结构，也将是一项巨大的、昂贵的决定。

在这个通用的敏捷项目管理构架内，每个阶段的成功取决于一系列的实际指导工作的做法。其中一些做法非常简单、直接，比如我们将在第5章讨论的产品构想框和项目记录表；其他做法直接基于敏捷组织的核心价值观，如与客户做焦点访谈和迭代计划；而像工作量自我管理和参与式决策这些做法的主要目的是建立敏捷、适应性强的文化。价值观和指导原则描述了为什么要敏捷项目管理，而做法描述了如何做。

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10732849/viewspace-330850/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10732849/viewspace-330850/