敏捷.敏捷项目管理V2.Jim Highsmith

吉姆·海史密斯（Jim HighSmith）是ThoughtWorks的执行顾问。从事IT行业工作的30年间，他先后担任过IT经理人、产品经理、项目经理、咨询顾问和软件开发师。

吉姆撰写了《敏捷项目管理与项目创新》、《敏捷软件开发的生态系统》，以及获得“震撼奖”的《弹性软件开发—-一种管理复杂系统的协作模式》等著作，而且他还是2005年“史蒂文斯国际系统开发杰出贡献奖”的获奖者。

盲目的增加流程和文档需求经常会导致重重问题，特别是当流程根本没有考虑到敏捷方法坚持最低限度的原则时。吉姆●海史密斯在此书中阐明了如何在不牺牲创意、设计、编码和测试效率的前提下保持软件开发的有效性。这本书让读者看到代码的含义不言自明，比任何冗长的解释都更加明朗清晰。

《敏捷软件开发宣言》(www.agilealliance.org)于2001年春问世.无论是新产品开发、新服务提供、软件应用程序，还是项目管理，这场运动的宗旨是要实现两个基本目标:向客户交付创新产品(特别是在高度不确定的环境下)和为员工创造一一个期望的工作环境。

这本书的目标读者群是项目经理，即带领团队穿越那令人激动但往往又凌乱不堪的流程、将构想转化为产品(无论产品是手机还是医疗电子仪器)的精神饱满的个人。敏捷项目管理反对将项目经理看作是仅仅严格按照日程表和预算要求执行的执行者，它认为项目经理的工作应该与帮助团队交付产品密切相关。

本书主要探讨4大主题:机会、原则、架构和做法。

• 机会存在于创造创新产品和服务的过程中。这些产品在开始时无法完全确定的，但随着时间推移，它们可以通过实验、探索和适应不断演变。敏捷项目管理创造为客户交付价值并适应未来需要的产品。其架构(企业架构或者项目架构)都有助于协助团队在面临变化、不确定和混沌时依然交付可靠的结果。
• 最后，做法一从开发产品构想框到参与决策，为项目团队交付结果提供可行的方法。

在本书中，提出和更新了5个新的主题:敏捷价值观、敏捷项目扩展、发布计划、项目治理和项目评估。

• 第2章~第4章分别讲述3个价值观:交付价值胜过满足约束、领导团队胜过管理任务、适应变化胜过遵循计划。
• “敏捷项目扩展”- 新增了一个新的章节，提醒团队应该把更多的注意力放在发布计划上。
• 最后，新增了- -些关于项目治理和变革评估方法的章节。

我们一方面要求团队敏捷，另一方面却严格按照铁三角(范围、进度和成本)的标准来考核团队业绩。因此，本版书中提出了一个新的三角一敏捷三角， 包括价值、质量和约束。发展敏捷组织，那么我们也要提倡敏捷评估体系。
 

相互依赖声明
我们通过关注价值的持续流动，来提高投资回报。
我们通过让客户参与频繁互动和共享所有权,来交付可靠的结果。
我们通过迭代，预见和适应,来尊重和管理不确定性。
我们通过承认个体是价值的最终来源，并创造使他们有所作为的环境来激发创造力和创新力。
我们通过对结果的集体负责制和对团队有效性的责任共担，来促进团队的绩效。
我们通过因地制宜的具体策略、流程和时间，来提升有效性的可靠性。

• 第1章，“敏捷革命”，本章概述了敏捷项目管理的商业目标，以及企业如何适应无序的世界。
• 第2章~第4章,介绍推动敏捷项目管理的价值观和原则。一些主要的敏捷价值观在《相互依赖声明》和《敏捷软件开发宣言》中都有明确表述。本书将其简要概括为:交付价值胜过满足约束、领导团队胜过管理任务和适应变化胜过遵循计划。
• 第5章~第.10章，讲述敏捷项目管理的流程架构及具体做法。
• 第5章介绍敏捷企业架构(包括项目治理、项目管理、迭代管理、技术措施)和敏捷流程架构(包括构想、推测、探索、适应和结束)。
• 第6章~第10章定义了敏捷流程架构中每个阶段并讲述其具体做法。
• 第8章讲述高级发布计划包含--节价值点计算的内容。
• 第11章，“敏捷项目扩展” ，结合实例查证说明如何运用敏捷原则，如何将敏捷项目管理扩展到大型项目和大型团队中。包括组织层面和产品相关的实践。
• 第12章，“ 治理敏捷项目”，以敏捷项目转换到敏捷组织为起始，主要围绕项目管理讨论领导和管理问题，并提出需要把治理从交付活动中剥离出去。
• 第13章，“ 超越范围、进度和成本:评估敏捷绩效”，继续把重点放在敏捷组织。提出了基于范围、进度和成本的评估体系应该改变。并把第1章中介绍过的敏捷三角形原则当作-种新的评估敏捷绩效的方式进行了详细地查证。
• 第14章，“可靠的创新”，强调敏捷项目管理如何帮助解决新产品开发的易变本.质，总结敏捷项目经理应该扮演的角色，并提出在实施敏捷项目管理和开发时需要具备的坚定信念和勇气。
   

