Agile 敏捷实践指南 - 知识梳理

个人的学习笔记/個人の勉強ノートです/Just my study minutes.

■ 敏捷概述

传统预测法旨在预先确定大部分需求，并通过变更请求过程控制变更。而敏捷方法的出现是为了在短时间内探讨可行性，根据评估和反馈快速调整。

■ 敏捷宣言

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

源自这些价值观的十二大原则是：

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

敏捷宣言价值观,原则和通用实践之间的关系
敏捷思维模式>4大价值观>12大原则>实践

“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。它是指符合《敏捷宣言》价值观和原则的任何方法，技术，框架，手段或实践。

敏捷方法和看板视为精益方法的子集。这样做的原因是，它们都是精益思想的具体实例，都反映了诸如以下概念：
- 关注价值
- 小批量
- 消除浪费

精益与看板方法

看待精益，敏捷与看板方法三者之间关系的一种思路是，将敏捷和看板方法视为精益思想的衍生物。

■ 生命周期选择

本实践指南涉及的四种生命周期。

预测型生命周期：
提前进行大量的计划工作，然后一次性执行。

迭代型生命周期：对未完成的工作进行反馈，从而改进和修改该工作。
长达数周时间的一个特定迭代中使用时间盒，集中各种见解，然后根据这些见解对活动进行返工。
当项目复杂性高，变更频繁或项目范围收到相关方对所需最终产品的不同观点的支配时，采用迭代型生命周期会有优势。
因为是为学习而优化，而不是为了交付速度而优化。
Ver1.0 - Ver2.0 - Ver3.0 造个原型出来，然后从模糊到清晰。

增量型生命周期：向客户啊提供各个已完成的，可能立即使用的可交付成果。
为了加快交付速度，少量可交付成果的频繁交付称为增量型。
客户愿意接受整个决策方案的一部分。
头-手-脚-人 从部分到整体。

敏捷生命周期：这种方法既有迭代，也有增量，便于完善工作，频繁交付。
基于迭代的敏捷：时间盒大小定好，在特定的时间合理进行迭代。
基于流程的敏捷：在流程中，完成各个功能开发所需要的开发时间不同。

混合生命周期,如
1. 敏捷开发后接预测（如：敏捷-敏捷-预测-预测）
2. 同时结合使用敏捷和预测方法（敏捷预测-敏捷预测-敏捷预测）
3. 预测为主，敏捷为辅
4. 敏捷为主，预测为辅

项目管理的目标是在给定的当前环境下尽可能以最好的方式创造商业价值。

混合敏捷方法

Scrum框架：产品待办事项列表，产品负责人，Scrum主管
看板：将工作可视化，使障碍容易被察觉，通过调整在制品限制来实现流程管理。
极限编程：使用故事卡，持续集成，重构，自动化测试和测试驱动开发，进一步提高敏捷团队的效力。

■ 实施敏捷：创建敏捷环境

仆人式领导为团队赋权。仆人式领导是通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。

目的：与团队一起定义“为什么”或目的，以便他们围绕项目目标进行合作互动。整个团队在项目层面而不是在人员层面优化。
人员：目标确立后，鼓励团队创造一个人人都能成功的环境。
过程：不要计划遵循完美的过程，而是要注重结果。如果跨职能团队能够常常交付完成的价值并反思产品和过程，团队就是敏捷的。

仆人式领导的促进作用：从管理协调转向促进合作。
仆人式领导消除组织障碍：认真审视哪些阻碍团队敏捷或组织敏捷的过程，并努力使其合理化。
仆人式领导为他人贡献铺路：注重与管理层，与产品负责人合作，为团队铺路。

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

■ 敏捷的角色

跨职能团队成员
包括具有生产可行产品所需的各种必要技能的团队成员。他们能在尽可能短的时间内，交付已完成的，高质量的，无外部以来的关系的任务。通才型专家组成。

产品负责人
产品负责人负责指导产品的开发方向。产品负责人为团队创建待办事项列表，待办事项列表帮助团队了解怎样在不产生浪费的情况下交付最大的价值。

团队促进者
仆人式领导。如项目经理，Scrum主管，项目团队领导，团队教练或团队促进者。
仆人式领导可以引导，指导和消除障碍技能。

团队工作场所
敏捷团队需要一个工作场所，他们可以一起工作，了解他们作为团队的状态，并进行写作。
在不同地点工作的团队成员需要虚拟的工作空间。
分散式团队管理沟通的一些技术包括鱼缸窗口和远程结对。

