本书概览
2 敏捷概述
2.1 可确定工作与高度不确定的工作
可确定性的工作项目具有明确的流程，它们再以往类似的项目中被证明视行之有效的，并且执行的不确定性和风险通常较低。
高度不确定的项目变化速度快，复杂性和风险也高。是探索性的。这些特点可能会给传统预测法带来问题，传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。
而敏捷的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。
2.2 《敏捷宣言》及思维模式
四大价值观
1 个体以及互动而不是过程和工具
2 可用的软件而不是完整的文档
3 客户合作而不是合同谈判
4 应对变更而不是遵循计划
十二大原则
1 我们的最高目标是，通过今早持续交付有价值的软件来满足客户的需求
2 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
3 要经常交付可用的软件，周期从几周到几个月不等，且越短越好
4 项目实施过程中，业务人员与开发人员必须使用通力协作
5 要善于激励项目人员，给予他们所需要的环境和支持，并相信他们能够完成任务
6 无论是对开发团队还是团队内部，信息传达最有效的方式都是面对面的交谈
7 可用的软件是衡量进度的首要衡量标准
8 敏捷过程提倡可持续的发展。项目发起人、开发人员和用户应该都能够始终保持步调稳定
9 对技术的精益求精以及对设计的不断完善讲提高敏捷性
10 简洁，即尽最大可能减少不必要的工作，这是一门艺术
11 最佳的架构、需求和设计讲出自于自组织团队
12 团队要定期反省怎样做才能更有效，并相应地调整团队的行为
敏捷方法
根据具体情况，敏捷可用是一种方法、手段、实践、技术、框架。本实践指南使用“方法”一词。
敏捷方法囊括，各种框架和方法的涵盖性术语，它指的是符合敏捷宣言价值观和原则的任何方法、技术、框架、手段或实践。
下图把敏捷方法和看板方法视为精益方法的子集，原因是他们都是精益思想的具体实例，反映了关注价值、小批量、消除浪费。
两种策略践行敏捷价值观和原则
一种正规的敏捷方法，那变更和裁剪前，需花时间学习和理解敏捷方法，且不成熟和随意的裁剪会让敏捷方法效果大打折扣。
一种以适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。使用
使用时间盒创建功能，使用特定技术迭代优化功能，在适用于特定项目背景下，考虑将一个大项目划分为几个部分发布。不为敏捷而敏捷。
2.3 精益与看板方法
敏捷和看板方法被视为精益思想的衍生物。精益思想是一个超集，与敏捷和看板方法拥有共性。
比如：交付价值、尊重人、减少浪费、透明化、适应变更、持续改善等
2.4 不确定性、风险和生命周期选择
不确定性->风险->较少的工作增量->迭代、增量方法
- 非常短的反馈循环
- 频繁调整过程
- 重新进行优先级排序
- 定期更新计划
- 频繁交付
需求、技术程度的不确定性
简单的->线性方法；繁杂的、复杂的->自适应方法；混乱的->冒险
当技术和需求的不确定性都很高时，项目会极端复杂，陷入无序状态。为了使项目可靠，要遏制其中一个不确定性的变量。
迭代、增量和敏捷方法适用一下特点的项目：
-需要研究和开发
-变更速度极快
-具有不明确或未知的需求、不确定性或风险
-最终目标难以描述
通过构建一个小的增量，对其进行测试和评估，团队可用在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。
3 生命周期选择
预测型：充分利用已知和已证明的事务，不确定性和复杂性减少，允许项目团队将工作分解成一系列可预测的小组。
迭代型：允许对部门完成或未完成的工作进行反馈，从而对该工作进行改进和修改。
增量型：可向客户提供完成的可交付成果，让客户能够立即使用。
敏捷型：同时利用迭代属性和增量特征。
先使用敏捷应对不确定性、复杂性、风险，然后到明确、可重复的发布阶段。
如敏捷的逐步过渡。
预测为主，敏捷方法处理不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测管理项目的其余部分。
敏捷为主，当某个特定要素不可协商或者使用敏捷方法不可执行时，可能会使用这种方法。
混合敏捷方法：
渐进过渡设计要增加更多的迭代技术，以便改进学习，加强团队和相关方的一致性。可以现在一个风险不大、具有中低程度不确定性的项目中尝试新技术，在组织成功的使用混合方法后，在尝试增加更多的增量技术，以加快发起人的价值和投资回报，以及使团队适应并接受变革的就绪情况而调整的渐进混合过渡
剪裁项目的影响因素：
4 实施敏捷：创建敏捷环境
4.1 从敏捷思维模式开始
敏捷方法管理项目，团队要采用敏捷思维模式，一下问题，有助于制定实施策略：
项目团队如何以敏捷方式行动?
为了使下一个交付周期受益，团队需要快速交付哪些成果并获得早期反馈？
团队如何以一种透明的方式行动？
为了专注于高优先级的项目，可以避免哪些工作?
仆人式领导对团队打成目标有何益处？
4.2 仆人式领导为团队赋权
仆人式领导通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
仆人式领导的作用时促进团队发现和定义敏捷，实践并传播敏捷，按一下顺序从事项目工作：
目的，与团队一期定义目的，以便围绕目标进行何做互动。整个团队在项目层面而不是在人员层面优化。
人员，目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目中做出贡献。
过程，不要机会遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能偶常常交付完成的价值并反思产品和过程，团队就是敏捷的。
促进团队的成功：
提升自我意识；倾听；为团队服务；帮助他人成长；引导与控制；促进安全、尊重与信任；促进他人精力和才智提升
成功的敏捷团队信奉成长思维模式，团队成员自己能能够学到新技能。
4.2.1 职责
通过管理管理，在团队内和组织中建立沟通与先做
4.2.2.1 促进作用
工作重点从“管理协调”转向“促进合作”，帮助每个人各尽所能的思考和工作，鼓励团队参与、理解，并对团队输出共同承担责任。帮助团队创建可接受的解决方案。
如，在团队内部与团队之间帮助发现瓶颈问题，并进行相应沟通，然后，团队解决这些问题。
鼓励大家通过交互式会议、非正式对话和只是共享展开协作。通过成为公正的搭桥者和教练来做到这一点，而不是代替责任人作出决策。
4.2.2.2 消除组织障碍
敏捷价值观关于个人与过程和工具的交互。对仆人式领导而言，更好的职责是认真审视阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。
仆人式领导还颖关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。
4.2.2.3 为他人贡献铺路
与各方合作，为团队铺路，让团队尽其所能。影响项目，鼓励组织以不同方式思考。
除仆人式领导，团队成员要重视自身的人机关系技能和情商技能，而不仅仅是专业技能。
团队每一个成员都要努力展示更多的主动性、正直、情商、诚实、合作态度、谦虚和以不同方式沟通的意愿，才能促进整个团队携手共进。
4.2.2.4 职责
教育相关方，使其了解为什么要敏捷如何敏捷，根据优先级说明商业价值的好处，对被赋权团队加强问责，提高工作效率，并通过频繁的评审改进质量。
通过指导、鼓励和帮助为团队提供支持。
通过技术管理活动，如量化风险分析来帮助团队。
庆祝团队的成功，为团队与外部合作提供支持，并起到桥梁作用。创建互相欣赏的积极氛围，建立加强合作的良好意愿。
项目经理的价值不在于他们的岗位，而在于他们能够让每个人都变得更好。
4.2.2 项目经在敏捷环境中的角色
是未知的，务实的敏捷实践者和组织认识到，许多情况下，项目经理都能创造重要的价值。关键的区别在于，他们的角色和职责看起来有些不同。
4.2.3 项目经理应用仆人式领导
PMBOK，项目经理：由执行组织委派，领导团队实现项目目标的个人。
PM习惯于作为项目的协调中心，负责跟踪项目的状态，并向组织中的其他成员反应，当项目被分解为鼓励的功能时，这种方法没有问题。
但对于高不确定性的项目，复杂性时一个人无法管理的，而跨只能团队技能协调自身的工作，还能与业务代表（产品负责人）开展合作。
敏捷项目，PM的角色转变为团队和管理人员提供服务，仆人式领导，工作重点变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。PM经理要鼓励将责任分配给团队成员，分配给那些掌握完成任务所需只是的人。
4.3 团队构成
敏捷的价值观和原则有一个核心宗旨，强调个人和交互的重要性。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。
要善于激励项目人员，为他们提供所需要的环境和支持，信任他们能够完成工作。
团队考虑如何优化价值流时，好处显而易见：
人员更有可能合作；
团队更快地完成有价值的工作；
由于不从事多任务，也不必重新建立环境，团队减少了时间浪费。
4.3.1 敏捷团队
最有效的敏捷团队由3-9个成员组成，集中在一个团队工作场所工作，100%专职成员。鼓励自我管理团队，由团队成员觉得谁执行下一阶段定义的范围内的共工作。
团队集体对工作负责并共同拥有完成工作所需的所有必要技能。
协同工作而不落入迷你瀑布的陷阱中。
4.3.2 敏捷的角色
跨职能团队成员
产品负责人
团队促进者
4.3.3 通才型专家
I型人才和T型人才，I有深度，T能够通过支持在一个领域补充自身的专业只是，在相关领域的技能虽有欠缺，但拥有良好的合作技能。
团队的目标，提高国恒效率，优化整个团队的产能。
团队规模小会促进团队合作，产品负责人确保团队从事最高价值的工作。
4.3.4 团队结构
相互协助的跨职能团队，自组织团队。
4.3.5 专职小组成员
100%专职工作，作为一个团队持续协作，更高效
多任务切换，会降低团队工作的产出，并影响团队预测交付能力的一致性
如在两个任务中切换，并非各占50%，可能损失率在20~40%，人一心多用时更容易犯错，任务切换消耗工作记忆。
4.3.6 团队工作场所
平衡公共和社交区域（公共区）与个人工作不被打扰的安静区或私人区域。
在不同地点工作时，使用文档共享、视频会议等等协作技术帮助人员实现远程协作。
分散式团队挂你沟通：鱼缸窗口、远程结对
如，长期视频会议链接，自然看到彼此互动，减少不同地点工作协作的滞后性；使用虚拟会议工具来共享屏幕，包括语言和视频链接，建立远程结对
4.3.7 克服组织孤岛
组织敏捷团队的最好开端是，拥有基本信任和安全的工作环境，确保团队成员都有平等的话语权，意见都能被听到并得到考虑。再加上构建敏捷思维模式，再此基础上，其他挑战和风险都能够缓解。
孤岛组织，给跨职能敏捷团队的组建带来重重障碍，跨职能团队想不同的管理人员报告，管理人员采用不同的标准衡量他们的绩效。管理人员需要关系不是资源利用率，而是过程效率。（和基于团队的指标）
来自不同职能团队，培养管理者和领导的敏捷思维模式，敏捷开发早期就让他们参与其中。
为克服孤岛问题，要与团队成员的不同管理者合作，让他们为跨职能团队安排必要的专职人员。这样不仅尽力团队协作，而且让组织看到怎样用人才能优化症状进行中的项目和产品。
敏捷项目领导，首要重点放在如何组建跨职能团队，让所有团队成员100%投入团队工作。
5 实施敏捷：在敏捷环境中交付
5.1 项目章程和团队章程
敏捷项目，团队至少还需要项目愿景或目标，以及一组清晰的工作协议。
敏捷项目章程回答：
我们为什么要做这个项目？这是项目愿景
谁会从中受益?如何受益？这可能是项目愿景/项目目标的一部分
对此项目二验，达到哪些条件才意味着项目完成？这是项目的发布标准
我们将怎样合作？这说明预期的工作流
团队章程：（团队的社会契约，规定团队成员之间彼此互动的方式）
团队价值观，例如可持续的开发速度和核心工作实践
工作协议，例如“就绪”如何定义，这是团队可接受工作的前提，“完成”如何定义，这样团队才能一致的判断完整性；考虑时间盒；或使用工作过程限制
基本规则，例如有关一个人在会议上发言的规定
团队规范，例如团队如何对待会议实践
5.2 常见敏捷实践
5.2.1 回顾
让团队学习、改进和调整其过程
关键时刻回顾：
团队完成一个发布或加入一些功能时
自上次回顾以来，又过了几周时间
当团队出现问题时，以及团队协作完成工作不顺畅时
当团队达到任何其他里程碑时
团队可以计划用充足的时间学习受益，无论在项目中还是结束时。团队需要了解他们的工作产品和工作过程。团队可以计划用充足的时间组织回顾，以此收集数据、处理数据、在决定之后要尝试的实验做法。
回顾针对定性的（人的感觉）和定量的（衡量指标）数据，然后利用这些数据找到根源，设计对策，并制定行动计划。
要对所有改进事项进行排序，并确定如何衡量结果，选择合适数量的改进事项。
5.2.2 待办事项列表编制
工作开始之前，不需要为整个项目创建所有故事，只需要了解第一个发布的主要内容正确即可，然后就可以为下一个迭代开发足够的项目。
考虑使用影响地图查看产品如何组合在一起，一般产品负责人领导这项工作。
产品负责人（或产品负责人价值团队）可能会绘制一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图。
5.2.2 待办事项列表的细化
团队通常有一个目标，每周用不超过1小时的实际来为下一批工作细化故事。尽可能把时间花在工作上，而不是计划上。
细化过程：
基于流程的敏捷的即时细化、基于迭代的敏捷团队在两周迭代中用1个小时的时间盒讨论、基于迭代的敏捷团队的多次细化讨论。
细化会议：（产品负责人）
鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事。
把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事。
与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断的交付完成工作。考虑每天至少完成一个故事。
5.2.4 每日站会
一般不超过15分钟，过一下看板或任务板，团队任何人都可以主持站会。要体现团队工作需要的密切合作，进行顺利，站会就非常有用。要针对团队何时需要站会、站会是否有效等问题有意识地做出决定。
基于迭代的敏捷，轮流回答：
上次站会以来我都完成了什么？
从现在到下次站会，我计划完成什么？
我的障碍（或风险或问题）是什么？
基于流程的敏捷，将注意力集中在团队的产出上，团队从右到左对看板进行评估：
我们还需要做些什么来推进这一工作？
有人在做看板所没有的事情吗？
作为一个团队，我们需要完成什么？
工作流程是否存在瓶颈或阻碍？
反模式：站会变成状态报告会议、问题变得明显时，团队才开始解决问题，站会是为了发现存在问题，而不是解决他们。将问题添加到停车场区，然后创建另一次会议，在站会后再召开。
5.2.5 展示/评审
当团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事。
基于迭代的敏捷，团队在迭代技术是展示所有已完成的工作项，基于流程的敏捷中，团队在需要时展示完成的工作，通常是当完成的功能累计到足够构建一个连贯组合时。团队都需要反馈来决定何定需要产品反馈。
一般，每周至少展示一次团队的工作产品。防止朝着错误的方向前进，让团队成员保持产品开发足够清晰，按照自己希望或需要的频率构建一个完整的产品。
5.2.6 规划基于迭代的敏捷
不同团队能力各不相同，不同负责人的典型故事大小也各不相同。团队要考虑迭代中所能完成工作的能力。
产品负责人当了解，当人员不可用时，团队能力降低。团队无法完成与前一时期相同的工作量。在能力降低的情况下，团队只会计划相应能力能够完成的工作。
团队估算能完成的工作，也是一种能力的衡量。团队无法100%确定自己能交付什么，他们无法知道意外情况。当拆分故事使其变小时，团队看到的时产品的完成进度，团队就会知道他们将来能够做什么。
敏捷团队在一个工作块中不会只计划一次。开始计划一点，交付、学习，然后再一个持续的循环中重新规划更多的东西。
5.2.7 帮助团队交付价值的执行实践
重视质量
持续集成
再不同层面测试
验收测试驱动开发（ATDD），atdd团队一起讨论产品的验收标准
测试驱动开发（TDD）和行为驱动开发（BDD），在编写创建产品之前编写自动化测试，帮助人员设计产品，防范产品错误
刺探（时间盒研究或实验），在团队需要学习一些关键技术或功能要素时，刺探会很有帮助
5.2.8 迭代和增量如何帮助交付工作产品
帮助团队为交付和多种反馈创建一个节奏，团队会收到关于产品的外观和运行方式的反馈，团队成员回顾如何检查和挑战有关过程以取得成功
团队应经常为反馈进行演示，并展示进度。鼓励PMO和其他感兴趣的人观看演示，以便决定项目组合的人能够看到实际的进展。
演示或评审时敏捷项目流程的必要组成部分。为团队的交付节奏安排适当的演示。
5.3 解决敏捷项目的挑战
5.4 敏捷项目的衡量指标
状态避免西瓜现象，外绿里红。
替代性指标（如完成百分比，红黄蓝灯）不如经验指标（如已完成功能）更有用。
定量指标衡量进度，定性指标衡量团队情况。
5.4.1 敏捷团队的衡量结果
敏捷倾向于基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。
对于习惯掌握项目基准、估算的挣值和投资回报率（ROI）的团队，可能会实施一个项目而不是管理一个基准感到茫然。敏捷基于对客户有可见价值的工作产品。
基准通常是尝试预测的产物，敏捷中，团队故事最多限于未来几周时间，如果团队可变性不高，团队能力文档，对未来几周做出更好的预测。
团队并不能创造出更多的工作能力，然而，工作量越少，人员就越有可能交付。
6 关于项目敏捷性的组织考虑因素
项目存在于组织环境下，文化、结构和政策可能会影响到所有项目的方向和成果。这些动态编号可能会对项目领导提出挑战。
项目领导无法根据自己的意愿来改变组织动态变化，但可以有技巧的引导这些动态变化。
6.1 组织变更管理
《组织变革管理实践指南》建议：
说明变更动态变化的模型
实现变革的框架
项目、项目集、项目组合层面的变革管理实践的应用
6.1.1 变革管理驱动因素
与加速交付相关的变革（接受组织可能尚未做好加速纳入这些输出的充分准备）
与敏捷方法相关的变革（高级别协作可能需要团队、部门和供应商之间的频繁交流）
6.1.2 变革就绪情况
变革友好型特征：
管理层的变革意愿
组织在员工认知、审核和评估方式上做出改变的意愿
集中或分散项目、项目集和项目组合管理职能
专注于短期预算和指标而不是长期目标
人才管理成熟度和能力
变革阻碍特征：
工作被分解为部门孤岛，阻碍加速交付的依赖关系，而不是构建在能力中心指导下的跨职能团队
采购策略基于短期定价策略而不是长期能力
奖励领导的一句时本地效率而不是端到端项目交付流或整体优化情况（就组织而言）
员工属于特定领域人才，实现技能多元化的工作或奖励有限，不重视培养T型专家人才
分散化项目组合使用员工分配到过多的项目，而无法专注于单个项目
项目领导尝试多种方法加速文化兼容性：
积极明确的管理层支持
变革管理实践，包括沟通和引导
诸葛项目应用敏捷实践
向团队增量的引入敏捷实践
通过采用适用的敏捷技术和实践示范引导
6.2 组织文化
组织文化就是组织的DNA，组织的核心标识。文化影响敏捷方法的使用。
“文化能把战略当早餐吃”-彼得德鲁克
6.2.1 创建安全环境
安全、诚实、透明
6.2.2 评估文化
根据组织文化决定和要求来确定优先级，引导这些动态变化，项目领导应花时间去评估组织通常所关注的重点。
6.3 采购和合同
多层结构，除了在单个文档正式说明整个合同关系，项目方可通过在不同文档说明不同方面来提高灵活性
强调价值交付，许多供应商关系是由中间人为因素的固定里程碑或“阶段关口”控制，而不是由增量业务价值的完全可交付成果控制。通常，这些控制会限制利用反馈来改进产品。于之相反的是，里程碑和支付项目可以根据价值驱动可交付成果来构建，以增强项目敏捷性。
总价值增量，项目分解为总价微型可交付成果，而不是将整个项目范围和预算锁定到单个协议中
固定时间和材料，将整体预算限制为固定数量
累进的时间和材料，高效率奖励，低效率扣除一定费用
提前取消方案，如在一半时间便可交付足够价值，则为剩余一部分支付取消费用
动态范围方案，调整功能以适应能力
团队扩充
支持全方位供应商，多供应商策略
6.4 商业实践
需求产生时，组织创新能力的意愿和能力时组织敏捷的标志，透明和开发协作至关重要
跨职能团队交付价值时，团队和个人可能会遇到组织多种支持职能方面的问题
如定期交付价值，财务部门和采购部门需频繁交付价值并与团队保持同步
团队开始协作后，对内部管理策略提出挑战，人力资源要重新审视绩效评估
组织发展到更高敏捷性时，业务部门要更改交互方式并履行自己的职责，以提高整个组织的效率
6.5 多团队协作和依赖关系（扩展）
6.5.1 框架
敏捷方法如scrum和极限编程，专注与单个小型且集中办公的跨职能团队活动。
项目集或项目组合中多个敏捷团队协作，目前有许多框架，如大规模敏捷框架、大规模敏捷开发、规范敏捷和方法scrum of scrums来应对
6.5.2 考虑事项
团队需要将多个敏捷项目工作扩展到单个敏捷项目集中
6.6 敏捷和项目管理办公室（PMO）
PMO目的：
指导商业价值，确认目标
提供团队教育、培训和项目支持
针对给定项目或项目集提供相关商业价值方面的管理建议
6.6.1 敏捷PMO为价值驱动型
所有项目都应在合适的实践为合适的受众提供合适的价值
以客户协作思想为基础，并存于所有PMO项目集中
PMO应努力按需交付并紧跟客户需求，确保了解并适应他们的需求，内部创业方法
6.6.2 敏捷PMO为面向创新型
强制执行某些解决方案或方法
6.6.3 敏捷PMO为多学科型
将其PMO转换为卓越敏捷中心以提供一下服务：
制定和实施标准
通过培训和指导发展人才
多项目管理，不同项目交流协调敏捷团队，如分享进度、问题、回顾性发现和改进等，借助适当的框架，帮助管理层的主要客户发布和项目组合曾的投资主题
促进组织学习
管理相关方
招聘、筛选和评估项目领导
执行专业化项目任务
6.7 组织结构
组织结构会严重影响其转向新信息或转变市场需求的能力：
地理
职能结构，高度职能结构的项目可能会在组织内部协作方面遇到很大阻力
项目可交付成果的大小
项目人员分配
重采购型组织，通过供应商实施项目
6.8 组织演变
将变更过程视为一个敏捷项目
7 行动呼吁
检查、适应和透明度时成功交付价值的关键因素
学习、实验、获取反馈、再实验
PMI和敏捷联盟
https://www.projectmanagement.com/blogs/347350/Agile-in-Practice