导图社区 PMP-14 敏捷的定义
此思维导图, 为希赛PMP思维导图的基础上, 进行扩展。 本章为: PMP-14 敏捷的定义 同时配有相关知识点的PMP试题, 从知识点到对应的试题, 可加深对知识点的理解和记忆!
编辑于2023-05-12 17:40:03 江苏省这是一部由杰出心理学家沃尔特·米歇尔博士撰写的经典之作。 书中深入剖析了延迟满足对于个人成长和成功的重要性, 指导我们如何在生活中培养自控力,面对诱惑时做出明智选择。 无论你是学生、职场人士还是家长,都能从中获得启发, 提升自我管理能力,迈向更美好的未来。
想要真正教会他人,说服他人,影响他人, 最应该学习的并不是什么沟通技巧, 而应该是脑科学知识。 只有自己学会科学用脑, 真正掌握认知原理, 才能在沟通的时候让他人更好地理解或记忆。
什么是我们一生中耗时最多、最费心力的事? 是做出大大小小的决策。 但是,我们往往深陷难以计数的偏见和非理性中,做出荒谬的判断。 该书阐述了如何通过助推在不需要强迫的情况下巧妙地引导人们做出更理性的选择。 通过这本书,你将了解什么是助推,以及助推如何帮助我们提升智慧,做出更明智的决策。
社区模板帮助中心,点此进入>>
这是一部由杰出心理学家沃尔特·米歇尔博士撰写的经典之作。 书中深入剖析了延迟满足对于个人成长和成功的重要性, 指导我们如何在生活中培养自控力,面对诱惑时做出明智选择。 无论你是学生、职场人士还是家长,都能从中获得启发, 提升自我管理能力,迈向更美好的未来。
想要真正教会他人,说服他人,影响他人, 最应该学习的并不是什么沟通技巧, 而应该是脑科学知识。 只有自己学会科学用脑, 真正掌握认知原理, 才能在沟通的时候让他人更好地理解或记忆。
什么是我们一生中耗时最多、最费心力的事? 是做出大大小小的决策。 但是,我们往往深陷难以计数的偏见和非理性中,做出荒谬的判断。 该书阐述了如何通过助推在不需要强迫的情况下巧妙地引导人们做出更理性的选择。 通过这本书,你将了解什么是助推,以及助推如何帮助我们提升智慧,做出更明智的决策。
PMP-14 敏捷的定义
为什么需要敏捷
1. 五种场景
客户并不知道自己想要什么
客户表达需求和所想的不一致
交付的时候,客户的需求发生了变化
团队理解错误,交付的并不是客户想要的
环境的变化,导致原来的需求不再适用
2. 敏捷方法VS传统方法
3. 确定型和不确定型工作
确定型工作
1. 范围
前期确定,不易变更
2. 项目工作
可以按计划进行
3. 产品
一次性交付
4. 团队成员
以执行为主
5. 具有明确的流程,在以往类似的项目中被证明是行之有效的
6. 不确定性和风险,通常较低
7. 传统预测法
旨在预先确定大部分需求,并通过变更请求过程控制变更
不确定型工作
1. 范围
难以事先确定,且走且看
2. 项目工作
计划赶不上变化
3. 产品
可多次交付
4. 团队成员
既要动手,又要动脑
5. 新的设计、解决问题和之前未做过的工作,都是探索性的
6. 它要求主题专家携手合作,解决问题,并创建解决方案
7. 高度不确定的项目
变化速度快、复杂性、风险高
8. 敏捷方法
为了在短时间内探讨可行性
根据评估和反馈,快速调整
4. 选择敏捷的理由
灵活性
更快交付价值
更低风险
持续改进
什么是敏捷
1. 敏捷的起源与发展
1950S
美国国防部和国家航空航天局 采用迭代和增量开发模式
1960S
演进式项目管理
1970S
丰田的精益理念
1990S
1. Scrum
2. 极限编程
3. 水晶方法
4. 动态系统开发方法
2. 敏捷是许多方法的总称
敏捷和看板
1. 是精益方法的子集
2. 是精益思想的具体实例
3. 反映了以下概念
关注价值
小批量
消除浪费
3. 敏捷核心商业目标
1. 持续创新
交付
现有客户的需求
2. 产品适应性
交付
未来客户的需求
3. 缩短上市时间
提高
投资回报率
4. 人员和流程适应性
快速响应
产品和商业的变化
5. 可靠的结果
支持
业务增长和盈利的能力
4. 敏捷三角形
敏捷项目评估的三个目标
价值目标
提供
可交付的产品
质量目标
提供
可靠的、适应性强的
可交付产品
约束目标
在可接受的约束内
实现价值和质量目标
5. 敏捷思维
混合敏捷方法
团队方法
1. Scrum
用于管理产品开发的单个团队过程框架
2. 极限编程(XP)
是一种基于频繁交付周期的软件开发方法
3. 看板方法
看板在精益制造中是一种规划库存控制和补给的系统
可确保工作流和价值交付的持续性
4. Scrumban
Scrumban是一种敏捷方法,最初设计为Scrum到看板之间的过渡方法
它是通过其自身衍生演变而成的另一种混合敏捷框架和方法, 其中团队将Scrum作为框架,而将看板作为过程改进方法
5. 功能驱动开发(FDD)
开发目的是满足大型软件开发项目的特定需求
6. 动态系统开发方法(DSDM)
是一种敏捷项目交付框架
因强调制约因素驱动交付而著称
该框架从一开始便可设置成本、质量、时间, 然后利用正式的范围优先级来满足这些制约因素的要求
7. 敏捷统一过程(敏捷型UP)(AgileUP)
是软件项目中统一过程(UP)的分支
扩展方法
1. 水晶方法
水晶是一种方法论家族
水晶方法论旨在根据项目规模(项目中涉及的人员数量), 以及项目的关键性来量化并提供方法严格程度选择
2. 精益
精益概念
1. 关注价值
2. 小批量
3. 消除浪费
精益、看板、敏捷的关系
1. 将敏捷和看板方法,视为精益思想的衍生物
2. 精益思想是一个超集
3. 敏捷是许多实践的总称
4. 共性
交付价值、尊重人、减少浪费、透明化、适应变更、持续改进
3. Scrum of Scrums(SoS)
也称“meta Scrum”
是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术, 其中一个团队包括三到九名成员来协调其工作
定期召开会议
通常一周两次或三次
模式类似于每日站会
4. 大规模敏捷框架(SAFe®)
为企业的所有层级提供知识库,来进行大规模开发工作
5. 大规模敏捷开发(LeSS)
是一种以扩展Scrum方法为共同目标,来组织多个开发团队的框架
6. 规范敏捷(DA)
是一种在综合模型中,整合多种敏捷最佳实践的过程决策框架
DA旨在平衡专注范围过于狭窄(如Scrum)或细节过于规范(如AgileUP)的流行方法
7. 企业Scrum
是一种旨在通过更整体型组织层而不是单个产品开发层来应用Scrum方法的框架
其目的在于通过实现颠覆式创新,将敏捷方法扩展到项目执行范围以外
敏捷思维模式
1. 由价值观定义
2. 以原则为指导
3. 并在许多不同的实践中体现
敏捷实践者
根据自身需求
选择不同的实践
6. 敏捷含义
敏捷是创造并响应变化,从而在动荡的商业环境中创造利润的能力
敏捷是平衡灵活性和稳定性的能力
吉姆·海斯密斯,2002
《敏捷宣言》解读
敏捷宣言 四大价值观
个体以及互动
以人为本
1. 胜过
流程和工具
2. 以人为本
流程是死的,人是活的
可用的软件
以价值为导向
1. 胜过
完整的文档
2. 当相关方想要详尽的文档、相信的计划时,可以展示成功经验说服
3. 可用的软件胜于完整的文档,但不是完全不需要文档
4. 当详细的文档已经是需求的一部分,我们需要关注价值,做出调整
客户合作
合作共赢
1. 胜过
合同谈判
2. 不一味遵循合同,与客户意见相左时,强调沟通合作达成一致,追求合作双赢
应对变更
拥抱变化
1. 胜过
遵循计划
2. 计划、需求等都可能发生变化,应该积极应对
收获新的内容(需求)时
3. 拥抱变化,不等于无条件接受所有变化
谐音记忆
可应各科
Scrum五大价值观
承诺、专注、开放、尊重、勇气
承诺
commitment
愿意对目标作出承诺
专注
focus
全身心都用到你承诺的工作上去
团队成员全职,专注本项目
清除障碍,使得团队成员专注项目事宜
本轮迭代,专注迭代待办列表,非必要不更换
开放
openness
团队内,所有信息,对所有人开放
尊重
respect
每个人都有他独特的价值和经验
勇气
courage
勇于承诺,履行承诺,敢于说不
《敏捷宣言-十二原则》解读
1. 十二大原则
1.我们的最高目标是,通过尽早持续交付有价值的软件来满足客户的要求
1. 要验证用户需求,敏捷通常会采用原型法,通过快速制作一个产品模型来验证客户的需求,并收集客户的反馈
原型法是一种根据相关方的初步需求,利用产品开发工具,快速地建立一个产品模型展示给相关方
一般用于收集需求
2. 最小可行产品是可用的、甚至可以推向市场的产品或模型,可以发布的内容,一般不用来验证客户的需求
MVP是最小的可行性产品
MVP指的是用最快、最简明的方式建立一个可用的、并可以推向市场的产品或演示,以满足用户核心需求,并获取反馈。
一般是用于尽快交付,比如先做一个可以推向市场的产品
关注
客户满意
要点
尽早交付
持续交付
有价值
客户满意
2.欢迎对需求提出变更,即使在项目开发后期也不例外
敏捷过程要善于利用需求变更,帮助客户获得竞争优势
关注
拥抱变化
要点
1. 传统项目管理影响和控制会导致变化的因素
2. 敏捷预期到需求会变化
3. 拥抱变化,即使这些变化发生在项目后期
4. 通过原则、模式、实践,来保证软件足够灵活
5. 迅速应对和适应变化,能给客户带来显著的竞争优势,从而应对新的机遇
3.要经常交付可用的软件,周期从几周到几个月不等,且越短越好
关注
频繁交付
要点
1. 经常交付工作的软件,时间间隔越短越好
2. Scrum的迭代周期
大概为一个月
3. XP的迭代周期
则会短至一周
4. 较短的迭代周期
强化团队持续关注客户的价值
4.项目实施过程中,业务人员与开发人员必须始终通力协作
关注
一起工作
要点
1. 传统项目中,负责商业价值的人员和软件开发人员是严格分开工作的
2. 让每支团队都可以集中精力做他们擅长的事情
3. 敏捷项目管理,提倡他们同一个地方一起工作
4. 团队成员和业务人员,能相互理解彼此的想法
5. 他们的共同目标
通过工作的软件向客户传递价值
5.要善于激励项目人员,给予他们所需的环境和支持,并相信他们能够完成任务
关注
提供环境和支持
要点
1. 激励人,人比拥有最好的流程和工具更重要
2. 建立强有力的团队,并积极避免微观管理
3. 自律的团队,而不是一个自上而下的指令
4. 提供团队一个免于外界打扰的环境, 消除创造产品的障碍
5. 给团队自由发挥的空间
6.无论是对开发团队,还是团队内部,信息传达最有效的方法都是面对面的交谈
关注
面对面沟通
要点
1. 非正式的口头沟通,在敏捷项目管理中远比正式的书面沟通更普遍
2. 敏捷项目中的沟通都是公开的,任何团队成员都可以自由参与对话
3. 沟通透明、及时、可视化
4. 最高效的沟通
面对面交谈
5. 渗透式沟通
6. 宽带宽沟通
7.可用的软件,是衡量进度的首要衡量标准
关注
衡量指标
要点
1. 传统项目
不断更新使得文件成为一种负担
2. 真正的价值
是通过结果来表达的,结果又是通过工作的软件
3. 可工作的软件是首要度量标准
4. 关注需求完成度
5. 关注软件的可用程度
8.敏捷过程提倡可持续的开发
项目发起人、开发人员和用户应该都能够始终保持步调稳定
关注
可持续步调
要点
1. 敏捷项目比传统项目有更高的工作强度
尤其是使用XP这样的方法时
2. 保持一个稳定的可持续的进展速度,从而使得团队成员不会在迭代周期的尾端匆忙赶工,导致出现
3. 不允许过度的压力和过度疲劳
4. 不会借用明天的精力来在今天完成多一点工作
9.对技术的精益求精,以及对设计的不断完善,将提高敏捷性
关注
技术卓越
要点
1. 设计越完善,维护越简单
2. 保持软件干净、整洁
3. 编写高质量代码
4. 重构
5. 稳定和优质的项目,比劣质的项目更加允许团队快速应对变化
10.简洁,即尽最大可能减少不必要的工作,这是一门艺术
关注
简洁
要点
1. 关键点是对客户价值保持专注和毫不犹豫地削减不增加价值的活动
2. 这个原则,被所有的敏捷方法所拥护,尤其是精益方法
3. 精益方法的核心之一是消除浪费
4. 保持简单是最基本的原则
5. 不构建华而不实的系统
11.最佳的架构、需求和设计将出自于自组织团队
关注
自组织团队
要点
1. 自组织团队,即该团队自己谈论决定工作如何分配及谁去做某个特定的工作
2. 任务是分配给整改团队的,而不是某个人
3. 敏捷团队:通才型专家(generalizing specialist)
4. 团队获得授权、自组织、自管理,团队做决策
5. 传统项目和敏捷项目最显著的区别
6. 不仅小团队是自我组织的,较大的跨职能团队也可以是自我组织的
7. 不仅存在某个人对架构、需求、测试负责的情况,整个团队共同承担这些责任
12.团队要定期反省怎样做才能更有效,并相应地调整团队的行为
关注
定期反思
要点
1. 传统项目里,当项目或阶段完成时,开会总结是最常见的做法
2. 敏捷
更频繁的回顾来完成这项工作
3. 每日站会(daily scrum)、迭代回顾会议(restrospective meeting)
4. 在迭代回顾会议中,查看上个迭代周期中已完成的工作或发布,并评估下一次如何改进他们的做法
5. 每日站会,是另一项协调团队努力方向、团队自我评定和自我调整的重要方式
2. 分类
工作原则
精一、至简、定期反省
9.对技术卓越和好的设计的持续关注,有助于增强敏捷性
10.尽量做到简洁,尽最大可能减少不必要的工作,这是一门艺术
12.团队要定期回顾和反省,如何能够做到更有效,并相应地调整团队的行为
团队原则
一起合作、激励、 信任、自组织
11.最佳的架构、需求和设计,出自自组织团队
5.要善于激励项目人员,给他们所需要的环境和支持,并相信他们能够完成任务
4.在项目过程中,业务人员与开发人员要始终通力合作
沟通原则
面对面
6.团队内部和各个团队之间,最有效的沟通方法是面对面的沟通
我们的最高目标是,通过尽早持续地交付有价值的软件来满足客户的需求
3.要不断交付可用的软件,周期从几周到几个月不等,且越短越好
8.敏捷过程提倡可持续的开发。
项目方、开发人员和用户应该能够保持恒久、稳定的进展速度
7.可工作软件是衡量进度的首要指标
2.即使在项目开发的后期,仍欢迎对需求提出变更。
敏捷过程通过拥抱变化,帮助客户创造竞争优势