鱼缸窗口：建立长期视频会议链接，创建一个鱼缸窗口，每天工作开始时，人们打开链接，工作结束时关闭链接。人员可以自然地看到彼此并进行互动。
远程结对：通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结对。只要考虑了时差，这种方法几乎和面对面结对一样有效。

■ 实施敏捷：在敏捷环境中交付

创建章程和团队章程
敏捷团队需要有团队规范以及对一起工作方式的理解。
团队可能需要一个团队章程，来回答以下问题：
1. 我们为什么要做这个项目？这是项目愿景。
2. 谁会从中受益？如何受益？这是项目愿景或项目目标的一部分。
3. 对此项目而言，达到哪些条件才意味着项目完成。这是项目的发布标准。
4. 我们将怎样合作？这说明预期的工作流。

■ 常见敏捷实践

回顾
回顾是最重要的一个实践，原因是它能让团队学习，改进和调整其过程。回顾不需要固定的时间，随时。
回顾不是责备：回顾是让团队从以前的工作中学习并做出较小的改进。

待办事项列表编制
待办事项列表是所有工作的有序列表，它以故事形式呈现给团队。

待办事项列表的细化
在基于迭代的敏捷中，产品负责人往往在迭代中期的一次或多次会议中与团队成员合作，为即将进行的迭代准备一些故事。这些会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间的相互关系。项目团队通常有一个目标，就是每周用不超过1小时的时间来为下一批工作细化故事。

每日站会
团队成员利用每日站会对彼此做出小的承诺，发现问题，并确保团队工作顺利进行。
在会议上讨论三个问题：
- 上次站会以来我做了什么?
- 到下一次站会前，我计划做什么？
- 是否有障碍或问题？

如果是基于流程的敏捷，可以将注意力集中在团队的产出上。团队从右到左对看板进行评估。包括：
- 我们还需要做些什么来推进这一工作？
- 有人在做看板上所没有的事情吗？
- 作为一个团队，我们需要完成什么？
- 工作流程是否存在瓶颈或阻碍？

注意：
站会不是状态报告会议。
站会上出现了问题，另行开会解决而非在站会解决。

展示/评审
当团队以用户故事的形式完成特定功能时，团队会定期展示工作产品。看过展示后，产品负责人接受或拒绝故事。
通过展示和发布，来提高团队的学习速度。

帮助团队交付价值的执行实践
持续集成：无论产品如何，都要频繁的将工作集成到整体中。然后重新测试，以确定整个产品仍然按照预期工作。

验收测试驱动开发（ATDD）：整个团队要聚集一堂讨论工作产品的验收标准。然后团队创建测试，来满足标准要求。

测试驱动开发（TDD）和行为驱动开发（BDD）：在编写/创建产品之前编写自动化测试，世界上可以帮助人员设计产品，防范产品错误。

刺探（时间盒研究或实验）：刺探对学习很有用。可以在诸如评估，验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术活功能要素时，刺探会有帮助。

（补充）影响地图：是需求不明确时，用实例化需求，用户故事地图和影响地图来构建产品路线图。然后将路线图分解为具有更少的具体需求的待办事项列表。

敏捷团队的测量结果
敏捷倾向于使用基于经验和价值的衡量指标，而不是预测性衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。
基于迭代的项目使用燃尽图（剩余的故事点）来查看项目随时间的进展情况。也有团队用燃起图（已完成的故事点）来展示。

团队可能会发现，可能需要四道八次迭代才能达到稳定的速度。团队需要从每个迭代中获得反馈，了解他们的工作情况以及如何改进。

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

如果组织能够做出相应调整，则可以提高项目敏捷性的效率和适应性。

组织文化
文化能把战略当早餐吃。（Culture eats strategy for breakfast.）-- Peter Drucker
这句名言强调了人的承诺和热情对于一份事业的重要性。

评估文化
项目领导可能感觉其职责就是满足各个相关方的期望，但是面对选择时，通常需要根据组织业务环境的文化和要求来确定优先级。
例如：移动电信项目偏重于速度，而政府项目则偏重于大众化和稳定性。

■ 敏捷框架

多个项目之间会产生依赖关系，即使不是在给定项目集中进行管理。因为有必要了解敏捷工作在现有项目集和项目组合管理环境下的工作方式。