这套丛书分为下列几类:

• 提高从事具体工作人员工作效率的技巧。WritingEffectiveUse Cases(科克伯恩，2001)和 Effective Use Cases(阿道尔夫等人，2003)属于个人技巧书籍。
• 提高团队工作效率的技巧。这些技巧可能包含组建团队、项目评审、协作、决策等方面的技巧。Improving Software Organizations( 马蒂亚森等人，2002)Collaboration Explained(塔巴卡，2006)和Surviving Object-Oriented Projects(科克伯恩，1998)属于团队技巧书籍。
• 特殊、成功的敏捷方法实例。在现有方法上进行修改远比创造一种新的方法更加容易，也比使用为其他情境设计的方法更有效。Scaling Lean &Agile Development(拉曼，2008)、 Scaling Software Agility(莱芬韦尔，2007)、Crystal Clear(科伯恩，2004)、 DSDM: Business Focused Development(动态软件开发协会，2003)以及Lean Software Development: An Agile Toolkit(波彭狄克和波彭狄克，2003)是关于方法的典范书籍。

以下3本书是这套敏捷软件开发系列丛书的基础读物:
(1)本书并不局限于软件开发领域，描述了如何通过应用敏捷原则和做法，更好地管理各种类型的项目，其内容涵盖了采用敏捷项目管理的理由、敏捷项目管理的原则和做法。
(2) Agile Software Development Ecosystems(海史密斯，2002), 阐述了敏捷开发背后的共同原则，即《敏捷宣言》中表达的原则，并且对六大敏捷方法逐- -评论。
(3)阿里斯代尔的Agile Software Development(2006),作者用了以下几个主题表达他的敏捷开发思想:软件开发如同合作游戏，方法如同协作惯例，以及方法论簇。
 

第一部分  敏捷革命【预见型（定义需求、设计、实施）------>探索型（构想、推测、探索、适应、结束）】

当我们将试验成本减少到足够低时，整个产品开发的经济学就会发生改变，从以预测为基础的流程(定义、设计，然后建造)转变为一个以适应为基础的流程(构想、探索，然后适应)。当生产不同产品的成本突然降低，而把这些不同产品集成到一个产品的成本又很低时，那么这个伟大的产品可以说不是生产出来的，而是进化出来的，就像自然界的生物进化一样，只是速度要快得多。

在新产品开发(New Product Development，NPD)中， 时间也是一个促进因素。

据产品开发和管理联合会Product Development And Management Association，PDMA)估算，最近推出的新产品的失败率达59%左右,这个数字自20世纪90年代早期以来就几乎没有变化。不仅如此，半途而废或者(在市场.比)失败的产品消耗了46%的产品开发资源(库珀，2001)。 

虽然公司需要从高强度的产品开发工作中获得成果，但不应该以质量为代价。曾带领球队获得10次全国冠军的加利福尼亚大学洛杉矶分校的传奇篮球教练约翰●伍登常常
对他的队员们说这样一句话:“要迅速， 但不要仓促”。这句话也适用于产品开发，也就是说要做正确的事，而且要学会怎样才能更快速地完成，即删除多余的没有价值的步
骤。

1、敏捷商业目标， 一个良好的探索流程(如敏捷项目管理)需要实现以下5个关键的商业目标:

• 持续创新-- 满足当前客户的需要;
• 产品适应性--内在质量--- 满足未来客户的需要;
• 短周期一满足市场，提高投资回报率(returm on investment, ROI);
• 人员和流程适应性一一对产品和企业变化做出迅速反应;
• 可靠的结果一--支持业务增长和赢利能力。---可靠不是重复的，精确的不变的流程。
  重复的流程是指按照同样的方式做同样的事情，并产生同样的结果; 而可靠是指无论在生产过程中遇到什么障碍，都能达到目标，它意味着为达到一个目标而不断改变。

2. 敏捷的定义

    敏捷是制造并响应变化从而在动荡的商业环境中创造利润的能力。
    敏捷是平衡灵活性和稳定性的能力。(海史密斯，2002)。 .

3 敏捷领导价值观

  敏捷强调的是态度而不是流程，它是氛围而不是方法。-----------原则上讲敏捷不是具体的操作，而是一种思维模式。

在业绩优良的团队中，领导管理原则，而原则管理团队。-一卡尔●拉尔森和弗兰克●拉夫斯托(1989)

传统项目管理三要素:范围、进度和成本，没有考虑质量要素(特别是技术质量，持续产生价值的决定性因素),更没有价值本身。他们认为按量、按期、按时交付产品就意味着交付价值。有研究表明，超过50%的软件功能很少被使用甚至从来没被使用过，所以，认为关注范围和要求就能产生价值的想法是错误的。

4 敏捷绩效评估---一个组织要想保持快速增长的话，就必须明确绩效评估方法

5 敏捷顶目管理架构

