敏捷项目管理读书笔记

一、敏捷革命

不确定性、不断缩短的进度以及对迭代研究的需求并不仅限于新产品开发。
客户关系管理实施中的高失败率，部分要归罪于预见性（以计划为推动力）的项目管理方法，这些方法没有“仔细研究”主要业务流程改变所带来的不确定性。
只有创新和更快的开发还不够，公司必须给用户交付更好的、更符合需要的产品。
敏捷方法针对的产品开发工作包括下列领域的新产品和产品改进：
•商业软件产品
•带嵌入式软件的工业产品（从电子设备到汽车）
•内部开发的IT项目
“要迅速，但不要仓促” 这句话也适用于产品开发，也就是说要做正确的事，而且要学会怎样才能更快速地完成，即删除多余的没有价值的步骤。
随着产品开发流程从预见性方式转向适应性方式，项目管理方法也随之改变。这种改变必须适应机动性、试验和速度的要求，而先决条件是，它必须适合企业目标。

1.1 敏捷商业目标

一个良好的探索流程需要实现以下5个关键商业目标：
•持续创新–满足当前客户的需要
•产品适应性–满足未来客户的需要
•缩短交付进度–满足市场，提高投资回报率ROI
•人员和流程适应性–对产品和企业变化做出迅速反应
•可靠的结果–支持业务增长和盈利能力

1.1.1 持续创新

创新思想并不会在模式化的、独裁的环境中产生，而会在基于自我组织和自我约束为原则的不断适应氛围中产生。

1.1.2 产品适应性

在敏捷项目中，卓越技术通过两方面判定：
一是现在提供客户价值的能力，二是创造强适应性产品的能力。
敏捷技术的做法将重点放在减少技术债务（提高适应能力），将其作为开发流程的组成部分。
在敏捷项目中，开发人员致力于卓越技术，而项目经理则提供支持。

1.1.3 缩短交付进度

敏捷项目管理的迭代开发、基于功能的本质可以通过3种方式缩短交付周期：突出重点、简化流程和培养技能。

1.1.4 人员和流程适应性

敏捷项目管理的指导原则和架构鼓励把学习和适应当做向客户提供价值的组成部分。

1.1.5 可靠的结果

组织结构适度、灵活的流程，对于新产品和新服务开发有更好的效果。
如果目标是提供符合已知的、不变的说明要求的产品，就用重复的流程。相反，如果目标是提供有特定限制的价值的产品，而变化和截止日期都是非常重要的因素，那么可靠流程更为适用。

1.2 敏捷的定义

敏捷是制造并响应变化从而在动荡的商业环境中创造利润的能力。
敏捷是平衡灵活性和稳定性的能力。
在高度变化的 产品幵发环境中，严格的配置管理可以保持稳定并促进灵活性，就像集中精力于卓越技术可以稳定开发工作一样。

1.3 敏捷领导价值观

敏捷强调的是态度而不是流程，它是氛围而不是方法。
团队为何存在、要创造什么产品、为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。
如果想要创造优秀的产品，就需要有优秀的人才；如果想要吸引并留住优秀的人才，就需要有优秀的原则。
团队管理者鼓励团队成员自我管理，通过完成拆分任务从而实现产品功能的开发。而任务管理者只是关注任务的完成情况，并用其评估团队是否遵循计划行事。
团队管理者帮助团队（或者更广泛意义的项目组）成员协同有效地工作从而保证他们能够成功地完成任务。 而任务管理者只是监督其成员，以确保他们在工作并能跟上计划进度。
有研究表明，超过50%的软件功能很少被使用甚至从来没被使用过，所以， 认为关注范围和要求就能产生价值的想法是错误的。
如果把项目看做是动态的且不断变化的， 那么适应变化的能力是最重要的，这种能力来源于创新思维和对目标的深刻理解。
一个企业无论敏捷与否，都应该了解客户需求，这是一个很重要的价值观，但它不能像那3个价值观一样用来区分企业敏捷与否。

1.4 敏捷绩效评估

敏捷项目评估的3个目标可归纳为：
价值目标–提供可交付的产品
质量目标–提供可靠的、适应性强的可交付产品
约束目标–在可接受的约束内，实现价值和质量目标

1.5 敏捷项目管理架构

