PMP敏捷项目管理

PMP敏捷项目管理知识点总结，结合考纲，梳理了PMP考试中有关敏捷部分的重要知识点，欢迎各位学友交流指导。

PMP敏捷项目管理

• 背景（VUCA时代新挑战）
  • 1. Volatility 易变性
  • 2. Uncertainly 不确定性
  • 3. Complexity 复杂性
  • 4. Ambiguity 模糊性
• 基础知识
  • 灵魂
    • 敏捷宣言
      • 1. 个体和互动 高于 流程和工具
      • 2. 工作的软件 高于 详尽的文档
      • 3. 客户合作 高于 合同谈判
      • 4. 响应变化 高于 遵循计划
    • 敏捷原则
      • 1. 持续交付，小步快跑
        • 迭代
      • 2. 拥抱变化，提高优势
      • 3. 尽早反馈，价值排序
        • Backlog 待办项
      • 4. 成果达成，衡量进度
        • DoD、AC、DoR
      • 5. 持续更新，强化敏捷
        • 培训
      • 6. 精简产品，杜绝浪费
        • MVP
      • 7. 团队合作，每日互动
        • 站立会
      • 8. 信任成员，给与支持
        • 私下
      • 9. 当面沟通，高效明了
        • 面对面
      • 10. 各方成员，稳定节奏
        • 全职、不换人、速度不变
      • 11. 同心协力，自我组织
        • 团队章程下自组织
      • 12. 团队自省，持续改进
        • 反思会/回顾会
  • 角色
    • Team（跨职能团队）
      • 1. 人数3-9个
      • 2. 团队成员跨职能，鼓励T型人才
      • 3. 成员需要全职，至少迭代内不能随意发生变化
      • 4. 在团队章程/迭代待办列表约束内有权力做任何形式的决策
      • 5. 高度的自组织能力
      • 6. 需要向Po演示产品功能
      • 7. 团队需要定义DoD
    • Po（产品负责人）
      • 1. 确定产品功能
      • 2. 决定发布日期
      • 3. 确定用户故事优先级
      • 4. 为产品ROI负责
      • 5. 每个迭代/冲刺前，根据需要调整功能和优先级
      • 6. 接受或拒绝开发团队的工作成果
      • 7. 作为客户的代言人，接收不同的需求和反馈，不断梳理待办项清单
    • Team Facilitator（团队促进者）
      • 不同组织内的称谓
        • 1. Scrum Master
        • 2. Team Leader
        • 3. Project Manager
      • 团队促进者
        • 1. 倡导仆人式领导
          • 1. 提升自我意识
          • 2. 倾听
          • 3. 为团队服务
          • 4. 帮助他人成长
          • 5. 引导与控制
          • 6. 促进安全、尊重和信任
          • 7. 促进他人精力和才智提升
        • 2. 更像是守望者，不做决策，而是提供支持
        • 3. 及时地为团队成员提供帮助
        • 4. 提供相应的培训和指导
        • 5. 保证良好协作
        • 6. 解决团队开发中的障碍
        • 7. 处理外界对团队成员的干扰
        • 8. 组织各种会议
    • 治理团队
    • 敏捷PMO
      • 目的
        • 引导组织实现商业价值
      • 类型
        • 1. 价值驱动型
        • 2. 面向创新型
        • 3. 多学科型
      • 职责
        • 1. 制定和实施标准
        • 2. 通过培训和指导发展人才
        • 3. 多项目管理
        • 4. 促进组织学习
        • 5. 管理相关方
        • 6. 招聘、筛选和评估项目领导
        • 7. 执行专业化项目任务
  • 方法
    • 看板
      • 1. 信息发射源
      • 2. 可视化：展示项目情况，透明各方信息
      • 3. 确保工作流和价值交付的持续性
      • 4. 包含：要完成的工作、进行中的工作、已完成的工作
      • 5. 遵从“在制品”（WIP）限制：完成工作比开始新工作更重要
    • 极限编程
      • 1. 轻量级开发流程
      • 2. 客户与开发人员face-to-face
      • 3. 实践
        • 3.1. 持续集成
        • 3.2. 结对编程
        • 3.3. 验收测试驱动开发
        • 3.4. 测试驱动开发
        • 3.5. 刺探（探针）
    • Scrum
      • 2个待办项backlog
        • 1. 产品待办项
        • 2. 迭代待办项
      • 3类人员
        • 1. Scrum主管（项目经理）：负责维护过程和任务
        • 2. 产品负责人Po：代表利益所有者
        • 3. 开发团队：包含所有开发人员
      • 4个会议
        • 1. 迭代计划会
        • 2. 每日站会
        • 3. 迭代评审会
        • 4. 迭代回顾会（反思会）
    • DSDM
      • 时间盒Time Box
        • 价值
          • 1. 帕金森定律的一剂良药
          • 2. 尽早促成难度大的决策和权衡
          • 3. 更好的控制
          • 4. 防止镀金
        • 运作规则
          • 1. 在每个时间盒过程中不要增加人员
          • 2. 时间盒不用来做绩效考核
          • 3. 时间盒内不许有变更
          • 4. 每日同步
    • 追逐太阳模式
      • 每天结束时将工作移交给下一个工作地点
    • 鱼缸窗口模式
      • 1. 各个地点之间建立长期视频会议链接
      • 2. 每天工作开始时打开链接
      • 3. 工作结束时关闭连接
    • 远程结对模式
      • 两名人员结对从事同一项工作，通过工具共享屏幕
    • 水晶方法
      • 使用三个因素确定项目的正确方法
        • 参与人数
        • 项目关键性
        • 项目优先级
  • 过渡
    • 混合生命周期应用场景
      • 1. 组织不能完全敏捷
      • 2. 敏捷过渡期
      • 3. 加速预测生命周期交付速度
      • 4. 改变团队成员思维模式
    • 敏捷转型成功的策略
      • 1. 增加更多的迭代技术促进学习
      • 2. 增加更多的增量技术加快对发起人的投资回报
      • 3. 先在一个风险不大、具有中低程度不确定性的项目中尝试新技术
      • 4. 通过组织成功的使用混合方法后，在尝试更复杂的敏捷项目