项目管理流程和绩效评估对于基于探索和试验的方法和基于生产和技术规范的方法是不同的。

• 以生产为导向的项目管理流程和做法强调完整的早期计划和要求说明，并且要求以后将尽量不会改动;
• 而基于探索的流程虽然也强调早期计划(仅是名义上的),但它更强调足够好的要求和可实验可改进的设计方案，而且随后会通过不断学习，做出重大改动。

敏捷项目管理交付方法包括5个阶段:构想、推测、探索、适应和结束，而每个阶段都有各自的做法。

• 构想阶段产生一个清晰明白的业务或者产品构想，为后面的阶段划出边界:-----，如产品构想框线图和项目记录表，客户焦点访谈，迭代计划
• 在推测阶段，团队推测产品的规格，制定一个发布计划，随着项目的不断进行，技术要求和客户要求会随着新知识的获得不断演变:
• 然后是探索阶段，它和法代平行作业，其中要完成最初的功能和需求设计;------------工作量自我管理，参与式决策
• 在适应阶段，这些试验的结果需要经过技术、客户和企业的个案审查，以便在下一次迭代过程中继续做出调整。

第二部分   三个价值观 

第2章  价值观1：交付价值胜过满足约束

传统项目经理总是关注项目要求(定义范围).然后致力于如何达到那些要求。而敏捷项目领导则更关注交付价值，然后会不断地提出这样的问题11 这些不同的项目范围
是否真的有价值? "

项目领导可以通过以下几种方式来关注产品价值: 价值确定(与客户-起)、价值优先级排序(订单管理)、价值创造(迭代开发)。

1. 尽管价值确定主要是业务经理和产品经理的职责，但项目领导也经常参与成本/效益分析和价值判断(特别是在产品公司)。
2. 价值优先级的排序也大多是产品经理的工作，但是项目领导者也需要参与，特别是没有面对客户或不知道技术需求的情况下。价值优先级排序也涉及订单管理。
3. 价值创造在项目组内指的是与客户合作、把客户需求分组、减少技术债务(保证质量和价值交付)等活动。

在定义客户价值时,经常会出现这样-一个问题:“谁是客户?是产品的用户、经理，还是其他利益相关方?”

最直接的回答是，客户是用创造的产品来产生商业价值的个人或群体。对于零售产品，客户就是使用产品的人。  客户定义价值，他们用亲身经历来判断产品价值。这个定义将客户与其他利益相关方区别开来。在本书中，“利益相关方”-词表示与项目相关的、协助定义产品商业价值和其他约束的个人。

1.  提供客户价值涉及3 个特别重要的话题: 

• 一是将重点放在创新和适应性而不是效率和优化，二是专注于执行； 三是精益思维。

2. 迭代----基于功能的交付方式

敏捷的迭代组成部分可以用下面为4 个关键词来表示:迭代、基于功能、时间框和增量。

• 迭代要求在一定的时间期限内一一时间框(对于软件是1-4 个星期)-一产生一个结果。该时间框强制迭代的结束，强迫人们在准备充分之前，就制造出部分实体。增量开发是指建造的产品，在经过→次或多次选代后都可以及时的被调用。对于软件公司而言，迭代开发和增量交付已经成为了竞争优势。短期的、有时间框的迭代是敏捷项目管理的一个固有部分。
• 迭代要基于功能交付方法，帮助定义客户和产品开发者间的可行界面。
• 对于需求可能会随时间推移而演变的项目和产品，让客户在开发过程期间评审结果，使其尽可能接近实际产品，就显得尤为关键；
• 通常，在时间框内进行频繁的迭代，迫使开发团队、客户团队和高级主管在早期和项目的整个期间经常做出困难的权衡决策。---迭代的意义是通过评审迫使团队做提前频繁地决策；//而不是象传统开发一样，总是在最后才发现大问题。

3. 致力于卓越技术可以交付客户价值，而不是卓越行政

项目领导必须是卓越技术的拥护者，他们在密切注视其他项目目标的同时，必须支持并提倡卓越技术。
项目经理必须支持卓越技术，因为它是适应能力和低成本迭代的关键，而这两者是产品长期成功的推动力。

4. 简化，去掉详细的基于任务的结构和合规工作来简化流程

敏捷项目管理的主要原则之一就是敏捷做法，在引导原则的推动下，它是可再生的，而不是规范性的。一套再生做法是一个系统在一起正常运转的最小单位。它并不规定一个团队需要做的每件事，而是确定那些具有非常高的价值、适用于几乎每个项目的做法。

刚刚足够方法论，“迅速而不仓促”，在决定流程、方法、做法、文档以及产品开发的其他方面时，简化理念告诫我们应该把方向引向刚刚足够、精简和实施的"比刚刚够少一点"。

简化也意味着降低管理费用。 合规vs价值  ：这个活动有助于你向客户交付价值吗?还是它只是能增加费用? 项目经理要尽可能地将项目团队从繁多的合规工作中解脱出来。对于必要的合规活动，应该采取的策略是尽量减少必要活动，井使他们远离关键途径和关键人员。

