敏捷实践读书笔记

一.简介

1.敏捷型学习

面对面的交流、有意义的学习、自组织团队以及利用想象力的增量型学习、迭代型学习都是敏捷原则，这些原则可能改变人们在课堂上的思维模式，促进教育目标的实现。

2.颠覆性技术

向云计算的过渡，尤其促进了颠覆性技术的应用。全球各地的公司都在利用这种模式迅速廉价获取计算资源，以进入传统市场。
敏捷技术和敏捷方法将有效地管理各种颠覆性技术。
敏捷第一原则将客户满意视为最高要求，这也是交付让客户满意的产品和服务的关键。
形势的不断变化将继续促使大型组织采用敏捷思维模式，以保持竞争力和现有的市场份额。
为项目领导者和项目团队成员提供实践指导，帮助他们在项目规划和执行过程中适应敏捷方法。
并不仅仅是为了帮助计算机软件开发行业解决敏捷方法应用问题，超出软件业的敏捷应用也属于本实践指南的范围。
为保持竞争优势，与时俱进，各组织不能只关注内部，而是要放眼外部世界，关注客户体验。
本实践指南适用于对于预测法和敏捷方法难以取舍的项目团队，试图解决快速创新和复杂性问题的项目团队，以及致力于团队改进的项目团队。
本实践指南将提供有益的指导方针，它们将有助于项目取得成功，帮助项目团队顺利交付商业价值，满足客户的期望和需求。

二.敏捷概述

1.可确定的工作与高度不确定的工作

项目工作包括可确定的工作与高度不确定的工作。可确定的工作项目具有明确的流程，它们在以往类似的项目中被证明是行之有效的。
随着可确定的工作日益实现自动化，项目团队也越来越多地从事高度不确定的工作，从事这些工作就需要使用本实践指南所述的有关技术。
传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。

2.《敏捷宣言》及思维模式

2.1 《敏捷宣言》

我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。
通过这项工作，我们开始更重视：
个体以及互动 而不是 过程和工具
可用的软件 而不是 完整的文档
客户合作 而不是 合同谈判
应对变更 而不是 遵循计划
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。

2.2 十二项原则

1.我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
2.欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
3.要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
4.项目实施过程中，业务人员与开发人员必须始终通力合作。
5.要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
6.不论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
7.可用的软件是衡量进度的首要衡量标准。
8.敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
9.对技术的精益求精以及对设计的不断完善将提高敏捷性。
10.简洁，即尽最大可能减少不必要的工作，这是一门艺术。
11.最佳的架构、需求和设计将出自于自组织的团队。
12.团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

2.3 敏捷方法

“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语，指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。
将敏捷方法和看板方法视为精益方法的子集，它们都是精益思想的具体实例，都反映了诸如“关注价值”、“小批量”和“消除浪费”的概念。

2.4 两种策略践行敏捷价值观和原则

第一种采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果。在变更和裁剪之前，就需要花时间学习和理解敏捷方法。不成熟和随意的裁剪会让敏捷方法的效果大打折扣，从而限制了收益。
第二种采用以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。使用时间盒创建功能，或者使用特定技术迭代优化功能。
在适用于特定项目背景下，考虑将一个大项目划分为几部分发布。实现有助于项目成功的变更，这些变更不必是组织的正式实践的组成部分。
最终目标不是为了敏捷而敏捷，而是为了向客户持续交付价值流，并达成更好的商业成果。

3.精益与看板方法

看板方法从精益制造构思而来，也围绕精益制造，但更广泛地应用于敏捷环境中。
将敏捷和看板方法视为精益思想的衍生物。 精益思想是一个超集，与敏捷和看板方法拥有共性。
重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等方面。
无论使用什么方法，目标都是为了实现最佳结果。
看板方法专门用于知识型工作，但不如某些敏捷方法规范，破坏性也较小，原因在于它是原始的“原地出发”方法。
在有必要或适当的情况下，项目团队可以相对轻松地应用看板方法，并向其他敏捷方法发展。

4.不确定性、风险和生命周期选择

团队选择的生命周期要能够通过较少的工作增量解决项目的大量不确定性问题。
团队可以利用较少的工作增量验证自身的工作，并且可以对接下来的工作做出相应变更。
与静态书面规范相比，当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。 随着项目不确定性的增加，变更、做无用功和返工的可能性也会随之增加，而这不仅代价高昂，而且耗费时间。
通过构建一个小的增量，然后对其进行测试和评估，团队可以在短时间内以低成本探索不确定性，降低风险，最大程度地实现商业价值的交付。
不确定性可能集中于适用性和需求（正在构建的产品是否正确？）。 技术可行性和性能（产品是否可以采用这种方法构建？）。 或过程和人员（这是否为团队工作的一种有效方式？）。
三个特点（产品规格、生产能力和过程适用性）通常都具有高度不确定性因素。
迭代和增量管理方法也有其应用局限性。当技术和需求的不确定性都很高时，项目就会极端复杂，陷入无序状态。
为了使项目尽可能可靠，需要遏制其中一个变量（不确定性或分歧）。

三.生命周期选择

四种生命周期包括：
•预测型生命周期。这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程。
•迭代型生命周期。这种方法允许对未完成的工作进行反馈，从而改进和修改该工作。
•增量型生命周期。这种方法向客户提供各个己完成的，可能立即使用的可交付成果。
•敏捷生命周期。这种方法既有迭代，也有增量，便于完善工作，频繁交付。

1.项目生命周期的特征

计划始终贯穿其中,敏捷项目也有计划。
通过对频繁交付的可交付成果的评审，团队将能获得更多的信息，从而在此基础上进行计划和重新计划。
无论采用哪种项目生命周期，项目都需要计划。

