PMP中的敏捷知识一览！这篇最全！

PMP中的敏捷知识一览！这篇最全！

引用

CSDN

1.

https://blog.csdn.net/weixin_42400743/article/details/144084936

PMP（项目管理专业人士）认证是项目管理领域的重要资质，而敏捷开发作为现代项目管理的重要方法论，越来越受到企业的重视。本文将详细介绍PMP中的敏捷知识，帮助读者全面了解敏捷开发的核心概念、原则和实践。

PMP是计划驱动的项目管理策略：

• 以计划驱动的项目，需求要明确
• 依靠实施整体变更控制，来管理变化的需求
• 一开始就要编写大量的文档
• 用户参与度不高
• 需要花大量的时间来汇报当前的项目状态
• 价值只有项目结束时才能凸显，造成了较高的风险
• 无法灵活的应对市场的变化
• 最大的问题：需求不明确的项目，无法使用计划驱动型的项目！

因此，现代企业的开发项目中，越来越多的采用敏捷。

核心概念：什么是MVP（Minimum Viable Product - 最小可行产品）？

开发团队通过提供最小可行产品获取用户反馈，并在这个最小可行产品持续快速迭代，直到产品达到一个相对稳定的阶段。MVP对创业团队来说很重要，可以快速验证团队的目标，快速试错。

敏捷的定义

敏捷是一种通过创造变化和响应变化，在不确定和混乱的环境中，取得成功的能力。关键词：适应、灵活、价值驱动。

敏捷宣言

• 个体互动胜过流程和工具
• 可用的软件胜过详尽的文档
• 客户合作胜过客户谈判
• 响应变化胜过遵照计划

尽管右侧项有其价值，但是我们更重视左侧项的价值。

敏捷开发 12 原则

1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化。（拥抱变更）
3. 经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目总的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支持，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好、效率也最高的方式是面对面交流。
7. 可工作的软件，是进度的首要度量标准。
8. 敏捷过程倡导可持续开发，责任人、开发人员和用户要能够共同维护其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增加。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调节自身的行为表现。

敏捷实践：Scrum

敏捷是倒三角，先确定进度、成本，再确定做的范围。Scrum的核心：3-3-5-5

3个角色

1. 产品负责人 (Product Owner)

• PO是产品待办事项列表（Product Backlog）的唯一责任人，负责对待办事项列表的条目进行排序。
• PO决定接受或拒绝每次Sprint完成的工作增量，以及是否发布。
• 其他Scrum团队成员可以参与PB的维护。

2. Scrum Master - 敏捷教练

• 仆人式领导、服务型领导风格
• 帮助各方理解并实施敏捷（提供培训指导）
• 当团队遇到障碍，特别是外部的障碍，比如相关方的干扰、供应商的问题等，应及时帮助团队扫清障碍。
• 一般不直接解决具体实施层面的问题，比如团队遇到的技术问题。

3. 开发团队

• 开发团队由组织构建，并授权来组织和管理他们的工作。
• 团队是自组织的，团队作为一个整体拥有创造产品增量所需的全部技能。
• 团队人才是T型人才。
• Scrum不认可开发团队成员的头衔，无论承担何种工作，他们都是开发者。去中心化、小而强大，主动学习。

3个工件

1. 产品待办事项清单（Product Backlog）

• PB由PO维护
• PB是产品需求变动的唯一来源，产品负责人负责PB的内容、可用性和优先级负责。
• PB列出所有的特征、功能、需求、改进方法和缺陷修复等需要对未来发布产品进行的改变。
• 用户故事：作为一个< 角色 >，我想要< 功能 >，以便于实现< 价值 >。
• PB是一个排序的列表，按照优先级由高到低排序，排在顶部的条目需要立即进行开发。更靠近顶部的条目更加清晰、更加具体（符合DOR - Definition of Ready）。
• 优先级可以根据“KANO模型”或“MoSCow法”来排序。
• 开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的决定；但是，最后的估算是由执行工作的人来决定的。

2. 冲刺待办事项列表（Sprint Backlog）

• Sprint代办事项列表，是一组为当前Sprint选出的产品代办事项列表条目，外加交付产品增量和实现Sprint目标的计划。
• Sprint代办事项类比，是由开发团队确定的。
• 开发团队将Sprint代办事项中的用户故事拆分为任务，团队成员主动领取任务。

3. 产品增量

• 增量是一个Sprint完成的所有产品待办列表的总和，以及之前所有Sprint所产生的增量的价值总和。
• 在Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到Scrum团队的“完成”的定义 DOD（Definition of Done）。
• 增量是迈向愿景或目标的一步，无论产品负责人是否决定发布它，增量必须可用。
• 技术负债：为加快开发而选择的次优技术方案，需要在未来偿还。

5个事件

