笔记《ACP：敏捷实践指南》

目录

• 问题整理
  • 1. 什么是敏捷？
  • 2. 敏捷是做什么的？
  • 3. 敏捷中践行的法则、核心关注点？ 团队价值？可交付物？
  • 4. 实行敏捷需要哪些环境or条件的支持，面对的挑战、以及敏捷管理过程中如何衡量指标？
  • 5. 敏捷项目组织需要考虑哪些因素？
  • 6. 其他对比工具影响？ 裁剪？对比？框架属性概述、筛选工具？
• 附录
  • 1. 和PMI发行的 《 PMBOK ®指南》关系 ？
  • 2.《敏捷宣言》映射？
  • 3. 敏捷和精益框架概述？
  • 4. 影响裁剪属性？
  • 5. 影响裁剪适用性筛选工具？
  • 6. 总结？

问题整理

1. 什么是敏捷？

• 艾哈迈德-西德基 （AhmedSidky )启发下提出的模式将敏捷明确表述为一种思维模式，
• “敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。

今天所使用的各种敏捷方法都植根于敏捷思维模式、价值观和原则。

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

不确定的工作和高度不确定的工作

广义方法：可通过两种策略践行敏捷价值观和原则.

• 一种策略是采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果。（变更和裁剪）
• 以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。

精益与看板方法

• 关系：敏捷和看板方法视为精益思想的衍生物
• 共性：重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等方面。

看板方法受到精益制造体系启发，专门用于知识型工作。
缺点：不如某些敏捷方法规范、破坏性较小， 在于“原地出发” 方法。

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

• 受斯泰西复杂性模型启发的不确定性和复杂性模型

• 当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
• 团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。
• 迭代和增量方法减少了浪费和返工。这些方法应用了：

1. 非常短的反馈循环
2. 频繁调整过程
3. 重新进行优先级排序
4. 定期更新计划
5. 频繁交付
   适用于具有以下特点的项目：
6. 需要研究和开发
7. 变更速度极快
8. 具有不明确或未知的需求、不确定性或风险
9. 最终目标难以描述

2. 敏捷是做什么的？

答：- 为项目领导者或项目团队成员提供实践指导，用以帮助他们在项目规划和执行过程组中适应敏捷方法。

• 第一原则：关注将客户满意视为最高要求是让客户满意和服务的关键

3. 敏捷中践行的法则、核心关注点？ 团队价值？可交付物？

关注点：即价值观十二原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件来使客户满意。

• 欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，要通过敏捷过程来适应变化。

• 经常性地交付可以工作的饮件，比如间隔几个星期或一两个月就交付，交付的时间间隔越短越好。

• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支持，辅以信任，从而达成目标。

• 不论团队内外，效果最好且效率最高的传递信息的方式，就是面对面的交流。

• 可以工作的软件是首要的进度度量标准。

• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户要能够共同维持其不断稳定延续。

• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 以简洁为本，它是极力减少不必要工作量的艺术。

• 最好的架构、需求和设计出自自组织团队。

• 团队定期地反思如何能提高成效，并依此调整自身的举止行为。

  提炼总结：

   需求：拥抱变化、
   过程：相互合作、激发个体斗志、面对面交流、衡量指标：可工作软件、追求技术卓越、简洁为主、自组织团队、
   结果：持续不断交付 频率越短越好、
   总结：定期回顾
  

敏捷宣言

• 个体和互动 高于 流程和工具

• 工作的软件 高于 详尽的文档

• 客户合作 高于 合同谈判

• 响应变化 高于 遵循计划

总结： 工作过程：个体互动、响应变化; 工作目标：工作软件、客户合作

组成: 这种思维模式、价值观和原则定义了敏捷方法的组成部分。

4. 实行敏捷需要哪些环境or条件的支持，面对的挑战、以及敏捷管理过程中如何衡量指标？

• 适用敏捷场景：不确定性（需求、范围 ~）

创建敏捷环境

• 敏捷思维模式开始
• 仆人式领导为团队赋权: 目的、人员、过程（不要计划遵循“完美”的敏捷过程，而是要注重结果。）

1. 仆人式领导的职责： 促进作用、消除阻碍、为人贡献、考虑职责
2. 敏捷中项目经理角色：有些未知、有些必要
3. 项目经理：应用仆人式领导