大多数流行敏捷方法（如Scrum和极限编程）的指导，专注于单个小型且通常是集中办公的跨职能团队活动。这对于单个团队非常有用，但对于项目集或项目组合会显得捉襟见肘。

目前已经出现许多框架（如大规模敏捷框架，大规模敏捷开发，敏捷规范）和方法（Scrums of Scrums）来应对这种情况。

1. SCRUM

用于管理产品开发的单个团队过程框架。该框架包括Scrum角色，事件，工件和规则。采用迭代方法来交付工作产品。

Scrum团队包括产品负责人，开发团队和Scrum主管。
产品负责人，负责实现产品价值的最大化。
开发团队是一个跨职能的自组织团队，并拥有所需要的一切资源。
Scrum主管负责确保Scrum过程中获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。

事件：
冲刺，冲刺计划，每日例会，冲刺评审，冲刺回顾

工件：
产品待办事项列表，冲刺待办事项列表，增量

需求管理+计划管理+任务管理

2. 极限编程 XP

极限编程是一种基于频繁交付周期的软件开发方法。该名称基于这样一个理念：将特定最佳实践提炼到最纯粹和最简单的形式，然后再整个项目周期内持续运用该实践。

在XP的项目开发中，首先引入了四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。

为了能成功地实施XP，XP制定四个准则：沟通、简单、反馈和勇气

1.极限编程（Extreme programming，缩写为XP），是敏捷软件开发中应用最为广泛和最富有成效的几种方法学之一。极限编程鼓励管理人员和开发人员接受并使用某些特别的有价值的方法。
2.极限编程的创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯。
3.极限编程的目标：降低因需求变更而带来的成本。极限编程通过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
4.极限编程的12个核心实践
（1）短交付周期：和Scrum一样xp采用迭代的交付方式，每个迭代1-3周时间。在每个迭代结束的时候，能够交付可运行的，经过测试的功能。
（2）计划游戏：主要包括软件发布计划和周期开发计划。
（3）结对编程：编程时两个人一起，一个考虑系统架构，一个设计编程细节。
（4）可持续节奏：在项目开发过程中持续保持节奏。
（5）代码集体所有：所有人都可以更改代码任意一部分，可以提升开发速度，提高错误发现的速率。
（6）编码规范：团队使用统一的编码规范。
（7）简单设计：用最简单的办法实现每个小需求。
（8）测试驱动开发（TDD）：从功能需求的测试用例开始，先添加一个测试用例，然后运行所有的测试用例看看有没有问题，再实现测试用例所要测试的功能，然后再运行测试用例，查看是否有case失败，然后重构代码，再重复以上步骤；确保照顾到所有需求并实现所有功能。
（9）重构：开发人员对每个USER STORY都进行简单设计，但同时也在不断地对设计进行改进。
（10）系统隐喻：用比喻来描述系统或功能模块是怎样工作的，帮助团队更好理解需求。
（11）持续集成：团队经常基集成，每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
（12）现场客户：客户应该时刻在现场解决问题
5.极限编程的4个价值：沟通、简单、反馈、勇气
6.极限编程的5个原则：快速反馈、假设简单、增量变化、拥抱变化、高质量工作。
————————————————
版权声明：本文为CSDN博主「暖暖木头」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_44850444/article/details/89036636

3.看板方法

看板在精益制造中是用一种用于规划库存控制和补给的系统。带有卡片的物理看板面板能够推动和实现整个系统工作流的可视化。最简单的看板可能包含三列（即，要完成的工作，进行中的工作和一完成的工作）,但可以调整为使用团队所需要的任何状态。

看板方法可以确保工作流和价值交付的持续性。看板方法未规定使用时间盒迭代。在看板方法中可以使用迭代，但应遵循在整个过程中拉取单个条目并限制在制品以优化流程的原则。

看板方法是一种整体性组织增量演变过程和系统变更框架。该方法采用拉式系统来完成在制品。团队完成一个条目后，即可拉取另一个条目到该过程。

在看板方法中，完成工作比开始新工作更为重要。

4.水晶方法

水晶是一种方法论家族。水晶方法旨在根据项目规模（项目中涉及的人员数量）以及项目的关键性来量化并提供方法严格程度选择。

水晶方法根据重要性使用不同的云暗色来确定使用的方法。用水晶的不同面代表了技术，工具，标准和角色。

