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