1.1 预测型生命周期的特征

预测型生命周期预计会从高确定性的明确的需求、稳定的团队和低风险中获益。
团队需要详细的计划，了解要交付什么以及怎样交付。

1.2 迭代型生命周期的特征

迭代型生命周期通过连续的原型或概念验证来改进产品或成果。
团队可能会在长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。

1.3 增量型生命周期的特征

有些项目优化是为了加快交付速度。 客户愿意接受整个解决方案的一个部分。
少量可交付成果的频繁交付。

1.4 敏捷生命周期的特征

对于建立在流程基础上的敏捷方法，团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。
团队定义任务板各列的工作流，并管理各列的进行中的工作。
团队让进行中的工作的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。
无需利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。

1.5 敏捷适用性筛选器

有各种评估模型可用来帮助确定使用敏捷方法的适合性或差距。
这些模型评估项目和具有适应性和适用性的组织因素，然后提供分数表明一致性或潜在风险领域。

1.6 混合生命周期的特征

对于整个项目，没有必要使用单一的方法。
为达到特定的目标，项目经常要结合不同的生命周期要素。
预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。

1.7 结合了敏捷和预测的方法

在同一项目中结合使用了预测法和敏捷方法。也许团队正在逐渐地向敏捷过渡，并使用一些方法，如短迭代、每日站会和回顾。
但在项目的其他方面，如前期评估、工作分配和进度跟踪等，仍然遵循了预测法。

1.8 以预测法为主、敏捷方法为辅的方法

以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。

1.9 以敏捷方法为主、预测法为辅的方法

当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。

1.10 符合目的的混合生命周期

当组织无法交付中间价值时，敏捷方法可能不是很有用。这样没有问题，但为了敏捷而敏捷并不是目标。
要选择一个对项目、风险和文化管理有用的生命周期或生命周期的组合。
敏捷关乎频繁向客户交付。而这种交付要给团队带来反馈。团队利用上述反馈规划并重新规划下一部分的工作。

1.11 混合型生命周期作为过渡策略

许多团队无法在一夜之间切换到敏捷工作方式。对于那些己经习惯于预测型环境、并在其中获得成功的人士，敏捷技术的观感截然不同。
组织越大，活动部件越多，转换需要的时间就越长。因此，计划一个渐进的过渡是有意义的。

2.混合敏捷方法

敏捷团队很少将其实践局限于一种敏捷方法。
每个项目背景都有其各自的独特性。 敏捷框架并不是针对团队定制的。
为了定期交付价值，团队可能需要对实践进行裁剪。

3.影响裁剪的项目因素

有时为了更好地配合，根据项目属性对方法进行裁剪。

四、实施敏捷：创建敏捷环境

1.从敏捷思维模式开始

以下问题的答案将有助于制定实施策略
•项目团队如何以敏捷方式行动？
•为了使下一交付周期受益，团队需要快速交付哪些成果并获得早期反馈？
•团队如何以一种透明的方式行动？
•为了专注于高优先级的项目，可以避免哪些工作？
•仆人式领导对团队达成目标有何益处？

2.仆人式领导为团队赋权

仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
仆人式领导的作用是促进团队发现和定义敏捷。 仆人式领导实践并传播敏捷。
仆人式领导可以帮助他们的团队通过合作更快地交付价值。
成功的敏捷团队信奉成长思维模式，团队成员自己能够学到新技能。
如果团队和仆人式领导都相信自己能够学习，那么所有人的能力都能得到提高。

2.1 仆人式领导的职责

仆人式领导通过管理关系，在团队内和组织中建立沟通与协作。
这些关系可以帮助领导在组织中得心应手地为团队提供支持。
这种支持有助于消除障碍，促进团队理顺过程。  
仆人式领导的促进作用
项目经理成为仆人式领导时，工作重点就会从“管理协调”转向“促进合作”。
促进者帮助每个人各尽所能地思考和工作。
促进者鼓励团队参与、理解，并对团队输出共同承担责任。
仆人式领导要通过成为公正的搭桥者和教练，而不是代替他责任人做出决策。
仆人式领导消除组织障碍
对仆人式领导而言，更好的职责是认真审视那些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。
仆人式领导还应该关注其他冗长的过程，这些过程往往造成瓶颈问题，阻碍团队或组织的敏捷性。
仆人式领导为他人贡献铺路
仆人式领导注重为团队铺路，让团队尽其所能。
仆人式领导影响项目，鼓励组织以不同方式思考。
人际关系技能与专业技能
除仆人式领导外，团队成员还要重视自身的人际关系技能和情商技能，而不仅仅是专业技能。
考虑这些仆人式领导的职责
教育相关方，使其了解为什么要敏捷以及如何敏捷。
通过指导、鼓励和帮助为团队提供支持。 倡导团队成员的培训和职业发展。
通过技术项目管理活动，如量化风险分析来帮助团队。
庆祝团队的成功，为团队与外部团队合作提供支持，并起到桥梁作用。
项目经理的价值不在于他们的岗位，而在于他们能够让每个人都变得更好。

2.2 项目经理在敏捷环境中的角色

项目经理在敏捷项目中的角色有些是未知的，原因是许多敏捷框架和方法都不涉及项目经理的角色。

2.3 项目经理应用仆人式领导

从事敏捷项目工作时，项目经理的角色就会从团队的中心转变成为团队和管理人员提供服务。
在敏捷环境中，项目经理充当仆人式领导，其工作重点转变为引导需要帮助的人，促进团队的合作，保持与相关方的需要一致。
作为仆人式领导，项目经理要鼓励将责任分配给团队成员，分配给那些掌握完成任务所需知识的人。