项目管理流程和绩效评估对于基于探索和试验的方法和基于生产和技术规范的方法是不同的。
以生产为导向的项目管理流程和做法强调完整的早期计划和要求说明，并且要求以后将尽量不会改动。
而基于探索的流程虽然也强调早期计划（仅是名义上的）， 但它更强调足够好的要求和可实验可改进的设计方案，而且随后会通过不断学习，做出重大改动。
两种方法各有其优势，两者的生命周期架构也大不相同。
在一个有4个管理层面的敏捷组织架构里，敏捷项目管理交付方法包括5个阶段：构想、推测、探索、适应和结束，而每个阶段都有各自的做法。这些阶段更近似于科学调査过程，而不是生产管理流程。
构想阶段，产生一个淸晰明白的业务或者产品构想，为后面的阶段划出边界；
推测阶段，团队推测产品的规格，制定一个发布计划，随着项目的不断进行，技术要求和客户要求会随着新知识的获得不断演变；
探索阶段，它和迭代平行作业，其中要完成最初的功能和需求设计；
适应阶段，这些试验的结果需要经过技术、客户和企业的个案审査，以便在下一次迭代 过程中继续做出调整。

1.6 敏捷项目成功率

敏捷项目也会失败，世界上没有一劳永逸的方法，敏捷方法也不例外。如果我们相信《敏捷宣言》中的价值观——个体比过程和工具重要的话，那么失败很可能是因为我们用错了人，而不是用错了流程。

1.7 总结

希望敏捷项目管理的概念和做法能帮助读者实现如下目标：向客户交付创新的产品和改善工作环境，
敏捷项目管理的许多做法并不是新创造的。
敏捷项目管理继承了丰富的项目管理遗产，并吸取其精华去其槽柏；吸收了丰富的管理、制造和软件开发理论和实践经验，融合了最适合机动性和速度的世界观和思想体系。
敏捷项目管理并不适用于所有人和所有项目，它并不是万事通用的最佳实践。
敏捷项目管理只针对特定类型的问题、特定类型的组织，适于那些有特定文化观点的人和那些有特定世界观的领导者。
敏捷项目管理不限于一小套做法和技巧，它定义了如下的策略能力：提供可交付的产品、创造和适应变化、在灵活性和结构之间保持平衡、挖掘开发团队的创造力和创新能力以及引导组织度过动荡和不确定的时期。

2.价值胜过约束

通常人们总是关注容易测量的因素，而忽视了真正至关重要却难以量化的特征。敏捷开发试图改变这种状况，去关注最重要的因素，而排在首位的正是价值。
结果包括产品构想、商业目标和性能（高级产品功能），而没有具体需求。这些结果特征定义了可发布的产品。
质量目标定义了交付可靠的、可适应的（可工作的并易于改进）产品。这些都是很关键的价值特质。
项目领导可以通过以下几种方式来关注产品价值：价值确定（与客户一起）、价值优先级排序（订单管理）、价值创造（迭代开发）。

2.1 持续创造客户价值

投资回报原则里有这样一对关键词：持续和价值。价值是指企业或组织的产出结果, 往往与财务收益有关。持续是指价值能经得起时间的考验——无论是现在还是将来。
客户阐明产品应该具备的性能、带来的价值和实现量化该价值的商业目标。客户是用创造的产品来产生商业价值的个人或群体。对于零售产品，客户就是使用产品的人。
客户定义价值，他们用亲身经历来判断产品价值。这个定义将客户与其他利益相关方区别幵来。
任何产品的成功都需要满足期最终客户的、利益相关方的和团队自身的期望值。培养忠诚的客户和利益相关方意味着与他们会谈讨论需求和期望值。
提供客户价值涉及3个特别重要的话题：一是将重点放在创新和适应性而不是效率和优化，二是专注于执行，三是精益思维。

2.1.1 创新

在一个公司的项目中，创新往往能创造最大价值。创新不拘泥于任何形式，可以是新的产品、新的商业模式、新的流程或者新的业绩。
创造新产品和新服务不同于对现有产品作微小改进。前者必须将重点放在创新和适应性，而后者通常注重效率和优化。
敏捷项目管理的主要目的是创造新产品和新服务。要实现这个目标，就需要不断的技术变革、增加竞争优勢、产生新的创意和不断地缩短产品开发周期。

2.1.2 执行

传统的项目管理做法过于强调计划管理和控制的自动调节模式，而对项目管理应该做的执行不够重视。
敏捷项目管理是侧重于执行的模型，而不是侧重于计划和控制的模型。
在敏捷项目管理中，项目经理的首要任务是促进产品构想的构思，并指导团队去实现该构想，而不是制定计划和进度表、控制进度，保证“计划”得以实行。
一旦项目团队将重点放在执行上，下一个关键步骤就是将精力集中到增值活动上， 即辅助团队交付结果的活动，而非只是确保合规的活动。

2.1.3 精益思维

