导图社区 PMP-16 Scrum敏捷实践
此思维导图, 在希赛PMP思维导图的基础上, 进行扩展。 本章为: PMP-16 Scrum敏捷实践 同时配有相关知识点的PMP试题, 从知识点到对应的试题, 可加深对知识点的理解和记忆!
编辑于2023-05-30 17:36:54 江苏省这是一部由杰出心理学家沃尔特·米歇尔博士撰写的经典之作。 书中深入剖析了延迟满足对于个人成长和成功的重要性, 指导我们如何在生活中培养自控力,面对诱惑时做出明智选择。 无论你是学生、职场人士还是家长,都能从中获得启发, 提升自我管理能力,迈向更美好的未来。
想要真正教会他人,说服他人,影响他人, 最应该学习的并不是什么沟通技巧, 而应该是脑科学知识。 只有自己学会科学用脑, 真正掌握认知原理, 才能在沟通的时候让他人更好地理解或记忆。
什么是我们一生中耗时最多、最费心力的事? 是做出大大小小的决策。 但是,我们往往深陷难以计数的偏见和非理性中,做出荒谬的判断。 该书阐述了如何通过助推在不需要强迫的情况下巧妙地引导人们做出更理性的选择。 通过这本书,你将了解什么是助推,以及助推如何帮助我们提升智慧,做出更明智的决策。
社区模板帮助中心,点此进入>>
这是一部由杰出心理学家沃尔特·米歇尔博士撰写的经典之作。 书中深入剖析了延迟满足对于个人成长和成功的重要性, 指导我们如何在生活中培养自控力,面对诱惑时做出明智选择。 无论你是学生、职场人士还是家长,都能从中获得启发, 提升自我管理能力,迈向更美好的未来。
想要真正教会他人,说服他人,影响他人, 最应该学习的并不是什么沟通技巧, 而应该是脑科学知识。 只有自己学会科学用脑, 真正掌握认知原理, 才能在沟通的时候让他人更好地理解或记忆。
什么是我们一生中耗时最多、最费心力的事? 是做出大大小小的决策。 但是,我们往往深陷难以计数的偏见和非理性中,做出荒谬的判断。 该书阐述了如何通过助推在不需要强迫的情况下巧妙地引导人们做出更理性的选择。 通过这本书,你将了解什么是助推,以及助推如何帮助我们提升智慧,做出更明智的决策。
PMP-16 Scrum敏捷实践
Scrum敏捷实践
三大支柱
透明、检查、适应
透明性
过程中的关键环节,对相关人是显而易见的,同时保证干系人对这些环节理解是统一的
检视
Scrum使用者必须经常检视Scrum的工件和完成Sprint目标的进展,检视频率应适应
确保能够及时发现过程中的重大偏差
适应
如果检视发现一个或多个方面偏离可接受范围以外,并且将会导致产品不可接受时,就必须对过程或过程化的内容加以调整
调整工作必须尽快执行,如此才能减少进一步的偏离
三个角色
1.产品负责人
1. 代言人、掌舵者、验收者
2. 对接
对接客户(发起人),收集需求,高度客户(发起人)
3. PO职责
聚焦于产品
指导产品的开发方向
4. 创建
产品待办事项列表(或与团队共同创建)
5. 排序
根据商业价值对任务进行排序(高于团队成员)
6. 监控需求
根据实际情况,清理、变更需求及排序
7. 参与反馈
参与项目,经常及时给出反馈
鉴定“已完成的用户故事”
2.敏捷教练
催化剂、老母鸡、卫道者
要点1:仆人式领导
角色定位是辅助性、仆人式、服务型
要点2:促进作用
促进团队内、外合作交流,不会替他人做决定
要点3:插手
1. 被求助时
2. 团队违反敏捷时
3. 不会用敏捷工具
4. 冲突自行解决无效
要点4:清除组织障碍
不干涉产品开发方向和如何开发的问题
要点5:为他人贡献铺路
提供支持和帮助,协助团队解决问题,确保敏捷实践的效果
3.自组织团队
1. 自组织、通才型、透明沟通
自组织特点
2. 聚焦绩效,自我管理
自我认领任务,建设性对抗,不对敏捷教练承诺
3. 人数
3-9人,正负2变动
PO、SM不包含在人数中
人数过多可以拆分团队
4. 专职
专注于一个项目
5. 通才型专家
有利于减少瓶颈、提升效率、减少孤岛/竖井
6. 团队成员更换
一般团队形成后,不会随意更换、增减人员
如果不得不进行更换, 比较好的时机是两个迭代之间进行
7. 办公方式
首选集中办公
定义:指团队办公的地理位置在一起
与虚拟办公相对
优势
面对面沟通
促进渗透式沟通
定义:信息在互相搭配工作的团队成员之间 无意识地进行共享
信息无意识地进行共享
一般在没有直接关注的情况下获取信息,从而降低信息传递成本,潜移默化的进行沟通
全球的、分布式团队
1. 可以使用虚拟手段,鱼缸窗口和远程结对
1. 鱼缸窗口
通过在团队分布的各个地点之间, 建立长期视频会议链接,创建一个鱼缸窗口
每天工作开始时,打开链接;工作结束时,关闭链接
2. 远程结对
通过使用虚拟会议工具,来共享屏幕,包括语音和视频链接,建立远程结对
它们都是分布式团队中,可能用到的沟通技术和方法
2. 使用在线协作工具(视频、看板)辅助沟通
洞穴CAVES和公共区域common原则
洞穴CAVES
是一个私人的交易预留空间,需要一个孤立且安静的环境
公共区域common
公共范围是一个公共的空间,在此常有渗透沟通和协作
8. 团队建设的五阶段
形成
明确团队成员的角色和职责
指导型
震荡
产生矛盾冲突
影响/教练型
规范
尝试去解决问题,协同工作
参与型
成熟
像成熟的单位有序地运作,高效完成工作
授权型
解散
项目结束,团队解散
塔克曼阶梯理论
1. 形成阶段
增加资源、新成员加入团队、互相认识
2. 震荡阶段
不同(反对)意见、发生冲突、争议分歧
3. 规范阶段
协同工作、按工作需要调整工作习惯、行为,开始学习信任
4. 成熟阶段
合作、高效解决问题
5. 解散阶段
解散团队、释放人员
9. 怎样培养通才型专家,怎样成为通才型专家
1. 知识分享
2. 交叉培训、技能培训
3. 结对编程
4.总结
成功敏捷团队的角色
产品负责人
1. 指导产品的开发方向
2. 创建、维护产品待办事项列表
3. 根据商业价值排序任务
4. 提供反馈
团队促进者
1. 确保遵循敏捷流程
2. 引导、指导团队,为团队消除障碍
跨职能团队成员
1. 通才型专家,拥有各种必要技能
2. 以常规节奏,交付潜在可发布产品
3. 核心职责
在短时间内交付任务
三个工件
列表
1.产品待办事项列表
DEEP模型
梳理产品待办事项列表
迭代0
为产品待办事项列表创建就绪的定义(DoR)
就绪的定义
是团队以用户需求为中心的核对单, 其中包括团队开始工作所需的全部信息
核对单
引用质量管理
Ready的定义,为了在下一个Sprint中,将用户故事从backlog转移到开发而必须满足的条件
具有就绪定义状态的用户故事 意味着该故事必须立即可操作
所以准备就绪的状态 也就意味着颗粒度细化是合适的了
DoR与DoD
DoR(Definition of Ready)
准备就绪的定义
定义
是指为了开始一个任务或功能,需要满足的一组条件或准则
作用
DoR有助于确保团队,在开始实施之前,就对任务或功能,有清晰的理解和共识
DoR可能包括以下内容
1.任务或功能
描述清晰、明确且详细
2.可行性研究和风险评估
已完成
3.所需资源(如人员、时间、预算)
已分配
4.项目需求、目标和验收标准
已明确
5.所有相关干系人,已就任务和功能
达成一致
DoD(Definition of Done)
完成的定义
定义
指一个任务或功能,在被认为已完成时,需要满足的一组条件或准则
作用
DoD有助于确保团队在任务或功能完成时,达到了预期的质量和标准
DoD可能包括以下内容
1.代码已编写并通过代码审查
2.功能已通过所有预定的测试
单元测试
集成测试
性能测试
3.文档已完成并更新
用户手册
技术文档
4.与任务或功能相关的问题和缺陷
已解决
本质
所有工作的有序列表,以价值为导向
排序
1. 考虑价值+风险
延迟成本:了解某个任务延迟带来的反价值, 可以帮助团队决定哪些任务先完成
2. 还可能考虑成本、依赖、政治等
细化梳理
渐进明细
内容
功能性内容
非功能性内容
技术债务、风险应对、运维工作等作为非功能性用户故事列入待办事项
性能需求
产品的关键运营和性能需求
航天飞机的重量
网站的负载量
性能需求,不是针对单个功能的,因此不应该放在单个功能的验收测试
性能需求应该有整体验收测试,确保产品通过性能指标
风险
风险是一个不确定事件,一旦发生可能会影响到项目
在敏捷中,消极的风险等同于反价值(anti-value)
价值是存钱,风险是花钱
如果风险发生了,就需要花费时间和资源去应对
同时也会威胁到项目的利益
敏捷
是业务价值与风险驱动的组合
尽早规划风险规避、转移的举措
敏捷项目不断进行迭代,在前期进行高风险处理
让高风险早曝光
这样,风险的应对成本相对更低,也降低了在之后阶段无效工作投入的可能性
基于风险的小试验
是风险管理的一个技能,叫刺探(spike)
责任人
主要由PO创建并维护
Deep模型
详细适宜的、可估计的、涌现的、排好优先级的
拆分
过大的用户故事需要拆分
以确保能够在迭代期间完成
其它
功能驱动开发模式(FDD)
1. 此模式中无产品负责人这个角色
2. FDD中主要存在的人员
1. 主要开发人员
2. 类的所有者
3. 功能团队
2.迭代待办事项列表
本质
本次迭代需要完成的目标和需要完成的工作项
明确具体任务
团队自行讨论领取
时间
在迭代规划会议上创建
原则
迭代过程中,迭代待办事项列表,一般不会随意改变
首先,要确保迭代任务,顺利完成
调整
如果用户故事,已经显然无效
或者当前情况紧急,不处理会危及整个迭代
可以对迭代待办事项列表进行调整
3.可交付产品增量
可交付产品增量,是一次迭代中实际完成的用户故事
潜在的封装好的一个产品功能增量
可交付产品增量,交付价值
尽早的交付价值,可以更好的应对变化
五个事件
会议
1.迭代、冲刺
迭代时间盒
应该和团队能力、项目特征协调一致
一旦确定,不会随意调整
需求变化频繁,客户要求增加评审频率时
可以缩短整体的迭代时间盒
8843
2.迭代、冲刺规划会议
PDCA-P
做什么
冲刺计划会议
1. 是确定迭代任务和目标
迭代目标
PO希望在一个Sprint期间完成和达到的目标
团队可以承诺完成
迭代待办事项(Sprint Backlog)
2. 讨论如何完成
3. 产出迭代待办事项列表
4. 会议基本内容
1.一般有PO来讲解产品待办事项列表(product backlog),并细化故事,团队来进行评估,得出迭代待办事项列表(sprint backlog)
2.将用户故事拆分成任务(task),以估算时间
3.团队成员自行领域任务(task)
4.更新sprint待办列表
谁参加
1. PO、开发团队、敏捷教练
PO讲解产品待办事项列表,并细化故事
团队来评估,得出迭代待办事项列表
2. 当相关方想了解团队计划、了解需求目标变化时 可以受邀参与冲刺计划会议
相关方可了解
团队情况
产品情况
开多久
时间盒2X
一个月的迭代周期,冲刺计划会议时间盒为8小时/月
2小时/周
要点
3.每日站会
PDCA-D
做什么
1. 目的
了解项目状态信息(掌握进度情况)
了解团队个人状态
共识信息
消除信息差
发现问题、障碍、风险
2. 每日站会,是支撑敏捷原则最重要的基石之一,不能随意取消
同步信息,提供工作的可见度和信息共享度
关键词:迭代期间不间断
怎么开
1. 每日站会,是团队自行组织,时间地点都是自行讨论确定,任何人都可以主持站会
2. 开发团队和敏捷教练都参会,PO视情况,相关方受邀
开发团队、敏捷教练都参会
3. 时间盒一般15分钟
因为其它原因(文化环境等)影响到会议效果,可以适当延长时间,但一般不超过20分钟
人数过多,可以考虑划分团队
4. 每个人轮流回答问题
1.上次站会以来,我都完成了什么?
2.从现在到下一次站会,我计划完成什么?
3.我的障碍(风险或问题)是什么?
站会只同步信息,提出问题,不解决问题
解决问题,可以是每日站会后单独安排
反模式
1. 不是状态报告会议
2. 只发现问题,不解决问题
问题可以站会以后专门讨论解决
如果不影响当前迭代目标,和整体流程相关的,可以回顾会议讨论改进
考点
4.迭代评审会议
PDCA-C
做什么
迭代评审会议上: 1.PO鉴定“已完成”, 2.客户验收已完成的用户故事,给出反馈
说明在冲刺迭代中完成了什么
演示完成的工作
产品负责人,原则上要到场
讨论
下次预期
变化的幅度
趋势的分析
未完成或者未验收的用户故事,需要协商沟通后,返回产品待办事项列表
谁参加
产品负责人、主要客户、敏捷教练、开发团队
开多久
一个月的迭代周期,会议时间盒是4小时
4小时/月
1小时/周
迭代评审会,主要是说明工作完成情况,演示“完成”功能
考点
5.迭代回顾会议
PDCA-A
做什么
检视自身,关注过程, 回顾措施有效性,找出原因、提出改进计划
讨论做的好的,和潜在需要改进的地方
总结经验教训,有助于团队调整过程
目的
1.检视前一个Sprint中,关于人、关系、过程、工具的情况如何
2.找出并加以排序做得好的和潜在需改进的主要方面
3.制定改进Scrum团队工作方式的计划
谁参加
1. 一般是团队成员、敏捷教练
敏捷教练确保会议
积极的和富有成效的
2. PO视情况
3. 相关方受邀参与
开多久
迭代评审之后,下次迭代规划之前
一个月的迭代周期,一般是3小时
Scrum五大价值观
承诺、专注、开放、尊重、勇气
承诺
commitment
愿意对目标作出承诺
专注
focus
全身心都用到你承诺的工作上去
1. 团队成员全职,专注本项目
2. 清除障碍,使得团队成员专注项目事宜
3. 本轮迭代,专注迭代待办列表,非必要不更换
开放
openness
团队内,所有信息,对所有人开放
尊重
respect
每个人都有他独特的价值和经验
勇气
courage
勇于承诺,履行承诺,敢于说不
其它
Scrum是用于管理产品开发的单个团队过程框架
该框架包含Scrum角色、事件、工件、规则,采用迭代方法来交付工作产品
Scrum是运行在1个月或更少时间的时间盒上的