PMP-敏捷方法知识点汇总
2024-10-10 10:54:56 0 举报AI智能生成
PMP-敏捷方法知识点汇总
作者其他创作
大纲/内容
敏捷基础概念
敏捷含义
Agile
轻巧、机敏、迅捷、灵活、活力、高效
敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，做到文档、度量适度。
适用于各类软件企业
敏捷宣言
2001年
犹他州雪鸟滑雪场
17位敏捷倡导者敏捷宣言
敏捷四大价值观
个体以及互动 > 过程和工具
可用的软件 > 完整的文档
客户合作 > 合同谈判
应对变更 > 遵循计划
敏捷十二大原则
我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
要经常交付可用的软件，周期从几周到几个月不等，且越短越好
项目实施过程中，业务人员与开发人员必须始终通力协作
要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务
无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面交流
可用的软件是衡量进度的首要衡量标准
敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该能够始终保持步调稳定
对技术的精益求精以及对设计的不断完善将提高敏捷性
简洁，尽最大可能减少不必要的工作，这是一门艺术
最佳的架构、需求和设计将出自于自组织团队
团队要定期反省怎样做才能更有效，并相应地调整团队行为
敏捷思维模式
由价值观定义
以原则为指导
并在许多不同的实践中体现
敏捷实践者根据自身需求选择不同的实践
敏捷实践：kanban、Scrum、Lean-Agile、XP、DSDM、Crystal
十二大原则
四大价值观
敏捷思维模式
迭代
敏捷的项目过程由一系列的迭代组成
迭代的长度一般控制在1-4周
通过固定的周期保持良好的节奏
产品的设计、开发、测试都在迭代期间完成
迭代结束时交付可以工作的软件
Sprint：冲刺
时间盒
计划会议：8小时
每日站会：15分钟
评审会：4小时
回顾会：3小时
一个冲刺：1-4周
Scrum团队-3个角色
PO-产品负责人（1）
定义：负责最大化产品以及开发团队工作的价值
承担角色
代表客户和项目相关方的利益
为产品的ROI（投资回报率）负责
决定交付范围
决定需求优先级
决定什么时候开发
验证交付是否符合期望
SM-敏捷教练（1）
定义：帮助团队每个人理解Scrum的理论、实践、规则和价值
承担角色
引导团队建立和遵守规则
辅导团队，促进合作
推动团队解决遇到的问题
对外接口，保护团队不受外界干扰
推动团队回顾、学习和提升
仆人式领导/服务型领导
敏捷教练=项目经理=Scrum主管=团队促进者
ST-敏捷团队（7±2）
定义：由各种专业技术人员组成，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量
承担角色
控制在5-9人
拥有完成交付需要的全部职能
负责具体的交付工作
跨职能
全职
T型人才
自组织团队
Scrum事件-4个会议
Plan-计划会议
会议在迭代的第一天举行
参会者：PO、SM、ST
输入
产品Backlog
一个需求的列表
一般情况使用用户故事来描述列表条目
理想情况每个需求项都对产品的客户或用户有价值
未完项条目按照商业价值排列优先级
优先级由产品负责人来排列
在每个迭代结束的时候要更新优先级的排列
也叫产品未完事项列表、产品需求列表
由PO创建，或PO与团队共同创建
产品待办事项列表梳理会
团队通过召开产品待办事项列表梳理会，编写产品待办事项列表中的主要内容，并对其中的用户故事进行优先级排序，将复杂的用户故事拆成粒度适中的用户故事
只有产品待办事项列表梳理会完成，迭代规划会议才能召开
一般情况下，两周的迭代用1个小时召开梳理会
待办事项列表的细化，在细化会议上，产品负责人可以向团队介绍故事的创意，让团队了解故事中潜在的挑战或问题
会议的目的是细化足够的故事，让团队了解故事的内容，以及故事之间的相互关系
用户故事
含义：站在用户角度，简短描述需求的一种方式
好处
用户视角，便于交流
独立交付，适合迭代
测试先行，避免过度设计
三要素
角色
活动
商业价值
团队速率
当前产品
商业条件
技术
迭代计划会议
会议1：做什么
会议2：怎么做
输出
迭代目标
迭代Backlog
待办
故事
任务区
待办任务
进行中任务
待验证任务
完成任务
完成
故事
团队成员自己挑选任务，而不是指派任务
对每一个任务，每天要更新剩余的工作量估算
每个团队成员都可以修改Sprint backlog。增加、删除或者修改任务
故事的所有任务被完成并达到验收标准，故事才算完成
故事点 - Story point
含义：敏捷创造出来用来描述用户故事工作量的单位
用一个用户故事所需时间很难达成共识
用一个用户故事的工作量可以快速达成工使
用一个用户故事的工作量可以快速达成工使
故事点是相对的，不同的项目所定义的故事点很可能是不等的
估算方法：带宽德尔菲、计划扑克、亲和估算
Do-每日站会
敏捷教练主持，也可团队成员轮流主持
你昨天做了什么
你今天准备作什么
你有遇到什么障碍
更新任务状态
Check-评审会议
迭代评审会：用来演示在这个迭代中开发的产品功能给产品负责人
产品负责人组织这个阶段的会议并邀请相关的干系人参加
团队展示Sprint中完成的功能
一般是通过现场演示的方式展示功能和架构
不要太正式
不需要PPT
一般控制在4小时
团队成员都要参加
可以邀请所有人参加
迭代评审会议常见问题
客户需求不详细
客户未提供信息
客户要求不详细
团队很难理解客户信息
客户反馈问题/抱怨
功能没有实现
产品功能有瑕疵
抱怨没有实现业务目标
认为项目未增加价值
Act-回顾会议
Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬
团队的定期自我检视，发现什么是好的，什么是不好的
一般控制在3小时内
每个迭代都要做
全体参加
敏捷教练
产品负责人
敏捷团队
可能的客户或其他相关方
何时召开
当团队完成一个发布或者加入一些功能时。这不一定是一个巨大的增量。它可以是任何发布，无论它有多小。
自上次回顾以来，又过了几周的时间。
当团队出现问题时，以及团队协作完成工作不顺畅时。
当团队达到任何其他里程碑时，
目的：持续改进
收集数据：使用数据来描述在迭代阶段发生的确切情况
审查方案进展是否顺利
评估项目的完成情况
收集和总结经验教训
洞察问题：讨论在迭代过程中哪些地方做的好，并找出阻碍成功的任何问题
哪些是可行的、哪些是不可行的
哪些需要持续改进
发现问题、记录问题
行动计划：概括出改进的必要步骤，并将其编入一个行动计划
讨论接下来继续坚持的、要停止的和需要开始执行的行动
Scrum工件-3个工件
Product Backlog-产品待办事项列表
Sprint Backlog-迭代待办事项列表
Product Increment-产品增量
Increment-增量
增量是之前所有增量的累加
增量必须经过验证并符合DoD，否则不能提供价值
一个Sprint可以创建多个增量
增量在Sprint Review中展示Demo
增量只要符合DoD就可以交付
MVP-最小可行性产品
快速地构建出符合产品预期功能的最小功能集合
原型法
含义：指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈
形式多样：微缩原型、计算机生成的二维和三维模型、实体模型或模拟
有形体验：因为原型是有形的实物，它使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述
DoD-完成的定义
什么是DoD：100%完成达成目标的最小活动集，代表对质量投入的共识与承诺
DoD作用：确保对完成的定义理解一致；避免技术债务聚焦目标；减少不必要的活动；检查是否有遗漏的活动
如何定义：逐步优化完善；DoD越弱，欠债越多，后期风险越大；质量投入活动要包含在DoD定义中
其他信息
迭代燃尽图
燃起图
看板：基于流程的敏捷-范围是固定的，每次必须完成预定的功能才能交付
Scrum：基于迭代的敏捷-交付的时间是固定不变，未完成的放回产品待办事项列表
优先级排序方法
卡诺模型
莫斯科法
加权最短作业优先WSJF
需求优先级
虚拟价值
100点
收藏
0 条评论
下一页