敏捷运动的许多想法都源于自精益生产。精益生产最早出现于20世纪80年代的日本汽车制造业。
精益生产的一个基本原则是系统地消除浪费，即减少不向客户提供价值的活动。
一个简化项目（做较少的事、做正确的事、消除瓶颈）的方法是区分交付活动和合规活动，以及对每种活动分别采用相应的策略。
过多的结构不仅会扼杀主动性和创新，而且消耗了大量的时间。不可将流程凌驾于个人知识和能力之上。
交付的相关活动与合规活动对项目经理有特殊的重大意义。
第一，项目经理需要分析项目活动，以保证用在交付活动上的时间最多；
第二，项目经理必须分析他们自己的活动，以确定他们是在从事交付活动还是合规活动。

2.2 迭代、基于功能的交付

采用迭代、基于功能的交付方式，能在早期捕获价值，而且通常可以极大地提高项目的投资回报率。
敏捷开发和项目管理侧重于交付实际产品的不同版本，或者，如果材料成本高的话，交付实际产品的有效模拟或者模型。
敏捷的迭代组成部分可以用下面为4个关键词来表示：迭代、基于功能、时间框和增量。
迭代开发是指要建造产品的部分版本，然后通过连续的短期开发以及评审和修改，扩展该版本。
基于功能的交付是指设计团队建造最终产品的功能，或者至少是与最终产品最接近的代表物（如模拟、模型），尤其是对于工业产品。
功能交付方法帮助定义客户和产品开发者间的可行界面.客户决定进度和功能的优先次序，而产品工程师确定提供这些功能需要的任务，以及完成该任务要花费的时间和成本。
对于需求可能会随时间推移而演变的项目和产品，让客户在开发过程期间评审结果，使其尽可能接近实际产品，就显得尤为关键。
迭代开发同时也是自我纠正的过程。促进探索很关键，但知道何时停止也很关键。

2.3 卓越技术

敏捷开发人员致力于卓越技术，不是因为美学（尽管它可能是一些项目的理论基础），而是因为致力于卓越技术可以交付客户价值。
高品质能确保公司在未来交付价值。敏捷组织的结构虽然不是很精致正规，但他们倾向于遵照自己己有的结构。敏捷开发人员认为迭代、新兴设计和频繁反馈可以产生更出众的设计。
支持卓越技术要求项目经理和团队成员明白卓越技术的含义——它在于产品技术以及从事工作的人的技能。
任何公司都不可能制造出完美的产品，但制造提供客户价值并保持技术完整产品是商业成功的关键，也是令技术团队满意的关键。
项目经理需要与团队一起，讨论和决定开发的技术方法，而且在决定技术问题时，让团队不要忘记企业目标。
项目经理必须支持卓越技术，因为它是适应能力和低成本迭代的关键，而这两者是产品长期成功的推动力。
项目经理不必是技术权威人士，但必须具备足够的知识，才能与技术权威沟通。

2.4 简化

如果想快速而又敏捷，就要保持事情简单。速度不是简化的结果，但简化能提高速度。
釆用去掉详细的基于任务的结构和合规工作来简化流程，就强迫人们思考和交流。
一套再生做法是一个系统在一起正常运转的最小单位。它并不规定一个团队需要做的每件事，而是确定那些具有非常高的价值、适用于几乎每个项目的做法。

2.4.1 再生规则

敏捷项目管理的主要原则之一就是敏捷做法，在引导原则的推动下，它是可再生的，而不是规范性的。
从最小单位的实践着手，然后明智地随着需要而增加其他业务，比从全面常规性做法开始，然后试图精简，最后找到可用的做法更加有效。
开发一套有用的规则不是件容易的事情，因为正确的规则组合通常是反直觉的。轻微的改变也能引发无法预料的结果。

2.4.2 刚刚足够的方法论

刚刚足够并不意味着不足，也不意味着“无文档”或者“无流程”。
迅速而又有效地完成交付活动能加快项目进程，而过于强调合规活动会中断速度。选择绝对、肯定要做的活动并很好地完成能够加快速度，过多地执行关键活动可能是仓促的结果。
找到迅速但不仓促这个平衡的一个竞争优势是它通常能够加速竞争。这实际上也是实施敏捷方法的一个潜在危险。
如果领导者能够巧妙地将复杂问题简单化、能够制定刚刚足够的流程、能够找到快速和仓促之间的分界线，那么他无疑有更高的成功几率。

2.4.3 交付活动与合规活动

系统往往不断扩张，填补己知的世界；系统往往反对他们自身的正确功能。
即使是要自己承担那些任务，项目经理也要尽可能地将项目团队从繁多的合规工作中解脱出来。
对于必要的合规活动，应该釆取的策略是尽量减少必要活动，并使他们远离关键途径和关键人员。