3.团队构成

敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。
要善于激励项目人员，为他们提供所需的环境和支持，信任他们能够完成工作。
团队在考虑如何优化价值流时，以下好处是显而易见的：
•人员更有可能合作。
•团队更快地完成有价值的工作。
•由于不从事多任务，也不必重新建立环境，团队减少了时间浪费。

3.1 敏捷团队

敏捷团队注重快速开发产品，以便能获得反馈。
在实践中，最有效的敏捷团队往往由三到九个成员组成。
理想情况下，敏捷团队应该集中在一个团队工作场所工作。
团队成员100%为专职成员。
敏捷鼓励自我管理团队，由团队成员决定谁执行下一阶段定义的范围内的工作。
敏捷团队与仆人式领导一起茁壮成长。领导支持团队的工作方法。

3.2 敏捷的角色

•跨职能团队成员
•产品负责人
•团队促进者

3.3 通才型专家

许多成功的敏捷团队都由通才型专家组成，他们也称为T型人才。
团队成员在具备一项擅长的专业化技能的同时，还拥有多种技能的工作经验，而不是单一的专业化。
由于密切协作和自我组织，敏捷团队成员才能够敏捷开发并迅速完成工作，而这就需要使互相帮助成为常态。

3.4 团队结构

有些组织己经能够建立集中办公的跨职能团队；还有组织有不同的情况。
有些组织并不是所有团队成员都为集中办公，而是拥有分布式或分散式团队。
分布式团队可以在不同地点拥有多个跨职能团队。分散式团队可能会让各团队成员分别在不同的地点工作，或在办公室，或在家里。

3.5 专职小组成员

当人员100%为团队专职工作时，团队最有可能最快地产出。
多任务处理会降低团队工作的产出，并影响团队预测交付能力的一致性。
当团队中所有的人都被分配到一个项目时，他们能够作为一个团队持续协作，从而使每个人的工作更加有效。
不是所有的团队都拥有自身需要的所有角色。
对每个人（专家和团队）设定期望，阐明团队承诺交付的水平。
分配兼职人员会给项目带来风险。

3.6 团队工作场所

团队需要一个工作场所，他们可以一起工作，了解他们作为团队的状态，并进行协作。
有些敏捷团队的所有成员都集中在一个房间里工作。
有些团队拥有一个团队工作场所用于开例会以及张贴各种图表，但团队成员分别在各自的小隔间或办公室里独立工作。
拥有在不同地点工作的成员时，团队会决定他们各自的工作场所有多少是虚拟的，多少是实际的。
在不同地点工作的团队成员需要虚拟的工作空间。另外，要考虑让团队成员定期聚集一堂，以便建立信任，学习怎样开展合作。
分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对。
通过在团队分布的各个地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，人们打开链接，工作结束时，关闭链接。通过这种方式，人员可以自然地看到彼此并进行互动，减少了身处不同地点工作所固有的协作滞后问题。
通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结对。只要考虑了时区差异因素，这种方法几乎和面对面的结对一样有效。

3.7 克服组织孤岛

孤岛组织往往给跨职能敏捷团队的组建带来重重障碍。
来自不同职能部门、拥有不同技能的人员共同组成团队。
培养管理者和领导的敏捷思维模式，在敏捷开发早期就让他们参与其中。
为克服组织孤岛问题，就要与团队成员的不同管理者合作，让他们为跨职能团队安排必要的专职人员。
作为敏捷项目领导，首先要把重点放在如何组建跨职能团队，让所有团队成员100%投入团队工作。

五、实施敏捷：在敏捷环境中交付

1.项目章程和团队章程

敏捷团队需要有团队规范以及对一起工作方式的理解。这种情况下，团队可能需要一个团队章程。
制定章程的过程能帮助团队学习如何一起工作，怎样围绕项目协作。
对于敏捷项目而言，团队至少还需要项目愿景或目标，以及一组清晰的工作协议。
仆人式领导可以促进章程的制定过程。
只要团队知道如何一起工作，制定章程就不需要一个正式的过程。
制定团队社会契约的基础：
•团队价值观
•工作协议
•基本规则
团队的社会契约，即团队章程，将规定团队成员之间彼此互动的方式。
团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大能力。

2.常见敏捷实践

2.1回顾

最重要的一个实践，原因是它能让团队学习、改进和调整其过程。
可以帮助团队从之前的产品开发工作及其过程中学习。

2.2 待办事项列表编制

待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。
考虑使用影响地图查看产品如何组合在一起。
正常情况下，由产品负责人领导这项工作。
产品负责人根据团队的实际成果重新规划路线图。

2.3 待办事项列表的细化

在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队合作，为即将进行的迭代准备一些故事。
这些会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间的相互关系。

2.4 每日站会

团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。
为每日站会规定时间盒，不超出15分钟。
团队以某种方式“过一下”看板或任务板，而团队中的任何人都可以主持站会。
要鼓励任何团队成员主持会议而不是由项目经理或领导主持，以确保它不会变成状态报告会议，而是作为团队进行自我组织和相互承诺的会议。

2.5 展示/评审

当团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。
看过展示后，产品负责人接受或拒绝故事。

2.6 规划基于迭代的敏捷

不同团队的能力各不相同。 不同产品负责人的典型故事大小也各不相同。
团队应考虑自身故事大小，避免提交更多的故事，而超出团队在一个迭代中所能完成工作的能力。

2.7 帮助团队交付价值的执行实践

•持续集成
•在不同层面测试
•验收测试驱动开发（ATDD）
•测试驱动开发（TDD）和行为驱动开发（BDD）
•刺探（时间盒研究或实验）

2.8 迭代和增量如何帮助交付工作产品