第3章  价值观2：团队管理胜过任务管理

敏捷领导管理团队，敏捷团队管理自己的任务。

敏捷领导阐明团队目的和目标、产品构想、关键性能和约束，然后激励团队成员交付一-团队成员自己弄清如何完成任务的细节。

这种项目管理方法赋予团队灵活性和适应性，而不是盲目遵循既定任务。这样的方法鼓励团队自我组织，从而找到最好的方式去实现项目目标。

1. 领导团队

敏捷项目管理强调团队管理，提倡建立自我组织团队和发展服务型领导方式。这比管理任务更加困难，但最终的结果会更令人满意。在敏捷项目中，团队成员关注任务，项目领导关注团队。大多数项目是管理太多、领导太少。项目管理和项目领导的区别是什么呢?他们之间有着微妙的关联，主要区别是管理处理复杂性，而领导应付变化。

无领导团队是无舵手的团队。想建立适应能力强的、自我组织的项目团队，领导者应该引导而不是控制，在某些情况下，他们影响、轻推、促进、教授、建议、协助、催促、劝告以及指导。

领导者之所以成为领导者，不是因为他们所做的事情，而是因为他们扮演的角色。领导者在很大程度上依靠的是影响力而井非权力，影响力来自于人们的尊敬而不是敬畏。尊敬又取决于领导者的素质，如正直、能力、公正、诚实。简而言之，取决于领导者的性格。领导者是项目团队的-部分，虽然他们得到组织的授权，但他们真正的权力不是自上而下委派的，而是自下而上赢得的。

团队领导掌管方向而不施加命令并非意味着他们不做决策。自我引导(与自我组织相反)团队，理论上没有单一的领导者，做事往往游移和拖延，而这一点非常不适合行动快速的产品开发国队。掌管方向意味着团队经理有时单方面做决策，有时让团队参与共同决策，但主要是把权力下放，让团队决策。

探索系数高的项目充满了渴望、变化、模糊性和不确定性，这些都是项目团队必须处理的。而且需要用不同的项目管理风格、不同的项目团队运作模式和不同类型的项目经理。我将这种类型的管理称为领导-协作。

领导·协作的管理风格创建了这样的社会体系结构:一个可以让组织和团队面对环境多变性的结构。这种社会体系结构融合了这些概念:平等主义、才干、激情、自律和自我组织。

指挥官知道目标，领导者把握方向;

指挥官发号施令，领导者施加影响;

控制者提出要求，协作者加以促进;

控制者事事管理，协作者不断鼓励。

支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提供指导以及促进人们与团队之间的联系
一(海史 密斯，2000)

2 建立跨职能、自我组织{自律}团队

自我组织团队是敏捷项目管理的核心，他们结合了自由和责任、灵活性和结构。在自我组织的团队中，个人负责管理自己的工作量，根据需要和最适合原则轮班工作，并对团队
效率负责。对于如何"交付结果"团队成员自己保有较大的灵活性，但他们对结果负责，并在制定的灵活框架内工作。

创建自我组织的团队需要:
●找到适当的人员;
●清楚表述产品构想、界限和团队角色(见第6章);
●鼓励协作(见下一节);
●坚持负责;

●培养自律;
●引导而不是控制。
根本上讲，敏捷项目管理关注人，以及人和人之间的交互、营造一种环境，激发个人创造力、从而创造优秀产品。创造优秀产品的是人，而不是流程。

3. 鼓励协作---团队

自我组织团队的能力在于协作。健康团队关系的核心是信任和尊重。协作结果的质量优劣取决于信任与尊重的程度、信息流动的自由度、辩论以及积极的参与，同时也受到参与式决策流程的约束。

在协作团队中，领导者的一个关键角色就是促进、教导、吸引和影响团队成员，让他们建立健康的关系。如果协作太少、信息交流太少，团队就会分歧严重，整合就会变成一个噩梦(因此需要经常整合);而如果协作太多、信息交流太多，团队就会陷入会议和信息超载.

3.1. 参与式决策

协作就是大家共同努力。决策是协作的心脏和灵魂。团队决策能力绝对是项目管理成功的关键。团队做决策的方法将对它的绩效产生重大影响。

领导也是良好决策的关键。"高效率的领导"吸收"模糊性、负责做决定并让团队继续其工作。双赢或者重新构思并不暗示着意见一致的决策，参与也不意味着意见-致。自我组织的团队偶尔需要经理做出单方面决定，但他们的主要风格是包容，鼓励团队成员广泛地参与决策以便做出最好的决策。自我组织的团队有许多自由决定的决策权力，与项目经理的权力平衡。和其他领域一样，平衡在决策中是敏捷的关键。

3.2. 共享空间

创新并不会因为→些确定性的流程而得到保证，创新是突发流程的结果，在这个流程中，具有创造性想法的个人相互交流，引发了某些新颖的、与众不同的东西的产生。
演示、原型、模拟和模型是相互交流的催化剂，他们组成了"共享空间"，其中开发人员、市场人员、客户和经理可以做有重大意义的相互交流。