2.5 总结

传统项目管理关注在范围、时间和成本等约束内按计划行事。而这个做法经常会使团队交付较低的客户价值。
计划很快就过时了，而商业目的和目标却保持不变，通过关注现在或将来的价值，团队能与他们的目标一致，而组织也能更加有效地实现企业目标。
产品性能的价值评估、追求卓越技术、改变绩效评估方法和提供精助团队交付价值而不是要素的做法等将会是主要的讨论内容。
敏捷三角形——价值（任何发布的产品）、质量（可靠的、适应的产品）、约束（成本、进度、范围）

3.团队胜过任务

敏捷领导者领导团队，非敏捷领导者管理任务。
敏捷项目管理强调团队管理，提倡建立自我组织团队和发展服务型领导方式。这比管理任务更加困难，但最终的结果会更令人满意。
在敏捷项目中，团队成员关注任务，项目领导关注团队。

3.1 领导团队

计划、控制、预算和流程可以帮助项目经理避开潜在威胁项目的复杂事物。然而，当不确定性、风险和变化显著的时候，只有这些做法是不够的, 还需要有适应变化的做法。
想建立适应能力强的、自我组织的项目团队，领导者应该引导而不是控制，在某些情况下，他们影响、轻推、促进、教授、建议、协助、催促、劝告以及指导。
领导者之所以成为领导者，不是因为他们所做的事情，而是因为他们扮演的角色。
领导者在很大程度上依靠的是影响力而并非权力，影响力来自于人们的尊敬而不是敬畏。
领导者是项目团队的一部分，虽然他们得到组织的授权，但他们真正的权力不是自上而下委派的，而是自下而上赢得的。
领导者鼓励变化，其方式为：提出未来可能性的想象，通过与大量人员交流，发现能够帮助将产品构想变为现实的新信息，以及激发目的感，激励人们致力于一些超出常规的事情。
掌管方向意味着团队经理有时单方面做决策，有时让团队参与共同决策，但主要是把权力下放，让团队决策。
领导——协作的管理风格创建了这样的社会体系结构：一个可以让组织和团队面对环境多变性的结构。这种社会体系结构融合了这些概念：平等主义、才干、激情、自律和自我组织。
支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提供指导以及促进人们与团队之间的联系。
敏捷运动支持个人和团队通过致力于自我组织、自律、平等主义、尊重个人和能力等观念，实现发展。
“敏捷”是社会技术运动，它有两个推动力：
一个是愿望：创造一种特定的工作环境；
一个是信念：适应性强的环境是向客户提供创新产品目标的关键。

3.2 建立自我组织（自律）团队

自我组织团队是敏捷项目管理的核心，他们结合了自由和责任、灵活性和结构。
面对矛盾和模糊性，团队的目标是始终如一地在项目范围内和产品构想基础上进行交付（包括适应性）。要达到这个目标，需要团队有自我组织的结构和自律的团队成员。建立这种团队是敏捷项目经理的工作核心。
个人负责管理自己的工作量，根据需要和最适合原则轮班工作，并对团队效率负责。对于如何“交付结果”，团队成员自己保有较大的灵活性，但他们对结果负责，并在制定的灵活框架内工作。
创建自我组织的团队需要：
•找到适当的人员；
•清楚表述产品构想、界限和团队角色；
•鼓励协作；
•坚持负责；
•培养自律；
•引导而不是控制。
敏捷项目管理是关于人，以及人和人之间的相互交流、是关于营造一种环境，让个人创造力和能力爆发、从而创造优秀产品。创造优秀产品的是人，而不是流程。

3.2.1 找到合适的人员

通过项目领导者或其他经理，组织有责任为项目配备适当的人员。找到适当的人员意味着找到具有合适技术和行为技能的人。
敏捷主义者认为，流程可以为高效率工作提供共同框架，但它不能代替能力和技能；产品是由能干的、技术熟练的人员制造的，而不是由流程制造的。
高效率的项目经理将重点依次放在人员、产品和流程。

3.2.2 坚持负责

责任和负责创造了自我组织团队。
每个团队成员和项目领导相互履行承诺是义不容辞的责任。
信任是协作的基石，而履行承诺是建立信任的核心，这样就能建立高效的团队。

3.2.3 培养自律

