问题整理
1. 什么是敏捷？
- 艾哈迈德-西德基 （AhmedSidky )启发下提出的模式将敏捷明确表述为一种思维模式，
- “敏捷方法”是一个囊括了各种框架和方法的涵盖性术语。它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。
今天所使用的各种敏捷方法都植根于敏捷思维模式、价值观和原则。
- 敏捷方法和看板方法视为精益方法的子集。它们都是精益思想的具体实例，都反映了以下概念：“关注价值”“小批量”和“消除浪费”。
不确定的工作和高度不确定的工作
广义方法：可通过两种策略践行敏捷价值观和原则.
- 一种策略是采用正规的敏捷方法，它们为特意设计，经证明可达成期望的成果。（变更和裁剪）
- 以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。
精益与看板方法
- 关系：敏捷和看板方法视为精益思想的衍生物
- 共性：重点在于交付价值、尊重人、减少浪费、透明化、适应变更以及持续改善等方面。
看板方法受到精益制造体系启发，专门用于知识型工作。
缺点：不如某些敏捷方法规范、破坏性较小， 在于“原地出发” 方法。
不确定性、风险和生命周期选择
- 受斯泰西复杂性模型启发的不确定性和复杂性模型
- 当团队交付小的增量时，他们能够更快更准确地理解真正的客户需求。
- 团队可以用明确稳定的管理要求规划并管理项目，轻松解决各种技术挑战。
- 迭代和增量方法减少了浪费和返工。这些方法应用了：
- 非常短的反馈循环
- 频繁调整过程
- 重新进行优先级排序
- 定期更新计划
- 频繁交付
适用于具有以下特点的项目：- 需要研究和开发
- 变更速度极快
- 具有不明确或未知的需求、不确定性或风险
- 最终目标难以描述
2. 敏捷是做什么的？
答：- 为项目领导者或项目团队成员提供实践指导，用以帮助他们在项目规划和执行过程组中适应敏捷方法。
- 第一原则：关注将客户满意视为最高要求是让客户满意和服务的关键
3. 敏捷中践行的法则、核心关注点？ 团队价值？可交付物？
关注点：即价值观十二原则
-
我们最重要的目标，是通过持续不断地及早交付有价值的软件来使客户满意。
-
欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，要通过敏捷过程来适应变化。
-
经常性地交付可以工作的饮件，比如间隔几个星期或一两个月就交付，交付的时间间隔越短越好。
-
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
-
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支持，辅以信任，从而达成目标。
-
不论团队内外，效果最好且效率最高的传递信息的方式，就是面对面的交流。
-
可以工作的软件是首要的进度度量标准。
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户要能够共同维持其不断稳定延续。
-
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
-
以简洁为本，它是极力减少不必要工作量的艺术。
-
最好的架构、需求和设计出自自组织团队。
-
团队定期地反思如何能提高成效，并依此调整自身的举止行为。
提炼总结：
需求：拥抱变化、 过程：相互合作、激发个体斗志、面对面交流、衡量指标：可工作软件、追求技术卓越、简洁为主、自组织团队、 结果：持续不断交付 频率越短越好、 总结：定期回顾
敏捷宣言
-
个体和互动 高于 流程和工具
-
工作的软件 高于 详尽的文档
-
客户合作 高于 合同谈判
-
响应变化 高于 遵循计划
总结： 工作过程：个体互动、响应变化; 工作目标：工作软件、客户合作
组成: 这种思维模式、价值观和原则定义了敏捷方法的组成部分。
4. 实行敏捷需要哪些环境or条件的支持，面对的挑战、以及敏捷管理过程中如何衡量指标？
- 适用敏捷场景：不确定性（需求、范围 ~）
创建敏捷环境
- 敏捷思维模式开始
- 仆人式领导为团队赋权: 目的、人员、过程（不要计划遵循“完美”的敏捷过程，而是要注重结果。）
- 仆人式领导的职责： 促进作用、消除阻碍、为人贡献、考虑职责
- 敏捷中项目经理角色：有些未知、有些必要
- 项目经理：应用仆人式领导
- 团队构成: 敏捷团队、敏捷的角色、通才型专家、团队结构、 专职小组成员、工作场所、克服组织孤岛
解释：
《敏捷宣言》的价值观和原则的一个核心宗旨是强调个人和交互的重要性。敏捷优化了价值流，强调了向客户快速交付功能，而不是怎样“用”人。
克服组织孤岛:
- 来自不同职能部门、拥有不同技能的人
- 作为敏捷项目领导，首先要把重点放在如何组建跨职能团队，让所有团队成员 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
