【PMP】3.敏捷
敏捷概述
生命周期类型
- 预测型生命周期：范围明确、有厚实的经验基础、计划驱动，也叫瀑布型
- 混合型生命周期：可以实现预测向敏捷的过渡；可以在风险不大，具有中低程度不确定性的项目中尝试
- 敏捷（适应型）生命周期：快速应对变化，以较小的增量，快速迭代，每次增量都注重价值
MVP
定义
最小可行产品，符合产品预期的最小功能集合。在MVP的基础上继续快速迭代，直到产品稳定。
作用
- 快速试错
- 快速获取市场反馈
典型场景
- 不知道市场是否欢迎
- 不知道是不是客户想要的
- 时间比较紧或者预算有限的情况下需要发布产品
敏捷十二原则
敏捷宣言
- 个体以及互动胜过过程和工具
- 可用的软件胜过完整的文档
- 客户合作胜过合同谈判
- 应对变更胜过遵循计划
敏捷宣言和原则
- 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。（及早、持续不断、价值驱动交付、客户满意）
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（拥抱变更、提高客户竞争优势）
- 经常地交付可工作的软件，相间隔几周或一两个月，倾向于采取较短的周期。（频繁交付、短周期）
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。（业务和开发相互合作、每天如此）
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。（提供环境、支持团队、对团队辅以信任）
- 不论团队内外，传递信息效果最好效率最高的方式是面对面的交谈。（面对面沟通效果最好、也可使用虚拟沟通、鱼缸窗口、远程结对）
- 可工作的软件是进度的首要度量标准。根据可工作的软件度量
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（可持续开发、步调稳定）
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。重构
- 以简洁为本，它是极力减少不必要工作量的艺术。（简洁、专注目标）
- 最好的架构、需求和设计出自自组织团队。自组织团队
- 团队定期地反思如何能提高成效，并依此调整自身的行为表现。（定期回顾、不断改进）
Scrum
三个角色
-
产品负责人 (PO)
- 清晰描述产品待办事项列表 Product Backlog (PB)
- 对列表现项进行优先级排序
- 确保 PO 透明清晰
- 确保开发团队对列表是清晰的了解了
- 团队可以参与工作，但是最后还是由 PO 决定
- 改变 Sprint 的优先级都需要经过产品负责人
- 常见考点
- 需求不明确，可以和 PO 不确认（客户）澄清
- PO 是某个业务专家，但一般不会担任 Scrum Master 责任
- PO 决定接受或拒绝 Sprint 范围的增量
-
开发团队
- 由组织创建并得到授权
- 自组织：自主进行工作的估算，自主决定任务的分配，自行决定具体怎么分派，意味着执行层面的工作已作决定
- 跨职能：团队拥有创建产品的全部技能，理论人人一专多能，有 T 型协作，交叉培训机制
- 去中心化：不可以设经理，不需要向什么汇报，职称为开发人员，没有多个层级也不认可子团队（比如测试、架构师等）
- 组织稳定：一般 3-9 个人，以鼓励沟通，建议全职
- 主动学习：通常被挑战，主动要求增长
- 一般不能和 PO 和 Scrum Master，除非他们也参与到执行 Sprint 待办事项的工作
- 常见考点
- 自行决定任务的分配
- 自行决定用什么方式完成任务
- 负责所有估算工作
- 强调团队协作
-
Scrum Master
- 服务型领导（仆人式领导）
- 服务于产品负责人
- 确保团队理解目标
- 找到有效管理 PB 的技巧
- 确保产品负责人了解如何排列 PB
- 帮助理解并实践敏捷性
- 服务于团队
- 作为教练在自组织和跨职能方面给予指导
- 移除开发团队工作中的障碍
- 在 Scrum 还未完全采纳和理解的环境中，作为教练指导开发团队
- 作为场地教练组织讲授 Scrum
- 帮助每个人理解并实践 Scrum
- 引导整个团队，生产率的改变
- 确保组织内 Scrum 应用的有效性
- 服务于组织
- 作为教练指导组织采纳Scrum
- 帮助干系人理解并实施Scrum
- 引发提升团队生产率的改变
- 增强组织中Scrum应用的有效性
- 常见考点
- 仆人式领导提供协作和支持，而不是命令和控制
- 不会去分配任务，不会去下达指示
- 当 PO、团队成员被给予私人（比如管理层）不了解敏捷时要提供培训，服务于各方
- 当团队遇到障碍，应该帮助团队扫清障碍
三个工件
-
产品待办事项列表 PBL
- 涵盖产品的已知需求
- 包括所有的特性、功能、需求、增强 & 修复
- 按照优先级排序，优先级越高细节越详细
- 优先级较高的，可以交给开发团队去开始的用户故事应该符合就绪的定义 DOR (Definition of Ready)
- 由产品负责人 PO 负责
- 为当前 Sprint 挑选出的待办的事项
-
Sprint 待办列表
- 至少包括一项在前次回顾会议中确定的高优先级的改进
- 一个 Sprint 制定的所有待办事项的总和；以及之前所有 Sprint 还没产生的增量的价值和
- 必须达到“完成”的定义标准 DoD (Definition of Done)
- 无论产品负责人是否发布，增量必须可用
- 长度固定（一般 2-4 周）
-
增量
五个事件
-
Sprint
- 包括：Sprint 计划会、每日 Scrum 站会、开发工作、Sprint 评审会、Sprint 回顾会议
- 不能超过体育盒子 Sprint 持续时间，Sprint 周期理论上不变更
- 不能降低质量
- 产品负责人和团队之间可以对要做的事宜加以澄清
- 未完成的待办事项没都会返回到 PB 中，重新估算和排序
- 只有产品负责人有权取消 Sprint，但是由于 Sprint 期限短，取消的意义不大
-
Sprint 计划会议 (P)
- 计划 Sprint 要做的工作，整个 Scrum 团队共同完成
- 有时间盒限定：2 周的 Sprint，一般 4 小时；对于一个月的 Sprint，最长 8 小时
- Scrum Master 确保会议举行，每个参会者都理解会议的目的并使讨论按质提问
- 会议回答两个问题
- Sprint 要交付的增量包括什么？
- 如何完成这些工作所需做的工作？
- 在计划会议中确定 Sprint 目标
- 产品负责人解释最高价值的产品待办事项
- 开发团队自己决定选择产品待办事项的数量
- 开发团队决定如何完成所选的产品待办事项
- 开发团队可以邀请其他人员参加会议以获得相关的知识或建议
-
每日 Scrum 站会 (站会) (D)
- 借助检查检视距离 Sprint 目标的进度，检验 Sprint 待办列表的进度
- 时间盒限定为 15 分钟的事件，每天召开
- 会议的作用
- 做出决策，同步信息
- 减少其他会议
- 发现需要移除的障碍
- 提高跨职能团队认知程度
- 会议内容
- 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
- 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
- 是否有任何障碍阻碍我或帮助开发团队达成 Sprint 目标？
- 会上不讨论问题，会后可以进行更详细的讨论
- Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。
- 注意点
- 每日 Scrum 站会是开发团队的内部会议。
- 如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。
- 如果有很多敏捷团队为一个项目工作，需要召开 SoS 会议 (Scrum of Scrums)
- 三问并非硬性要求（推荐使用更加冲动的领域，如代码 git 状态、累积流图值、障碍板等等）
-
Sprint 评审会议 (C)
- 在 Sprint 快结束时举行，用以检视所交付的产品增量，并调整适应 PB
- 有时间盒限定：2 周的 Sprint，一般 2 小时；对于一个月的 Sprint，最长 4 小时
- 整个 Scrum 团队和干系人参加
- 评审内容
- 团队演示完成的项
- PO 说明哪些已经完成，哪些没有完成
- 参会的所有人就下一步工作进行探讨
- 评审接下来最有价值/最可能进入下一个 Sprint 的产品待办事项
- 评审会的结果是—份修订后的产品待办事项列表，表明可能进入下一个 Sprint 的产品待办事项
- 评审会之后，下一个 Sprint 之前
-
Sprint 回顾会议 (A)
- 团队检视自身，并创建一个 Sprint 改进计划的机会
- 有时间盒限定：2 周的 Sprint，一般 1-2 小时；对于一个月的 Sprint，最长 3 小时
- Scrum Master 应该确保接下来的 Sprint 中需要做出的改进
-
产品待办事项梳理会
- 逐渐细化用户故事，审查优先级等工作，一般不超过团队产能的 10% 的时间
五大价值观
- 勇气：有勇气做出承诺，履行承诺，接受别人的尊重
- 承诺：愿意对目标做出承诺
- 专注：把你的心思都用到你的承诺的工作上去
- 开放：Scrum 项目中的一切对所有的人
- 尊重：每个人都有其独特的背景和经验
看板系统
- 可视化管控
- 拉动式
- 消除瓶颈
极限编程
- 测试驱动开发 TDD：类似的还有验收测试驱动开发 ATDD，行为驱动开发 BDD
- 重构：解决技术债务
- 结对编程
- 代码集体所有权
- 持续集成
整合管理
- 团队自行决定计划及其组件的整合方式（自组织）
- 项目经理负责营造一个合作型的决策氛围
- 团队如果是T型人才有助于合作并解决知识孤岛
项目章程
- 为什么要做这个项目
- 谁会从中受益，如何受益
- 达到什么条件意味着项目完成
- 将怎么合作
范围管理
- 先为整个项目确定一个高层级的愿景
- 多次迭代开发可交付成果
- 每次迭代开始定义详细范围
- Sprint 计划会议
- Sprint Backlog
- 干系人持续参与
- 有目的地构建和审查原型
- 增量
- 每次迭代都会确认范围和控制范围
- Sprint评审会议
进度管理
- 具有未完项的进度计划
- Scrum
- 专注Sprint目标，不能做出有害于Sprint目标的改变
- 实践
- 按每周进度计划
- 看板
- WIP限制
- 消除瓶颈
- 看板
- 按每周进度计划
- 敏捷发布规划
- 产品愿景、产品路线图（高层级）
- 发布计划（高层级） 每个产品版本需要多少次迭代
- 迭代计划 Sprint中的详细用户故事
- 控制进度
- 燃尽图
- 燃起图
成本管理
- 轻量级方法生成高级别预测
- 详细的估算适用于采用准时制的规划
质量管理
- 完成的定义DOD
- 测试驱动开发、行为驱动开发、验收测试驱动开发
- 持续集成
- Sprint回顾会议
- 代码集体所有
资源管理
- 全员责任
- 集中办公
- T型人才
- 协作型团队
- 自组织任务分配
- 交叉培训
沟通管理
- 团队价值观
- 团队章程
- 工作协议
- DOR
- DOD
- 时间盒
- WIP
- 基本规则
- 团队规范
- 工作协议
- 透明、高效
- 信息扩散器（看板、燃尽图、燃起图、累积流图、障碍板）
- 面对面
- 虚拟沟通
- 鱼缸窗口
- 远程结对
- 多个敏捷团队沟通
- Scrum of Scrums(SoS会议)
- 追逐太阳
风险管理
- 经常审查增量，加快知识分享
- 在迭代规划的时候考虑风险，在迭代期间识别、分析和管理风险
- 根据风险敞口的理解加深，重新排列优先级
采购管理
- 客户协作高于合同谈判
- 灵活的协议
- 多层结构
- 主协议和补充文件
- 关注用户故事而非整个项目的预算
- 动态范围方案
- 提前取消方案
- 资助团队而非范围
干系人管理
- 频繁参与
- 高效透明的沟通
- 常见的干系人管理
浙公网安备 33010602011771号