自律是自由和授权的前提，如果个人和团队想要更多的自主权，他们就必须有更多的自律。
自律的个人可以：
•对结果负责；
•用严谨的思维对抗现实；
•参与激烈的交流和争辩；
•愿意在自我组织框架内工作；
•尊重同事。
对话、讨论和参与式决策都是建立自律的一部分。
自律也是建立在能力、坚持和愿意承担结果的责任之上。才干不仅是技能和能力，它是态度和经验。
让合适的人员参与，自律就会更容易些；而如果找到的是不适当的人员，强迫的纪律就会逐步蔓延，从而破坏信任和尊重的氛围。
敏捷团队不会因为有良好的意图就自动发展。敏捷团队的成长和成熟需要时间，也需要致力于建立关系和鼓励协作。这是项目领导及个体团队成员最重要的任务。

3.3 鼓励协作

自我组织团队的能力在于协作，即两个或更多的人相互交流和合作以共同地产生一个结果。
协作的结果可以分为：有形的可交付物、决定和共享知识。
适度的流程和工具很有用，但是当要做出关键的决策时，更多的是依赖个体和团队的知识和能力去克服那些障碍。
协作结果的质量优劣取决于信任与尊重的程度、信息流动的自由度、辩论以及积极的参与，同时也受到参与式决策流程的约束。
在协作团队中，领导者的一个关键角色就是促进、教导、吸引和影响团队成员，让他们建立健康的关系。

3.3.1 参与式决策

决策是协作的心脏和灵魂。任何人都可以坐下来，谈论产品的设计。协作就是大家共同努力创造一个功能、一个设计、或者编写产品的文档。协作就是大家共同努力。
妥协来自于输贏思想，其中不是我正确，就是你错误。取而代之，可选择双贏思想模式，用重新构思代替妥协。
重新构思意味着将多种想法合并起来，创造一种比任何一个单独想法更好的东西。它不是放弃，而是增加。
自我组织的团队有许多自由决定的决策权力，与项目经理的权力平衡。和其他领域一样，平衡在决策中是敏捷的关键。

3.3.2 共享空间

创新并不会因为一些确定性的流程而得到保证，创新是突发流程的结果，在这个流程中，具有创造性想法的个人相互交流，引发了某些新颖的、与众不同的东西的产生。
演示、原型、模拟和模型是相互交流的催化剂，他们组成了“共享空间”，其中开发人员、市场人员、客户和经理可以做有重大意义的相互交流。
共享空间有两个要求——直观化和公共性。直观化推动了如今的工业设计。公共性意味着原型需要得到开发工作的所有利益相关方的理解。
在项目的每个阶段，项目领导者都需要知道哪些人在该阶段需要相互交流、需要什么样的共享空间以达到交流的效果。

3.3.3 客户合作

敏捷项目管理依赖于有效的客户合作。客户或者产品团队应该是任何敏捷开发工作不可或缺的一部分。
下面列出了客户团队在参与敏捷项目时的部分责任：
•创造并管理功能清单；
•确定发布和迭代计划的优先级；
•辨别并定义功能；
•定义接受标准；
•审核并接受完整的功能；
•和开发团队持续交流；
•为结果和调整约束负责。
“敏捷”经常指出客户和产品团队的不足，并且需要和产品团队定位各自的角色，如界定产品经理和产品专员的角色。

3.4 不再需要自我组织团队

尽管敏捷领导在自上而下的决策制定活动中角色“轻”，但他们在诸如阐述目标、促进交流、提高团队动力、支持协作、鼓励试验和创新的活动中角色却“重”。
我们需要的是优秀的领导，我们需要的是更好的领导方式，我们需要的是在正确范围内努力授权给他们团队的经理和领导。

3.5 总结

敏捷领导管理团队，敏捷团队管理自己的任务。
敏捷领导阐明团队目的和目标、产品构想、关键性能和约束，然后激励团队成员交付，团队成员自己弄清如何完成任务的细节。
赋予团队灵活性和适应性，而不是盲目遵循既定任务。
鼓励团队自我组织，从而找到最好的方式去实现项目目标。

4.适应胜过遵循

传统的顼目管理者注重按计划行事，尽量做到和计划没有出入，而敏捷项目领导者关注如何成功地去适应不可避免出现的变化。
传统的项目经理视计划为目标，而敏捷领导者视顾客价值为目标。
以客户价值和质量为目标，计划就是实现这些目标的方式，而不是目标本身。计划应该灵活，应该是依据，而不是约束。
传统和敏捷领导者都做计划，而且花费相当长的时间做计划，但他们看待计划的方式却截然不同。他们都视计划为基线，但是传统经理不断修正实际结果以符合那个基线。
PMBOK称一种相关做法为纠偏行为，用来引导团队回归基线。在敏捷项目管理中，适应行为用来描述应该釆取什么行动方针（其中一个行为可能被修正以符合计划要求）。
适应性有关的原则可以概括如下：
•预测变化（不确定性），然后做相应调整，而不是遵循过期计划；
•根据需要调整流程和做法。
响应变化的能力提升竞争优势。
•思考每周发布一个新的产品版本的可能性（而不是问题）；
•思考竞争优势能够提供功能包给客户，让客户感觉到是为他们个性化定制的软件和保持低消耗的软件维护费用。
团队必须适应，但是不能脱离最终的项冃目标。无论是适应性流程还是预测性流程，团队都应不断评估流程。
可以用下面4个问题来评估流程：
•在发布产品的同时，是否交付了价值？
•是否实现了创造可靠的、具有适应性的产品质量目标？
•项目进程是否满足可接受的要素范围？
•团队是否在有效地适应管理、客户和技术等方面的变化？