5.SCRUMBAN

是一种混合敏捷框架和方法。将Scrum作为框架，而将看板作为过程改进方法。在Scrum中，工作被分解上许多小的冲刺，并利用看板来可视化和监督工作。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中，Scrum模型中规定时间的sprint显然就不能够满足项目的需求了，但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝，通过这两样法宝，能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。

Scrum-Ban中没有定义角色，团队保留当前角色。

6.功能驱动开发（FDD）

功能驱动开发是满足大型软件开发项目的特定需求。小型商业价值功能重视能力。可以理解为以功能为中心展开过程或活动。

功能驱动开发的生命周期
- 开发高层级模型
- 开发功能列表
- 依据功能规划
- 依据功能设计  （有需要，就修改模型）
- 依据功能构建  （有需要，就修改模型）

7.动态系统开发方法（DSDM）

动态系统开发方法（DSDM）是一种敏捷项目交付框架，最初设计出来是为了提供迭代方法的严格程度。DSDM的特点是强调制约因素驱动。该框架一开始设置成本质量和时间，然后利用正式范围优先级来满足这些制约因素的要求。

1994年，动态系统开发方法开发了敏捷项目适用性问卷调查和组织适用性问卷调查来帮助衡量敏捷可能适合的领域和潜在的方法。

也就是说，与传统方法不同，利用范进成不同的倒三角，成本-时间→范围来推进。

9.敏捷统一过程（AgileUP）

是软件项目中统一过程（UP）的分支。该过程具有加速周期和轻量级的过程。

AUP2的实践环节不是普适的，随着时间的变化也不是一成不变的。它只是提供了一个思路：在任何情况下，我们都应该统一地看待企业所采纳的过程、技术、组织架构……等内容，以期达到最低的拥有价值。

在本人参与或了解的企业中，实施敏捷开发的主要阻力不是敏捷开发本身的实践有多难，而是如何将敏捷开发与现有的组织结构和制度相适应，或如何改造现有的结构和制度以适合敏捷开发。

因此应该在敏捷开发的语境下扩展那些周边的过程，以便为实施敏捷开发的大环境提供指导，以降低研发管理的总体成本。

其中一个有效的方法，就是建立以敏捷为指导思想的统一过程，以涵盖敏捷之外的组织结构与制度，并使之与敏捷开发相匹配。
————————————————
版权声明：本文为CSDN博主「火星人陈勇」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/cheny_com/article/details/8181184

扩展框架