团队应该经常为反馈进行演示，并展示进度。
鼓励PMO和其他感兴趣的人观看演示，以便决定项目组合的人能够看到实际的进展。

3.解决敏捷项目的挑战

出于解决具有高变化率、不确定性和复杂性的项目相关问题的需要，敏捷方法应运而生。
由于这些原因，敏捷方法包含了各种各样的工具和技术，用于处理预测法中出现的问题。

4.敏捷项目的衡量指标

使用敏捷意味着要审视对团队和管理层都很重要的新指标。这些衡量指标很重要，因为它们关注的是客户价值。
状态报告的一个问题是，团队预测完成或使用交通灯状态来描述项目的能力。
敏捷项目的衡量指标包含有意义的信息，这些信息提供了历史记录，因为敏捷项目要定期交付价值（完成的工作）。
替代衡量指标（如完成百分比）不如经验指标（如己完成功能）更有用。
除了定量指标之外，团队还可以考虑收集定性衡量指标。例如，对交付功能的业务满意度、团队的士气；团队希望跟踪的任何东西等都是定性衡量指标。

4.1 敏捷团队的衡量结果

敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。
敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。
由于学习是项目的重要组成部分，因而，团队需要在平衡不确定性的同时为客户提供价值。
许多敏捷团队使用故事点估算工作量。燃尽图中的虚线表示计划。
对新建的敏捷团队，燃起图将显示迭代过程中范围内的变化。
当团队依赖于外部人员或团队时，衡量周期时间可了解团队完成工作所需的时间。
团队完成工作之后，衡量交付周期可了解外部依赖关系。
团队还可以测量反应时间，从准备就绪到第一列的时间，了解平均需要多长时间才能对新请求做出响应。
燃起图、燃尽图（能力衡量指标）和交付周期，以及周期时间（可预测的衡量指标）可帮助团队了解他们共有多少工作，以及团队是否能按时完成工作。
累积流图显示了看板上进行中的工作。如果一个团队有许多等待测试的故事，测试团队将会扩大。累积工作可一目了然。

六、关于项目敏捷性的组织考虑因素

每个项目都存在于组织环境下。文化、结构和政策可能会影响到所有项目的方向和成果。这些动态变化可能会对项目领导提出挑战。
项目领导可能无法根据自己的意愿来改变组织动态变化，但可以有技巧地引导这些动态变化。

1.组织变革管理

1.1变革管理驱动因素

所有项目都涉及到变革。但是，有两种主要因素会进一步激励敏捷环境中变革管理实践的应用：
•与加速交付相关的变革
•与敏捷方法相关的变革

1.2 变革就绪情况

组织在开始采用敏捷方法时应了解这些方法与其当前方法之间的相对兼容性。
项目领导可以尝试多种方法来加速文化兼容性：
•积极明确的管理层支持
•变革管理实践，包括沟通和引导
•逐个项目应用敏捷实践
•向团队增量地引入敏捷实践
•通过采取适用的敏捷技术和实践示范引导

2.组织文化

组织文化就是组织的DNA-组织的核心标识。文化始终影响敏捷方法的使用。
组织文化一直在连续运转，从高预测型计划到一切皆为实验的精益创业阶段均有体现。

2.1 创建安全环境

尝试构建安全的工作环境。
只有在安全、诚实和透明的环境中，团队成员和领导才可以真正反思其成功，确保项目持续进步，或者应用从失败项目中所吸取的教训，不再重蹈覆辙。

2.2 评估文化

项目领导可能感觉其职责就是满足各个相关方的期望；但是在面对选择时，通常需要根据组织业务环境的文化和要求来确定优先级。
要引导这些动态变化，项目领导应花费时间去评估组织通常所关注的重点。
有一些模型可用于评估这些动态变化；但是，采取何种模型或方法并不重要，关键是让项目领导了解其环境的驱动因素。

3.采购和合同

协作方法提倡共担项目风险和共享项目奖励的关系，实现所有方共赢。
合同签署技术包括：
•多层结构
•强调价值交付
•总价增量
•固定时间和材料
•累进的时间和材料
•提前取消方案
•动态范围方案
•团队扩充
•支持全方位供应商

4.商业实践

在需求产生时，组织创建新能力的意愿和能力即是组织敏捷性的标志。
在跨职能团队交付价值时，团队和个人可能会遇到组织多种支持职能方面的问题。
当组织发展到更高敏捷性时，其他业务部门将有必要更改其交互方式并履行自己的职责。
现在应拥护对组织其他领域有益的变更，以此来提高整个组织的效率。

5.多团队协作和依赖关系（扩展）

多个项目之间会产生依赖关系，即使不是在给定项目集中进行管理。

5.1 框架

大多数流行敏捷方法的指导专注于单个小型且通常是集中办公的跨职能团队活动。
目前己出现许多框架和方法来应对需要在一个项目集或项目组合中进行多个敏捷团队协作的情况。

5.2 考虑事项

团队可能需要将多个敏捷项目工作扩展到单个敏捷项目集中。或者，组织可以设计出支持整个项目组合中不同敏捷方法的结构。
无论采用哪种方法，关键成功因素是健康的敏捷团队。
如果单个团队采取敏捷方法无法获得成功，则勿尝试将其扩展到更大范围；而是要先行解决阻止团队敏捷工作的组织障碍。
大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值。
团队可以采用正式的框架或应用敏捷思维调整现有项目集管理实践。

6.敏捷和项目管理办公室（PMO）

设立PMO的目的是引导组织实现商业价值。
PMO还会针对给定项目或项目集提供相关商业价值方面的管理建议。

6.1 敏捷PMO为价值驱动型