4.1 适应学

适应性开发流程与优化流程具有不同的特征。
优化反映的是说明性的“计划-设计-建造”周期，而适应反映的是有机的、进化的“构想成索-适应”周期。
适应流程不是以一个解决方案开始，而是以多个可能的解决方案（试验）开始。
应用一系列的适合性测试（实际产品功能或者模拟，取决于验收试验），根据反馈信息进行改变，从而探索并选择最好的解决方案。

4.2 探索

变革是艰难的。敏捷领导者需要鼓励和激发团队成员度过这些高度变化的环境所造成的困难。
鼓励包括保持自我镇静、鼓励试验、借鉴成功和错误经验，以及帮助团队成员理解这种鼓励的所有部分。
创造变化，就是向对手展开竞争攻势。响应竞争对手的变化，就是在防守。
好的领导者创造安全的环境，让人们说出奇特的想法，更何况一些想法原来并不奇特，外部的鼓励和激发可以帮助团队建立内部激励。
伟大的探索来自于精神领袖。伟大的探索者清楚表述出可以激发人们灵感的目标。
鼓励型领导者知道好目标和坏目标之间的区别。鼓励型领导知道设定一个产品的构想需要团队的努力，需要基于分析、理解和现实的风险评估，同时还要有一点冒险精神。
领导者清楚阐述团队目标，团队成员透彻了解这些目标并以此激励自己。内在的激 励可以激发探索。
团队需要有共同的目的和目标，也同样需要有人鼓励他们试验、探索、犯错误、重新编组和向前迈进。

4.3 响应变化

预测变化（不确定性），然后做相应调整，而不是遵循过期计划。
这条宣言反映了敏捷方法的观点，可以进一步归纳为：
•构想一探索与计划一执行；
•适应与预见。
每个项目都有己知的和未知的条件、有确定因素和不确定因素，因此，每个项目都必须在计划和变化之间找到平衡。
影响项目管理类型的另一个因素是迭代的成本，即试验成本。即使非常迫切需要创新，但如果迭代的成本非常高，可能会导致某个流程有较多的预期工作。
低成本的迭代可以产生适应风格的开发，这种开发就是计划、体系结构和设计与实际的产品同时演变。

4.4 产品、流程和人员

适应性有3个组成部分：产品、流程和人员。
•需要拥有同心协力的敏捷团队，对变化有正确的态度;
•需要有能让团队随时应 对变化的流程和做法;
•需要有髙质量的能自动测试编码。
要想拥有敏捷、适应的环境，产品、流程和人员都很重要。
许多软件组织实施敏捷的障碍是他们没有处理遗留代码中的技术债务。这也是可以理解的，因为解决方案耗时耗钱。然而，不解决这一重大障碍，许多组织将不会实现其敏捷潜能。

4.5 障碍还是机会

大多数情况下（不是所有情况），人们感觉适应变化有障碍（成本太贵）是因为做事效 率低下——没能抓住机会简化流程并提高组织的适应能力。
敏捷开发需要短期迭代，做短期迭代需要找到快速、低成本的做重复事情的办法；
•快速、低成本的做事情使得团队采用以前从没有想到的方式去适应变化;
•快速、低成本的做事情促进创新，因为它鼓励团队试验。这些创新扩散并渗透到组织其他部分。
降低变化成本促使公司重新思考他们的商业模式。

4.6 可靠，但不重复

重复意味着按照同样 的方式做同样的事情，并取得同样的结果；而可靠意味着无论在前进道路中遇到什么障碍，都能达到目标，也意味着为达到一个目标而不断改变。
可重复流程通过评估和不断的流程纠正，减少可变性。
可靠流程将重点放在输出，而非输入。即使输入差别巨大，釆用可靠流程，团队成员也可以找到达到预定目标的方法。
敏捷项目中需要考虑的正确范围不是限定的要求，而是清晰、明白的产品构想一个可发布的产品。
尽管敏捷项目管理是可靠的，但它不是一贯正确的，它也不能消除不确定性的反复无常和在探索中遇到的出乎意料的事情。