10.Scrums of Scrums (SoS）

也称Meta Scrum，是有两个或多个Scrum团队而不是一个大型Scrum团队使用的一种技术。每个团队代表与其他团队定期召开会议，目标是确保团队协调工作并清除障碍，以优化所有团队的效率。

11.大规模敏捷框架（SAFe）

The Scaled Agile Framework（SAFe）focuses on providing a knowledge base of patterns for scaling development work across all levels of the enterprise.

SAFe专注于项目组合，项目集合团队层详细设定实践，角色和活动，强调围绕专注于向客户提供持续价值的价值流来组织企业。

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

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

13.企业Scrum

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

14. 规范敏捷（DA）

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

■ 裁剪

裁剪的注意事项
裁剪是应由有经验的从业者实施的高级课题，从业者在考虑进行裁剪之前，必须已在前面说明的多种环境下成功使用过敏捷方法。换言之，必须首先积累经验并能够成功利用一种敏捷方法才能尝试裁剪。

评估变更的理想方式是首先尝试一个或两个迭代，然后在考虑永久采用。或者考虑基于流程的方法以实现某些功能，然后通过回顾和重新评估来进行反思。

注意清除影响
许多敏捷实践都是具有相互作用的。例如，集中办公和频繁业务对话可以快速弥补理解方面的差异，因此可以降低需求程度。同样，XP的大量测试可以支持大胆重构，因为各个实践是相辅相成的。

裁剪指南

大型项目团队
将大型项目重建为多个小项目，首先尝试技术实验项目，然后再执行实施项目。

分散团队
如果团队保持稳定，尽快构建面对面会议以提高未来远程交流的效率。因为面对面交流时更容易建立信任感，提高对话质量。
此外，避免使用整个项目的迭代方式，而是鼓励开展更多更频繁的私人会议。

某些安全关键性产品可能需要当前敏捷过程所建议的其他文档及合规性检查
考虑使用混合方法（多种敏捷方法），按照产品环境所要求的的更高严格程度，从敏捷所带来的的协作和沟通改善中获得益处。航空飞行系统开发商和药物公司采用敏捷方法并结合自己的其他过程，充分利用这些优势并保留了相应的控制权。

稳定需求和执行过程
是否真正需要敏捷方法？如果需求不确定性较低，变更速度缓慢，或者执行风险较小，则可能不需要整套敏捷方法，尽管协作和透明程度提高对任何项目都有益处，但某些迭代构建和审查周期可能是多余的。

如果构建/反馈周期无法定期发现或优化需求，请考虑延长其持续时间以减少审查时间对成本的影响。

团队位于职能型组织内的职能孤岛中
敏捷是基于跨职能团队的理念。如果能够通过组织报酬系统认可职能领域并给予奖励，请考虑首先变更该系统。除非对自己的报酬有一定影响，员工才会为产品或团队的利益行事。

透明会产生恐惧
敏捷将会创建透明文化，透明需要勇气。
通过使用状态或白板，示范引导并在决策过程中展示透明化。

许多团队成员缺乏技术领域知识
敏捷团队将会提高团队的主动性并发挥其优势，作出工作内容相关的本地决策，例如任务安排顺序以及在解决问题时采取何种方法。如果团队经验不足，一些"分配"和“指导”方面的额外帮助可能是必需的。考虑构建能力中心以帮助提供指导并积累领域知识。

缺乏管理层支持
根据组织需求找到共同点和改进之处，然后利用实验和回顾取得进展。考虑管理层教育/培训。考虑从精益思维方面解释敏捷：周期短，规模小，频繁审查，回顾与小幅改进。

敏捷术语和语言不适合组织文化
如果不是敏捷语言，就修改术语，让员工了解并同意这些活动。
例如，如果组织认为 计划游戏 一词不够专业，就采用 计划研讨会 这样的术语。

■ 敏捷适用性筛选工具

水晶方法家族还用了适用性标准，根据团队规模以及所开发产品或服务的关键性来对项目排序。水晶方法建议，较小的不关键的项目应该采用简单的方法并实施较弱的控制。大型任务或生命关键型项目建议使用更高的严格程度和验证级别。

筛选工具的模型概述

文化：是否具有支持该方法并已建立信任的团队环境。
团队：适当规模的团队是否能在采取敏捷后获得成功？成员是否能够获取成功所需的技术以及业务代表联系渠道？
项目：变更速度极快？增量交付可行？项目关键型如何？

回答这些了别的问题，然后将结果绘制在雷达图中。图中心的值表示非常适合敏捷方法。外围则表示预测法会更适合。中间表示混合方法可能会更奏效。

敏捷方法适用性模型

总结：敏捷适应型筛选是确定敏捷方法潜在适合性与差距的有用工具。

■ 术语

敏捷生命周期（Agile Life Cycle）：它是一种迭代兼增量方法用于优化工作项目增加交付频率。

燃尽图（Burndown Chart）：剩余工作与时间盒内剩余时间关系的一种图形化表示形式。

燃起图（Burnup Chart）：已完成工作与产品发布关系的一种图形化表示形式。

CI/CD：持续整合（Continuous Integration），持续交付（Continuous Delivery）。

跨职能团队（Cross-Functional Team）: 它是指由实践者组成的团队这些实践者掌握交付价值产品增量所需的各种技能。

极限编程（eXtreme Programming）： 它是一种敏捷软件开发方法不仅能提高软件质量，改善软件对不断变化的客户需求的响应能力还能缩短软件版本发布周期增加发布频率。

产品待办事项列表（Product Backlog）：它是指团队围绕某产品维护的一个以用户为中心的需求的有序列表。

Scrum：它是一种复杂产品开发与维持的敏捷框架，他由特定的橘色，事件和工件等元素组成。

孤岛组织（Slloed Organization）：它是指以智能部门满足客户交付价值的需求的方式构建的组织。

影响地图（Impact Mapping）：它是一种战略规划技术被组织作为打造新产品的路线图。

用户故事地图（User Story Mapping）：它是一种将工作纳入一个应用模型的可视化实践旨在帮助理解随着时间推移而创建的高价值功能集发现待办事项列表中的遗漏，有效规划向用户交付价值的软件发布。

_________________________________
参考：PMI 《敏捷实战指南》