PMP敏捷思维导图
2023-08-28 11:37:06 72 举报AI智能生成
PMP敏捷思维导图是一种以项目管理专业认证（PMP）为基础的敏捷项目管理工具。它通过可视化的方式，将项目的关键要素、任务、资源和时间线整合在一起，帮助项目经理更好地规划、执行和监控项目进度。这种思维导图采用树状结构，从中心主题出发，分为多个子主题，每个子主题下又有多个细分任务。通过这种方式，项目经理可以清晰地看到项目的全貌，以及各个任务之间的关联性。此外，PMP敏捷思维导图还可以与其他项目管理工具（如甘特图、PERT图等）相互结合，实现更高效的项目管理。总之，PMP敏捷思维导图是一种实用的项目管理工具，能够帮助项目经理更好地应对复杂的项目挑战。
作者其他创作
大纲/内容
看板
作用
可视化管控，消除瓶颈
流程
记录团队例行工作
布置看板墙
确定WIP限制
WIP限制决定了每种情况下的工作流中可以存续的最大工作量。
定义完成规则
召开每日站会
极限编程12最佳实践
1、计划游戏：快速制定计划、随着细节的不断变化而完善
2、小型发布：系统的设计要能够尽可能早地交付，在非常短的周期内以递增的方式发布新版本，可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈
3、系统隐喻：找到合适的比喻传达信息
通俗易懂的黑话
4、简单设计：只处理当前的额需求市设计保持简单
5、测试驱动：先写测试代码再编写程序TDD
6、重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求；在不改变系统行为的前提下，重新调整、优化系统内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。
7、结对编程：由两个程序员在同一台电脑上共同编写解决同一问题的代码。通常一个人编写，另一个负责保证代码正确性和可读性
8、集体所有权：任何人在任何时候都可以在系统中的任何位置更改任何代码。每个成员都有更改代码的权利，所有人对全部代码负责。
9、持续集成：可以按日甚至按小时为客户提供可运行的版本；提倡在一天中集成系统多次，而且随着需求的改变，要不断地进行回归测试，避免了一次系统集成的噩梦
10、每周40小时：要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响效率
11、现场客户：在团队中加入一位真正的、起作用的用户，他将全职负责回答问题
12、编码标准：强调通过制定严格的代码规范来进行沟通，尽可能减少不必要的文档
PS
TDD
测试驱动开发
ATDD
验收测试驱动开发
BDD
行为驱动开发
将编码实现与业务行为描述完美地结合
PMP中的敏捷
整合
自组织团队
团队自行决定计划及其组件的整合方式
仆人式领导
对PM期望保持不变，把对具体产品的规划和交付授权给团队来控制。PM关注营造一个合作型的决策氛围，确保团队有能力应对变更
T型人才解决知识孤岛
如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那这种合作型方法就更加有效
范围
小步快跑，增量交付
多次迭代开发可交付成果，在每次迭代开始时定义和批准详细的范围
Sprint计划会议
需应对大量变更，需要相关方持续参与项目
整体范围分解为一系列产品未完项
在迭代开始时团队努力确定产品未完项哪些最优项应在下一次迭代中交付
Sprint Backlog
相关方频繁参与
发起人和客户代表应该持续参与项目，随同可交付成果的创建提供反馈，确保产品未完项反映他们的当前需求
Sprint评审会议
每次迭代都会重复开展：确认范围和控制范围
专注于Sprint目标
使用未完项（包括产品需求和用户故事）反映当前需求
产品增量
早起缩短定义和协商范围的时间，并未持续探索和明确范围而延长创建相应过程的时间
Sprint评审会两大目的
有目的地构建和审查原型，并通过多次发布版本来明确需求。范围在整个项目期间被定义和再定义
把需求列入未完项
产品愿景、产品路线图、发布计划
先为整个项目确定一个高层级的愿景，再针对一个迭代期明确详细范围。通常随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。
迭代待办事项列表
史诗Epic
总的目标，表示商业价值
特性Features
产品的功能特点，一般由一到到个迭代完成
用户故事
将长篇故事分解为用户故事
MoSCoW
优先级排序方法
Must：必须有
Should：应该有
Could：可以有
Won't：这次不会有
进度
价值驱动
适用型方法采用短周期开展工作、审查结果，在必要时做出调整。可针对方法和可交付成果的适用性提供快速反馈。
具有未完项的迭代型进度方法
滚动式规划，敏捷。按优先级排序并优化用户事故，在规定的时间盒内开发产品。
向客户交付增量价值，允许在整个开发生命周期期间变更
固定时间盒
增量交付、频繁演示
拥抱变更
按需进度计划
看板体系，基于WIP制约理论和精益生产的拉动式进度计划，在资源可用时立即从未完项中提取出来开展
在运营或持续环境中以增量方式研发，且任务规模和范围类似，或者可对任务进行组合
WIP在制品限制，拉动
消除瓶颈
产品愿景->产品路线图->发布计划->迭代->功能->用户故事->任务
宽带德尔菲
专家估算，多轮，趋同
计划扑克
团队估算，阐述原因，多轮，趋同
进度管理
燃尽图
追踪迭代未完项，分析与理想燃尽图的偏差，可使用预测趋势线预测偏差及应采取的行动
燃起图
与燃尽图相反，跟踪已完成项
看板
可视化监控，消除瓶颈（WIP）
每日站会
成本
范围未明确，经常变化的项目，采用轻量级方法快速生成对项目人力成本的高层级预测，出现变更时更容易调整预测
详细的估算适用于采用准时制的短期规划
严格的计划，为了适时地满足项目工作对资源的需要，同时又要消除资源的闲置
质量
敏捷中多个质量与审核步骤贯穿整个项目，而不是在面临项目结束时才执行
循环回顾，定期检查质量过程的效果；寻找问题的根本原因，然后建议实施新的质量改进方法；后续回顾过程评估试验过程，确定是否可行、可继续、或做出调整，或直接弃用
小批量系统，在项目生命周期早期发现不一致和质量问题，早期变更成本更低
敏捷中整个项目期间的质量管理由所有团队成员执行，传统项目中由特定成员执行
DOD
完成的定义
TDD
测试驱动开发
在开发人员实现功能代码前，先设计好测试用例的代码，然后再根据测试用例的代码编写产品的功能代码，最终目的是让开发前设计的测试用例代码都能够顺利执行通过
BDD
行为驱动开发
BA和测试开发一起对用户故事分析，转化为通俗的文字
研发团队使用BDD工具把用户故事场景文件转化为可执行的自动化测试代码，研发人员运行自动化测试用例来验证开发出来的软件产品是否符合用户故事场景的验收要求
ATDD
验收测试驱动开发
定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动产品的代码开发和测试脚本开发
持续集成
刺探
回顾会议
强调较小的增量
代码集体所有
责任归属于整个团队
资源
易变性高的项目得益于最大限度地集中和协作的团队结构，如拥有通才的自组织团队
协作型团队可以促进不同工作活动的加速整合、改善沟通、增加知识分享，及提供工作分配的灵活性和其他优势
自组织团队
T型人才
相互协作，共同解决问题
自组织任务的分配
交叉培训
沟通
需要对不断变化的细节，进行更频繁和快速的沟通。应尽量简化成员获取信息的通道，频繁进行团队检查，让团队集体办公
集中办公
鱼缸窗口
建立长期视频会议链接，创建一个鱼缸窗口，每天工作开始时，人们打开链接，工作结束时关闭链接。人员可以自然地看到彼此并进行互动。
远程结对
通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程结对。只要考虑了时差，这种方法几乎和面对面结对一样有效。
SoS
追逐太阳
利用时差，衔接工作
为促进与高级管理层和相关方的沟通，需以透明的方式发布项目工件，定期邀请相关方评审项目工件
信号扩散器/信息发射源
不提倡状态报告
透明、高效
风险
环境变化意味着不确定性和风险。需要采用适用型方法管理项目
跨职能项目团队，经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理
在选择每个迭代期的内容时，应考虑风险；在每个迭代期间应该识别、分析和管理风险
整个Sprint考虑风险
根据当前风险敞口的理解和加深，定期更新需求文件，并随项目进展重新排列工作优先级
利用量化的敞口排优先级
采购
客户协作高于合同谈判
敏捷中可能会需要与特定卖方协作扩充团队，这种协作能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励
大型项目中，可能部分适应型方法，部分稳定方法
主体协议来管辖整体协作关系，适用型工作写入附录或补充文件
主协议和补充协议的多层结构
变更只针对适应型工作，而不会对主题协议产生影响
考虑动态特性的合同
关注用户故事而非整体预算
动态范围方案
增加需求
提前取消方案
达到目的停止
自助团队而非项目（包人头）
相关方
高度变化的项目需要相关方的有效互动和参与
频繁参与
为了及时高效的讨论和决策，适应型团队直接与相关方互动，而不是通过层层的管理级别
高效透明的沟通
客户、用户、开发在动态的共创中交换信息，通常能实现更高的相关方参与和满意程度
整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出调整，从而节约成本，提高项目成功的可能性
常见的相关方管理方法
为加快组织内部与组织之间的信息分享，敏捷提出高效透明
邀请所有相关方参与项目会议和审查
将项目工件发布到公共空间
让各方之间的不一致和依赖关系，或其他问题，尽快浮现
其他概念
预测型特点
计划驱动、需求明确
需求变化时需要经过变更流程
一开始就有大量文档工作
客户参与度不高
大量时间汇报状态
价值在结束的时候体现，风险较高
无法灵活应对市场
MVP
STACEY矩阵
需求不确定性低、技术不确定性低
线性方法有效
需求不确定性高、技术不确定性高
根本上是冒险的
其他
敏捷方法有效
混合型生命周期
无法一夜之间转换到敏捷
可以在风险不大，中低程度不确定性的项目中尝试
混合方式实现后，再尝试复杂项目渐进过度
敏捷宣言
个体互动胜过流程和工具
个体互动
可用的软件胜过详尽的文档
可用软件
客户合作胜过合同谈判
客户合作
响应变化胜过遵循计划
响应变化
敏捷开发十二原则
最重要的目标是尽早、持续不断地交付有价值的软件使客户满意
尽早、持续不断交付有价值的
欣然面对需求变化，即使在开发后期。为了客户的竞争优势，敏捷过程掌控变化
欣然面对需求变化
经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
较短周期迭代交付可工作的软件
业务人员和开发人员必须相互合作，项目中的每一天都不例外
业务开发相互合作
激发个体的斗志，以他们为核心搭建项目。提供所需环境和支援，辅以信任，从而达成目标
提供环境和支持，辅以信任
不论团队内外，传递信息效果最好的是面对面交谈
面对面交谈
可工作的软件是进度的首要度量标准
可工作的软件
敏捷倡导可持续开发。责任人、开发人员和用户要共同维持其步调稳定延续
可持续开发，共同维护步调稳定
坚持不懈追求技术卓越和良好设计，敏捷能力由此增强
技术卓越和良好设计
以简洁为本，它是极力减少不必要工作量的艺术
简洁为本
最好的架构、需求和设计出自自组织团队
自组织
团队定期反思如何提高绩效，并依次调整自身的行为表现
定期反思
敏捷发布规划
产品愿景
产品路线图
发布计划
迭代
功能
用户故事
任务
Scrum
3个角色
PO产品负责人
产品待办事项列表唯一负责人
清晰表达PB
排序
PB可见、透明、清晰，显示团队下一步工作
确保DT对PB条目有一定理解
PB工作可由开发团队完成，但PO是最终负责人
PO是一个人而不是一个组织
组织所有人员必须尊重PO的决定。开发团队不听从任何其他人指令
PO决定接受或拒绝每次Sprint完成的增量，及发布
Scrum Mstar敏捷教练
负责确保Scrum被理解并实施
确保敏捷团队遵循敏捷理论、实践、规则
敏捷团队中的服务式领导（项目经理、Scrum主管、团队促进者）
服务于PO
找到有效管理PB的技巧
确保PO了解如何安排PB
清晰地和DT沟通愿景、目标和PB
帮助理解并实践敏捷
服务于DT
指导DT自组织和跨职能
移除DT进展过程中的障碍
教导并领导DT创造高价值产品
在Scrum还未完全被采纳和理解的情况下指导开发团队
服务于组织
领导并指导组织实践Scrum
帮助相关方理解并实施Scrum
发起能提升Scrum团队生产力的变革
帮助组织更有效地应用Scrum
DT开发团队
一般3-9人，稳定、全职
负责在每个Sprint结尾交付潜在可发布的完成的产品增量
DT由组织构建并授权来组织和管理他们的工作
特点
自组织
没有人告诉DT如何把PB变成可发布功能
自主选择任务、自己决定如何实现、自己估算并决定每个Sprint完成哪些工作、主动学习、管理层级相同
跨职能
团队作为整体拥有创造产品增量所需的全部技能
不认可头衔，都是开发者
T型人才
每个成员可以有特长和专注领域，但责任归属整个团队
开发团队不包括如测试、业务分析等负责特定领域的子团队
3大组件
产品待办清单PB
用户故事
角色
功能
价值
PB是一个排序的列表，包含所有产品需要的东西，也是产品需求变动的唯一来源。PO负责PB的内容、可用性和优先级
PB列出了所有特性、功能、需求、改进方法和缺陷修复等
按优先级由高到低排列，排在顶部的需要立即进行开发。排序越高的越清晰、具体。可作出更准确估算
满足DOR（就绪的定义）
通过PB梳理来增添细节、估算和排序。这是持续不断地过程，PO和DT协作讨论PB中的细节
在梳理PB时，条目可能被评审和修改。梳理在迭代中是一项兼职活动，在PO和DT之间展开
开发团队负责所有的估算工作。PO可通过协助团队权衡取舍来影响他们的决定，最后的估算是由执行的人来决定的
Sprint待办清单
SB是当前Sprint选出的PB条目，外加交付增量和实现Sprint目标的计划
SB是DT确定的，达到Sprint目标所需的工作清晰可见（做什么，做多少）
DT将SB中的用户故事拆分为人物，团队成员主动领取任务
SB是一份足够具体的计划，使进度上的改变能在每日站会中得到理解
DT专注于达成Sprint的目标
增量
迭代完成的所有PB的总和，以及以前所有Sprint所产生的增量的价值总和
在Sprint的最后，新的增量必须是完成的，这意味着它必须可用并且达到了Scrum团队的完成的定义的DOD
增量是在迭代结束时可以检视的和已完成的产品组成部分
增量是迈向愿景或目标的一步，无论PO是否决定发布它，增量必须可用
PS
技术负债（技术债务，设计负债，代码负债）
DT为了加快软件开发速度，在技术方案汇总妥协，给未来的自己带来额外的开发负担。
未来必须付出额外精力持续修复之前的问题，或重构
5大工件
Sprint
冲刺、迭代
Sprint是Scrum的核心，持续时间一个月或更短，以构建一个完成的、可用的和潜在可发布的产品增量
在开发过程中，迭代长度一般保持一致（规定的时间盒）
Sprint由迭代计划会议、每日站会、开发工作、评审会议、回顾会议组成
在Sprint期间不能作出有害于Sprint目标的改变
所有未完项都会被放回PB，并重新估算（价值通常会贬值，所以必须经常性重估）
Sprint可以在结束之前取消。只有PO有取消的权利
如果Sprint对其所在环境失去价值，就应该被取消。由于Sprint时间本身就很短，所以取消意义不大
Sprint计划会
计划会是Sprint的开始。计划会议室有限时的，两周的Sprint一般4小时上限
会议前半段，PO把待完成的高优先级功能介绍给团队
会议后半段，DT针对这些功能提出问题，如果团队有信心完成某个功能，就把这个功能从PB移动到SB中
若团队发现增加的工作量已经超过了整个团队一个迭代能完成的量，团队会立即建议PO停止
理论上团队按照优先级次序选择用户故事直到足够为止，实际情况中，通常选择优先级最高的五个故事，再选择两个低优先级但与前五个故事相关的故事。团队会和PO沟通，但是通常由团队决定一个Sprint做多少
团队和PO一起确定Sprint目标，在Sprint结束时的评审会中审视是否达成目标
PS
故事点
是一个度量单位，是产品待办项或其他工作的工作量估算结果
选择一个最简单的用户故事为基准，来衡量其他用户故事的工作量是多少个故事点
不同团队故事点不具有可比性
故事点完成不是越多越好，而是越稳定越好
通常在一个迭代中估计故事持续时间
刺探、探测、探针
快速而简陋的设计，作为被丢弃的试验品而设计，主要是为了获取背景知识以知道某需求在技术上是否可行
通常在不能有效估计用户故事时采用此方法
速率
衡量团队在Sprint中可以解决的工作量的指标
一般需要经过多个Sprint才能稳定（4-8个迭代测速）
每日站会
以15分钟为限
SM确保DT每日站会如期举行，但DT自己负责召开会议
SM强制执行每日站会规则，会中其他相关方可参与但不能干扰会议
同一时间同一地点举行，以便降低复杂性
增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍并促进快速地做决策、提高DT认知程度。进行检视与适应的关键会议
会议中
作为，我为帮助DT达成Sprint做了什么
今天，我为帮助DT达成Sprint准备做什么
是否有任何障碍在阻碍我或DT达成Sprint目标
会上只记录问题，不讨论问题
会议后
通常立即聚到一起进行更详细的讨论，或者为Sprint中剩余的工作进行调整或重新计划
SOS会议
多个敏捷团队之间需要沟通时，每个团队派出代表来沟通，之后各自在团队中传达信息
信息发射源（信息扩散器）
在集中办公区域设立一块大白板，用高可视化、图形化的方式展示出项目实施状态和信息，促进团队成员间、团队和相关方间透明的信息流通。
产品待办列表、问题列表、迭代燃尽图、燃尽图、燃起图、累积流量图、停车场图等
累积流量图
累积流图是在排队理论里使用的一个工具。它是一个面积图，强调用户故事或是需求数或是工单数随时间而变化的程度，同时直观显示整体趋势走向。X轴代表时间，Y周代表需求数量或是bug数或是用户故事数（可根据实际情况来定义）。我们可以用它来跟踪和预测项目的进展情况，也能借助于这个图来识别潜在的问题和风险。
停车场图
敏捷文档，用来对用户故事按主题进行分类和管理。包括：确定主题的名称、用户故事的数量、其包含的故事点、展现故事点完成百分比的进度图表。
障碍板
提供一个活跃的障碍的视图，对什么是障碍这一定义达成共识。
Sprint评审会
在Sprint快结束时进行，两周迭代一般2小时
检视所交付的产品增量并按需调整PB
Scrum团队和相关方协同讨论在这次Sprint中所完成的工作
开发团队演示完成的工作并解答关于所交付增量的问题，演示增量的目的是为了获取反馈并促进合作
参会的所有人就下一步工作进行探讨，为下次Sprint计划会议提供有价值的输入信息
Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办事项
Sprint回顾会
在评审会议结束后，在下个计划会之前举行。两周迭代一般不超过2小时
SM鼓励敏捷团队在Scrum的过程框架内改进开发过程和实践，使得他们能在下个Sprint中更高效更愉快
在回顾会议结束时，Scrum团队应明确接下来的Sprint中需要实施的改进
5个原则
勇气
有勇气做出承诺，接受尊重
承诺
愿意对目标做出承诺
专注
把心思和能力都用到承诺中
开放
把项目中的一切开放给每个人看
尊重
每个人都有他独特的背景和经验
客户
产品负责人PO
迭代计划会
每日站会
开发团队
Scrum Master
迭代评审会
迭代回顾会
敏捷团队、客户
敏捷团队、客户等
敏捷团队
产品待办事项列表PB
增量：想法、功能、缺陷...
迭代待办事项列表
Sprint迭代
0 条评论
下一页
