《敏捷实践指南》读书笔记思维导图模板

引论

传统方法基于对未来的预测，敏捷方法关注适应变化的及时调整

敏捷不再只局限于软件开发

技术增长加速，价值交付趋紧

客户满意是第一原则

关注客户反馈

颠覆性技术正在破坏传统竞争壁垒

轻量型团队和组织显得更有威胁性

敏捷概述

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

确定的流程性工作vs不确定的探索性工作

高度不确定意味着变化、复杂和风险，难以预测

《敏捷宣言》及思维模式

价值观

充分考虑人的因素

重视结果胜于过程

换位思考

响应变化

并不是价值观中右边的不重要，而是左边的更重要

原则

客户满意

拥抱变化

短周期

跨职能合作

激发和信任

面对面沟通

可工作的软件

可持续的开发

技术卓越

简洁

自组织团队

回顾总结

敏捷是一种思维模式，并未在实践层达成共识

精益思想的具体实例

敏捷

看板

精益三原则

关注价值

小批量

消除浪费

精益与看板方法

践行敏捷的两种策略

正规方法

做适应性调整

不是为了敏捷而敏捷，而是为了向客户持续交付价值

精益思想是一个超集

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

不确定性的增加带来了风险和复杂性的增加

利用较少的工作增量验证自身的工作是否符合需求

STACEY矩阵

简单的Simple

需求低不确定性

技术低不确定性

繁杂的Complicated

需求低不确定性

技术高不确定性

需求高不确定性

技术低不确定性

复杂的Complex

需求较高不确定性

技术较高不确定性

混沌的Anarchy

需求高不确定性

技术高不确定性

动态调整

许多项目由开始的简单逐渐演变为复杂

从需求和交付两方面进行评估

小步迭代、快速试错

生命周期选择

项目生命周期的特征

预测型和敏捷代表两个极端情况，其中敏捷方法既有迭代又有增量

所有项目都具有需求、活动、交付和目标着几个特征，而不同项目的固有特征决定了其适用哪种方法

没有哪个方法完美适用于所有项目

预测型生命周期

团队领导的目标是尽可能减少变更

迭代型生命周期

迭代型方法需要更长时间来完成一次交付

为了学习而优化，而不是为了交付速度而优化

增量型生命周期

少量而频繁交付可以加快交付速度

更重视客户能尽早获得价值

敏捷生命周期

可有效应对不确定的需求，并快速交付用户价值

功能性的、提供价值的增量交付过程，即是客户满意度不断提升的过程

不同方法可以在整个项目中混合或结合，特别的，敏捷结合后的方法不能被称为敏捷，因为只是形式上的应用

局部应用敏捷或预测是一种在整体方法中植入部分针对性解决方案的做法

方法的取舍是为了创造价值、取得成功

为了敏捷而敏捷并不是目标

混合型生命周期可作为过度策略

混合敏捷方法

敏捷框架并不是针对团队定制的

混合敏捷方法能进一步提高整体效率

Scrum提供一些基础方法

Kanban实现流程管理

XP提高开发效力

……

影响裁剪的项目因素

针对不同项目特征裁剪敏捷实践来形成最优工作方法

实施敏捷：创建敏捷环境

从敏捷思维模式开始

仆人式领导为团队赋权

仆人式领导旨在为团队创造能够激发潜能创造高绩效的工作氛围

仆人式领导要实践并传播敏捷

结果胜于形式；经常交付完成的价值并反思，即为敏捷

仆人式领导并非敏捷所独有

敏捷团队信奉成长思维模式

项目经理的工作重点从“管理协调”转向“促进合作”

仆人式领导不是代替其他责任人做决策

仆人式领导更重要的职责是防止团队变得不敏捷

冗长的流程会造成瓶颈问题，正是它们阻碍团队快速交付价值

仆人式领导为团队铺路，让团队尽其所能

仆人式领导并不针对特定职务或岗位

敏捷项目工作中，项目经理不再是中心

团队构成

敏捷优化了价值流

促进合作

交付价值

减少浪费

与仆人式领导相对应的是自我管理的100%全职团队

团队试图解决所有的需求就会落入迷你瀑布的陷阱中

小增量交付利于试错和快速学习

敏捷团队的一个关键成功因素是强烈的产品责任感，即不为客户创造价值的工作都是浪费

成功的敏捷团队多由通才型专家组成

互相帮助是敏捷团队的常态

团队的目标是提高过程效率，优化整个团队的产能

分布式团队也是可行的

非专职小组成员会出现多任务处理和任务切换的问题

人们在一心多用的时候更容易犯错，至少大多数人如此

实际中，并不是所有团队都拥有自身所需的所有角色

尽可能创造在一起工作的条件，至少是相似的

拥有基本信任和安全的工作环境是组建敏捷团队的开端

警惕孤岛组织的形成

