敏捷专题
敏捷专题
author: chengyd date: 2023-07-11
1 敏捷概述
1.1 什么是敏捷
敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。
敏捷思维模式由价值观定义，以原则为指导，并在许多不同的实践中体现。
1.2 为什么要用敏捷
VUCA 时代（volatile，uncertain，complex，ambiguous）：易变不稳定、不确定、复杂和模糊
更需要：
Vision（愿景）：找准核心靶点 Understanding（共识）：上下同欲，战无不胜 Courage（勇气）：改变与试错的勇气 Adaptability（适应）：快速行动，持续迭代
1.3 敏捷的好处
快速交付、降低风险、适应变化、质量更好、持续改进、满意度高
对组织：提高了管理变更的能力、加快了软件的交付、提高了团队生产力
1.4 生命周期的选择
1.5 混合型生命周期
混合型生命周期是预测性生命周期和适应型生命周期的组合或者不同敏捷方法的混合。
许多团队无法在一夜之间切换到敏捷工作方法，可以用混合作为过渡。
例：
- 分阶段混合型生命周期： 预研阶段敏捷，开发阶段瀑布
- 分子项目混合型生命周期： 软件子项目敏捷，硬件子项目瀑布
1.6 敏捷与传统相比
- 传统：文档驱动、过程监控
- 敏捷：价值驱动
瀑布：从计划中估算成本与进度；敏捷：从发布规划与预期功能估算成本与进度
敏捷三角形：
- 价值：外在质量（可发布的产品）
- 质量：内在质量（可靠的、适应性强的产品）
- 约束：成本、进度、范围（在可接受的约束内）
1.7 敏捷开发特性
一切从客户出发，一切从价值出发，精益思维，持续改进
- 精益思维，最小 MVP
- 固定时间盒，价值导向
- 拥抱变化，不怕变更
MVP（Minimum Viable Product）：最小可行产品
以最小成本打造出“可用”且“能表达出核心理念”的方案版本，使其功能“极简”但能够帮助我们"快速验证应对新变化的构思。 MVP 是验证假设的试验品，类似于原型，MVP 可以帮助敏捷团队以最小成本试错。
2 敏捷思维
2.1 敏捷宣言
我们一直在实践中探寻更好的 软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：
- 个体与互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
2.2 敏捷 12 原则
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人. 开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构. 需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
2.3 总结
- 一个好的敏捷团队是要整合所有价值观和原则， 而不是从中寻找几个进行实践。
- 整合这些实践的关键在于团队的思维方式，敏捷的价值观和原则是思维背后的功力和源泉。
- 敏捷团队不仅要诚实的回顾开发软件的方式，同时还要多回顾成员交流的方式，以及与公司其他同事交流的方式。
- 首先要理解原则，然后理解其中的原理，还要在工作中不断的评估和改进，最后融会贯通，学以致用。
3 敏捷环境
3.1 仆人式领导
敏捷教练，也称作项目经理、Scrum 主管、项目团队领导、团队教练或团队促进者。
职责：
- 促进作用工作重点从“管理协调”转向“促进合作”
- 消除组织障碍
- 为他人贡献铺路
- 教育相关方
一般不做决定。敏捷教练鼓励团队成员自行解决问题，但在被求助时、团队违反敏捷时、不会用敏捷工具、冲突自行解决无效时，敏捷教练会出来解决问题。
3.2 自组织团队
3.2.1 自组织团队属性
由外部创建，给予授权，自主决策
5-9 名，100% 专职成员，通才型专家
集中办公（首选）与虚拟办公
3.2.2 团队章程
团队章程将规定团队成员之间彼此互动的方式。目标是创建一个敏捷的环境。
包含团队价值观，工作协议，基本规则，团队规范。
制定团队章程是一种很好的开始工作的方式
3.2.3 自组织式管理
用户、业务直接驱动， 无微观管理，团队目标驱动，自动自发
3.2.4 自组织团队特点
跨职能团队
团队是一个整体
集体目标
成员相互承诺
成员相互学习
绩效集体负责： 以基体为单位进行绩效评估，运用燃尽图及速率
真实可用的成果是最好的绩效考核指标 每日都考量 关心剩余的工作量 保持更新与可见性
提倡高效沟通
面对面交流：面对面的沟通最有效
渗透式沟通：没有直接关注的情况下获取到的信息，进一步降低思想传递的成本
分布式团队善用工具：
通过在团队分布的各个地点之间建立长期视频会议链接，创建一个鱼缸窗口 使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结对
开放的环境
- 透明、信任
- 提倡集中办公
- 个人空间、团队共享空间
- 信息发射源
4 Scrum 敏捷方法
4.1 Scrum 是什么
Scrum 是一种 “敏捷实践框架”。
Scrum：英式橄榄球比赛中的并列争球。团队成员就如同橄榄球队员一样协同工作以获得对球的控制并将球送往目标区，相互协同工作来提交产品。
特点：自组织、跨职能的团队，以“Sprint”为周期的产品开发，以一系列“产品 Backlog”记录了产品需求，强调在敏捷开发环境交付产品，集中办公。
4.2 Scrum 的 3 个角色
| 角色 | 名称 | 职责 |
|---|---|---|
| Product Owner | 产品负责人 | 对接客户 管理产品待办事项 鉴定“已完成的用户故事” |
| Scrum Master | Scrum 教练 | 帮助团队掌握 Scrum 价值观与框架 帮助团队排除影响生产力的障碍 保护团队不受打扰 |
| Development Team | 开发团队 | 按照 Scrum 框架工作，对交付成果负责 能够跨职能工作，自组织、自管理 一起为 Sprint 创建计划，即 Sprint Backlog 通过遵循 Definition of Done 来保证质量 |
4.3 Scrum 的 3 个工件
4.3.1 3 个工件
| 工件 | 负责人 | 内容 | 要求 |
|---|---|---|---|
| 产品待办事项列表（Product Backlog） | PO | 包含业务需求、技术需求、NFR 等 每一个待完成的工作都将产生客户价值 PO 负责对该列表按优先级排序 待办事项列表中的条目以用户故事的形式呈现 | 粗细得当 估算过的 涌现式的 排好优先级的 |
| 迭代待办事项列表（Sprint Backlog） | 团队成员 | 将用户故事拆分成任务，团队成员主动领取任务 团队成员可以添加、删除或者更改迭代中的任务 迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新 | |
| 完成定义（Definition of Done） | 团队和 PO | 基于"随时可向用户发布"的目标，制定衡量团队工作是否已完成定义的标准 由团队和 PO 达成共识 | 团队自协商 有层次：发布级、迭代级、每日级、故事级 |
4.3.2 敏捷场景下的变更
新需求先进入产品待办事项列表，由产品负责人而根据轻重缓急确定优先级，在下一个冲刺（Sprint）的计划会上讨论是否进入冲刺待办事项列表（Sprint Backlog）。原则上，冲刺周期之内不可变更
4.4 Scrum 的 5 个事件
| 事件 | 内容 | 参与人 |
|---|---|---|
| 冲刺计划会（Sprint Planning） | 1 至 4 周的 Sprint，计划会在 2 至 4 小时内 生成 Sprint 待办列表 | SM DT PO |
| 每日站会（Daily Scrum Meeting） | 15 分钟 上次站会到现在，完成了哪些任务 今天到下次站会之间，将要完成哪些任务 有什么问题需要帮助或者有什么可以分享 | SM(可选) DT PO(可选) |
| 冲刺评审会（Sprint Review） | 大约 2 小时 演示工作成果 收集反馈 产品负责人根据预先定义的验收标准接受或拒绝团队的工作成果 客户不一定会参加，但是产品负责人一定要参加 | SM DT PO，其他相关方(可选) |
| 冲刺回顾会（Sprint Retrospective） | 1 至 3 小时 回顾我们哪些做的好、或不够好，列出我们哪些方面可以提升 | SM DT PO |
| 产品待办梳理会（Backlog Refinement） | 不超过 Sprint 中开发时间的 10% 为即将来到的 Sprint 做准备 确保优先级高的工作项 | SM DT PO |
冲刺（Sprint）：
- Scrum 的核心，所有创意（idea）在这里转化为价值
- 固定时长的事件，小于一个月，1-4 周
- 可使用各种实践来预测进展，例如，燃尽图、燃起图等
- 仅有 Product Owner 可以取消 Sprint
优先级排序：莫斯科法则
卡诺模型
4.5 Scrum 的 5 项价值观
勇气、专注、承诺、尊重、公开
5 Scrum 管理流程
5.1 敏捷项目管理架构（APMF）
- 立项：建立愿景，商业论证
- 启动：项目章程，团队规则，人物角色，初步的 Backlog，高层次的估算，产品 Roadmap，用户故事地图
- 发布计划：用户故事分解，估算，定义 DoD，发布 Backlog
- 迭代：迭代 0 与 spike，Sprint 的特点与探讨，迭代计划会议，任务板，每日站会，迭代评审会议，迭代回顾会议
- 收尾：项目回顾会议，感恩游戏，总结经验教训，成果交接，文档归档，行政收尾
5.2 Scrum 框架
5.3 敏捷发布规划
5.4 Scrum of Scrums
- Scrum of Scrums（SoS）是由两个或更多 Scrum 团队所使用的一种技术
- 每个团队代表会定期和其他团队代表开会沟通
- 大型组织、团队可能需要执行 Scrum of Scrum of Scrums
6 用户故事
6.1 用户故事
描述需求的一种规范化表达形式，从用户或客户的角度对某个特性进行简短的描述。
3W 构成要素：
- 角色（Who） ：为谁做，谁要用
- 活动（What）：做什么，要完成什么需求、任务
- 价值（Why） ：为什么要做，做了能带来什么价值
3C 制定原则：
- 卡片（Card）：用户故事概述一般写在纸质卡片上，卡片正面写故事的简短描述，背面写规则、验收标准等。
- 交谈（Conversation）：用户故事背后的细节源于与客户或者产品负责人的交流，确保各方对故事的理解准确一致。
- 确认（Confirmation）：用验收标准来测试确认用户故事是否被正确完成。
属性：
- 独立的
- 可讨论的
- 有价值的
- 可估算的
- 小的
- 可测试的
6.2 用户故事拆分
拆分注意事项：
- 拆分故事不仅是要使故事变小， 而且还要拆分低价值、高投入的部分， 以便它们可以沉在待办事项底部。
- 拆分故事是迭代的，并且没有固定的迭代次数， 因此定义固定的层次结构“史诗/功能/故事/其他”不是必要的。
- 故事多小取决于你的团队是否满意。
- 故事应 “及时”拆分， 但只有在进行足够的分析以便充分理解故事后， 才能进行。定期重新确定优先级。
- 故事应垂直分割， 即将用户目标分解为子目标。
- 故事拆解很难！
6.3 用户故事估算
敏捷通过故事点来估算工作量的规模（大小），故事点是一个相对值。
通常使用的方法：Fibonacci、Powers of 2、计划扑克
6.4 用户故事地图
是一个用户故事网络，是一种有效的需求工具，强调以合作沟通的方式来全面理解用户需求，通过一系列对话迭代完成。
作用：了解整个产品的全貌，找到整个产品的主干，促使产生更多用户故事
6.5 速度/速率
速度，即本次迭代中实际完成功能的故事点大小的总和， 让团队得以通过观察历史表现来更准确地规划下阶段的能力。
敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标。敏捷衡量团队所交付的成果，而不是团队预测将交付的成果。在不同的敏捷团队中横向比较速度是不明智的。
速度的变化应该是连续一致且稳步上升的。
7 Kanban 管理方法
7.1 看板
尊重现状，从现状开始的增量式、渐进式地改进方法
看板方法的原则：
- 从现有的工作方式开始
- 实施渐进式变革
- 启动时，尊重现有的角色、职称和工作职责
- 鼓励各级领导力
瓶颈：
- 识别瓶颈
- 决定如何最大化地利用瓶颈资源
- 所有其他活动服从于第二步的各种措施
- 提升瓶颈的效能
7.2 Scrum 与看板
信息发射源：
用可视化的形式展示项目当前状态的一种方法，于团队及干系人快速了解项目当前的状态。
7.3 其他敏捷方法
8 敏捷转型
8.1 敏捷转型
变革友好型特征：管理层的变革意愿；
推动组织进行敏捷转型：
- 积极明确的管理层支持；
- 逐个项目应用敏捷实践；
- 向团队增量地引入敏捷实践；
- 通过采取适用的敏捷技术和实践示范引导。
8.2 敏捷合同/协议