• 团队构成: 敏捷团队、敏捷的角色、通才型专家、团队结构、 专职小组成员、工作场所、克服组织孤岛

解释：

《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。

克服组织孤岛:

1. 来自不同职能部门、拥有不同技能的人
2. 作为敏捷项目领导，首先要把重点放在如何组建跨职能团队，让所有团队成员 100% 投入团队工作。即使这只是意味 着关键团队成员（如开发人员和测试人员）每天一起工作和交流，但也是迈向正确敏捷方向的一步。

敏捷团队:

敏捷的角色:

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

• 项目章程和团队章程

• 敏捷实战：回顾、待办事项列表编制&细化、每日站会、展示/评审、规划基于迭代的敏捷、帮助团队交付价值的执行实践

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

面对的挑战

剩余故事点的燃尽图:

显示已完成故事点的燃起图:

看板面板示例:

敏捷背景下的挣值:

已完成功能的累积流图:

敏捷项目的衡量指标

敏捷团队的衡量结果: 敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。

团队可能会发现，可能需要四到八次迭代才能达到稳定的速度。团队需要从每个迭代中获得反馈，了解他们

当团队依赖于外部人员或团队时，衡量周期时间可了解团队完成工作所 需的时间。团队完成工作之后，衡量交付周期可了解外部依赖关系。团队还可以测量反应时间，从准备就绪到第一列的时间，了解平均需要多长时间才能对新请求做出响应。

5. 敏捷项目组织需要考虑哪些因素？

文化、结构和政策可能会影响到所有项目的方向和成果。

• 组织变革管理

变革管理驱动因素(1.加速交付相关，调频繁并尽早交付项目输出 2. 敏捷方法相关，采用敏捷方法时也会经历更高程度的变革 )

• 变革就绪情况

• 组织文化(1. 创建安全环境 2.评估文化)

• 采购和合同

• 商业实践

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

• 敏捷和项目管理办公室（PMO) [价值驱动型、面向创新型、多学科型]

• 组织结构

• 组织演变

变更初始待办事项列表排序:

使用待办事项列表和看板面板组织和跟踪变革工作:

6. 其他对比工具影响？ 裁剪？对比？框架属性概述、筛选工具？

生命周期特征

• 预测型：从高确定性的明确的需求、稳定的团队和低风险中获益。顺序方式执行
  

• 迭代型：通过连续的原型或概念验证来改进产品或成果。迭代有利于识别和减少不确定性
  

• 增量型：少量可交付成果的频繁交付 （优化为项目发起人或客户交付价值的工作）
  

完整性和交付是主观的 ;

• 敏捷型：拥抱变化，迭代和增量提供反馈改善进一步计划!基于迭代的敏捷,以迭代（相等持续时间的时间盒）形式交付完整的功能。

符合敏捷宣言提倡的生命周期: 客户满意度将随着有价值产品的早期交付和持续交付不断提升! 功能性的、提供价值的增量可交付成果，是衡量进展的主要尺度。
敏捷适用性筛选器: 各种评估模型用以评估适合性和差距。

• 混合型：结合不同的生命周期要素。预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。

• 混合敏捷和预测型：团队逐渐地向敏捷过渡，使用某些方法，如短迭代、每日站会和回顾，但在其他方面，如前期评估、工作分配和进度跟踪等，仍遵循预测法。

• 预测主敏捷为辅：敏捷处理不确定性、复杂性或范围蔓延机会一部分，预测法管理项目的其余部分。

• 敏捷主预测为辅：当某个特定要素不可协商，或者使用敏捷方法不可执行时。

• 符合目的的混合生命周期：项目团队可能基于项目风险设计一个混合生命周期。

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

混合敏捷方法：不只局限于一种敏捷方法。敏捷框架非针对团队定制，为了定期交付价值，对实践进行裁剪;实践各自特殊的敏捷组合。

影响裁剪的项目因素：根据项目属性对方法进行裁剪，

附录

1. 和PMI发行的 《 PMBOK ®指南》关系 ？

2.《敏捷宣言》映射？

《敏捷实践指南》中涵盖的《敏捷宣言》价值观

《敏捷宣言》背后原则的实践指南映射：

3. 敏捷和精益框架概述？

• 常用的敏捷方法。可以单独或结合使用，以调整适应特定环境或情况。 没有必要一定使用这些方法；敏捷方法可以完全重新开发，只需符合《敏捷宣言》的思维模式、价值观和原则即可。