共享空间有两个要求一一直观化和公共性。

• 在产品开发领域，其中一个共同的问题是需求文档缺乏质量。当工程师与客户讨论原型、致力于功能而不是文档时，相互交流的质量就会得到很大提高。直观化推动了如今的工业设计。
• 公共性意味着原型需要得到开发工作的所有利益相关方的理解。

在项目的每个阶段，项目领导者都需要知道哪些人在该阶段需要相互交流、需要什么样的共享空间以达到交流的效果。

4. 客户合作--目标内容-

客户团队在参与敏捷项日时的部分责任(第6 章会进一步阐述这些责任):
• 创造井管理功能清单:
• 确定发布和迭代计划的优先级:
• 辨别并定义功能:
• 定义接受标准
• 审核并接受完整的功能:
• 和开发团队持续交流:
• 为结果和调整约束负责

5. 自我组织--领导协作管理模式/授权服务型领导模式，而非无政府主义，放任不管，与命令控制管理模式相对应

自我组织是敏捷管理的核心。怎样把自我组织的概念从无政府主义的边缘带回到授权、服务型领导方式(不是没有领导力)的领域来呢?

在Adaptive Software Development 一书中，我用"领导·协作管理"一词代替"命令-控制管理"的概念。本书深入地讨论了领导者(指人)和领导力(指任何组织成员提供情景领导)一一作为敏捷团队和敏捷领导力模式的一个部分的概念。

桑吉夫·奥古斯丁(2005)在《管理敏捷项目》一书中也提到了这个问题，他提倡管理要"轻触"。希望通过本章对领导力和适应性团队的描述，帮助大家从正确的角度理解自我组织的概念。

自我组织意味着尽可能的把决策权下放到个体团队。授权不是放任不管。尽管敏捷领导在自上而下的决策制定活动中角色"轻"但他们在诸如阐述目标、促进交流、提高团队动力、支持协作、鼓励试验和创新的活动中角色却"重'；相比决策权，领导的这些特征对于成功更关键。但决策制定仍然是领导者很重要的一个角色。

监督指导、促进协作，鼓励创新；尽量不直接决策。

第4章 价值观3:适应变化胜过遵循计划---对变化做出的深思熟虑的回应

探索和适应是创新的两个行为特质，拥有探索未知世界的勇气、拥有承认错误并适应形势的谦逊。

传统的项目经理视计划为目标，而敏捷领导者视顾客价值为目标。

以客户价值和质量为目标，计划就是实现这些目标的方式，而不是目标本身。计划中的约束依然重要，依然指导项目的完成，人们依然想要了解计划的变化，但计划不再神圣不可侵犯，计划应该灵活，应该是依据，而不是约束。

传统和敏捷领导者都做计划，而且花费相当长的时间做计划，但他们看待计划的方式却截然不同。他们都视计划为基线，但是传统经理不断修正实际结果以符合那个基线。PMBOK2称这种行为叫纠偏行为，用来引导团队回归基线。

适应流程不是以一个解决方案开始，而是以多个可能的解决方案(试验)开始，然后，应用一系列的适合性测试(实际产品功能或者模拟，取决于验收试验)，根据反馈信息进行改变，从而探索并选择最好的解决方案。如果不确定性低，则适应方法的风险是高成本，而如果不确定性高，则优化方法的风险在于太早的确定某个解决方案会抑制创新。

4.1. 探索

创新产品开发团队是被引导的而不是被管理的。那些将精力集中在网络图、成本预算和资源柱状图的项目经理注定他们的团队是平庸的。团队需要有共同的目的和目标，也同样需要有人鼓励他们试验、探索、犯错误、重新编组和向前迈进。

4.2. 响应变化

预测变化(不确定性)，然后做相应调整，而不是遵循过期计划。这条宣言反映了敏捷方法的观点，可以进一步归纳为:  构想一探索与计划一执行--适应与预见。

• 每个项目都必须在计划和变化之间找到平衡。探索型项需要有强调构想的流程，然后根据该构想探索，而不是依照详尽的计划并相对严格地执行任务。
• 影响项目管理类型的另一个因素是迭代的成本，即试验成本。即使非常迫切需要创新，但如果迭代的成本非常高，可能会导致某个流程有较多的预期工作。

4.3. 适应性的3 个组成部分:产品、流程和人员

要想拥有敏捷、适应的环境，产品、流程和人员都很重要。

敏捷开发需要短期迭代:做短期迭代需要找到快速、低成本的做重复事情的办法:快速、低成本的做事情使得团队采用以前从没有想到的方式去适应变化。快速、低成本的做事情促进创新，因为它鼓励团队试验。这些创新扩散并渗透到组织其他部分。降低变化成本促使公司重新思考他们的商业模式。

4.4. 可靠，但不重复

