PMP敏捷管理模型知识点

针对敏捷模型的知识点梳理，PMP考试敏捷考点梳理，让每个人从忙忙碌碌中解脱出来，达到事半功倍之功效。

敏捷模型知识点

• 1. 重要性
  • pmp考试占比42%
• 2. 敏捷知识点金字塔
  • 思想
    • 敏捷核心思想和原则
  • 人员
    • 敏捷组织打造
  • 流程
    • 技术、流程、工具
  • 主要考点
  • 组织转型
    • 敏捷转型、持续改进
• 3. 敏捷概念
  • 项目四种生命周期
    • 预测
      • 一次交付，最终返工风险较大
      • 需求不经常变、交付时间限定不死
    • 迭代
      • 适应客户变化、一次交付
    • 增量
      • 快速上线占领市场、可能大量返工
    • 敏捷
      • 又名适应性生命周期
      • 融合增量和迭代的优势
      • 可以适应客户多变的环境，用小迭代方式收获客户反馈
      • 小迭代可以上市
      • 快速适应变化、快速上市
  • 敏捷宣言四大价值观
    • 个体与交互重于过程和工具
    • 可用的软件重于完备的文档
    • 客户协作重于合作谈判
    • 响应变化重于遵守计划
  • 敏捷管理核心
    • 以人为本
    • 交付价值
    • 拥抱变化
    • 持续改进
  • 十二原则
    • 原则1：我们的最高目标是通过尽早持续交付有价值的软件来满足客户的需求
    • 原则2：可用的软件是衡量进度的首要度量标准
    • 原则3：要经常交付可用的软件，周期从几周到几个月不等，且越短越好
    • 原则4：对技术的精益求精以及对设计的不断完善将提高敏捷性
    • 原则5：简洁，即尽最大可能减少不必要的工作，这是一门艺术
    • 交付价值
    • 原则6：敏捷过程是提倡可持续的开发。项目发起人、开发人员和用户都能够始终保持步调稳定
    • 原则7：项目实施过程中，业务人员与开发人员必须始终通力协作
    • 原则8：善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
    • 原则9：无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
    • 原则10：最佳的架构、需求和设计将出自于自组织团队
    • 以人为本
    • 原则11：欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
      • 拥抱变化
    • 原则12：团队要定期反省怎么做才能更有效，并相应地调整团队的行为
      • 持续改进
• 4. 敏捷人员角色
  • 产品负责人（PO）
    • 理战略：制作产品路线图
    • 定需求：增加、调整用户故事、根据商业价值对用户故事进行排序
    • 做验收：项目成果的评审反馈
  • Scrum Master（团队领导）
    • 保护：保护团队不被中断
    • 保障：移除障碍
    • 保持：通过项目和团队章程，保持持续引导项目愿景
    • 保姆：为团队提供支持
  • 团队
    • 虚拟团队：沟通规划最重要。要考虑让团队成员定期聚集一堂，以便建立信任，学习怎样开展合作，并用鱼缸窗口和远程结对提高沟通
    • 工作区域：私人区域和公共区域
    • 渗透式沟通：信息在互相搭配工作的团队成员之间无意识地进行共享
    • 全职的、通才、跨职能、自组织团队，团队3-9人
    • 团队的主要特点：避免任务切换、分享知识、特性团队、主动工作、团队决策、团队解决问题