• 精益软件开发（LSD）

精益软件开发由Tom和Mary Poppendieck 引入敏捷群体。它采用来自丰田生产系统（TPS）的原则和实践。

①TPS开发旨在解决影响生产过程问题，例如：

1）过度：对于雇员和过程施加不必要的额外压力

2）违规：不切实际的需求导致过程中的不均匀

3）浪费：非增值活动或过程

②精益七原则：

1）消除浪费：对客户没有带来价值的事务就是浪费；

2）尽快交付：短期迭代或小批量提供有价值的反馈，促进有效的决策制定；

3）增强学习：通过短迭代周期、重构、集成测试和频繁的客户反馈会议增强学习；

4）团队授权：精益专注于团队，因为决策制定和管理的来源让团队了解最佳选择和成本；

5）较迟决定：管理不确定性的最佳方法是手机信息，最后的责任时刻给予承诺，打破部件间的依赖关系；

6）建立整体：确保质量是嵌入在整个系统的，系统需要构建自动化测试、安装和持续集成；

7）目光长远，脚踏实地，快速试错，快速学习。

• 《敏捷实践指南》的选择标准：专供整体使用、适合常用环境、现代流行用例。
  图A3-1根据广度和详情制订的敏捷方法：
  

• Scrum

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

1、Scrum团队包含产品负责人、开发团队和Scrum主管。

1）产品负责人负责实现产品价值的最大化；

2）开发团队是一个跨职能的自组织团队，其开发人员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品；

3）Scrum主管负责确保Scrum过程获得相应支持且Scrum团队遵从实践和规则，并指导团队消除障碍。

2、Scrum事件：

①冲刺Sprint

②sprint计划会议

③每日Scrum站会

④sprint评审会议

⑤sprint回顾会议

3、Scrum工件：

①产品代办列表

②冲刺sprint代办列表

③增量

• 极限编程

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

• 看板方法

看板是日本的信号板的说法，是由丰田生产系统（TPS）开发；

①看板方法是从精益思维原则衍生而来，是一个跟精益和及时制生产相关的概念；

②敏捷采用了看板方法去反映冲刺或迭代的吞吐量。

以下适用场景

• 灵活性
• 专注于持续交付
• 提高工作效率和质量
• 提高效率
• 团队成员专注力
• 工作负载的可变性
• 减少浪费

• 水晶方法

水晶是一种方法论家族。水晶方法论旨在根据项目规模（项目涉及的人员数量）以及项目的关键性来量化并提供方法严格程度的选择。
水晶方法认识到每个项目可能需要一系列轻量剪裁的策略、实践和过程，以匹配项目的独特特征。该方法论家族根据“重要性”使用不同颜色来确定要使用的方法。“水晶”一词的使用源自宝石，它的不同面代表了根本的核心原则和价值观。不同面代表了技术、工具、标准和角色，

• Scrunban

Scrumban是一种敏捷方法，最初设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法。

在Scrumban中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。

• 功能驱动开发

功能驱动开发（FDD)的开发目的是满足大型软件开发项目的特定需求。小型商业价值功能重视能力

• 动态系统开发方法

动态系统开发方法（DSDM）是一种敏捷项目交付框架，最初的设计目的是提高20世纪90年代普及的迭代方法的严格程度。该框架开发为行业领导者之间的非商业性协作方式。DSDM因强调制约因素驱动交付而著称。该框架从一开始便可设置成本、质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求。

• AUP敏捷统一过程

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

• 扩展框架 ScrumofScrums

Scrum of Scrums(SoS)也称为“meta Scrum”，是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含三到九名成员来协调其工作。

• 大规模敏捷框架 SAFe

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

• 大规模敏捷开发（LeSS）

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

• 企业 Scrum
• 规范敏捷（ DA )

4. 影响裁剪属性？

5. 影响裁剪适用性筛选工具？

6. 总结？

敏捷适应性筛选是确定敏捷方法潜在适合性与差距的有用工具。
首字母缩略词：

链接：https://pan.baidu.com/s/1pwWKenK71FQguBaARWlg9w 提取码：请留言作者
源文档MD格式： 链接：https://pan.baidu.com/s/1rpFViEsozsdkVL5Pa598Qw