• 全过程实践
  • 事情的方向--产品愿景
    • 电梯测试法
      • 1-2分钟介绍自己的产品，引发兴趣
    • 愿景盒子
      • 1. 展示项目特性及其带来的好处
      • 2. 有名字和品牌
      • 3. 包括操作指南
  • 事情的节奏--产品路线图
  • 人的要求--敏捷团队章程
    • 1. 仆人式领导，与团队一起决定
    • 2. 目标是创造一个敏捷的环境，团队成员可以发挥最大能力
    • 3. 主要内容
      • 1. 团队价值观：可持续的开发速度和核心工作时间
      • 2. 工作协议
        • 1. 如何定义“就绪”是团队可以接受工作的前提
        • 2. 如何定义“完成”团队才能一致判断完整性
        • 3. 考虑时间盒
        • 4. 使用工作过程限制
      • 3. 基本规则
      • 4. 团队规范
  • 用户故事
    • 1. 颗粒度：用户故事——特性——史诗
    • 2. 标准语法：作为，可以，以便
    • 3. INVEST原则
  • 产品待办列表Backlog
    • 内容
      • 1. 是一个排序的列表
      • 2. PO负责内容、可用性、优先级
      • 3. 永远是不完全的
      • 4. 是动态的
    • DEEP原则
      • 1. 详略得当
      • 2. 被估算的
      • 3. 动态发展
      • 4. 排列优先级
    • 输出PBL的原则
      • 1. 团队成员首先要考虑做Demo
      • 2. 一个sprint内不做调整
      • 3. 本周期的bug不一定要在这个周期处理完，取决于bug的优先级，需要和PO确认
      • 4. Product Backlog 兼顾设计和要求
      • 5. Sprint Backlog 兼顾计划和设计
  • 每日站立会（每日Scrum会）
    • 1. 每天同样的时间和地点
    • 2. 一般15分钟
    • 3. 只有团队成员可以发言
    • 4. 其它人员可以参加，但只能旁听
    • 5. 所有成员轮流回答三个问题
      • 昨天完成了什么
      • 今天打算做什么
      • 在工作中遇到了什么困难和障碍
    • 6. 可以使用Scrum任务板展示进度
    • 7. 可以展示燃尽图/燃起图
    • 8. 有可能涉及任务在拆分
    • 9. 强调准时
    • 10. 不要在展会上花费过多时间解决问题
  • 迭代会
    • 迭代计划会
      • Part 1
        • 1. PO向团队介绍整体产品规划，优先级排序方法
        • 2. 团队成员尽可能提问问题
        • 3. 与PO确认验收标准
        • 4. 多关注商业价值及其由来
        • 5. 不过分考虑设计的问题
        • 6. 确认是什么，不是什么
        • 7. 确认异常场景
      • Part 2
        • 1. 将用户故事拆解为任务，制作冲刺待办项
        • 2. PO全程参加
        • 3. 团队成员共同估算
        • 4. 估算不要过细
        • 5. 任务要落实到人
        • 6. PO负责估算过程中与需求有关的问题，但不能干预估算结果
        • 7. 文档任务的管理也要做估算
      • 具体操作步骤
        • 1. 确认问题
          • 确认story优先级
            • 价值期望度
            • 成本
            • 行业和技术
            • 风险
          • MoSCoW原则
          • 风险与价值的关系
            • 首先处理：高风险高价值
            • 其次处理：低风险高价值
            • 最后处理：低风险低价值
            • 避免：高风险低价值
        • 2. 拆分故事
          • 何时做拆分
            • 一个故事的大小超过一个迭代
            • 一堆故事的排列超过一个迭代，需要拆分某个故事
        • 3. 估算故事
          • 故事点
            • 1. 规模的相对度量
            • 2. 不能同其他项目比较
            • 3. 有助于跨职能驱动
            • 4. 故事点不会过期
            • 5. 纯粹对规模的度量
            • 6. 通常更快
          • 理想日
            • 1. 实际时间与理想时间的区别
            • 2. 更容易解释
            • 3. 更容易开始
        • 4. 确认目标，制作冲刺待办项
          • 要点一
            • 1. 确保优先级相符，可使用MoSCoW原则
            • 2. 每个队员都要参与
            • 3. 讨论每一个用户故事该如何实现how
            • 4. 确定开发任务之前，对完成的标准有明确定义
            • 5. 标识出所有需要完成的任务
          • 要点二
            • 1. 不要事先将任务分配给个人
            • 2. 重新审视sprint承诺
            • 3. 不要使用过多的时间
            • 4. 简单开发项目，可以直接将story放进SBL
            • 5. 复杂项目开发一定要分解任务
    • 迭代评审会
      • 1. Team向PO演示开发的产品功能
      • 2. PO组织会议并邀请干系人参与
      • 3. 通过现场演示的方式
      • 4. 不需要太正式
      • 5. 不一定需要PPT
      • 6. 一般控制在2小时
      • 7. 属性判断，而非变量判断
      • 8. 如果用户故事没有通过,PO判断优先级，确定在第几个冲刺完成
    • 迭代回顾会
      • 1. 也称反思会
      • 2. 目的是总结经验教训，便于进一步解决问题
      • 3. 可以使用鱼骨图、卡片法
      • 4. 汉堡包原则：先表扬在批评再给解决方案
      • 5. 对于变更的评价：反思为何变，如何避免
      • 6. 对于没完成的用户故事评价：什么原因没完成
      • 7. 一件事法则