4.7 反思和回顾

有效的团队在回顾时会涉及4个领域：
产品–A客户的角度和技术质量的角度；
流程–团队正在使用的优秀流程和做法；
团队–作 为高绩效团队，这个小组的工作情况如何；
项目–项目按计划进行的如何。
在每次迭 代结束时和项目末期，对这些领域进行回顾和反馈，然后适应，从而提高绩效。

4.8 从原则到做法

人们所做的事和做事的方式最终产生优质的产品。原则和做法是向导，他们帮着确定和加强人们的行为。
在敏捷项目中，既要有预见性也要有适应性的流程和做法。根据已知信息发布计划来预见未来。反思根据随后在项目中发现的信息来适应代码。

4.9 总结

开发优质的产品需要探索，而不是遵循计划。
探索和适应是创新的两个行为特质–拥有探索未知世界的勇气、拥有承认错误并适应形势的谦逊。

5.敏捷项目管理模式

敏捷开发的信条之一是适应不同情况。
通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。
使用一个共同的架构，而且能在其中选择各自不同的敏捷方法，对于较大型组织来讲，无疑具有很大的吸引力。

5.1 敏捷企业架构

从上至下依次为投资组合治理、项目管理、迭代代理、技术实践。
这个结构有利于组织釆取混合的敏捷方法，即每层使用不同的敏捷方法，以满足组织的特定需要。
该架构倡导底层（技术实践层）具有较大灵活性，上层（项目管理层）灵活性较小。这种结构认同没有哪一种敏捷方法适合所有层次。

5.1.1 投资组合治理层

主管们需要的就是一个通用的架构，可以用来评估所有项目。
这个架构涉及主管们所关心的主要问题——投资和风险。主管们想知道项目的价值（及投资回报率）和获取该价值的确定性和不确定性。
无论项目是什么类型——敏捷或是其他，都需要创建一个管理机制，解决这两个关键的代表项目属性的指标。

5.1.2 项目管理层

项目管理即是与核心小组的外围利益相关者打交道，而迭代管理与核心小组的内部利益相关者打交道，这的确是两者差异的一部分，但只是一半。另一个很大的不同是一个是管理发布，一个是管理迭代。
一个完整的项目发布计划，涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。
项目管理还包括与核心小组外围的利益相关者和供应商合作。因此，项目管理层关注全面的项目/发布活动，协调多功能团队和管理项目外围事件。
项目管理和迭代管理是可以是同一个领导者，也可以是不同的领导者，取决于项目的大小。

5.1.3 迭代管理层

迭代管理层关注每个短期迭代的计划、执行和团队领导。

5.1.4 技术实践层

软件项目中的技术实践，包括从持续集成到结对编程，从测试开发到重构等做法。硬件项目可能釆用一系列工程做法，从电子到机械不等。在各种各样的组织中，变革技术实践是实施敏捷方法的关键。
分离出技术实践层的另外一个原因是，使敏捷项目管理更适合各种项目和产品类型。敏捷软件的等值做法在各种产品开发领域都很有价值。
除了硬件项目中可能存在较长时间的迭代外，投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

5.2 敏捷交付架构

流程也许不如人那么重要，但它绝非不重要。
如果目标是重复性的制造，那么常规性流程是完全合理的；如果目标是可靠的创新，那么流程架构必须是有组织的、灵活的和容易适应的。
敏捷项目管理模式的结构：构想一推测一探索一适应一结束，重点在交付（执行）和适应。
•构想：确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。
•推测：制定基于性能和/或功能的发布计划，确保交付构想的产品。
•探索：在短期内计划和提供它经测试的功能，不断致力于减少项目风险和不 确定性。
•适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
•结束：终止项目、交流主要的学习成果并庆祝。
该架构中各阶段的命名与传统的阶段命名完全不同，其意义重大。第一，“构想”代替较传统的“开始”，指出构想的重要性；第二，推测阶段代替计划阶段。
第三，敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。以迭代交付的方式，很明显探索是非线性的、并存的、非瀑布式的模式。

5.2.1 阶段：构想

构想阶段为客户和项目团队创建构想，该构想包括什么、谁提供提供和如何提供。构想是项目早期 “成功的关键因素”。
首先，我们需要构想提供什么，即产品及项目范围构想；
其次，我们需要构想参与者都有谁：客户、产品经理、项目团队成员和利益相关方组成的社团；
最后，项目团队成员必须构想他们打算如何共同工作。

5.2.2 阶段：推测