所有项目都应在合适的时间为合适的受众提供合适的价值。PMO的目标是帮助促进这个目标的实现。
基于敏捷的PMO方法以客户协作思维为基础，并存在于所有PMO项目集中。
有些项目可能需要工具和模板，还有些项目可能会从管理层引导中获益。
PMO应努力按需交付并紧跟客户需求，确保了解并适应他们的需求。

6.2 敏捷PMO为面向创新型

为了在基于价值的章程下加速发展，PMO可能需要强制执行某些解决方案或方法，例如，保持所有人行动的一致性以快速获得成功。

6.3 敏捷PMO为多学科型

为了支持特定项目需求，PMO还需要熟悉项目管理本身以外的其他一些能力，因为不同的项目要求不同的能力。
例如，一个项目可能需要组织设计来解决人员配备挑战，而另一个项目可能需要组织变革管理技术来确保相关方参与或获得独特的业务模型以支持客户目标。

7.组织结构

组织结构会严重影响其转向新信息或转变市场需求的能力。
下面列出了主要特征：
•地理
•职能结构
•项目可交付成果的大小
•项目人员分配
•重采购型组织

8.组织演变

应对单个挑战领域或实施新的混合或敏捷方法时，建议以累积方式承接工作。
常用实践是将变更过程视为一个敏捷项目，团队可以根据自己的价值观或其他考虑事项引入自己的变更待办事项列表并确定其优先级。
每个变更可以被视为一个实验，将进行短时间测试以确定。
每个变更的适应性以及进一步细化/考虑需求。
使用看板面板跟踪进度，显示已作为“已完成”使用的新方法、被视为“进行中”的方法、以及仍在等待被引入“待办事项”的方法。
通过使用工具来组织和管理变更实施，将可提供进度的可视化并对正在实施的方法进行建模。
以透明和吸引人的方式部署变更，将可以提高成功可能性。

七、行动呼吁

如今，“敏捷”呼声前所未有地高涨起来。由于业内对敏捷的最佳途径还存在争议，围绕该主题的讨论仍甚嚣尘上，并且不断涌现出更多的创新。
有一个真理永恒不变，那就是：检查、适应和透明度是成功交付价值的关键因素。

附录

描述了一些常用的敏捷方法。这些方法可以单独或结合使用，以调整适应特定环境或情况。

1.Scrum

Scrum是用于管理产品开发的单个团队过程框架。
该框架包含Scrum角色、事件、工件和规则，采用迭代方法来交付工作产品。
Scrum是运行在1个月或更少时间的时间盒上的，其中包含持续时间一致的多个冲刺，在这些冲刺中会产生潜在可发布的产品增量。
Scrum团队包含产品负责人、开发团队和Scrum主管。产品负责人负责实现产品价值的最大化。
开发团队是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品。
Scrum主管负责确保Scrum过程获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。

2.极限编程

极限编程（XP）是一种基于频繁交付周期的软件开发方法。
基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。
旨在改进软件项目成果的整套实践。该方法最初包含十二种主要实践，随后逐渐演变，采用了一些其他推论实践。
该演变是通过筛选核心价值观（沟通、简洁、反馈、勇气、尊重）并根据主要原则信息来设计和采用技术的结果。

3.看板方法

看板在精益制造中是一种用于规划库存控制和补给的系统。
看板方法应用并适用于多种场合，可以确保工作流和价值交付的持续性。
在看板方法中可以使用迭代，但应始终遵循在整个过程中持续拉取单个条目并限制在制品以优化流程的原则。
有以下需要时，则看板方法最为适用：
•灵活性
•专注于持续交付
•提高工作效率和质量
•提高效率
•团队成员专注力
•工作负载的可变性
•减少浪费
看板方法是一种整体性组织增量演变过程和系统变更框架。
在看板方法中，完成工作比开始新工作更为重要。

4.水晶方法

水晶是一种方法论家族。
水晶方法论旨在根据项目规模（项目中涉及的人员数量）以及项目的关键性来量化并提供方法严格程度选择。
水晶方法认识到每个项目可能需要一系列轻量剪裁的策略、实践和过程，以匹配项目的独特特征。

5.Scrumban

Scrumban是一种敏捷方法，最初设计为Scrum到看板之间的过渡方法。
在Scrumban中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。
将故事列在看板面板上，团队通过使用在制品限制来管理其工作。
通过召开每日例会来维持团队之间的协作并消除阻碍。
Scrumban看板中没有预定义角色一团队保留其当前角色。

6.功能驱动开发

功能驱动开发（FDD）的开发目的是满足大型软件开发项目的特定需求。
小型商业价值功能重视能力。
功能驱动开发项目中有六个主要角色，每个人可以担任以下一个或多个角色：
•项目经理
•首席架构师
•开发经理
•首席编程人员
•类负责人
•领域专家
功能驱动开发项目分为五个过程或活动，以迭代方式执行：
•开发整个模型
•构建功能列表
•依据功能规划
•依据功能设计
•依据功能构建
由一组核心软件工程最佳实践提供支持

7.动态系统开发方法

动态系统开发方法（DSDM）是一种敏捷项目交付框架，该框架开发为行业领导者之间的非商业性协作方式。
强调制约因素驱动交付而著称。
该框架从一开始便可设置成本、质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求。
通过八个原则来指导DSDM框架的使用：
•专注于业务需求
•准时交付
•协作
•在质量上永不妥协
•在坚实的基础上进行增量式构建
•迭代开发
•保持持续和明晰的沟通
•演示控制（使用适当的技术）

8.敏捷统一过程