• 5. Scrum管理框架要素
  • 产品待办列表
    • 目的：记录需求
    • 也叫用户故事集，每个需求都是一个用户故事
    • 用户故事
      • 作为什么用户，在时间/地点，我想做什么，是为了什么目的/商业价值
      • 于是，我怎样做/怎样操作
      • 最后如何验证
    • 产品待办列表特点
      • 工作开始之前，不需要为整个项目创建所有的故事，只需要创建第一个发布计划的主要内容即可
      • 待办列表是不断变化和完善的，可以随时更新、增加、删除、修改、变更优先级等
        • 需求发生变化，不需要走变更流程，直接加入待办列表
      • 巨大的用户故事也叫史诗故事，写在待办列表的最底部
      • 完成用户故事的定义：0/1法制，完成或者未完成
      • 对需求无从下手，影响地图可作为待办列表的有效输入
    • 产品待办列表梳理会
      • 内容：把当前的产品需求清单进行梳理，包括排优先级、拆成粒度适中的故事卡片等
      • 梳理会的时间：两周的冲刺用1小时的时间盒讨论
      • 梳理会与冲刺规划会议的关系：只有产品待办列表梳理会完成，冲刺规划会议才能开始
  • 特性
    • 传统模型：范围固定，时间、成本可变
    • 敏捷模型：时间和成本固定，范围可变
  • 工件
    • 产品待办列表
    • 冲刺待办列表
    • 增量
  • 任务流程
    • a.用户故事集
    • b.估算每个用户故事的规模
      • 故事点估算是一个倍数估算；是由团队进行估算；
    • c.评估用户故事优先级
    • d.估算团队速率
      • 团队速率：团队在单位时间里完成的工作量
      • 每个冲刺完成的平均故事点
  • 估算
    • 用故事点估算用户故事
      • 故事点是衡量用户故事规模和复杂性的一种方式，而不是持续时间
    • 传统估算持续时间的问题
      • 传统项目计划都是以小时、天和周为单位
      • 实际情况：为了避免估算不准确或者过度承诺，估算着最终会给你一个时间范围
    • 故事点估算的优势
      • 无需纠结估算的准确性。快速投入工作
      • 团队不会混淆估算与承诺
        • 估算=充分猜测；承诺=最坏情况下的策略；
    • 估算方法
      • 估算扑克
        • 斐波那契数列
        • 由团队成员，以一个故事点为基础，对故事进行估算
      • T-shirt估算
        • 比估算扑克更粗略的估算，比估算扑克更容易达成一致。6张牌
      • 亲和规模估算
        • 故事间比大小，并不是比精确的倍数，比估算扑克更容易达成一致
  • 用户故事优先级排序
    • 莫斯科法（MoSCoW）
      • M：must必须做的
      • S：should应该做的
      • C：could可以做的
      • W：won't不会做的
    • Kano模型
      • 基本需要：必须（优先开发）
      • 性能需要：越多越好（完成尽可能多）
      • 愉悦需要：很高满意度
    • 100点法
      • 分为每人100点，他们可以使用这些点给最需要的需求投票
    • 相对量级
      • 根据客户的判断，按照产品价值最大化估算
  • 项目进度计划
    • 产品愿景
    • 产品路线图（2-5年）
    • 发布计划（6-12月）
    • 冲刺计划（1-4周）
    • 每日站会
• 6. 敏捷活动
  • 冲刺规划会
    • 前半部分：团队向PO询问产品待办列表的内容、目的、含义及意图
    • 后半部分：团队计划本冲刺的安排
      • 把用户故事继续分解为活动
      • 团队成员确定活动分工
  • 每日站立会议
    • 团队每日例会，通常15分钟
    • 内容
      • 上次站会后我做了什么
      • 本次站会后我要做什么
      • 我在工作中遇到了什么障碍、风险或问题
    • 发现问题后，添加到停车场，创建另一个会议，在站立会之后立即召开，并在会上解决问题
    • 鼓励任何团队成员主持会议而不是由项目经理或领导主持
    • 作为团队进行自我组织和相互承诺的会议
    • 工具
      • Srcum任务板
        • 任务墙展现了在冲刺过程中所有要完成的任务。团队可以通过任务板及时发现问题，快速反馈，工作完成也会增加信心
      • 燃尽图
        • x：时间轴，y：剩余故事点
      • 燃起图
        • x：迭代1、迭代2……，y：已完成故事点
      • 风险燃尽图
        • x：时间轴，y：风险暴露值
        • 风险暴露值=风险发生概率%*风险影响（天）
        • 风险应对计划可以写入待办列表与活动统一管理
      • 看板
        • 可视化工作流
        • 限制在制品数量（限制正在进行中的工作），实现拉动式生产，提升生产效率
        • 待办、研发（进行中，已完成）、测试（进行中，已完成）、完成
        • 如果想缩短周期时间，就要减少在制品数量
        • 累计流量图
      • 看板VS任务板
        • 共同点：可视化的工作流
        • 不同点：在精益理论中看板更能提高效率，得到更大的收益
  • 冲刺评审会议
    • 冲刺评审会用来演示在这个冲刺中开发的产品功能给PO
    • PO会组织这阶段的会议并且邀请相关方参加
    • 会议内容
      • 团队展示冲刺中完成的功能
      • 团队成员都应参加
      • 可以邀请所有人参加
      • PO负责接受或拒绝故事
      • 一般的指导方针是，每两周至少展示一次团队的工作产品。这种频率对于大多数团队来说是足够的，这样，团队成员就可以得到反馈，防止他们朝着错误的方向前进
  • 冲刺回顾会议
    • 目的：分享好的经验和发现改进点，促进团队不断进步。通常每轮冲刺结束后举行的会议，但回顾会议可由团队决策在关键时刻进行
    • 会议内容
      • 本次冲刺有哪些做得好
      • 本次冲刺我们在哪些方面还能做得更好
      • 我们在下次冲刺这边在哪些方面改进
    • 会议步骤
      • 找出定性（人的感觉）和定量（衡量指标）的数据
      • 利用这些数据找到根源
      • 设计对策，并制定行动计划
    • 冲刺回顾会议的关键要点
      • 会议目的：并不是责备，回顾是让团队持续改进
      • 关注重点：团队共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）
      • 会议结论要跟踪闭环：可以放在产品待办列表中，确定每个改进的衡量结果，验证每个改进是否成功
  • 冲刺
