第一章 基本概念
敏捷思维
- 价值驱动
- 适应变换
- 自组织团队
敏捷宣言/敏捷四大价值观/VUCA时代
- 个体和互动 高于流程和工具
- 工作的软件 高于详尽的文档
- 客户合作 高于合同谈判
- 响应变化 高于遵循计划
十二条敏捷原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欢迎需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。
- 经常地交付可工作的软件，相隔几星期或几个月，倾向于采取较短的周期。
- 业务人员和开发人员必须每天在一起工作。
- 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
- 在团队内部，传递信息效果最高效的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 对技术精益求精，对设计不断完善，将提高敏捷能力。
- 以简洁为本，极力减少不必要工作量。
- 最好的架构、需求和设计出自于自组织的团队。
- 团队定期地反省如何能提高成效，并由此调整团队的行为。
敏捷概念
- 敏捷最适合具有复杂要求和技术的项目
- 敏捷项目范围不固定，而时间和成本是固定的
- 敏捷使用自上而下的估计
- 敏捷文档通常勉强够用
- 敏捷有利于适应，而传统的管理方法有利于预期
- 敏捷挣值管理（EVM）用于价值跟踪报告，最好应用于迭代级别
Scrum三个角色
一、PO/Product owner/产品负责人，职责：
- 确定产品功能
- 决定发布日期和发布内容
- 对ROI负责
- 根据市场价值确定功能和优先级
- 每个Sprint前根据需要调整功能优先级
- 接受或拒绝DevTeam工作结果
- 维护PBI，对工作进行优先排序
- 听取收集各方信息，包括DevTeam意见
- 从客户角度及业务角度思考问题
二、SM/Scrum Master/敏捷教练，职责：
- 教练
- 权威专家
- 团队保护伞
- 障碍清道夫
- 变革代言人
三、DevTeam/开发团队/团队，职责：
- 定义DoD/Definition of Done/完成标准
- 分解工作任务
- 评估工作量
- 开发产品
- 确保质量
- 完善过程
- 团队学习
- DevTeam五大特点：
- 自组织
- 小规模（5~9人）
- CFT/Cross Function Team/跨职能团队
- 成员稳定
- 集体责任
- DevTeam六种特征：
- 任务自领
- 团队做技术决策
- 团队自己定准则
- 团队内透明
- 管理层指导方向
- 管理层不帮团队做决定
Scrum三大支柱
- 透明Transparency
- 检查Inspection
- 适应adaption
Scrum三大工件
- 产品待开发项/PBI/Product Backlog Items/PB列表/产品积压/积压
- 迭代任务/Sprint Backlog
- 增量交付物
Scrum五大仪式
- 迭代计划会/Sprint Planning Meeting
- 每日站会/Daily Meeting
- 迭代评审会议/Sprint Review Meeting
- 迭代回顾会议/Spring Retrospective Meeting
- 待办事项梳理/Grooming
第二章 敏捷项目管理架构
一、立项
1.1产品愿景：被客户定义和展示
- 设定产品目标
- 创建愿景基础草案
- 与干系人确认愿景声明
- 确定发布愿景声明
1.2 商业论证
- 商业需求
- ROI
- 论证项目合理性
- 宏观边界
- 风险
二、启动
2.1 敏捷项目章程：微章程
2.2团队宪章
- 愿景
- 协定价值观
- 建立项目社区
- 创建工作协议
2.3 人物角色/用户画像
作用
- 捕捉用户见解
- 发现正确故事
工具
- 虚拟任务
- 极端角色
2.4 创建初步的PBI
①用户故事/User Story：PO组织编写，客户可以参加
②用户故事核心
- 角色：谁要这个功能
- 功能：功能定义
- 价值：为什么要这个功能
③3C原则
- Card/卡片
- Conversation/对话
- Confirmation/确认/完成标准
④INVEST原则（对用户故事的要求）
- Independent/独立的
- Negotiable/可讨论的
- Valuable/有价值的
- Estimable/可估计的
- Small/小的
- Testable/可测试的
⑤PB列表/Product Backlog列表/产品代办事项列表
- PO维护，由用户故事组成
- 经过优先级排序和工作量评估
- 优先级越高，用户故事越细致
- 每个Sprint/迭代开始时，重新排定PB列表
- PB列表里都是客户想要的东西
- 不一定需要完整的PB列表才开始工作
⑥DEEP原则（对待办事项的要求）
- 详略得当/Detailed Appropriately
- 做过估算的/Estimated
- 涌现的/Emergent
- 排列优先级的/Prioritized
⑦影响地图：分析需求的工具
- 结构性
- 整体性
- 协作性
- 动态性
- 可视化
⑧相对估算：亲和估算
⑨产品Roadmap/产品路线：产品需求在时间轴上的总体视图
- 记录高层级目标
- 关注目标与收益
- 获得高度认可
- 动态文档
三、发布计划阶段
3.1拆分用户故事
3.2 定义DoD：
- 验收标准：针对单个需求
- DoD：针对所有需求
3.3 故事点估算
①故事点：敏捷估算时，用来计量工作量规模的单位
②故事点估算特点
- PO和SM不参加
- 准确而不精确
- 估算不是承诺
- 使用相对值
- 避免长时间讨论
③什么时候估算
- 第一个迭代开始前
- 迭代计划会议上
- 每个发布/迭代中做待办事项梳理的时候
④估算的工具
- 亲和估算：大小分类亲和，如果需要估算的故事多且团队掌握的信息还不够充分时，最好选择亲和估算，以快速得到估算结果，并且这时很难能得到比较精确的估算。
- 斐波那契估算：使用斐波那契数列估算故事点。
- 计划扑克：一种标有数字的扑克牌。计划扑克的目的是为了能够在一个尽可能短的时间内，让团队成员更加多的了解需要做的工作，同时顺带得到一个可接受的估算结果，一般推荐4到8人参与估算。
- 宽带德尔菲法： 一种生成估计的方法，涉及参与者之间比传统Delphi方法更多的交互和沟通。团队成员聚在一起演示用户故事，讨论面临的挑战，然后私下进行估算的一种估计技术。每个故事的估算结果都会被匿名标注在图表上，然后团队就故事点范围进行讨论，并尝试达成普遍共识。
⑤价值优先排序
- MoSCoW方法：Must have/必须有，Should have/应该有，Could have/可以有，Won't have this time/这次不会有
- Kano分析方法：基本需求＞期望型需求＞兴奋型需求
- 简单优先级排序：直接设置优先级
- 100点法：每个人总共有100点，分配给各个需求
四、迭代循环阶段
4.1 迭代0
- Spike/探刺：在短时间内，快速试验，发现问题解决或降低风险的办法
4.2 迭代
①迭代计划会议/Sprint Plan Meeting
- 做什么？PB列表，商业条件
- 怎么做？怎样实现迭代目标，创建迭代待办事项/Sprint Backlog，定义DoD
团队速率：一个迭代中完成的故事点数；获得速率的方法：历史数据，真实测算，团队估算；团队速率在不同迭代中应保持稳定。
迭代计划会议特点：
- 从第一个PBI开始讨论
- PO可以不参加
- 只有DevTeam才能定解决方案
KanBan/看板方法：用于跟踪在制品/WIP/Work In Process的系统，是一种信息发射源
②每日站会/Daily Meeting
- 昨天完成了什么
- 今天计划完成什么
- 有什么困难
敏捷监控指标：
- 燃尽图/Burndown Chart：直观得展现项目总体进度。它展示了时间和项目剩余总体工作量间的关系。燃尽图是在项目完成之前，对需要完成的工作的一种可视化表示；
- 燃起图/Burnup Chart：它能够直观展现项目时间与已完成的工作间的关系的一种图表，根据每天完成的story情况动态展现工作成果的曲线。
- 累计流量图：一个实践工具，可以帮助我们看到WIP的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈
- little/利特尔法则：在一个稳定的系统中，长期的平均顾客人数，等于长期的有效抵达率，乘以顾客在这个系统中平均的等待时间
③迭代评审会议/Sprint Review Meeting
目的：
- 产品第二个检视和适应点
- 敏捷团队在会议中向最终用户展示工作成果
- 获得反馈，并以之创建或变更Backlog条目
参加成员：PO，SM，DevTeam，客户，其他干系人
④迭代回顾会议/Sprint Retrospective Meeting
- 总结做的好的，做的不好的，提升下次迭代效率，持续改善
第三章 其他敏捷方法
极限编程XP
- 以客户需要的软件为目标
- 有效相应变变化，哪怕是在后期
- 人与人合作，利用优点
- 文档、架构不如直接编程
- 提倡的做到最好，不提倡的一概忽略
- 结对编程
- 测试驱动开发TDD
水晶方法
- 经常交付
- 渗透式交流
- 反思改进
- 个人安全
- 持续集成
DSDM/Dynamic System Development Method
- 时间是固定的，功能和资源可以进行规划
精益
- 消除浪费
- 强化学习
- 尽晚决策
- 尽快交付
- 授权团队
- 构建完整，建立统一
- 全盘检视，了解整体
第四章 特殊概念
- 史诗故事/Epic Story： 史诗般的故事是大型用户故事，可以分解为较小的用户故事，可以在产品backlog的底部找到
- 所见即所得/IKIWISI , I know it when I see it：这是普通客户的典型，他们需要直观感受产品以挖掘自身的需求。
- 信息发射源/Information Radiator：显示项目进度和状态的高度可见的图表和数字，例如看板，燃尽图。
- 最小化可交付的特性/MMF：为最终用户提供价值的最小功能集. 一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护，（很像Scrum中的产品Backlog），但对队列的大小有严格的限制（James认为应该是两到三个，最多七个）。
- 渗透式沟通：通过无意间听到其他人之间的对话而无意中获取有用的信息，当一个人提问时，房间内的其他人可以选择听或者不听——参与讨论或者继续工作。
- 帕累托原则： 也称为80-20规则指出，对于敏捷项目，80％的最有用的功能可以在20％的努力中完成，强烈建议关注“20％”
- 精益投资组合管理：选择项目以最大化投资回报的方法
- 参与式设计：通过积极让利益相关者参与设计过程来确保结果符合预期的设计方法。
- 项目章程对于敏捷项目和传统项目都很重要，必须在敏捷项目开始时创建。
- 重构：在不改变行为或效率的情况下提高代码质量
- 故事地图/Story Maps显示每个版本中用户故事/史诗的分类方式：
- 主线：基本功能
- 行走的骨骼：最小的功能集
- 附加功能：其他功能
- 技术债/Technical Debt：
- 技术债务 ：包含代码，技术文档，开发环境，第三方工具和开发实践方面的缺陷，这使得团队难以更改代码
- 通过简化或优化设计来降低技术债务可以提高生产率，从而提高速度
- 从理论上讲，XP项目不会产生技术债务，因为重构是一只进行的。