敏捷统一过程（AgileUP）是软件项目中统一过程（UP）的分支。
与紧前统一过程相比，该过程具有加速周期和轻量级的过程。
目的在于在七个主要因素之间执行更多迭代的周期，并在正式交付之前纳入相关反馈。

9.扩展框架

Scrum of Scrums(SoS)也称为“meta Scrum”
由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术
一个团队包含三到九名成员来协调其工作
具有多个团队的大型团队可能要求执行Scrum of Scrum of Scrums，其遵循的模式与SoS相同，每个SoS代表向更大组织的代表报告

10.大规模敏捷框架

大规模敏捷框架SAFe专注于为所有级别企业的大规模开发工作提供模式知识库。
SAFe专注于以下原则：
•采用经济视角
•应用系统思维
•假设可变性、预留方案
•以快速整合的学习周期进行增量式构建
•根据对工作系统的客观评估设定里程碑
•直观显示并限制在制品，减小批次规模并管理队列长度
•应用节奏、与跨域规划同步
•解锁知识员工的内在动力
•决策分散化
SAFe专注于在项目组合、项目集和团队层详细设定实践、角色和活动，强调围绕专注于向客户提供持续价值的价值流来组织企业。

11.大规模敏捷开发（LeSS）

一种以扩展Scrum方法为共同目标来组织多个开发团队的框架，其核心组织原则是尽可能保留传统单个团队Scrum模型的元素。
有助于减少任何模型扩展，避免造成不必要的混乱或复杂性。

12.企业Scrum

企业Scrum是一种旨在通过更整体性组织层而不是单个产品开发层来应用Scrum方法的框架。
该框架尤其建议组织领导：
•将所有Scrum应用扩展到所有组织方面
•普及Scrum技术以便在这些不同的方面轻松应用
•根据需要使用补充技术扩展Scrum方法
其目的在于通过实现颠覆性创新将敏捷方法扩展到项目执行范围以外。

13.规范敏捷（DA）

规范敏捷（DA）是一种在综合模型中整合多种敏捷最佳实践的过程决策框架。
DA旨在平衡专注范围过于狭窄（如Scrum）或细节过于规范（如AgileUP）的流行方法。
为实现这种平衡，该方法根据以下原则混合了多种敏捷技术：
•以人为先
•面向学习
•完全交付生命周期
•目标驱动
•企业意识
•可扩展

术语表（中文排序）

1.首字母缩略词

ATDD 验收测试驱动开发
BDD 行为驱动开发
BRD 业务需求文档
DA 规范敏捷
DoD 完成的定义
DoR 准备就绪的定义
DSDM 动态系统开发方法
EVO 渐进价值交付
LeSS 大规模敏捷开发
LSD 精益软件开发
PDCA 计划 — 实施 — 检查 — 行动
PMO 项目管理办公室
ROI 投资回报率
RUP 统一软件开发过程
SAFe® 大规模敏捷框架®
SBE 实例化需求
XP 极限编程

2.定义