重复流程最多只能支付事先规定的东西，敏捷项目管理是可靠的、可预测的:在不确定性程度相同的情况下，它比其他任何流程更能在有限的限制内交付满足客户需要的产品。为什么会这样呢?不是因为一些项目经理规定了详细的任务、事无巨细都管理，而是因为敏捷领导者创造了一个让人们都想争先、达到目标和倾尽全力的环境。

5. 反思和回顾

如果希望有较强的适应性，就必须愿意认真严格地评估个人和团队的绩效。有效的团队在回顾时会涉及4 个领域:

• 产品一一从客户的角度和技术质量的角度:
• 流程一-团队正在使用的优秀流程和做法:
• 团队一一作为高绩效团队，这个小组的工作情况如何:
• 项目一一项目按计划进行的如何。

第三部分   敏捷项目管理方式

敏捷开发的信条之一是适应不同情况。<<相互依赖宣言》的6 个原则之一是通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。

第五章 敏捷项目管理模式

5.1    敏捷企业架构     

 5.2. 敏捷交付架构---(狗腿探视)--【构想+推测】-【探索--交付+团队管理+沟通】--【适应(变化)-评审反思回顾改进持续集成迭代】--结束

如果是重复性的制造，那么常规性流程是完全合理的；而如果目标是可靠的创新，则流程架构必须是有组织的、灵活的和容易适应的。

5.3 扩展的敏捷交付架构

第6章. APM1: 构想阶段--产品愿景+项目范围+团队构想

没有明确的构想，敏捷项目的探索本质就会导致该项目陷入无休止的试验当中。明确的构想必须明确探索的界限。

6.1. 团队构想--找到合适的人

6.2. 产品团队一开发团队交互

任何项目都应该有开发团队和产品团队，开发团队应该以项目经理为首，而产品团队应该由产品拥有者领导。

在构想阶段后，构想并没有停止。在每次迭代(或里程碑)的开头，团队在一起思考下一次迭代时，团队成员需要重新审视该构想。重新审视的目的是为了修改这个构想，或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里。

第7章. 推测阶段----基于功能的发布计划(规模+资源+时间)---创建用户故事清单+构建发布计划

在功能开发开始之前，需要完成3 个主要的活动:清楚表述产品构想、定义项目的目标和约束，以及制定迭代的、基于功能的交付计划。最后→个是推测阶段的最主要成
果。一旦完成发布计划，其他共同的项目管理计划过渡文件(如开支预算)，就可以最终确定。事实上，当完成功能清单和发布计划后，其他的事情就相对容易了!

有了迭代和里程碑结束时的重新计划，计划和产品就会随着试验中得到的信息和不断的反馈而演变。

7.1 推测产品和顶目

7.2 创建产品功能清单，功能 vs 用户故事；  用户故事 vs 任务；

从潜在功能清单中，产品团队和工程团队需要讨论这些功能的优先级，并列出这些功能在发布计划中的迭代时间表。

敏捷项目的特点之一是，功能清单上的这些功能具有易变性。在为每次迭代做计划时，功能清单可能发生改变，以至于不同于原来的发布计划。

功能和故事的基本区别是，故事是一个小的可交付的有用功能，但构不成-个完整的功能。

7.3 发布计划---在约束条件下实现产品构想的路线图

敏捷生命周期以迭代和故事驱动，大多数传统的项目管理计划使用任务来构造工作分解结构以组织工作。故事驱动表现在它将计划和执行的主要重点从任务转变为产品功能。

敏捷开发将重点放在交付产品功能而不是中间文档上。这并不是要贬低"合理的和刚好的"文档的重要性，而在于这些中间产品与团队制造最终产品的实际过程并无太大关系。

客户价值和风险是推动发布计划的两个主要因素。发布计划的主要任务是以价值和风险为基础把故事分配到迭代中。

通常，在将故事分配到迭代时，最优先考虑的是交付产品团队规定的产品价值，然后是制定故事的进度计划，以便尽早降低项目风险。但有时，技术风险需要放在首要位置。至于制定进度计划时需要考虑的其他因素，如资源的可用性、依赖关系以及其他，都排在价值和风险因素之后。

7.3.1 范围演变

敏捷项目管理处理范围管理非常现实。范围蔓延不是问题，如果范围改变是随意和恶意想出来的，那么它们对于项目有害无利；但一般而言，从满足不断演变的客户需求出发、在认同它对项目的影响的基础上做出的范围变更会提高项目成功的可能性。

敏捷开发鼓励逐步深入了解后所作的变化，它不鼓励镀金和需求蔓延的前提下，构建最少功能策略以及简单、适度地适应变化会使团队受益匪浅。

敏捷开发按功能制定计划，让客户参与，从而将计划流程的重点放在客户关心的、很容易确定优先级的事情上。

产品范围的推动因素应该包括:客户价值、技术可行性、成本和关键的业务进度需要。它不应该受到我们在对产品和项目仍然不了解的情况下所制定的计划的制约。
简化非常关键，它是最大程度地减少不必要的工作的艺术。一一《敏捷宣言》

当进度出现问题的时候，瀑布式方法缩减任务，通常是减少测试，而敏捷方法减少功能。前者降低质量，后者缩小范围。