1. Sprint

• Sprint的长度，是一个固定的时间盒（Time Box）
• Sprint内没做完的任务，重新丢回PB排优先级。代办工作事项的价值，很可能会贬值。
• 在Sprint期间，不能做出有害于Sprint目标的改变。

2. 计划会（与会方：PO + 团队 + Master）

• 2周的Sprint，最多开4个小时；1个月的Sprint，最多开8个小时。
• 故事点（Story Point）：1、2、3、5、8、13 ...... 我们可以选择一个简单的用户故事作为基准，来衡量其他用户故事的工作量是多少个故事点。可以使用计划扑克，目的是为了促进团队参与，并顺带得到一个一致同意的结果。
• 团队速率（Velocity）：跑几个Sprint，来获得团队速率的情况。

3. 每日站会（与会方：团队 +/ Master）

• 站会的目的，是为了让团队之间了解相互的进展。
• 会议时长以15min为限
• 开发团队自己负责召开会议，Scrum Master确保开发团队每日如期举行。
• 每日Scrum站会在同一时间、同一地点举行，以便降低复杂性。
• 会议内容：昨天做了什么，今天打算做什么，遇到了任何障碍（在这个会议上只记录问题，不解决问题、不讨论问题）。
• 每日站会规则：只有开发团队成员才能参加。
• SoS会议：Scrum of Scrum
• 信息发射源/信息扩散器：看板、燃尽图、燃起图、累计流量图、停车场图。高效、透明沟通。

4. 评审会（与会方：团队 + PO + Master + 关键相关方）

• 在Sprint的结束时开展，一般2个小时。
• 在评审会议上，开发团队演示“完成”的工作并解答关于所交付增量的问题，演示增量的目的是为了获取反馈并促进合作。P.S. 相关方也要参加。
• Sprint评审会议的结果，是 一份修订后的产品待办列表，产品很可能进入下一个Sprint的产品待办列表项。

5. 回顾会（与会方：团队）

• 回顾会议，总结经验教训，一般不超过2个小时。
• 在回顾会议结束时，团队应该明确接下来的Sprint中要实现的改进（至少1个）。

5个价值

• 承诺：愿意对目标进行承诺
• 专注：把你的心思和能力都用到你承诺的工作上去
• 开放：Scrum把项目中的一切开放给每个人看
• 尊重：每个人都有他独特的背景和经验
• 勇气：有勇气做出承诺，履行承诺，接受别人的尊重

PMBOK中的敏捷

整合管理中的敏捷

• 项目经理授权的自组织团队
• 仆人式领导
• T型人才

范围管理中的敏捷

• 小步快跑，增量交付：在每个迭代开始时，我们定义和批准了一个Sprint的详细范围。
• Sprint计划会议：在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。
• Sprint Backlog
• 相关方频繁参与
• Sprint评审会议
• 专注于Sprint目标
• 产品增量
• Sprint评审会议的两大目标：构建和审查原型，范围会在整个项目期间被定义和再定义。
• 抛弃型的原型 v.s. 改进型的原型

进度管理中的敏捷

• 价值驱动
• 固定的时间盒
• 增量交付，频繁演示
• 拥抱变化
• WIP（Work in Process）在制品限制，拉动式生产
• 消除瓶颈
• 产品愿景 → 产品路线图（发布计划，粗略的）→ Sprint计划（详细的）
• 燃尽图、燃起图、看板
• 每日站会

成本管理中的敏捷

• 准时制短期规划

质量管理中的敏捷

• DOD（Definition of Done）
• 测试驱动开发 TDD（Test-Driving Development）/ 行为驱动开发 BDD（Behavior-Driving Development）/ 验收测试驱动开发 ATDD
• 持续集成
• 刺探（Spike）
• Sprint回顾会议：为了能够持续改进质量
• 代码（成果）集团所有
• 责任归属整个团队

资源管理中的敏捷

• 自组织团队
• T型人才
• 相互协作，共同解决问题
• 自组织任务的分配
• 交叉培训

沟通管理中的敏捷

• 透明、高效
• 信息扩散器（信息发射器）
• 不提倡状态报告
• 提倡集中办公；如果无法集中办公，则通过鱼缸窗口、远程结对等方式加强沟通。
• 敏捷实践：追逐太阳

风险管理中的敏捷

• 整个Sprint考虑风险
• 风险也是待办事项
• 利用量化的敞口排优先级

采购管理中的敏捷

• 客户协作高于合同谈判
• 考虑动态特性的合同
• 主协议和补充的多层结构
• 关注用户故事而非整个项目的预算
• 动态范围方案
• 提前取消方案
• 自助团队而非范围（包人头）

相关方管理中的敏捷

• 相关方频繁参与
• 高效透明的沟通

本文原文来自CSDN