组建跨职能的全职团队是敏捷项目领导的首要任务

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

项目章程和团队章程

项目章程回答了

重要性

方向

目标

团队章程回答了

共同准则

对协同的理解

制定章程的过程是一个良好的协作开端

团队的社会契约，即团队章程，将规定团队成员之间彼此互动的方式

常见敏捷实践

回顾

回顾并不一定发生在迭代时，可以是任何关键时刻

回顾并不是责备，而是为了做出改进

对将要做的改进排序，每次完成力所能及的数量，并决定如何衡量结果

待办事项列表

待办事项列表是所有工作的有序列表

不必一次创建所有用户故事，只要确保下一个内容正确即可

代办事项列表细化

产品负责人组织会议来细化故事

细化有一个连续区间

基于流程的敏捷的即时细化

1小时的时间盒

基于迭代的敏捷团队的多次细化讨论

故事要足够小，小到便于团队能不间断地交付成果

时间多用于工作上而不是计划上

每日站会

每日站会上团队成员彼此做出小的承诺，发现问题，并确保团队工作顺利进行

每日站会上不解决具体问题

将注意力集中在团队的产出上

每日站会不应变成状态报告会

任何团队成员都可以组织站会

展示/评审

Dev Team展示，PO评审

使项目敏捷的一个基本要素是频繁地交付工作作品

规划基于迭代的敏捷

故事大小要适应团队的即时能力

敏捷团队在循环中重新规划更多的东西——在一个工作块中不会只计划一次

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

持续集成

在不同层面测试

验收测试驱动开发（ATDD）

测试驱动开发（TDD）和行为驱动开发（BDD）

刺探（时间盒研究或实验）

交付的第一部分是一次演示

解决敏捷项目的挑战

敏捷是为了解决具有

高变化率

不确定性

复杂性

奥卡姆剃刀，思考“最简单有效的方法是什么？”

敏捷项目的衡量指标

敏捷项目的衡量指标关注客户价值

敏捷团队的衡量结果

敏捷倾向于基于经验和价值的衡量指标

基准通常是尝试预测的产物，敏捷团队不会做过多长远的预测

敏捷并不能创造出更多的工作能力，只是提升工作效率

交付价值的同时进行学习

平衡不确定性的同时为客户提供价值

燃尽图和燃气图基于相同的数据，但分别以不同的方式显示

敏捷团队根据工作能力规划下一次交付内容

不同的衡量指标

交付周期

周期时间

响应时间

团队需要从每个迭代中获得反馈

不同的功能拥有独一无二的周期时间

衡量故事点时，衡量的是能力，而不是已完成的工作

功能图体现了过程中新出现的用户需求

敏捷中的挣值是基于已完成的功能

衡量挣值可以考虑使用燃起图

EVIM

SPI=完成的功能/计划的功能

CPI=挣值、实际成本

如果团队有大量进行中的工作，就会延迟整体功能的交付

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

组织变革管理

项目领导面对组织环境的挑战

组织动态变化难以再短时间发生，但可以被引导

与加速交付相关的变革和敏捷方法相关的变革会激励敏捷环境中变革管理实践的应用

变革开始前要考虑新旧方法之间的兼容性

既有的机构特征也可能成为组织敏捷变革的障碍

项目领导可以尝试多种方法来加速文化兼容性

组织文化

当文化和战略相遇时，则文化恒胜

组织文化是组织的核心标尺

安全、诚实和透明的环境中，团队才会真正进步

相关方的期望再被满足的过程中要明确优先级

了解环境的驱动因素是项目领导的关键动作

采购和合同

项目成功的一个关键是建立合作共赢的关系

将合同中的更多变化因素隔离到单独的文档中会简化修改该工作并提高灵活性

价值驱动可交付成果

项目可以将范围分解为总价微型可交付成果

固定时间和材料类似于总价合同，累进的时间和材料类似成本加酬金合同

商业实践

全方位供应商即为总承包模式，由总包方提供整体价值交付

组织创新能力的意愿和能力即组织敏捷性的标志

透明和开发协作至关重要

多团队协作和依赖关系

多个项目之间会产生依赖关系

关键成功因素是健康的敏捷团队

大规模敏捷项目的目标是协调不同团队的工作以便为客户提供价值

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

所有项目都应在合适的时间为合适的受众提供合适的价值

设置PMO的目的是引导组织实现商业价值

敏捷PMO可分为价值驱动型、面向创新型和多学科型

组织结构

组织结构会严重影响其转向新信息或转变市场需求的能力

组织演变

以累积方式承接工作来应对单个挑战领域或实施新的混合或敏捷方法

将变更过程视为一个敏捷项目

行动呼吁

有一个真理永恒不变，那就是：检查、适应和透明度是成功交付价值的关键因素

没有适应的检查只是浪费精力