A3 A3: 它是一种思维方式及一种解决问题的系统化过程将相关信息囊括在一张 A3 大小的纸上。
DevOps DevOps: 它是通过改善开发和运营员工之间的协作来理顺交付流程的各种实践的集合。
I 型人才 I-shaped: 它是指深入掌握单一专业技能的人员他们不具备团队所需的其他技能或对其不感兴趣。
IDEAL IDEAL: 它是一种组织改进模型以所描述的五个阶段命名启动、诊断、确立、执行和学习。
Scrum Scrum: 它是一种复杂产品开发与维持的敏捷框架它由特定的角色、事件和工件等元素组成。
Scrum of Scrums Scrum of Scrums: 它是指一种多个团队围绕同一产品实施大规模敏捷开发工作的技术
他们需要协调讨论其相互依赖关系重点是如何整合软件的交付在重叠的领域尤为如此。
Scrum 主管 Scrum Master: 它是指开发团队的教练和Scrum框架中的产品负责人。其负责消除障碍促进富有成效的事件并保护团队免受干扰。
Scrumban Scrumban: 它是一种在团队选择Scrum作为工作方式时产生的管理框架它以看板方法作为透镜从而审视、理解并持续改善其工作。
Scrum板 Scrum Board: 它是一种用于管理产品代办事项列表和冲刺代办事项列表的信息发射源它能显示工作流及其瓶颈。
Scrum团队 Scrum Team: 它是指在敏捷开发中开发团队、Scrum 主管和产品负责人的总和。
T 型人才 T-shaped: 它是指深入掌握单一专业技能并广泛掌握团队所需其他技能的人员。
测试驱动开发 Test-Driven Development: 它是在工作开始前定义测试的一种技术它采用零缺陷的思维模式使工作进度能持续得到确认。
产品待办事项列表 Product Backlog: 它是指团队围绕某产品维护的一个以用户为中心的需求的有序列表。
产品负责人 Product Owner: 它是指负责使产品实现最大价值的人员其对所创建的终端产品负责并承担最终责任。
持续交付 Continuous Delivery: 它是立即向客户交付功能增量的实践往往通过采用小批量工作和自动化技术实现。
持续整合 Continuous Integration: 它是一种对团队各成员的工作产品经常整合并彼此确认的实践。
冲刺 Sprint: 它描述敏捷开发中的时间盒迭代。
冲刺代办事项列表 Sprint Backlog: 它是指由Scrum团队识别的、需要在Sprint中完成的工作事项列表。
冲刺计划 Sprint Planning: 它是指敏捷开发中的一个协作事件其中团队为目前的冲刺制定工作计划。
刺探 Spike: 它是指项目中短暂的时间间隔通常长度固定在此期间团队开展研究或针对方案的某个方面进行原型研究验证其可行性。
大规模敏捷开发 (LeSS) Large-Scale Scrum (LeSS): 大规模敏捷开发是一种产品开发框架它根据扩展指导方针扩大敏捷开发规模同时保留原有的敏捷开发目的。
大规模敏捷框架 (SAFe®) Scaled Agile Framework (SAFe®): 它是一个集成模式的知识库用于企业范围的精益开发。
代码集体所有 Collective Code Ownership: 它是一种项目加速和协作技术其中任何团队成员都有权修改任何项目工作产品或可交付成果它强调整个团队的责任和最终责任。
待办事项列表的细化 Backlog Refinement: 它是对项目需求和/或正在进行的活动的渐进明细其中团队协作参与需求的审核、更新和撰写以满足客户需求。
单循环学习 Single Loop Learning: 它是指未根据经验提出质疑、仅仅利用预先确定的特定方法解决问题的实践。
迭代 Iteration: 它是产品或可交付成果开发的一个时间盒循环其中需要执行交付价值所需的所有工作。
迭代型生命周期 Iterative Life Cycle: 它是一种允许对未完成工作提供反馈从而对工作加以改善和修改的方法。
动态系统开发方法 (DSDM) Dynamic Systems Development Method (DSDM): 它是一种敏捷项目交付框架。
反模式 Anti-Pattern: 它是一种已知的、有缺陷的、不可取的工作模式。
方针管理 Hoshin Kanri: 它是指一种策略或政策的部署方法。
服务请求管理者 Service Request Manager: 它是指在连续工作流或看板环境中负责整理服务请求、旨在实现最大价值的人员。它相当于产品负责人。
服务型领导 Servant Leadership: 它是一种向团队提供服务的领导实践重点是理解并解决团队成员的需求和发展尽可能提高团队的绩效。
符合目的 Fit for Purpose: 符合预期目的的产品。
改善活动 Kaizen Events: 它是指旨在对系统加以改善的活动。
工作流主管 Flow Master: 它是指在连续工作流或看板环境下工作的团队教练和服务请求管理者。它相当于Scrum 主管。
功能规范 Functional Specification: 它是指某系统或应用需要实现的一种特定功能。它通常体现在功能规范文档中。
功能驱动开发 Feature-Driven Development: 它是一种从客户重视的功能角度出发的轻量级敏捷软件开发方法。
功能需求 Functional Requirement: 它是指某产品或服务应完成的一个特定行为。
孤岛组织 Siloed Organization: 它是指以只能部分满足向客户交付价值的需求的方式构建的组织。请对照参见价值流。
故事点 Story Point: 它是用于相关用户故事估算技术中的一种无量纲指标。
规范敏捷 (DA) Disciplined Agile (DA): 它是指一种过程决策框架其能够围绕增量和迭代解决方案的交付 来简化过程决策。
滚动式规划 Rolling Wave Planning: 一种迭代式的规划技术对近期要完成的工作进行详细规划对远期工作只做粗略规划。
行为驱动开发 (BDD) Behavior-Driven Development (BDD): 它是一种系统设计和确认实践采用测试优先的原则和类似英语的脚本。
回顾 Retrospective: 它是一种定期进行的研讨活动其中参与者针对其工作和工作成果进行探讨旨在对过程和产品做出改进。
混合方法 Hybrid Approach: 它是指两种或两种以上敏捷或非敏捷要素的组合具有非敏捷最终结果。
混合敏捷 Blended Agile: 它是指同时使用两种或两种以上的敏捷框架、方法、要素或实践例如Scrum与极限编程和看板的结合使用。
极限编程 eXtreme Programming: 它是一种敏捷软件开发方法不仅能提高软件质量、改善软件对不断变化的客户需求的响应能力还能缩短软件版本发布周期增加发布频率。
计划 — 执行 — 检查 — 行动 (PDCA) Plan–Do–Check–Act (PDCA): 它是组织中的一种迭代管理方法旨在促进过程和产品的控制和持续改善。
技术债务 Technical Debt: 它是指产品生命周期早期未能完成工作的递延成本。
价值流 Value Stream: 它是一种组织性结构重点关注通过特定产品或服务交付流向客户的价值。
价值流图 Value Stream Mapping: 一种用于记录、分析和改善为客户生产产品或提供服务时所需的信息或材料流的精益企业技术。
渐进价值交付 (Evo) Evolutionary Value Delivery (Evo): 它是公认的首要敏捷方法拥有其他方法所不具备的特点重点关注向相关方交付多种可衡量的价值需求。
渐进明细 Progressive Elaboration: 随着信息越来越多、估算越来越准确进而不断提高项目管理计划的详细程度的迭代过程。
节奏 Cadence: 它是指项目执行节奏。另请参见时间盒。
结对编程 Pair Programming: 主要指编程的结对工作。
结对工作 Pair Work: 它是一种由两名团队成员结对、同时从事同一工作项目的技术。
精益软件开发 (LSD) Lean Software Development (LSD): 精益软件开发是软件开发领域的精益制造原理和实践它基于一套旨在满足质量、速度和客户定位要求的原理和实践。
看板方法 Kanban Method: 它是一种受到看板库存控制系统启发的敏捷方法专门用于知识工作。
看板面板 Kanban Board: 它是一种可视化工具能够通过瓶颈和工作量的有形呈现改善工作流。
跨职能团队 Cross-Functional Team: 它是指由实践者组成的团队这些实践者掌握交付有价值产品增量所需的各种技能。
框架 Framework: 它是指一种比某种特定方法更为通用的方法。
冒烟测试 Smoke Testing: 它是指利用一组轻量级测试确保正在开发的系统实现最重要的预期功能的实践。
每日例会 Daily Scrum: 它是指每天召集的一种简短的协作会议其中团队将回顾前一天的进展宣布当天的计划强调曾遇到或预期出现的障碍。也称为每日站会。
敏捷 Agile: 它是用于描述反映了《敏捷宣言》所述价值观和原则的思维模式的一个术语。
敏捷教练 Agile Coach: 它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。
敏捷生命周期 Agile Life Cycle: 它是一种迭代兼增量方法用于优化工作项目增加交付频率。
敏捷实践者 Agile Practitioner: 它是指接受敏捷思维模式、在跨职能团队中与志同道合的同事开展协作的人。也称为敏捷专家。
敏捷思维模式 Agile Mindset: 它是一种思维和行为方式其植根于《敏捷宣言》的四大价值观和十二条原则。
敏捷统一过程 Agile Unified Process: 它是在业务应用软件开发中应用敏捷技术和思想的一种简单且便于理解的方法。它是统一软件开发过程 (RUP) 的简化版本。
敏捷宣言 Agile Manifesto: 它是敏捷价值观和原则的最初官方定义。
敏捷原则 Agile Principles: 它是指《敏捷宣言》中所体现的敏捷项目交付的十二条原则。
“破梳齿”人才 Broken Comb: 它是指对团队所需的多种技能掌握程度深浅不一的人。也称为“颜料滴洒”人才。
群集 Swarming: 它是指一种团队多个成员合作、重点消除特定障碍的技术。
群体开发 Mobbing: 它是一种工作技术其中多名团队成员围绕某个具体工作项目同时协调工作。
燃尽图 Burndown Chart: 它是剩余工作与时间盒内剩余时间关系的一种图形化表示形式。
燃起图 Burnup Chart: 它是对已完成工作与产品发布关系的一种图形化表示形式。
人物角色 Personas: 它代表一组类似终端用户的典型用户通过其目标、动机和具有代表性的个人特征描述。
生命周期 Life Cycle: 它是指产品从构想、创造到投入使用的过程。
时间盒 Timebox: 它是指一段固定时间例如 1 周、2 周、3 周或 1 个月。另请参见迭代。
实例化需求 (SBE) Specification by Example (SBE): 它是为软件产品定义需求和定义面向商业的功能测试的一种协作方法基于使用实例获取并阐明需求而不是抽象陈述需求。
适合使用 Fit for Use: 以当前形式使用能实现其预期目的的产品。
双循环学习 Double-Loop Learning: 它是一种质疑潜在的价值和假设的过程其目的不是仅关注征兆而是为了更好地阐述根本原因制定改善对策。
水晶家族方法论 Crystal Family of Methodologies: 它是轻量级敏捷软件开发方法的集合其重点关注特定情况的适应性。
完成的定义 (DoD) Definition of Done (DoD): 它是团队需要满足的所有标准的核对单只有可交付成果满足该核对单才能视为准备就绪可供客户使用。
项目管理办公室 (PMO) Project Management Office (PMO): 对与项目相关的治理过程进行标准化并促进资源、方法论、工具和技术共享的一种管理架构。
信息发射源 Information Radiator: 它是一种可见的实物展示其向组织内其他成员提供信息在不干扰团队的情况下即时实现知识共享。
验收测试驱动开发 (ATDD) Acceptance Test-Driven Development (ATDD): 它是一种协作制定验收测试标准的方法用于创建交付前的验收测试。
业务需求文档 (BRD) Business Requirement Documents (BRD): 它是某特定项目的所有需求列表。
影响地图 Impact Mapping: 它是一种战略规划技术被组织作为打造新产品的路线图。
用户故事 User Story: 它是针对特定用户的可交付成果价值的简要描述。它是对澄清细节对话的承诺。
用户故事地图 User Story Mapping: 它是一种将工作纳入一个应用模型的可视化实践旨在帮助理解随着时间推移而创建的高价值功能集发现待办事项列表中的遗漏有效规划向用户交付价值的软件发布。
用户体验 (UX) 设计 UX Design: 它是一种促进用户体验的过程重点改善用户与产品互动中的可用性和可访问性。
预测法 Predictive Approach: 它是一种工作管理方法在整个项目生命周期中应用工作计划和管理工作计划。
预测型生命周期 Predictive Life Cycle: 它是一种更为传统的方法大部分规划在前期进行随后一次性执行它是一个连续的过程。
增量 Increment: 它是一种经过测试、验收的实用可交付成果也是项目总体成果的组成部分。
增量型生命周期 Incremental Life Cycle: 它是一种提供已完工的、客户可立即使用的可交付成果的方法。
障碍 Impediment: 它是指妨碍团队达成其目标的干扰因素。也称为阻碍。
重构 Refactoring: 它是一种产品质量技术其通过提高产品的可维护性和其他需要的属性来改善产品设计同时并不改变产品的预期行为。
转向 Pivot: 它是指计划中的方向修正旨在检测产品或策略的新假设。
准备就绪的定义 (DoR) Definition of Ready (DoR): 它是团队以用户需求为中心的核对单其中包括团队开始工作所需的全部信息。
自动化代码质量分析 Automated Code Quality Analysis: 它是用于检测代码库缺陷和漏洞的脚本化测试。
自组织团队 Self-Organizing Team: 它是一种跨职能团队其中为实现团队目标团队成员根据需要轮换着发挥领导作用。
组织变革管理 Organizational Change Management: 它是一种全面的、周期性的、结构化方法旨在使个人、群组和组织在从当前状态转换为未来状态时实现预期的业务收益。
组织偏好 Organizational Bias: 组织偏好是指组织对一组衡量指标的选择。这组衡量指标具有如下核心价值探索与执行、速度与稳定性、数量与质量、灵活性与可预测性。