敏捷项目管理包括的构想和探索比计划和执行要多，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。
推测阶段包括：
•收集初始的、广泛的产品要求；
•将工作量定义为一个产品功能清单；
•制订一个迭代的、基于功能的交付计划；
•把风险降低策略纳入计划；
•估计项目成本，并生成其他必要的行政管理和财务信息。

5.2.3 阶段：探索

探索阶段交付产品功能。从项目管理的角度看，这个阶段有3个关键的活动区域：
第一，通过管理工作量和使用适当的技术方法和风险降低策略，技计划交付产品功能；
第二，建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代 领导者推动；
第三，管理团队与客户、产品经理和其他利益相关方的相互交流。

5.2.4 阶段：适应

控制和纠正是这个周期阶段常用的术语。
在适应阶段，需要从客户、技术、入员和流程绩效，以及项目状况等方面对结果进行检査。
要根据项目得到的最新信息，思考实际的与修订后的项目前景。修改后的结果将反馈并应用到重新计划工作中，以开始新的迭代。
自构想阶段以后，其循环通常是推测——探索——适应，每次迭代都不断地优化产品。但是对团队收集新信息来说，定期修正构想阶段也尤为重要。

5.2.5 阶段：结束

项目应该以庆功典礼为结束。结束阶段（以及每次迭代末尾的小型结束）的主要目标是；学习并将学到的东西融入下一次迭代工作中。或者传递给下一个项目团队。

5.2.6 不是完整的产品生命周期

产品生命周期的前后两个阶段（早期的概念构想阶段和晩期的配置阶段）没被包含在这个架枸中，不是因为它们不重要，而是因为它们超出了本书的范围。

5.2.7 选择和整合做法

原则指导做法，做法用实际例子证明原则，两者是相辅相成。
在选择和使用做法时，作者采用了如下指导原则：
•简单的；
•再生的而非常规性的；
•与敏捷价值观和原则一致的；
•关注交付活动（增值）而非合规活动；
•最少数量（刚好可以完成工作）的；
•相互支持的（做法系统）。

5.2.8 需具备的判断力

尽管项目可能遵照一般的构想、推测、探索、适应和结束 这个次序，但人们不应该将整个模式看作是固定的。
生产型模式所用的阶段名称暗示着一个线性和重复的模式：开始、计划、定义、设计、构建、测试，而这里选用的敏捷项目管理术语是用来表示迭代演变：推测、探索、适应。
过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是盲目的变化。
对于任何一种模式，开发团队成员、产品团队成员和高级主管在应用时都需要作出敏锐的判断。
敏捷方法中计划、架构和需求活动所用时间和传统的序列方法一样多，只是在敏捷方法中这些活动被分配到几次迭代和多次功能开发中。
在序列开发过程中，早期的架构决策在项目晚期及实际的构建出现时才能得到验证。到那个时候， 已经花费了大量的时间和金钱。到时再改变这个架构，就成为一项重大的耗时的决定， 但通常已经不可能修改了。

5.2.9 项目规模

敏捷项目管理的核心价值观和原则适用于任何规模的项目，相似的，在后面章节描 述的做法也适用于任何规模的项目。
随着项目团队不断扩大，通常需要有更多的文档、有其他的协调做法、增加仪式 或者其他合规活动（如财务控制），这些扩展的做法同样也受敏捷项目管理的价值观和原则的指导。
只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协 调问题再复杂，它也能随时应对商业、技术和组织的变化。

5.3 扩展的敏捷交付架构

敏捷开发生命周期包括：构想阶段——推测阶段——探索阶段——产品开始阶段——结束阶段
构想阶段：项目章程、产品构想、项目范围和界限、准备性评估、骨架结构、团队构想
推测阶段：故事ID、发布计划
探索阶段：迭代交付、项目领导
产品开始阶段：最终评审和接受、最终质量评估和文档、增量交付和最终产品部署
结束阶段：项目反思、最终项目、最终项目、产品文档、清理余下问题
迭代交付包括：准备和计划——开发——质量评估和接受测试——评审和适应（持续和故事部署贯穿始终）
持续：架构和设计演变，持续构建和集成，项目管理，日常站立会议，文档，变化协调，迁移和集成。

5.4 结束语

像敏捷项目一样，敏捷架构应该在结构和灵活性之间保持平衡。
随着组织中敏捷项 目的数量和规模不断増大，组织就需要有一个通用的架构、一些通用的指导原则、少许标准做法和一套通用的价值观。
“敏捷艺术”，即平衡结构和灵活性的能力。它用有效的领导力和敏捷经验去发现每个组织的最佳平衡点。