项目管理/PMP/PMBOK第六版/新考纲纯干货！敏捷型/Stacey矩阵/vuca/敏捷宣言/冲刺/产品负责人/敏捷团队/敏捷教练/待办事项列表/迭代任务列表/可交付产品增量

Posted 2021-06-28 雨果虾滑猫

系列文章目录

1. 一篇文章看懂PMP的2021新考纲重点(建议收藏)
2. 项目发展史/项目定义/项目集/项目组合/十五至尊图
3. 商业论证/效益管理计划/项目运行环境/组织过程资产/环境事业因素/组织系统

项目生命周期-敏捷型

• 产品目标、范围、需求都是不明确的，只有通过持续不断的迭代开发和确认，才能完成最终产品
• 敏捷需求变化大，是受变更驱动的，含有增量和迭代的成本，需要用户持续参与
• 敏捷开发中后面的迭代有可能是对前面迭代产品的修正、完善甚至颠覆

Stacey矩阵

通过对需求和技术的两个纬度的明确程度，帮助开发者选择不同的开发方法。

最常见的示意图是下面的这种

英文原版的示意图是这样的

接近确定性: 当因果关系确定时，问题或决策也接近确定性。当过去一个相似问题或决策发生时，通常是这样的。人们可以非常确定地从过去推断和预测行动的结果。

远离确定性: 确定性连续的另一端是远离确定性的决策。对决策制定者而言，这些情况常常是独特和新颖的。因果关系不是很明朗。从过去的经验推断，在远离确定性的范围预测不是一个良好的方法。

项目生命周期-混合型

混合型 = 预测型(瀑布型) + 适应型(敏捷型)

vuca时代

VUCA是指组织将处于"不稳定"(Volatile)、“不确定”(Uncertain)、“复杂”(Complex)、和"模糊"(Ambiguous)状态之中。

不稳定

• V=Volatility（易变性）是变化的本质和动力，也是由变化驱使和催化产生的。
• 特点：挑战本身与维持的时长是未知并且不稳定的，但是并非难以理解。相关信息通常是现成的。
• 举例：一场自然灾害使得供应链脱节，继而导致产品价格波动。
• 做法：勤于闲时，将资源投入到预备力上，例如，保持库存和储备人才。这些措施通常意味着大额的花销，但是投资应与风险程度匹配。

不确定性

• U=Uncertainty（不确定性）缺少预见性,缺乏对意外的预期和对事情的理解和意识
• 特点：尽管缺乏额外信息，事件的基本因果关系已知。具备变革的可能性，但不一定成功。
• 举例：竞争者的新产品发布悬而未决，业务与市场的未来不够明朗。
• 做法：将资金投入信息的搜集、分析，并分享你的所得。这一做法与组织结构变革相结合时效果最佳，例如用信息扩大分析网络，降低不确定性。

复杂性

• C=Complexity（复杂性）企业为各种力量，各种因素，各种事情所困扰。
• 特点：这种情况包括许多相互连通的变量，有些信息是现成的，或能预测到。但想清晰地梳理其复杂程度与本质并非易事。
• 举例：生意遍布多个国家，每个国家的监管环境千差万别，关税体系以及文化价值观也各不相同。
• 做法：重组、聘用或培养专业人士，积累重组资源，应对复杂性。

模糊性

• A=Ambiguity（模糊性）对现实的模糊，是误解的根源，各种条件和因果关系的混杂。
• 特点：因果关系往往是不清晰的。没有先例可供参考，你面对的是“不确定中的不确定”
• 举例：决定将业务拓展到未成熟的市场或新兴市场，或在主营业务范围之外开发新产品。
• 做法：试验。理解因果关系需要不断提出假设，确保你能够从中得到教训，并将成果广泛应用到实际中。

敏捷宣言

原版官网 http://agilemanifesto.org/iso/zhchs/manifesto.html

敏捷宣言强调的敏捷软件开发的四个核心价值是：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

冲刺

Product Owner 产品负责人

• PO是有授权的产品领导力核心，是Scrum团队的三大角色之一。

日常工作内容

1. PO参与组合规划
2. PO参与产品规划，与利益干系人一起构思新产品。
3. Sprint前，PO负责制定Sprint计划。
4. Sprint内，PO要参加Daily Meeting。例会上听取情况，了解进展，提供协助。
5. PO必须每天能够解答问题，并进行验收测试。
6. Sprint内，PO还要确定下个Sprint的计划及优先级顺序
7. PO参与Sprint Plan，对产品列表进行梳理。
8. Sprint结束时，PO要参与show case 和 Sprint RetroSpect

Scrum Team 敏捷团队

• 敏捷团队对交付成功负责
• 高度自治
• 人少，够开发功能
• 跨职能部门

Scrum Master 敏捷教练

不是团队领导者，也不是项目经理，更不是经理。

Scrum Master 是反馈环中重要的角色（另外一个反馈环是 Scrum 中的事件），他是一个支持角色，更像是团队的一面镜子，帮助团队识别出现在的问题，从而能够走向“完美”的目标。

对以下方面负责

1. 团队
2. 产品负责人
3. 组织
4. 开发实践

Product Backlog 待办事项列表

根据路线图及其需求为开发团队列出的工作的优先级列表

1. 产品负责人在项目开始时对backlog进行优先级排序，但是当来自开发人员和涉众的反馈不断涌来时，他不会对backlog进行调整。
2. 团队将backlog上的条目限制为那些面向客户的条目。
3. 待办事项列表以文档的形式保存在本地，并且不经常共享，防止相关方获得更新。

Sprint Backlog 迭代任务列表

• 每个 Sprint 的需求库，在每个迭代规划时会选择当前迭代需要完成的需求或者大的缺陷。

• 一种做法是 PO 可以先规划好 Sprint Backlog，然后和 Scrum Members 一起讨论本次 Backlog 规划。也可以整个敏捷团队在做 Sprint Plan 时一起规划这次迭代的 Backlog。

• 大概原则：Sprint Backlog 应该是可完成的，Backlog 的工作量应该是可度量的，包含每个需求的工作量评估。对 Member 来说有的 Story 是有挑战性的。

• 状态：基于 Scrum 团队自身的特点进行定义即可，常规做法如：ToDo-Doing-Done-Testing-Finish 等等，格式不局限。目的让整个团队很直接的看到当前迭代 Sprint 的整体状态即可。

Increment 可交付产品增量

冲刺结束，团队可以交付的产品增量
这应该是潜在可发布的，指的是产品质量达到发布的标准
是否发布由产品负责人做最后的决定

总结

作为新考纲的新增内容，敏捷开发的内容和细节实际上非常多，对于没有IT项目研发经验的同学来说有些难，推荐参考其他知识体系中的敏捷多学习相关内容。

可以关注我下，这样就不会丢掉之后的重点~