• 7. 敏捷项目交付方法
  • XP的技术实现
    • 持续集成
      • 频繁的将工作集成到整体中
    • 不同层面的测试
      • 端到端信息使用系统级测试：是对整个系统的测试
      • 对构建块使用单元测试：对软件中的最小可测试单元进行检查和验证
      • 系统集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为子系统或者系统
      • 冒烟测试：在软件开发过程中的一种针对软件版本包的快速基本功能测试验证策略
      • 回归测试：修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
      • 自动化测试：软件测试的自动化
    • 验收测试驱动开发（ATDD）
      • 团队一起讨论工作产品的验收标准
      • 团队创建自动化测试，满足标准要求
    • 测试驱动开发（TDD）和行为驱动开发（BDD）
      • TDD：在开发功能代码之前，先编写单元测试用例代码，测试代码确定要编写什么产品代码
      • BDD：用自然语言或类自然语言，按照编写用户故事或用户用例的方式，以功能使用者的视角，描述并编写测试用例
    • 刺探/探针
      • 针对系统、技术和应用领域一些未知情况进行探测
      • 对学习很有用，在团队需要学习一些关键技术或功能要素时使用
    • 技术债务的解决
      • 技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策
      • 解决方法是重构 、敏捷建模
    • 结对编程
      • 两个程序员在一个计算机上共同工作、一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色
    • 代码集体所有
      • 任何团队成员都有权修改任何代码，整个团队所有权和问责权
  • 其他敏捷方法
    • 水晶
      • 根据项目规模以及项目的关键性两个维度来提供不同的敏捷方法选择。例如：C6、D6
    • 功能驱动开发（FDD）
      • 建立特征清单，按照特征做规模、按照特征做设计
    • 动态系统开发（DSDM）
      • 从一开始便可设置成本、质量和事件，然后利用正式的范围优先级来满足这些制约因素
    • 敏捷统一过程（AUP）
      • 以架构为核心、注重数据库设计、强调与用户的沟通
    • Scrum of Scrums（SoS）
      • 由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含3-9名成员来协调其工作
    • 大规模敏捷框架（SAFe）
      • 专注在项目组合、项目及和团队层详细设定实践、角色和活动。强调围绕专注于向客户提供持续价值流来组织企业
    • 大规模敏捷开发（LeSS）
      • 一个多团队Scrum框架，可以应用于由20、100甚至数千个人组成的敏捷团队，所有这些人都共同致力于一个特定的共享产品
    • 企业Scrum
      • 一种旨在通过更整体性组织曾而不是单个产品开发层来应用Scrum方法的框架
    • 规范敏捷（DA）
      • 一种在综合模型中整合多种敏捷最佳实践的过程决策框架
• 8. 组织转型
  • 组织向敏捷转型的原则
    • 变革管理
      • 变革的影响因素
    • 文化打造
      • 敏捷组织文化如何打造
    • 组织驱动
      • 敏捷PMO
      • 供应商
  • 敏捷变革的影响因素
    • 敏捷变革的驱动力
      • 快速交付成功
      • 已具备敏捷特色的团队
    • 组织架构对敏捷变革的影响
      • 地理位置
      • 职能结构
      • 项目可交付成功的大小
      • 项目人员分配
      • 重采购型组织
    • 敏捷变革就绪与否
      • 变革就绪的特征：管理层意愿、员工认知、人才能力等
      • 变革尚存障碍的特征
  • 敏捷文化的打造
    • 第一步：创建安全环境
    • 第二步：评估文化
    • 第三部：项目领导加速敏捷文化产生的方法
      • 积极明确的管理层支持
      • 运用变革管理经验推动
      • 逐个项目推动敏捷实践
      • 增量引入
      • 示范引导敏捷技术和实践
  • 敏捷项目管理办公室（PMO）
    • 价值驱动型
      • 实现项目价值交付
    • 面向创新型
      • 通过思考和实践一些创新思想和观点，帮助客户快速高效实现价值
    • 多学科性
      • 熟悉项目管理本身以外的知识来满足不同的项目支持需求
  • 敏捷合同
    • 多层结构
    • 强调价值交付
    • 总价增量
    • 固定时间和材料
    • 累进的时间和材料
    • 提前取消方案
    • 动态范围方案
    • 团队扩充
    • 支持全方位供应商
    • 范围可调整