敏捷.敏捷项目管理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章，“可靠的创新”，强调敏捷项目管理如何帮助解决新产品开发的易变本.质，总结敏捷项目经理应该扮演的角色，并提出在实施敏捷项目管理和开发时需要具备的坚定信念和勇气。
敏捷软件开发系列丛书,我们推出该丛书有两个出发点:
(1)不同的项目需要有不同的流程或方法;
(2)注重技巧、交流和团体比注重具体流程使项目更有效、更敏捷。
这套丛书分为下列几类:
- 提高从事具体工作人员工作效率的技巧。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 敏捷绩效评估---一个组织要想保持快速增长的话，就必须明确绩效评估方法
|
电影《泰坦尼克号》，严重超出了预算和时间，早期被批评家认为是拿2亿美元打水漂，后来却成为全球第一部票房收入超过10亿美元的电影。 依据一般的约束一预算、 范围、进度等指标来评估项目，《泰坦尼克号》 是失败的; 而在某些范围内,铱星项目被认为是个成功案例，因为它完全符合最初的目标要求。 |
摩托罗拉公司投资数10亿美元的铱星(Iridium)项目 脱胎于军用的摩托罗拉信奉“技术至上”理论，特别是在移动通信领域，摩托罗拉凭借先发的优势几乎垄断了第一代的移动通信市场，份额达到70%以上。 欧洲几家通信巨头携手打造了第二代GSM。新的GSM属于数字信号系统，相较于摩托罗拉的模拟信号系统在保密性以及抗干扰能力上得到了显著的提升。 而摩托罗拉由于误判了数字时代到来的时间点——他们估计起码在2000年数字信号时代才会真正来临。摩托罗拉在1991年发起了铱星计划——通过构建77颗近地卫星组成的星群，让用户从世界上任何地方都可以打电话。整个铱星计划的成本高达60亿美元，而每年的维护费用也需要几亿美元，同时设备终端铱星手机的售价也高达5000美元，这无疑让大量用户望而生畏。 1996年数字通信时代到来。而摩托罗拉依然忙着在发射卫星。最终卫星数目由77颗降低到66颗，而铱星系统也终于在1998年迎来了商用。但此时已经太晚了，GSM已经成为了事实上的标准，无论在通信质量还是在通话价格上都远远领先于铱星系统，最终铱星公司坚持了一年就宣布破产 |
|
|
||
| 传统铁三角 |
敏捷项目铁三角，早期衡量敏捷开发的方式。在这个三角里，进度是固定的(时间框).范围可以有变化。 但是，这个铁三角和第一个铁三角的评估方式是一样的。许多公司认为成功就是遵循成本、进度和范 |
第3个三角形一敏捷三角形。 考量指标是价值(向客户交付价值)、质量(需要向客户交付可持续的价值)和约束(范围、进度和成本)。 约束仍然是重要的项目评估参数，但 价值是目标，为了提升客户价值，这几个约束可以随着项目的进展适时做出调整。 进度可能仍是一一个固定的约束;如果那样的话，范围就可以调整为在固定的时间期限内向客户交付最有价值的产品。 如果要适应性，就必须以牺牲或调整 |
|
●价值目标 -提供可交付的产品 ●质量目标- -提供可靠的、适应性强的可交付产品 ●约束目标-在可接受的约束内，实现价值和质量目标 |
||
5 敏捷顶目管理架构
项目管理流程和绩效评估对于基于探索和试验的方法和基于生产和技术规范的方法是不同的。
- 以生产为导向的项目管理流程和做法强调完整的早期计划和要求说明，并且要求以后将尽量不会改动;
- 而基于探索的流程虽然也强调早期计划(仅是名义上的),但它更强调足够好的要求和可实验可改进的设计方案，而且随后会通过不断学习，做出重大改动。
敏捷项目管理交付方法包括5个阶段:构想、推测、探索、适应和结束，而每个阶段都有各自的做法。
- 构想阶段产生一个清晰明白的业务或者产品构想，为后面的阶段划出边界:-----，如产品构想框线图和项目记录表，客户焦点访谈，迭代计划
- 在推测阶段，团队推测产品的规格，制定一个发布计划，随着项目的不断进行，技术要求和客户要求会随着新知识的获得不断演变:
- 然后是探索阶段，它和法代平行作业，其中要完成最初的功能和需求设计;------------工作量自我管理，参与式决策
- 在适应阶段，这些试验的结果需要经过技术、客户和企业的个案审查，以便在下一次迭代过程中继续做出调整。
2.1 交付价值胜过满足约束
传统项目经理总是关注项目要求(定义范围).然后致力于如何达到那些要求。而敏捷项目领导则更关注交付价值，然后会不断地提出这样的问题11 这些不同的项目范围
是否真的有价值? "
项目领导可以通过以下几种方式来关注产品价值:价值确定(与客户-起)、价值优先级排序(订单管理)、价值创造(迭代开发)。
- 尽管价值确定主要是业务经理和产品经理的职责，但项目领导也经常参与成本/效益分析和价值判断(特别是在产品公司)。
- 价值优先级的排序也大多是产品经理的工作，但是项目领导者也需要参与，特别是没有面对客户或不知道技术需求的情况下。价值优先级排序也涉及订单管理。
- 价值创造在项目组内指的是与客户合作、把客户需求分组、减少技术债务(保证质量和价值交付)等活动。
项目领导可以通过许多方式培养团队以价值为导向的理念。这与传统的以范围、进度、成本为导向的理念相差甚远。
目团队的目标是向客户交付价值。在定义客户价值时,经常会出现这样-一个问题:“谁是客户?是产品的用户、经理，还是其他利益相关方?”
最直接的回答是，客户是用创造的产品来产生商业价值的个人或群体。对于零售产品，客户就是使用产品的人。
客户定义价值，他们用亲身经历来判断产品价值。这个定义将客户与其他利益相关方区别开来。
在本书中，“利益相关方”-词表示与项目相关的、协助定义产品商业价值和其他约束的个人。
任何产品的成功都需要满足期最终客户的、利益相关方的和团队自身的期望值。要求和期望值之间存在巨大的差别:要求是有形的，而期望值是无形的。
当最终评估实际结果时，依据的是无形的期望值。培养忠诚的客户和利益相关方意味着与他们会谈讨论需求和期望值。
1. 提供客户价值涉及3 个特别重要的话题:
- 一是将重点放在创新和适应性而不是效率和优化，
- 二是专注于执行，
- 三是精益思维。
| 1. 创新 | 效率和优化是生产型项目的有利助推器，而创新和创造力却是探索型项目的助推器。敏捷项目管理的主要目的是创造新产品和新服务。要实现这个目标，就需要不断的技术变革、增加竞争优势、产生新的创意和不断地缩短产品开发周期。 |
| 2. 执行 |
项目经理将精力集中于交付活动，他们为项目增加了价值:而如果集中于计划和控制，就可能增加管理费用。 按照霍韦尔和科斯克拉的说法，普通项目管理方法由3 个信息交流流程组成:计划、 他们发现在建筑项目中，传统计划存在一些问题:
敏捷项目管理是侧重于执行的模型，而不是侧重于计划和控制的模型。在敏捷项目 |
| 3. 精益思维 |
精益生产的一个基本原则是系统地消除油费，即减少不向客户提供价值的活动。 一个简化项目(做较少的事、做正确的事、消除瓶颈)的方法是区分交付活动和合规活动，以及对每种活动分别采用相应的策略。 ----------------消除无增值的合规活动----------- |
2. 迭代----基于功能的交付方式
敏捷的迭代组成部分可以用下面为4 个关键词来表示:迭代、基于功能、时间框和增量。
- 迭代要求在一定的时间期限内一一时间框(对于软件是1-4 个星期)-一产生一个结果。该时间框强制迭代的结束，强迫人们在准备充分之前，就制造出部分实体。增量开发是指建造的产品，在经过→次或多次选代后都可以及时的被调用。对于软件公司而言，迭代开发和增量交付已经成为了竞争优势。
- 短期的、有时间框的迭代是敏捷项目管理的一个固有部分。
- 迭代要基于功能交付方法，帮助定义客户和产品开发者间的可行界面。
- 对于需求可能会随时间推移而演变的项目和产品，让客户在开发过程期间评审结果，使其尽可能接近实际产品，就显得尤为关键；
- 迭代开发同时也是自我纠正的过程。在结束时，对产品、技术、流程和团队进行评审后，迭代会根据合理的评审结果，自我纠正。
- 通常，在时间框内进行频繁的迭代，迫使开发团队、客户团队和高级主管在早期和项目的整个期间经常做出困难的权衡决策。---迭代的意义是通过评审迫使团队做提前频繁地决策；//而不是象传统开发一样，总是在最后才发现大问题。
2. 致力于卓越技术可以交付客户价值，而不是卓越行政
项目领导必须是卓越技术的拥护者，他们在密切注视其他项目目标的同时，必须支持并提倡卓越技术。
项目经理必须支持卓越技术，因为它是适应能力和低成本迭代的关键，而这两者是产品长期成功的推动力。
3. 简化，去掉详细的基于任务的结构和合规工作来简化流程，就强迫人们思考和交流。
敏捷项目管理的主要原则之一就是敏捷做法，在引导原则的推动下，它是可再生的，而不是规范性的。一套再生做法是一个系统在一起正常运转的最小单位。它并不规定一个团队需要做的每件事，而是确定那些具有非常高的价值、适用于几乎每个项目的做法。
刚刚足够方法论，“迅速而不仓促”，在决定流程、方法、做法、文档以及产品开发的其他方面时，简化理念告诫我们应该把方向引向刚刚足够、精简和实施的"比刚刚够少一点"。
简化也意味着降低管理费用。敏捷项目管理的首要任务是向客户交付价值。
一个非常简单但很少用来辨别交付活动与合规活动的方法，就是问做这个工作的人这样的问题"这个活动有助于你向客户交付价值吗?还是它只是能增加费用? "，即使是要自己承担那些任务，项目经理也要尽可能地将项目团队从繁多的合规工作中解脱出来。对于必要的合规活动，应该采取的策略是尽量减少必要活动，井使他们远离关键途径和关键人员。
|
|
传统项目管理关注在范围、时间和成本等约束内按计划行事。而这个做法经常会使团队交付较低的客户价值。因此，产品性能的价值评估、追求卓越技术、改变绩效评估方法和提供帮助团队交付价值而不是要素的做法等将会是本书主要的讨论内容(如图2-1所示)。 |
2.2 团队管理胜过任务管理
敏捷领导管理团队，敏捷团队管理自己的任务。敏捷领导阐明团队目的和目标、产品构想、关键性能和约束，然后激励团队成员交付一-团队成员自己弄清如何完成任务的细节。
这种项目管理方法赋予团队灵活性和适应性，而不是盲目遵循既定任务。这样的方法鼓励团队自我组织，从而找到最好的方式去实现项目目标。
1. 领导团队
敏捷项目管理强调团队管理，提倡建立自我组织团队和发展服务型领导方式。这比管理任务更加困难，但最终的结果会更令人满意。在敏捷项目中，团队成员关注任务，项目领导关注团队。大多数项目是管理太多、领导太少。项目管理和项目领导的区别是什么呢?他们之间有着微妙的关联，主要区别是管理处理复杂性，而领导应付变化。
无领导团队是无舵手的团队。想建立适应能力强的、自我组织的项目团队，领导者应该引导而不是控制，在某些情况下，他们影响、轻推、促进、教授、建议、协助、催促、劝告以及指导。
领导者之所以成为领导者，不是因为他们所做的事情，而是因为他们扮演的角色。领导者在很大程度上依靠的是影响力而井非权力，影响力来自于人们的尊敬而不是敬畏。尊敬又取决于领导者的素质，如正直、能力、公正、诚实。简而言之，取决于领导者的性格。领导者是项目团队的-部分，虽然他们得到组织的授权，但他们真正的权力不是自上而下委派的，而是自下而上赢得的。
团队领导掌管方向而不施加命令并非意味着他们不做决策。自我引导(与自我组织相反)团队，理论上没有单一的领导者，做事往往游移和拖延，而这一点非常不适合行动快速的产品开发国队。掌管方向意味着团队经理有时单方面做决策，有时让团队参与共同决策，但主要是把权力下放，让团队决策。
探索系数高的项目充满了渴望、变化、模糊性和不确定性，这些都是项目团队必须处理的。而且需要用不同的项目管理风格、不同的项目团队运作模式和不同类型的项目经理。我将这种类型的管理称为领导-协作。
领导·协作的管理风格创建了这样的社会体系结构:一个可以让组织和团队面对环境多变性的结构。这种社会体系结构融合了这些概念:平等主义、才干、激情、自律和自我组织。
指挥官知道目标，领导者把握方向;
指挥官发号施令，领导者施加影响;
控制者提出要求，协作者加以促进;
控制者事事管理，协作者不断鼓励。
支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提供指导以及促进人们与团队之间的联系
一(海史 密斯，2000)
敏捷运动支持个人和团队通过致力于自我组织、自律、平等主义、尊重个人和能力等观念，实现发展。"敏捷"是社会技术运动，它有两个推动力:一个是愿望一一创造一种特定的工作环境:另一个是信念一一适应性强的环境是向客户提供创新产品目标的关键。
2 建立自我组织{自律}团队
自我组织团队是敏捷项目管理的核心，他们结合了自由和责任、灵活性和结构。在自我组织的团队中，个人负责管理自己的工作量，根据需要和最适合原则轮班工作，并对团队
效率负责。对于如何"交付结果"团队成员自己保有较大的灵活性，但他们对结果负责，并在制定的灵活框架内工作。
创建自我组织的团队需要:
●找到适当的人员;
●清楚表述产品构想、界限和团队角色(见第6章);
●鼓励协作(见下一节);
●坚持负责;●培养自律;
●引导而不是控制。
根本.上讲，敏捷项目管理是关于人，以及人和人之间的相互交流、是关于营造一种环境，让个人创造力和能力爆发、从而创造优秀产品。创造优秀产品的是人，而不是流程。
| 找到合适的人员 |
人员比流程重要这个敏捷价值观促使了找到合适人选的需要。
|
| 坚持负责 |
责任和负责创造了自我组织团队。 ((相互依赖声明》中有这样一条原则:通过激发成员的使命感和责任感来提高团队绩效。 每个团队成员都有责任提高团队协作。每个团队成员和项目领导相互履行承诺是义不容辞的责任。信任是协作的基石，而履行承诺是建立信任的核心，这样就能建立高效的团队。 |
| 培养自律 |
自律是自由和授权的前提。 自律的个人可以: 对话、讨论和参与式决策都是建立自律的→部分。 自律也是建立在能力、坚持和愿意承担结果的责任之上。才干不仅是技能和能力，它是态度和经验。 |
3. 鼓励协作
自我组织团队的能力在于协作。健康团队关系的核心是信任和尊重。协作结果的质量优劣取决于信任与尊重的程度、信息流动的自由度、辩论以及积极的参与，同时也受到参与式决策流程的约束。
在协作团队中，领导者的一个关键角色就是促进、教导、吸引和影响团队成员，让他们建立健康的关系。如果协作太少、信息交流太少，团队就会分歧严重，整合就会变成一个噩梦(因此需要经常整合);而如果协作太多、信息交流太多，团队就会陷入会议和信息超载.
1. 参与式决策
协作就是大家共同努力。决策是协作的心脏和灵魂。，团队决策能力绝对是项目管理成功的关键。团队做决策的方法将对它的绩效产生重大影响。
领导也是良好决策的关键。"高效率的领导"吸收"模糊性、负责做决定并让团队继续其工
作。双赢或者重新构思并不暗示着意见一致的决策，参与也不意味着意见-致。自我组织的团队偶尔需要经理做出单方面决定，但他们的主要风格是包容，鼓励团队成员广泛地参与决策以便做出最好的决策。自我组织的团队有许多自由决定的决策权力，与项目经理的权力平衡。和其他领域一样，平衡在决策中是敏捷的关键。
2. 共享空间
创新并不会因为→些确定性的流程而得到保证，创新是突发流程的结果，在这个流程中，具有创造性想法的个人相互交流，引发了某些新颖的、与众不同的东西的产生。
演示、原型、模拟和模型是相互交流的催化剂，他们组成了"共享空间"，其中开发人员、市场人员、客户和经理可以做有重大意义的相互交流。
共享空间有两个要求一一直观化和公共性。
- 在产品开发领域，其中一个共同的问题是需求文档缺乏质量。当工程师与客户讨论原型、致力于功能而不是文档时，相互交流的质量就会得到很大提高。直观化推动了如今的工业设计。
- 公共性意味着原型需要得到开发工作的所有利益相关方的理解。
在项目的每个阶段，项目领导者都需要知道哪些人在该阶段需要相互交流、需要什么样的共享空间以达到交流的效果。
3. 客户合作--目标内容---------
客户团队在参与敏捷项日时的部分责任(第6 章会进一步阐述这些责任):
• 创造井管理功能清单:
• 确定发布和迭代计划的优先级:
• 辨别并定义功能:
• 定义接受标准
• 审核并接受完整的功能:
• 和开发团队持续交流:
• 为结果和调整约束负责
4. 自我组织--领导协作管理模式/授权服务型领导模式，而非无政府主义，放任不管，与命令控制管理模式相对应
自我组织是敏捷管理的核心。，怎样把自我组织的概念从无政府主义的边缘带回到授权、服务型领导方式(不是没有领导力)的领域来呢?
在Adaptive Software Development 一书中，我用"领导·协作管理"一词代替"命令-控制管理"的概念。本书深入地讨论了领导者(指人)和领导力(指任何组织成员提供情景领导)一一作为敏捷团队和敏捷领导力模式的一个部分一一一的概念。桑吉夫·奥古斯丁(2005)在《管理敏捷项目》一书中也提到了这个问题，他提倡管理要"轻触"。希望通过本章对领导力和适应性团队的描述，帮助大家从正确的角度理解自我组织的概念。
自我组织意味着尽可能的把决策权下放到个体团队。在一个组织中， 授权也不是一项简单的事。授权不是放任不管。尽管敏捷领导在自上而下的决策制定活动中角色"轻"但他们在诸如阐述目标、促进交流、提高团队动力、支持协作、鼓励试验和创新的活动中角色却"重'；相比决策权，领导的这些特征对于成功更关键。但决策制定仍然是领导者很重要的一个角色。
监督指导、促进协作，鼓励创新；尽量不直接决策。
2.3 适应变化胜过遵循计划---对变化做出的深思熟虑的回应
开发优质的产品需要探索，而不是遵循计划。探索和适应是创新的两个行为特质一拥有探索未知世界的勇气、拥有承认错误并适应形势的谦逊。
传统的项目经理视计划为目标，而敏捷领导者视顾客价值为目标。
以客户价值和质量为目标，计划就是实现这些目标的方式，而不是目标本身。计划中的约束依然重要，依然指导项目的完成，人们依然想要了解计划的变化，但这次是太
变化，计划不再神圣不可侵犯，计划应该灵活，应该是依据，而不是约束。
传统和敏捷领导者都做计划，而且花费相当长的时间做计划，但他们看待计划的方式却截然不同。他们都视计划为基线，但是传统经理不断修正实际结果以符合那个基线。PMBOK2称这种行为叫纠偏行为，用来引导团队回归基线。
| 《敏捷宣言》和《相互依赖声明》中共包含了5 个与适应性有关的原则(如图4-1所示)。 |
|
|
这些原则可以概括如下: • 预测变化(不确定性)，然后做相应调整，而不是遵循过期计划: • 根据需要调整流程和做法。 |
|
|
团队必须适应，但是不能脱离最终的项目目标。无论是适应性流程还是预测性流程，团队都应不断评估流程。可以用下面4 个问题来评估流程: • 在发布产品的同时，是否交付了价值? • 是否实现了创造可靠的、具有适应性的产品质量目标? • 项目进程是否满足可接受的要素范围? • 团队是否在有效地适应管理、客户和技术等方面的变化? |
|
适应流程不是以一个解决方案开始，而是以多个可能的解决方案(试验)开始，然后，应用一系列的适合性测试(实际产品功能或者模拟，取决于验收试验)，根据反馈信息进行改变，从而探
索并选择最好的解决方案。如果不确定性低，则适应方法的风险是高成本，而如果不确定性高，则优化方法的风险在于太早的确定某个解决方案会抑制创新。
1. 探索
鼓励型领导者知道好目标和坏目标之间的区别。鼓励型领导知道设定一个产品的构想需要团队的努力，需要基于分析、理解和现实的风险评估，同时还要有一点冒险精神。创新产品开发团队是被引导的而不是被管理的。优秀的新产品、现有产品的显著改进和创新的新业务方案都是由激情和灵感推动的。那些将精力集中在网络图、成本预算和资源柱状图的项目经理注定他们的团队是平庸的。
团队需要有共同的目的和目标，也同样需要有人鼓励他们试验、探索、犯错误、重新编组和向前迈进。
2. 响应变化
预测变化(不确定性)，然后做相应调整，而不是遵循过期计划。
这条宣言反映了敏捷方法的观点，可以进一步归纳为:
• 构想一探索与计划一执行: • 适应与预见。
- 每个项目都有己知的和未知的条件、有确定因素和不确定因素，因此，每个项目都必须在计划和变化之间找到平衡。探索型项需要有强调构想的流程，然后根据该构想探索，而不是依照详尽的计划并相对严格地执行任务。
- 影响项目管理类型的另一个因素是迭代的成本，即试验成本。即使非常迫切需要创新，但如果迭代的成本非常高，可能会导致某个流程有较多的预期工作。
3. 适应性3 个组成部分:产品、流程和人员
需要拥有同心协力的敏捷团队，对变化有正确的态度:需要有能让团队随时应对变化的流程和做法:还需要有高质量的能自动测试编码。要想拥有敏捷、适应的环境，产品、流程和人员都很重要。
短期迭代、频繁数据库更新、持续整合、自动化测试还有一系列其他敏捷做法。如果你们想要敏捷，就必须尽早并经常地对整个产品系列进行集成，经常集成好处非常大，它可以减少许多以前遗留的问题，尽早发现那些直到发布期快结束的时候才发现的问题。
敏捷开发需要短期迭代:做短期迭代需要找到快速、低成本的做重复事情的办法:快速、低成本的做事情使得团队采用以前从没有想到的方式去适应变化。快速、低成本的做事情促进创新，因为它鼓励团队试验。这些创新扩散并渗透到组织其他部分。降低变化成本促使公司重新思考他们的商业模式。
4. 可靠，但不重复
重复流程最多只能支付事先规定的东西，而可靠、交友流程可以支付比开始时每个人的设想都更好的结果。只要你足够机敏且具备预见能力，突发流程就可以产生最初希望的东西。
敏捷项目管理是可靠的、可预测的:在不确定性程度相同的情况下，它比其他任何流程更能在有限的限制内交付满足客户需要的产品。
为什么会这样呢?不是因为一些项目经理规定了详细的任务、事无巨细都管理，而是因为敏捷领导者创造了一个让人们都想争先、达到目标和倾尽全力的环境。
5. 反思和回顾
如果希望有较强的适应性，就必须愿意认真严格地评估个人和团队的绩效。有效的团队在回顾时会涉及4 个领域:
- 产品一一从客户的角度和技术质量的角度:
- 流程一-团队正在使用的优秀流程和做法:
- 团队一一作为高绩效团队，这个小组的工作情况如何:
- 项目一一项目按计划进行的如何。
第三部分 敏捷项目管理方式
敏捷开发的信条之一是适应不同情况。<<相互依赖宣言》的6 个原则之一是通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。然而，使用一个共同的架构，而且能在其中选择各自不同的敏捷方法，对于较大型组织来讲，无疑具有很大的吸引力。
1 敏捷企业架构
|
这个结构有利于组织采取混合的敏捷方法，即每层使用不同的敏捷方法，以满足组织的特定需要。该架构倡导底层(技术实践层)具有较大灵活性，上层(项目管理层)灵活性较小。这种结构认同没有哪一种敏捷方法适合所有层次。事实上，组织中使用的所有敏捷方法都是泪合型的。 例如，一个组织的项目管理层可能采用APM（Agile PM）(和部分PMBOK的组合)，迭代管理层用Scrum，而在技术层选用XP 做法。 |
|
| 技资组合治理层 |
技资组合治理层提供一些常见的检查点，关注投资和风险。 主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。他们不会真的关心需求文档是否完成了。他们想了解项目进程、投资和风险。 因此无论项目是什么类型一一敏捷或是其他，都需要创建一个管理机制，解决这两个关键的代表项目属性的指标。 |
| 项目管理层 |
项目管理还包括与核心小组外围的利益相关者和供应商合作。因此，项目管理层关注全面的项目/发布活动，协调多功能团队和管理项目外围事件。除此之外，像风险分析、合同管理等凡是对项目有用的做法，无论敏捷与否，都属于这个管理层的管理范畴。 |
| 迭代管理 | 迭代管理层关注每个短期法代的计划、执行和团队领导。 |
| 技术实践层 |
软件项目中的技术实践，包括从持续集成到结对编程，从测试开发到重构等做法。 分离出技术实践层的另外一个原因是，使敏捷项目管理更适合各种项目和产品类 |
2. 敏捷交付架构
流程也许不如人那么重要，但它绝非不重要。如果是重复性的制造，那么常规性流程是完全合理的:而如果目标是可靠的创新，则流程架构必须是有组织的、灵活的和容易适应的。
|
该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试，结束)完全不同。
|
|
| 1. 构想 |
1. 构想提供什么，即产品及项目范围构想: 2. 构想参与者都有谁，客户、产品经理、项目团队成员和利益相关方组成的社团: |
| 2. 推测---循环1 |
• 收集初始的、广泛的产品要求:--产品要求 • 制订一个迭代的、基于功能的交付计划;---里程碑发布计划 |
| 3. 探索--循环2 |
探索阶段交付产品功能。 从项目管理的角度看，这个阶段有3 个关键的活动区域: 第三，管理团队与客户、产品经理和其他利益相关方的相互交流。 |
| 4. 适应--循环3 |
控制和纠正是这个周期阶段常用的术语。 在适应阶段，需要从客户、技术、人员和流程绩效，以及项目状况等方面对结果进 自构想阶段以后，其循环通常是推测一探索一适应，每次选代都不断地优化产品。 |
| 5. 结束 | |
| 选择和整合做法的原则 |
• 简单的: //随着组织中敏捷项目的数量和规模不断增大，组织就需要有一个通用的架构、→些通用的指导原则、少许标准做法和一套通用的价值观。 |
|
关于敏捷项目管理的一个最常见的问题是"计划、架构和需求阶段如何? " 最简单的答案是，这些是活动而不是阶段。敏捷方法中这些活动所用时间和传统的序列方法一样多，只是在敏捷方法中这些活动被分配到几次选代和多次功能开发中。 |
|
| 敏捷项目管理的核心价值观和原则适用于任何规模的项目，只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化。 | |
3 扩展的敏捷交付架构
|
|
|
4. 构想阶段
没有明确的构想，敏捷项目的探索本质就会导致该项目陷入无休止的试验当中。明确的构想必须明确探索的界限。
|
|
|
|
敏捷项目成功的基础被定义为2 构想阶段的目的是明确地鉴定需要做什么以及如何做。具体地讲，这个阶段需要回答以下几个问题: • 项目的质量目标是什么? |
|
| 产品构想 |
|
|
在设计产品盒的活动中，包括客户在内的整个团队每4-6 人分成一个小组，他们的任务是设计产品盒，包括正面和背面。
提出1 当个或20 个产品功能很容易，但要想确认哪3 个或4 个功能能够吸引其他人 |
|
|
除构想框外，团队应该同时用"电梯测试说明书"编写产品定位的简短陈述，用几 电梯测试说，明书，即在两分钟内向其他人解释项目的句子，采用以下格式: 对于需要高级纸箱搬运功能的中等规模公司的配售仓库，"供应机器人"利用机器人控制升降和传送系统，提供了动态的仓储分配；它利用卡车运输各种尺寸的纸箱，减少了配售成本和装运时间。与其他同类产品不同的是，我们的产品具有高度自动化和价格优势。 |
|
|
最后，需要花费几个小时讨论记录活动挂图纸上的产品构想，团队可以对一个1~2 这份文档可能包括任务说明、构想框图、目标客户及其各自的需要、电梯测试说明书、客户满意评估标准、主要技术和业务要求、关键产品限制(性能、操作的简便性、体积)、竞争分析，以及主要财务指标。 原型和工作模型； |
|
|
产品体系结构---FBS/WBS, RBS---技术体系结构+人员体系结构 软件项目可以使用业务领域模型(参与者和性能)和技术上的框图概念模型。敏捷模型鼓励建立早期体系结构草图以便对方法有一个总体构想，也有助于确定成本和项目周期预估，随后就是体系结构和设计的演变。 功能分解结构(Feature Breakdown Structure. FBS)可以用来描述软件或硬件项目由产品体系结构(如图6-5 和图6-6 所示)。 |
|
|
指导原则 一些指导原则除了可以在项目构想阶段就制定外，通常要到早期的开发迭代时才出现。每个原则应该用一两个句子描述，而且在任何情况下，一个项目的全部原则描述不得超过十个句子。 |
|
| 顶目目标和约束 |
产品构想句勒的目标没有限制，但是作为一个项目来讲就需要有目标和限制。项目需要有明确的商业目标，质量目标和一套明确定义的性能，从而开始界定出可交付产品的范围。 项目数据表是用一页纸概括主要商业和质量目标、产品功能和项目管理信息。这是一个简单却有重要影响力的文档。它简洁的格式，对整个项目社区呼吁并且不断提醒他们哪些是项目的战略方面。 根据不同的组织和项目类型，项目数据表可能包括下面部分内容:
• 商业目标:做这个项目的总的金融和商业原因 • 性能/质量属性:产品主要性能和质量属性清单
|
| 权衡矩阵 |
这个矩阵显示出敏捷三角形(价值、质量、约束)所确定的3 个约束(范围、进度、成本)的相对重要性。如果组织必须适应变化，那么他们需要知道哪方面最具有灵活性。 随着重要性从固定、灵活到可接受逐步降低，变化的容许度逐步增加。 另一个协助团队做项目决策的有效信息是延误成本。了解延误成本有助于推动项目决策，并帮助避免无限制地增加营销部门提出的新功能。当利益相关方坚持进度是项目最重要的组成要素时，让他们计算延误成本就可以从思想上认识到进度的关键性。 |
| 探索系数 |
探索系数用来表示项目的不确定性和风险的指标。探索系数为10 表示问题领域是以探索为主(高风险)，而系数为1 表示比较稳定的环境。 找出各个问题领域因素非常重要，但更重要的是根据问题裁剪相应的流程和做法，井对期望但进行相应的调整。 探索系数是从产品需求(目的)的易变性及其技术平台(手段)的新颖性(也撤是不确定性}探生出来的。
|
4.1. 团队--找到合适的人
| 团队--找到合适的人 |
在项目计划阶段初期就需要确定所有项目参与人员，以便他们都能了解各自的和其 项目参与者包括项目社团的任何个人和群体:影响项目并决定需求的产品客户，提供资金并对项目承担一些管理监察的高级主管，以及致力于交付产品的核心项目团队成员。 参与者分为3 类: 客户(可能包括最终用户、他们的经理、产品专员、产品经理和高级主管)、开发团队成员和利益相关方。本书中"利益相关方"这个术语不仅表示内部参与者(如不是产品直接客户的经理)，也表示外部参与者(如供应商)。 作者罗布·托姆塞特将参与者(他称为"利益相关方" )分为3 个级别，每个级别的参与者对于项目有不同程度的影响
确定和管理参与者有助于提高协作. 项目参与者可能包括: • 高层管理:可能包括非常广的一群人，他们可能负责参与者的组织、也可能有预算和技术决策权力、或者对项目结果有影响力 • 产品团队:全职或者兼职的一群人，他们负责确定需要建造的功能，并排列这些功能的优先级，接受结果 |
4.2. 产品团队一开发团队交互
大量项目失败是因为定义产品·-开发团队交互活动很糟糕.任何项目都应该有开发团队和产品团队。开发团队应该以项目经理为首，而产品团队应该由产品经理领导(Scrum 称其为产品拥有者)。
|
组织内部IT 项目失败或者表现不佳，其中一个关键原因是:错误地理解了这两个角色的本质。 验收产品是客户团队验证产品是否符合发布目标并接收。验收需要通过一系列的自动测试和客户中心组评审完成。技术质量保证团队可以协助产品团队做这项工作，但最终的验收责任是产品团队的。 |
|
协作不仅是沟通，还涉及相互交流以产生一些共同结果。协作是把大家的想法综合为一个整体。
在构想阶段后，构想并没有停止。在每次迭代(或里程碑)的开头，团队在一起思考下一次迭代时，团队成员需要重新审视该构想。重新审视的目的是为了修改这个构想，或者在紧张的日常工作之余，提醒团队他们努力的目的地在哪里。
5. 推测阶段----成果：基于功能的迭代交付计划
在功能开发开始之前，需要完成3 个主要的活动:清楚表述产品构想、定义项目的目标和约束，以及制定迭代的、基于功能的交付计划。最后→个是推测阶段的最主要成
果。一旦完成发布计划，其他共同的项目管理计划过渡文件(如开支预算)，就可以最终确定。事实上，当完成功能清单和发布计划后，其他的事情就相对容易了!有了迭代和里程碑结束时的重新计划，计划和产品就会随着试验中得到的信息和不断的反馈而演变。
5.1 推测产品和顶目
|
推测阶段的产品是发布计划，该计划基于要交付的功能而并非活动。迭代计划和开发方法有两个至关重要的组成部分一一短期迭代时间框和功能 功能是开发工程师和产品团队之间的界面一一共同理解的一个媒介。这个共同的媒介采用故事卡片的形式，每个故事都写在-个另外的索引卡上。，把功能拆分成可以执行的小块任务。 功能--用户故事拆分。 |
|
|
产品经理没有权力说"我们落后了，让我们缩短测试时间吧"这样的话。相反，他们只能说"我们落后了，让我们去掉34 号和68 号功能吧。" 如果我们不断地按照计划评估人员的业绩，就会损害适应性。如果我们想要适应性、灵活性、创新以及对客户了解到的新信息作出晌应，就需要奖励团队对这些变化的响应，而不能因为团队成员未能"实现计划" |
|
5.2 产品功能清单，功能 vs 用户故事； 用户故事 vs 任务；
从潜在功能清单中，产品团队和工程团队需要讨论这些功能的优先级，并列出这些功能在发布计划中的迭代时间表。敏捷项目的特点之一是，功能清单上的这些功能具有易变性。在为每次迭代做计划时，功能清单可能发生改变，以至于不同于原来的发布计划。
功能和故事的基本区别是，故事是一个小的可交付的有用功能，但构不成-个完整的功能。
|
传统的项目计划关注这些任务领域，故事却是以客户为导向。 对于发布计划，我们以故事为单位分配每次选代的工作，因为我们想让产品团队参与到这个过程中来，他们与技术任务不相关。对于详细的迭代计划，故事被拆分成技术任务，供开发团队使用。 这些技术任务很小，因为它们的实施只是为了满足故事的需要。 |
|
| 故事卡片 |
基于故事的开发目的是面向客户开发。 故事卡片用于列出功能，而不是详细定义功能。故事卡片被用作是客户和项目团队成员在一次选代期间详细需求的讨论后达成的协议。
需求不确定性的程度和技术风险因素不仅会影响故事进度，而且会影响团队实施该故事的方法。通常，高风险的故事(无规律或者波动的)将安排在早期的迭代中，这样，团队可以确定:第一，该功能是否可以实现:第二，如果它能够实现，那么它花费的时间和金钱是否比预期要多。 不确定性高的先安排，逐步迭代，可能需要原型，可能需要预研等等。 |
|
功能清单是产品团队确定的产品性能、功能和故事的一个列表。通常情况下功能清单信息有限，包括ID 、名称、简要描述、优先级别、探索系数和估算等项目。 发布计划和法代计划都会使用功能清单上的数据(尽管两个计划的详尽水平不同)。 该主题分为两个主要部分:一是谁做这项工作，二是确定和定义功能清单项目的做法。 在瀑布式开发环境中，业务分析师与客户协作创建文档，然后传递给开发团队。开发团队与客户或者分析师几乎没有联系。而在运作良好的敏捷团队中，客户、产品专员和开发人员之间的协作比文档重要，并且协作能促进和提高对整个需求的理解过程。 三要素： 人；角色；功能（用户故事）； |
|
5.3 发布计划
发布计划是团队在项目数据表中所描述的在项目目标和约束内实现产品构想的路线图。
敏捷生命周期以迭代和故事驱动，与以瀑布式和任务驱动的传统计划有很大的区别。大多数传统的项目管理计划使用任务来构造工作分解结构以组织工作。故事驱动表现在它将计划和执行的主要重点从任务转变为产品功能。
敏捷开发让团队将重点放在交付产品功能而不是中间文档产品上。这并不是要贬低"合理的和刚好的"文档的重要性。根本问题不在于文档，而在于项目团队在制作中间产品时，往往会迷失方向，这些中间产品与团队制造最终产品的实际过程并无太大关系。通过迭代，开发团队将精力集中在少量的工作上。
里程碑是中间点，通常持续1~3 个月。里程碑既是项目管理，也是技术功能。从项目管理角度看，里程碑为评审进度和调整项目提供了机会。
客户价值和风险是推动发布计划的两个主要因素。发布计划的主要任务是以价值和风险为基础把故事分配到迭代中。
通常，在将故事分配到迭代时，最优先考虑的是交付产品团队规定的产品价值，然后是制定故事的进度计划，以便尽早降低项目风险。但有时，技术风险需要放在首要位置。至于制定进度计划时需要考虑的其他因素，如资源的可用性、依赖关系以及其他，都排在价值和风险因素之后。
发布计划应该是团队(包括产品团队、开发团队和主管)共同协作的结晶。尽管主管可以不参与整个计划过程，但是在开始阶段，团队需要主管的参与讨论，从而实现最终
目标。通常主管的建议和想法能帮助团队克服巨大的障碍。
5.3.1 范围演变
敏捷项目管理处理范围管理非常现实。范围蔓延不是问题，虽然许多评论家对需求逐步上升的问题发出了哀叹。现实非常复杂"避免范围蔓延"这样一个警告还不足以应付它。
一些范围改变的成本很低但很有价值:一些范围改变既大又代价昂贵，但对于提供客户价值又是至关重要的。
当然，如果范围改变是随意和恶意想出来的，那么它们对于项目有害无利。
但一般而言，从满足不断演变的客户需求出发、在认同它对项目的影响的基础上做出的范围变更会提高项目成功的可能性。
敏捷开发鼓励逐步深入了解后所作的变化，与此同时，它不鼓励镀金和需求蔓延，这在传统的预先需求收集时经常出现。构建最少功能策略以及简单、适度地适应变化会使团队受益匪浅。
敏捷开发按功能制定计划，让客户参与，从而将计划流程的重点放在客户关心的、很容易确定优先级的事情上。由于在每次迭代中，都根据实际开发经验、而不是凭空猜想或希望对计划进行调整，因此可有可无的功能放在以后的选代中进行或者经常被彻底取消。
产品范围的推动因素应该包括:客户价值、技术可行性、成本和关键的业务进度需要。它不应该受到我们在对产品和项目仍然不了解的情况下所制定的计划的制约。
简化非常关键，它是最大程度地减少不必要的工作的艺术。一一《敏捷宣言》
当进度出现问题的时候，瀑布式方法缩减任务，通常是减少测试，而敏捷方法减少功能。前者降低质量，后者缩小范围。
敏捷项目中的短期迭代结合迭代结束时的客户评审，使整个团队(包括开发人员、客户和经理)都认清了现实。
我们估计这次迭代可以实现25 个功能，但实际上，我们只能交付15 个，现在怎么办? "我们不得不丢弃一些功能，增派人手井且/或者延长项目时间。
注意，我们要在项目早期，趁还有时间补救的时候就这样做。传统的方法总是将这些困难的决定推迟到几乎不可能有应变措施的时候。短周期的现实检验可以防止功能失去控制。通过消除功能或者降低功能深度来减少整个工作量对于生产效率的影响非常大。
短期迭代也让开发人员精力高度集中，由于每隔几周就有一个截止日期临近，因此"增强"功能的倾向就会减少。前面讨论的优先级强调减少功能的数量，而短期迭代用于限制功能的规模。敏捷做法将变化融入开发流程中，并通过不断、集中地强调核心部分来减小项目规模。
5.3.2 第0次迭代--不交付任何价值，做相应合适的准备；在长时间做需求和架构工作或者什么准备也不做两种行为之间做平衡，或者在构想阶段完成。
第0次迭代就是尝试着找到这两者之间的平衡点。"0" 意味着在时间期限内没有任何有用的东西(即功能)可以向客户交付。然而，这个做法对于团队还是很有用的。意识到第0 次选代不交付客户价值会促使团队尽量使其保持简短。
5.3.3 第1-N次迭代
开发团队和产品团队(包括产品经理在内)共同制定发布计划。制定这个计划涉及以下活动：
• 确定己知的风险对迭代计划的影响:
• 确定进度目标---(不考虑可实现性，只从产品管理的角度确定进度目标);
• 为每次迭代编制主题:
• 将故事卡片分派给每次选代，必要时，平衡价值、风险、资源和依赖关系:
• 结合故事卡片布局(通常在墙上)、完整的发布计划、或者项目停车场图总结该计划;
• 运用权衡矩阵，必要时，调整完成的计划。
| 发布计划 | |
|
|
|
客户价值和风险是制定功能进度计划的主要因素。
例如，在需求风险无规律(需求复杂易变)的项目中，决定哪些功能首先实现可能会与技术风险高(团队从没有使用过技术组合)的项目不同。
有些时候，为了降低风险，会先期实施高风险的功能，而推迟开发正常情况下应该首先实施的高价值的功能。因此，应该认真检查风险清单，确定风险降低对发布计划的影响，特别是改变功能顺序和纠入高风险项目对发布计划的影响。
| 目标日期 | 每个项目都有目标交付日期，无论它们是即兴的或是深思熟虑的结果，都代表了利益相关方的期望。 |
| 计划日期 | 工程团队的发布计划流程的一部分。 |
|
项目团队需要理解利益相关方的期望，哪怕它是稀奇古怪的。在很多情况下s 目标日期成为项目的约束。 对于每次迭代，团队应该制定一个指导主题，这有助于团队确定重点并确保在功能的深度和广度两者之间保持平衡。 |
|
|
索引卡仍然是敏捷团队制定发布计划的主要工具。索引卡很有效，因为其可触、可视，并在每次选代计划会议期间便于查找。 |
|
|
技巧1： 在制定发布计划时，为每次迭代计划多，安排10%的时间以应对返工和意外事件，可以使计划j 更加精确。 技巧2： 尤其是对于探索系数高的项目，在项目结尾留出一个或者多个"壁的"迭代。这些缓冲区可以用来应对变化、修复缺陷或重构。另外，分配到最后才进行迭代的功能应该是优先级别较低的功能，一旦出现情况就可以放弃的这些功能。 技巧3： 其他类型的计划卡片有
|
|
| 敏捷发布计划是用来成功地适应不可避免出现的变化，而不是遵循一成不变的计划。 | |
|
第一个可行的部署FFD---确定第一个可以部署产品的迭代。早期部署和测试策略需要同时考虑。 不是所有项目都合适提前部署。 |
|
5.3.4 估计---评估工作量
由于敏捷方法通常用于探索系数高的项目，关键的估计问题变成了"您如何估计未知因素? "答案是"不能"。
当面对未知因素时，您是在猜测而非估计，这也是我们唯一能做的。这正是为什么在敏捷项目中，进度和成本通常被看作是限制而非估计的一个原因。敏捷组织学会了与不确定性共存，而不是试图在一个快速变化的世界里要求确定性。
精益思想的原则即减少浪费，对于研究活动来说，就是消除或者减少不直接产生客户价值的活动。估计是一个浪费时间的活动。在项目早期对功能进行过于详细的估计很浪费时间，因为有好多功能随后会被放弃。当对某些只是列在功能清单上的功能进行一遍又一遍估计时，也是在浪费时间。对于许多小的维护功能来说，完成它们和估计它们所用时间几乎→样。所以，估计(特别是经常进行详细的估计)应该与估计所带来的利益密切相连。一些看板(一种较新的做法，第8 章将要介绍)软件团队己经完全摒弃了估计这一活动。
一个减轻估计负担的方法是把估计和设定界限区分开来。对于一个为期12 个月要完成125 个功能的项目，大多数敏捷团队都会尝试设定界限，而不是进行精确估计。设定界限是基于拥有足够的有关项目规模的信息，从而感觉发布计划是可行的。设定界限有助于回答这样的战略问题:团队是否有能力在项目的约束内交付可发布的、有品质的产品。
许多敏捷软件团队估计故事点而不是估计员工工作时间。故事点是试图确定一个工作单位而不是工作量。在软件开发中，人们过去尝试用行代码和功能点来提供测量方法。这两种方法都有问题，最大的问题是早期估计需要做太多的工作。
故事点是一种相对测量方法(例如，这个功能比那个功能看起来大3 倍)。与试图估计工作时间的团队相比，有经验的团队做这种相对测量速度要快得多。相反，某些时候管理层通常需要进行总体工作量估计或者成本估计，就必须转换一些功能点。一些组织对于发布计划使用时间估计，而对于迭代计划使用功能点估计9。
采用基于任务的计划的优秀项目经理都知道，根据任务或者功能的详细估计累积得出的项目估计值会导致整个项目的估计值过高。
5.4 改进发布计划--
一些在多数组织中被证明非常有用的观点，其中包括：发布计划的价值、基于性能做计划、价值点分析、计划主题、应对不确定性，以及在制品与制成晶。
5.4.1 发布计划-----组织经常基于愿望做计划
管理层之所以批准项目是因为他们想要解决一个商业问题。他们想知道这个问题如何解决、成本多少、历时多长时间、他们面临多大风险等。当敏捷团队或者其他团队回
答不出这些问题时，就会被认为缺乏责任心或者缺乏信用。这也是灵活性与稳定性的问题一一"对于承诺的东西如何做到既能保证交付，同时又能留出变化、学习和惊喜的空
间? " "如何在固定期限内进行创新? "只有最优秀的团队才能解决这些看似矛盾的问题。
强加的进度表和没有进度表都不是正确答案。无论是固定的计划还是根本没有计划都不是解决问题的办法。这样只是阻碍敏捷方法更广泛的被人们所接受。
要想解决这个计划和不计划的两难境地，所有参与方必须理解敏捷发布计划的目标，即:
• 有助于更好地理解项目的可行性和可实施性
• 概述风险评估和缓解风险
• 增强团队排列性能和功能优先级的能力
• 让团队对项目有一个整体的认识
• 回答管理层有关价值、进度和成本的问题
• 创建一个让管理层和团队成员都感到舒适的项目平台
• 创建部分部署计划
其次，计划常常不是基于能力，而是基于愿望的。
一些行业文章中有关项目成功的光鲜故事使得经理们认为只要他们的团队足够努力，就会非常卓越。通常，这种激励的把戏最终导致团队不仅没能高绩效，反而功能失调。随着时间的推移，超越极限的项目计划就成为非理性的、基于愿望的计划。
组织往往基于愿望做计划，而不是基于自身能力。例如，团队经理希望他们下次能够发布50 个功能以满足市场需求，尽管开发人员清楚地知道发布30 个功能才是更现实的做法。许多经理把压力作为→种激励技巧，让员工满负荷的工作似乎是经理们最广泛使用的方法之一。
另外一个有关计划(需求)的大问题是，计划总是被当作"激励"团队的基本。一个经过认真估计和合理计划从而判定周期是9 个月的项目，有人也许会说"我们给他们6 个月的时间吧，这样能激励他们。"最好的激励是激发内部动力，而不是外部强加。把不现实的进度表强加给项目不但起不到激励作用，反而更容易起反作用。
能力与需求的不平衡产生螺旋动态使得组织深陷功能失调的行为中。
5.4.2 发布计划----多层计划---计划既需要预测性又需要灵活性
小型的为期3 个月的项目完全可以把计划做到故事层。而一个200 人、为期18 个月的项目，其计划工作必须在几个层面(如业务领域、性能、故事)展开
|
|
|
|
|
|
|
5.4.3 发布计划---性能（史诗/商业业务模块)
性能是指高级的、完整的和有价值的业务或产品功能，而故事是指向客户交付的一项有用和有价值的功能(有些人用同义词史诗代替性能来表明史诗是由许多故事组成)。
大型项目最好按功能分层做计划，区分各个层次的最好办法是根据其大小的不同。故事应该是大约2-10 天的工作量，性能应该是20-200 天的工作量。另外一个指导方针是每个高一级功能的大小大概是低一级的3 倍。完成一个功能需要6-30 天，而完成一项性能需要18-90 天。
|
在概念阶段将要结束的时候，会召开由整个产品和开发团队参加的项目章程会议，讨论产品构想、项目范围和界限以及发布计划的各种活动。 |
|
5.5 价值点分析
故事是小块的用户功能。它们既可以做相对估计(故事点)，也可以做绝对估计(小时数)。那么故事点的总数代表项目的总成本。如果项目成本是60 万美元，那么每个故事点代表了400 美元的成本。为什么不用类似的方法来衡量价值并且创造一种叫价值点的东西来代表相对价值或者货币价值呢?
需要分开考虑价值和优先级，因为最高价值的故事并非总是拥有最高优先级。适合的模糊测量方式要好于不适合的精准测量方式。价值点是表明我们非常关注价值的一种方式。，用模糊数字表示一些重要的东西比用精准数字描述一些不重要的东西更有用。
| 价值点确定:角色和时机 | 产品经理带领下的产品团队负责价值点估计。 |
| 计算相对价值点 |
应该指出的是，故事层的价值点与性能层的价值点彼此相互独立，也就是说，它们 不要忘记价值点是对总收入流的一种"分配"。如果没有实际的总收入数值以供分配，性能值的百分比就能起到防止故事层的价值点分配成为空谈或者变得无意义。 |
| 故事点+性能点+价值点 | 都是相对的。 |
| 计算货币价值点 |
货币价值点和货币故事点一起使用可以提供利润与成本进度报告。 首先，货币价值点的计算是把商业案例分析中使用的收入流表中的净现值.(Net 分配收益或净现值从而进行价值点的计算是个很恰当的方法，但是实际的成本支出
|
| 不面向客户的故事 |
如技术债务、技术故事或重构故事。 建议是根据不同情况给这些故事分配相对较小的值，如0 、1 、2 或3(0 可能分配给非常小的故事)给这些故事分配较小值的做法正好也符合"简单就好"口号。 |
| 价值与优先级 |
尽管价值永远是决定优先级的最大因素，但是其他诸如主题、风险减低、依存关系 尽管产品团队和开发团队都会参与制定是否进行技术债务投资的决策，但人们还是习惯在制定迭代计划时把新故事的开发放在首要位置。组织解决这个问题并确保技术债务能够减少的唯一办法是，技入一定比例的补贴资金专门用于此项工作。 所以，使用投入百分比资金的办法来确定其优先级的故事最多占所有故事的20%左右。 |
5.6 发布计划主题
为了能合理关注价值，项目既需要有一个总体"构想"也需要有实现该构想的短期"主题"。主题对于迭代和大型项目的里程碑都非常有用。几个不同类型的主题可以
单独使用或者联合使用，如业务职能、业务职能的广度或深度、业务流程、风险缓解和部署计划等。
我们首先实现业务职能的广度或者深度，这取决于商业价值和风险的分析。某些情况下，首先深度开发某→特定功能可能会更有益。而某些情况下，首先实现一系列众多
功能的框架结构，然后在随后的迭代中填充内容的方式会更加适合。
在项目早期，关注风险比关注商业价值更重要(这也是交付价值的方式)。例如，可能需要攻克某个技术障碍，否则整个项目就会失败。先于破除技术障碍而广泛实现业务
功能完全是在浪费资金。风险缓解主题，特别是降低那些非常重要的风险，在项目的早期就应该予以考虑。
团队应该一直考虑如果削减项目资金那么能够交付什么产品。
| 8.6.2 提高生产率 |
有两种方法可以提高生产率：做得更好或者做得更少。 有研究表明64%的软件功能很少或从来不被使用，而只有20% 的功能会经常或一直使用。但是如何考量这些不被使用的功能的生产率呢?答案又回到价值上 我们是否正以做较少的工作而交付客户的预期价值? 敏捷项目通过减少两个维度的工作来提高生产率一一广度和深度。 |
| 8.6.3 风险分析和降低 |
计划不会消除项目风险，不断系统地收集信息才能降低项目期间的风险。风险分析是产品开发流程的组成部分，并且也是发布计划的关键部分。 在关于软件风险管理的Waltzing with Bears 一书中，汤姆·狄马克和蒂姆·利斯特列出了软件项目中的5 个关键风险: 狄马克和利斯特谈到的最后一个风险是生产率低下，它有下列3 个原因:团队用人不当、团队不能很好地协作以及士气不振。敏捷项目管理中的一些做法，如找到适当的团队人员、指导和团队开发以及强迫接受项目现实，这些做法都有助于抵消这些风险。 |
| 8.6.6 其他故事类型 |
尽管发布计划中80%-90% 的故事应该都是面向客户的故事，但不要忘记还有另外 1. 维护故事 维护和改进请求(SCR)可以列为故事(故事可以是一个SCR 集合)，然后和新的开发工作一样列入选代计划中，唯一变化的是功能清单的属性。 2. 任务卡片 故事计划优先于任务计划并不意味着可以完全掏汰任务。 3. 变更卡片 4. 团队间职责协议卡片 团队间职责协议卡片用于在大型项目(有多个团队)中记录-个团队承诺为项目组内的另一个团队所做的工作。 5. 决策里程碑 不管任何项目敏捷与否，都需要监控决策点，这样做的关键在于提高项目的敏捷性。
6. 性能卡片 |
| 8.6.7 在制晶与制成品 |
减少项目数量、尽可能让专人负责项目(正如敏捷方法所推荐的)和为项目配备足够的工作人员(而不是有多个项目，每个项目的人员配备都低于平均值)可以对制成品的产出产生重大影响。 同时操作多个任务不可避免的会有等待时间。此外，任务转换时间甚至对项目造成更大的拖延。
|
5.7 新做法
| 8.7.1 看板 |
看板系统因为着手解决这个较高在制品的问题，从而在软件界越来越受欢迎。 看板把信号系统引入进度过程中，根据资源设定一个在制品的上限，一旦在制品完成就立刻引进新的工作(故事或其他工作内容)。工作通过这个"拉式"系统完成(一旦完成了一个功能，就立即把下一个功能从功能清单下拉下来)。看板井非适合所有项目，它因为取消了固定长度的法代而在组织中引起了争议，但看板可以减少估计工作从而精简计划(安德森， 2009) 。 尽管看板系统有定期发布的时间范围，但它们不使用能完成所有故事的严格的迭代长度。 看板从根本上来讲是敏捷做法一一以价值为导向、自我组织团队、反思、短期迭代(尽管不固定)和适应能力(看板系统甚至比其他敏捷计划方法更具适应性)一一所以，我认为看板恰恰就是敏捷运动的一部分。当敏捷组织成熟并寻求其他的提高绩效的方法时，看板系统非常值得考虑。 |
| 8.7.2 联合开发 |
一个组织负责完成交付工作的各个方面(新功能、改进和系统变更请求)。3 个迭代长度同时运行一一每周、每月和每季度。
|
发布计划是最重要的，有时也是最不受重视的敏捷项目管理做法之一。。发布计划为团队提供了一个游戏计划，弥补了敏捷项目总是关注短期迭代的不足，同时也为产品营销部门提供了一个依据，使其能够据此做出有关性能和故事的关键优先级的决策。最后，发布计划为管理层和主管提供了一个基准，据此他们可以判断在既定的约束内交付高质量、可发布产品的可行性。
6. 探索阶段
探索阶段旨在交付可运行的、己测试和己验收的功能。敏捷项目管理关注敏捷领导如何创建自我组织和自律的团队，从而交付可发布的产品，而不关注实现这一目标的技术细节。探索阶段包括了第5 章介绍的4 个敏捷开发方法中的3 个一一项目管理、法代管理和技术做法。
敏捷领导(包括项目、产品和迭代)必须在更广泛的组织中发挥作用。他们需要管理内部(确保职能经理和主管了解敏捷方法的好处和差异)、
- 管理外部(确保客户了解他们在
- 敏捷项目中的主要角色和责任)，
- 管理团队(鼓励他们接受并充分理解敏捷原则和做法)。
6.1 敏捷顶目领导
敏捷项目领导关注增加项目价值。
项目管理应该看作是提供鼓舞领导、集中交付客户价值的管理，而不应看作是日常管理费用。我们之所以未能看到这点，是因为许多项目管理做法和项目经理都关注合规活动，而不是交付价值。这些管理者是项目管理人员，而不是项目领导者。
客户购买的是价值，其他所有事情都是日常管理费用一一虽然有的是必要的，但终究还是日常管理费用。------------/略失偏颇，没有合规、审批，无法为公司创造利润。
- 符合政府条例的团队活动是必要的，但它们很少增加客户价值:合法的需求文档也是必要的，但不能增加价值，至少不是直接增加价值:
- 工作进度报告帮助经理完成其受托的责任，但不能增加价值:
- 无数重要事件的审批权会迷惑管理人员，让他们以为-切都在控制之中，但它们也不能增加价值。
6.2 迭代计划和监督
迭代计划和监督包括3 个主要活动z 迭代计划、工作量管理和监督法代过程。主要负责管理此项工作的是迭代经理。迭代经理也可以在每次迭代结束时组织召开诸如回顾等内容的会议.
| 9.2.1 迭代计划 |
团队在制定项目全面的发布计划之后，就开始为下一次选代(或者是第1 次选代，如果是在项目开始的话)制定详细的计划. 选取故事卡片，拆分成任务；重新评估工作量； 整个项目团队(包括产品经理、产品专员、客户、开发人员、测试人员、迭代经理 迭代计划会议所需的时间基于项目的类型和迭代的长度，建议为期一周的迭代其计 迭代主题： 在制定发布或者里程碑计划时，团队或许己经确定了迭代"主题"。如果是这样的话，还应该重新审视一下该主题，必要时再做调整。迭代主题确定了迭代的重心，防止团队陆入某些细节任务中。该主题既可以以客户为导向(如"完成信用验证能力" )，也可以以技术为导向(如"完成重构上次技术审查确定的数据库")。 |
敏捷.敏捷项目管理V2.Jim Highsmith相关推荐
- 敏捷史话（十四）：敏捷之峰的攀登者 —— Jim Highsmith
本文转自敏捷开发. "我们希望,一起组成的敏捷联盟能够帮助到其他同行,帮他们用新的更'敏捷'的方式去思考软件开发.方法论和组织.做到这一点,我们就得偿所愿了."Jim Highsm ...
- Leangoo敏捷开发项目管理软件-工作日志
Leangoo敏捷开发项目管理软件为了计算研发成本,每天开发人员可以填报他在每个需求上实际花费了多少时间,管理员可以按月进行统计. 工作日志的统计:
- Docker快速搭建Taiga敏捷开发项目管理平台
Taiga.io , Open Source, full featured project management platform for startups and agile developers ...
- 周小桥老师--技术与产品敏捷创新项目管理资深专家--沪师经纪刘建
周小桥老师 --技术与产品敏捷创新项目管理资深专家 国家职业资格鉴定中心(项目管理)专业委员会专家委员 清华大学敏捷创新项目管理主讲老师 美国Concordia大学客座教授 PMI全球专家库成员 国际 ...
- 项目管理电子书_Scrum实战：敏捷软件项目管理与开发【电子书】 附下载地址
关注公众号[互联互通社区],回复[敏捷软件项目管理与开发]获取全部内容 内容介绍 <Scrum实战--敏捷软件项目管理与开发>为软件项目团队提供了如何成功实施敏捷软件框架Scrum的实用指 ...
- 2022国产敏捷开发项目管理软件趋势
软件作为信息技术的代表是现代新经济体系的重要组成部分.回看国内软件行业的发展情况,我国软件行业起步要比国外晚个二三十年,目前只有扶持国内软件企业,才能建立国内良好的软件市场,才能让我国内软件越来越好. ...
- 敏捷研发项目管理软件和scrum看板
只要是在IT互联网行业工作的人肯定对 Scrum敏捷开发 都多多少少有一些了解.工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo. 它是由国内最早推广敏捷 也是最权威的 ...
- 敏捷是项目管理+合作
关于项目管理: 1.项目管理的目标是成功,使项目成功,提升项目成功的概率. 2.从空间角度,项目管理涉及到5W2H.人机料法环. 3.从时间角度,项目管理是PDCA.PDCA扩展一下是6D: 1)En ...
- Jim Highsmith
Jim Highsmith在软件开发和IT行业有着超过25年的经验,也是敏捷宣言的创始人之一.敏捷联盟的发起人和第一任理事. 在加入ThoughtWorks之前,Highsmith服务于CutterC ...
最新文章
- CentOS 7实战Kubernetes部署
- 和前端撕出逼格，撕的硬气 - 产品应该懂的html/css基础知识
- C 语言结构体_点运算符( . )和箭头运算符( - )的区别
- html显示hdf5文件,python读取hdf5文件
- [Leedcode][JAVA][第542题][01矩阵][BFS]
- Vue笔记大融合总结
- 阿里首款自研芯片含光800问世！算力相当于10个CPU，性能超第二名4倍！
- 谷歌推出TFGAN：开源的轻量级生成对抗网络库
- Silverlight网络寻奇 at 090413
- oracle仅部分记录建立索引的方法
- Atitit 提升扩展性bpmn艾提拉总结 工作流 目录 1.1. 尽管BPMN 1.1全面地处理了过程建模符号，但它实质上缺少解决交换格式（用于图交换）的问题 1 1.2. BPMN 2.0中使
- MySql数据库基本操作（一）
- python北京房价预测_Python爬虫告诉你北京房价有多高
- 华中科技大学计算机免试,华中科技大学计算机学院2015年接收推荐免试研究生待录取结果公示...
- 如何在 LaTeX 中画一个树状图（使用tikz和tikz-qtree包中的宏绘制树、森林、二叉树）
- 【IoT】智能硬件设计：遥控窗帘设计
- Python 学习（一） 【廖雪峰教程】
- 攻防红队日记：利用路由器创建PPTP搭建隧道进内网
- 【Git常用】之回滚
- poj-2251 Dungeon Master【bfs】