敏捷项目中的短期迭代结合迭代结束时的客户评审，使整个团队(包括开发人员、客户和经理)都认清了现实。

短期迭代也让开发人员精力高度集中，由于每隔几周就有一个截止日期临近，因此"增强"功能的倾向就会减少。前面讨论的优先级强调减少功能的数量，而短期迭代用于限制功能的规模。敏捷做法将变化融入开发流程中，并通过不断、集中地强调核心部分来减小项目规模。

7.3.2 第0次迭代--不交付任何价值，做相应合适的准备；在长时间做需求和架构工作或者什么准备也不做两种行为之间做平衡，或者在构想阶段完成。

"0" 意味着在时间期限内没有任何有用的东西(即功能)可以向客户交付。意识到第0 次选代不交付客户价值会促使团队尽量使其保持简短。

7.3.3 第1-N次迭代

开发团队和产品团队(包括产品经理在内)共同制定发布计划。制定这个计划涉及以下活动：
• 确定己知的风险对迭代计划的影响:
• 确定进度目标---(不考虑可实现性，只从产品管理的角度确定进度目标);
• 为每次迭代编制主题:
• 将故事卡片分派给每次选代，必要时，平衡价值、风险、资源和依赖关系:
• 结合故事卡片布局(通常在墙上)、完整的发布计划、或者项目停车场图总结该计划;
• 运用权衡矩阵，必要时，调整完成的计划。

客户价值和风险是制定功能进度计划的主要因素。

有些时候，为了降低风险，会先期实施高风险的功能，而推迟开发正常情况下应该首先实施的高价值的功能。因此，应该认真检查风险清单，确定风险降低对发布计划的影响，特别是改变功能顺序和纠入高风险项目对发布计划的影响。

7.3.4 估计---评估工作量

由于敏捷方法通常用于探索系数高的项目，关键的估计问题变成了"您如何估计未知因素? "答案是"不能"。

当面对未知因素时，您是在猜测而非估计，这也是我们唯一能做的。这正是为什么在敏捷项目中，进度和成本通常被看作是限制而非估计的一个原因。敏捷组织学会了与不确定性共存，而不是试图在一个快速变化的世界里要求确定性。

精益思想的原则即减少浪费，对于研究活动来说，就是消除或者减少不直接产生客户价值的活动。估计是一个浪费时间的活动。在项目早期对功能进行过于详细的估计很浪费时间，因为有好多功能随后会被放弃。当对某些只是列在功能清单上的功能进行一遍又一遍估计时，也是在浪费时间。对于许多小的维护功能来说，完成它们和估计它们所用时间几乎→样。所以，估计(特别是经常进行详细的估计)应该与估计所带来的利益密切相连。一些看板(一种较新的做法，第8 章将要介绍)软件团队己经完全摒弃了估计这一活动。

一个减轻估计负担的方法是把估计和设定界限区分开来。对于一个为期12 个月要完成125 个功能的项目，大多数敏捷团队都会尝试设定界限，而不是进行精确估计。设定界限是基于拥有足够的有关项目规模的信息，从而感觉发布计划是可行的。设定界限有助于回答这样的战略问题:团队是否有能力在项目的约束内交付可发布的、有品质的产品。

许多敏捷软件团队估计故事点而不是估计员工工作时间。故事点是试图确定一个工作单位而不是工作量。在软件开发中，人们过去尝试用行代码和功能点来提供测量方法。这两种方法都有问题，最大的问题是早期估计需要做太多的工作。

故事点是一种相对测量方法(例如，这个功能比那个功能看起来大3 倍)。与试图估计工作时间的团队相比，有经验的团队做这种相对测量速度要快得多。相反，某些时候管理层通常需要进行总体工作量估计或者成本估计，就必须转换一些功能点。一些组织对于发布计划使用时间估计，而对于迭代计划使用功能点估计9。

采用基于任务的计划的优秀项目经理都知道，根据任务或者功能的详细估计累积得出的项目估计值会导致整个项目的估计值过高。

7.4 改进发布计划----一些改进措施

发布计划的价值、基于功能做计划、价值点分析、计划主题、应对不确定性，以及在制品与制成晶。

7.4.1 发布计划-----组织经常基于愿望做计划，应该基于能力做计划--速度

这也是灵活性与稳定性的问题一一"对于承诺的东西如何做到既能保证交付，同时又能留出变化、学习和惊喜的空间? " "如何在固定期限内进行创新? "只有最优秀的团队才能解决这些看似矛盾的问题。

强加的进度表和没有进度表都不是正确答案。无论是固定的计划还是根本没有计划都不是解决问题的办法。这样只是阻碍敏捷方法更广泛的被人们所接受。

组织往往基于愿望做计划，而不是基于自身能力。例如，团队经理希望他们下次能够发布50 个功能以满足市场需求，尽管开发人员清楚地知道发布30 个功能才是更现实的做法。许多经理把压力作为→种激励技巧，让员工满负荷的工作似乎是经理们最广泛使用的方法之一。