• 敏捷工作过程中的应用
  • 整合
    • 1. 迭代和敏捷方法能促进团队成员以相关领域专家对的身份参与整合管理
    • 2. 团队成员自行决定计划
    • 3. 项目经理关注营造合作型的决策氛围
    • 4. T型人才
  • 范围
    • 1. 在整个项目期间逐渐明确
    • 2. 在整个项目期间被定义和再定义
    • 3. 把需求列入待办项backlog
  • 进度
    • 1. 采用短周期开展工作
    • 2. 针对可交付成果的适用性提供快速反馈
    • 3. 可能同时存在小规模项目和大规模举措
    • 4. 混合
    • 5. 项目经理角色不变，但需要了解更多的工具和技术
  • 成本
    • 1. 高层及预测--轻量型估算
    • 2. 短期规划--详细估算
  • 质量
    • 1. 整个项目期间频繁开展质量与审核步骤
    • 2. 循环回顾，定期检车质量过程效果
    • 3. 寻找问题的根本原因，建议实施新的质量改进方法
    • 4. 频繁增量交付，关注小批量工作
    • 5. 在早期发现不一致和质量问题
  • 资源
    • 1. 拥有通才的自组织团队
    • 2. 协作型团队
    • 3. 快速供应和经乙方法定的协议
  • 沟通
    • 1. 更频繁和快速沟通
    • 2. 尽量简化团队成员获取信息的通道，并让团队集中办公
    • 3. 以透明的方式发布项目工作，并定期邀请相关方评审项目工作
  • 风险
    • 1. 在选择每个迭代期内的工作内容时，应考虑风险
    • 2. 风险事件放入待办项
    • 3. 风险应对方案和需求放在一起共同排列优先级
  • 采购
    • 1. 买方和卖方共担项目风险，共享项目奖励
    • 2. 通过主体协议管辖整体协作关系，将适应型工作写入附录或补充文件
  • 相关方
    • 1. 直接与相关方互动
    • 2. 组织内部和组织之间信息分享，高度透明
    • 3. 邀请所有相关方参与项目会议和审查