7.4.2 发布计划----多层计划---计划既需要预测性又需要灵活性

小型的为期3 个月的项目完全可以把计划做到故事层。而一个200 人、为期18 个月的项目，其计划工作必须在几个层面(如业务领域、性能、故事)展开

7.4.3 发布计划---性能（史诗/商业业务模块)

性能是指高级的、完整的和有价值的业务或产品功能，而故事是指向客户交付的一项有用和有价值的功能(有些人用同义词史诗代替性能来表明史诗是由许多故事组成)。
大型项目最好按功能分层做计划，区分各个层次的最好办法是根据其大小的不同。故事应该是大约2-10 天的工作量，性能应该是20-200 天的工作量。另外一个指导方针是每个高一级功能的大小大概是低一级的3 倍。完成一个功能需要6-30 天，而完成一项性能需要18-90 天。

7.5 价值点分析---基于收入流

故事是小块的用户功能。它们既可以做相对估计(故事点)，也可以做绝对估计(小时数)。那么故事点的总数代表项目的总成本。如果项目成本是60 万美元，那么每个故事点代表了400 美元的成本。为什么不用类似的方法来衡量价值并且创造一种叫价值点的东西来代表相对价值或者货币价值呢?

需要分开考虑价值和优先级，因为最高价值的故事并非总是拥有最高优先级。适合的模糊测量方式要好于不适合的精准测量方式。价值点是表明我们非常关注价值的一种方式。，用模糊数字表示一些重要的东西比用精准数字描述一些不重要的东西更有用。

7.6 发布计划主题

为了能合理关注价值，项目既需要有一个总体"构想"也需要有实现该构想的短期"主题"。主题对于迭代和大型项目的里程碑都非常有用。几个不同类型的主题可以
单独使用或者联合使用，如业务职能、业务职能的广度或深度、业务流程、风险缓解和部署计划等。

在项目早期，关注风险比关注商业价值更重要(这也是交付价值的方式)。例如，可能需要攻克某个技术障碍，否则整个项目就会失败。先于破除技术障碍而广泛实现业务
功能完全是在浪费资金。风险缓解主题，特别是降低那些非常重要的风险，在项目的早期就应该予以考虑。

团队应该一直考虑如果削减项目资金那么能够交付什么产品。

7.7 新做法

发布计划为管理层和主管提供了一个基准，据此他们可以判断在既定的约束内交付高质量、可发布产品的可行性。

8. APM3: 探索阶段--交付功能+内部团队管理+外部客户沟通

敏捷项目管理关注敏捷领导如何创建自我组织和自律的团队，从而交付可发布的产品，而不关注实现这一目标的技术细节。探索阶段包括了第5 章介绍的4 个敏捷开发方法中的3 个一一项目管理、迭代管理和技术做法。

敏捷领导(包括项目、产品和迭代)必须在更广泛的组织中发挥作用。他们需要管理内部(确保职能经理和主管了解敏捷方法的好处和差异)、

• 管理外部(确保客户了解他们在敏捷项目中的主要角色和责任)，
• 管理内部团队(鼓励他们接受并充分理解敏捷原则和做法)。

8.1 敏捷顶目领导 ---敏捷项目领导关注增加项目价值，而不是合规工作

项目管理应该看作是提供鼓舞领导、集中交付客户价值的管理，而不应看作是日常管理费用。

客户购买的是价值，其他所有事情都是日常管理费用一一虽然有的是必要的，但终究还是日常管理费用。------------/略失偏颇，没有合规、审批，无法为公司创造利润。

• 符合政府条例的团队活动是必要的，但它们很少增加客户价值:合法的需求文档也是必要的，但不能增加价值，至少不是直接增加价值:
• 工作进度报告帮助经理完成其受托的责任，但不能增加价值:
• 无数重要事件的审批权会迷惑管理人员，让他们以为-切都在控制之中，但它们也不能增加价值。

8.2 迭代计划和监督--迭代计划、工作量管理和监督迭代过程

主要负责管理此项工作的是迭代经理，迭代经理也可以在每次迭代结束时组织召开诸如回顾等内容的会议.

 8.3 其他技术实践

 8.4 团队领导

10. APM4: 适应阶段---监督和控制--产品价值+产品质量+团队绩效+项目状态--产品+团队+项目适应--评审+回顾

适应阶段包括产品、项目和团队评审及适应措施。"适应措施"这个术语表达的是"响应"含义，而不是"纠正"。

适应阶段的大多数做法应安排在每次迭代结束时进行(如产品评估);团队评审的部分做法应该包括评估这些评审之间的时间期限。在敏捷项目中，默认情况下不能忽略任何东西:团队应时刻评估每种做法的相关性和影响。例如，在项目初期团队评审需要更频繁地进行，而在中期和晚期则不用那么频繁。

有4 种类型的评审很有用：-------------评审后，适应改进

• 从客户团队的角度看产品功能性，----价值
• 从设计团队的角度看技术质量，---质量
• 团队绩效检查点和      ---绩效
• 对整个项目进度的评审   ---状态