PMI-ACP敏捷项目管理全套笔记
2022-03-20 17:45:07 3 举报AI智能生成
登录查看完整内容
为你推荐
查看更多
PMI-ACP敏捷项目管理全套笔记
作者其他创作
大纲/内容
过程和工具
重于
个体与交互
完备的文档
可用的软件
合同谈判
客户协作
遵循计划
响应变化
敏捷联盟宣言（核心价值观）
持续尽早向客户交付软件
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
拥抱变化
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势
频繁的发布可用软件
要不断交付可用的软件，周期从几周到几个月不等，且越短越好
客户和开发一起
项目过程中，业务人员与开发人员必须在一起工作
以人为本
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
面对面交谈
7%语调+38%声音+55%肢体语言
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
衡量开发过程的手段是可用的软件
可用的软件是衡量进度的主要指标
稳定的开发速度
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度
敏捷高效的设计
对技术的精益求精以及对设计的不断完善将提升敏捷性
简单有效
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术
重视teamwork
最佳的架构、需求和设计出自于自组织的团队
积极调整
团队要定期反省如何能够做到更有效，并相应地调整团队的行为
十二个原则
定义：完全计划驱动的生命周期，在项目前期确定项目范围及交付时间和成本，瀑布模型
充分了解拟交付产品
有厚实的行业实践基础
整批一次性交付产品有利于相关方
适用场景：
预测型生命周期
定义：将项目分成和多个冲刺
管理技术风险
不断演化需求
迭代型生命周期
定义：将产品分成多个模块，每次交付其中的一个模块
管理日常风险
应对小的需求变更，难以处理影响到架构的变更
增量型生命周期
定义：预测型+适应型
传统到敏捷转型过度期
使用每种生命周期的优点
混合型生命周期
项目开发生命周期
结对编程
简单设计
代码更加简洁优雅
重构
减少bug
快速定位bug
提高代码质量
减少调试时间
单元测试
技术债务
测试驱动开发（TDD）
对业务文档统一
自然语言描述
可以运行的需求和用例
活着的文档
验收测试驱动开发（ATTD）
探索性测试
系统级测试
集成测试
冒烟测试
回归测试
自动化测试
编程方法
减少风险
减少重复过程
产生可部署的软件
是项目更加透明
建立项目信心
持续集成
代码集体所有
编码标准
隐喻：讲故事的方式
稳定高速
知识共享
小组实践
完整的团队
现场客户
小规模发布
计划游戏
交付和管理
XP
建设团队
探索360
为团队指定规范
建立初试计划
项目章程
渗透式沟通
交付迭代
反思提高研讨会
项目总结
最佳实践
水晶方法Crystal
特征驱动开发FDD
动态系统开发方法DSDM
AUP敏捷统一过程
过度生产
等待
传输
过度流程
库存
再作业
情绪
消除浪费
精益方法（严格意义上不是一种敏捷方法）
决定产品发布的内容及发布日期
定义所有产品功能
根据市场的变化对需要开发的功能排列优先顺序
合理的调整产品功能和迭代顺序
对产品投入产出负责（ROI）
认同或者拒绝迭代的交付成果
产品负责人（product owner）
对项目的直接管理
领导团队完成SCRUM实践以及体现其价值
排除团队遇到的困难
确保团队的胜任其工作，并保持高效的生产率
使得团队紧密合作，使得团队个人有多方面职能的工作能力
保护团队不受外来无端的影响
ScrumMaster
经典团队3/5-9人
团队成员都是多面手\\跨职能（开发人员、测试人员、用户设计师等）
团队成员都全职工作
团队组我组织和管理
团队关系在一个迭代内是固定的，个人的职能可以在新的迭代开始时发生调整
Team
3个角色
概要
仆人式管理
流程
清除障碍
保护团队
when
what
value
delivery
产品待开发列表（ProductBacklog）
冲刺待开发列表（SprintBacklog）
燃尽图（Burndownchart）
3个组件
冲刺规划会议（SprintPlan）
冲刺评审会议（SprintReview）
冲刺回顾会议（SprintRetrospective）
每日站立会议（DailyScrumMeeting）
冲刺（Sprint）
5个仪式
承诺
专注
公开
尊重
勇气
5个价值观
3355模型
PO和开发团队对产品业务目标形成共识
PO建立和维护产品需求列表（需求会不断新增和改变）并进行优先级排序
PO每轮迭代前，Review需求列表，并筛选高优先级的需求进入本轮迭代开发
开发团队细化本轮迭代需求，并按照需求的优先级依次在本轮迭代完成
开发团队每日站立会议、特性开发、持续集成、使开发进度真正透明
PO对每轮迭代（2-4周）交付的可工作软件进行现场验收和反馈
回到第3部，开始下一个迭代
典型场景
SCRUM
可视化价值
可视化价值流动
可视化问题和阻塞因素
可视化队列、瓶颈
可视化流转规则
可视化的工作流
限制WIP（work in progress）
速度：对每次迭代完成的用户故事点或故事的衡量
生产量：在一个特定时间内团队能够开放的特征数量
周期时间（Cycletime）：处理一个工作项目所需时间。团队通过衡量周期时间发现瓶颈和延迟问题.(开发-发布)
交货时间（Leadtime）:交付一个项目花费的总时间，从项目添加到看板直至完成。衡量交货时间可了解外部依赖关系
相应时间（Responsetime）:Leadtime-Cycletime
关注平均完成时间
协同改进
3个规则
看板墙
1个工具
看板
敏捷框架和方法
建立敏捷团队
相关方
最小化可行性产品MVP
价值驱动交付
电梯游说
设计产品盒子
产品愿景
投资回报率
回收期
净现值
内部报酬率
商业论证
目标说明
用户和客户收益
要点
技术上的考虑
问题和风险
干系人
主要里程碑
团队成员
ROI
子主题
PO
教导
SM
3-9人
自组织、资管理、通才
TEAM
确定角色
敏捷项目启动
猪
产品地图（RoadMap）
合适的详细程度
带估计的
优先级排序的
Card
Conversation
Comfirmation
故事描述3C原则
完成的定义DoD
作为一名<角色>，我可以<活动>，使得<业务价值>
三要素
影响地图
验收标准
简单设计（高中低）
MoSCoW
虚拟货币
100点必须花出去
100点方法
基本
期望
超预期
Kano分析
需求优先级模型
优先级排序
看重数量
PO筛选进入backlog
用户故事工作坊
用户故事
独立性
independent
可协商性
negotiation
有价值
valuable
可估算
estimable
短小
small
可测试性
testable
INVEST
grooming backlog
用户故事地图就是将story用可视化的方式展现在团队面前，让团队可以仔细梳理、讨论，确认这个story包含的内容，最终产出需求进行开发。
用户故事地图是Userstory的前传！
产生背景
听众
地图的核心是一条从左到右的时间线
时间线上第一行放置最大粒度的需求，即Epic
时间线上第二行放置二级粒度需求，即Theme
时间线下自上而下放置三级粒度需求，即Userstory
Release和时间线平行，确保在放入Release的过程中考虑故事的完整性。
结构
了解整个产品的全貌。找到整个产品的主干，也就是路径。促使产生更多用户故事
作用
防止只见树木不见林，更容易看清backlog全貌确保backlog覆盖了最重要的用户体验路径，及当前所规划的场景是否可以为用户提供价值确定发布计划以及发布目标，同时确保早期的发布可以验证整体架构和解决方案
解决问题
金字塔的顶端是需求的目标，也就是解决什么用户或业务问题？金字塔的中间层次是操作和操作流程，为了实现上面目标，系统需要支持哪些用户操作？这些操作的流程是什么样的？金字塔的底层是业务规则，各个操作步骤对应的业务规则是什么样的？
需求金字塔
绘制
用户故事地图
n轮
差异大的解释原因，再次估算
敏捷扑克牌
宽频德尔菲
对比几倍的估算
相对估算
按故事点大小分类估算
亲和估算
task时间估算，无任何干扰下的估算
理想日
干扰时间+理想日
流失时间
用户故事的估算，倍数。斐波那契数列 往大估算3-5倍
用户故事点
估算
团队的整体速度
用1-2个sprint试验
团队速率无可比性
拒绝人/天方式
速率
Task
SprintBacklog
ProductBacklog
ReleasePlan
计划
敏捷项目规划
昨天
今天
困难
每日立会
塔可曼模型
沟通愿景
给大家事物和水
仆人式领导
内心倾听
专心倾听
全心倾听
积极聆听
世界大战
圣战
争辩
争执
信息分享和协作
语言开发基于事实
冲突管理
你有没有跟xx提到过顾虑和感受
没有的话，xx应该知道你的顾虑，如果我跟你去找他有帮助吗
没有的话，我可以告诉xx有这些顾虑吗
不可以的话就置之不理
三步干预法
学习期
守
破
离
守破离
工作空间
简单投票
拇指上下边
决策分级
5个拳头投票
决策模型
高效团队
敏捷项目执行
发布后
Release BurnDown
站会后
Sprint BurnDown
燃烧图
正常的是平行的
非平行有问题
累计流量图
信息可视化
信息共享
信息雷达图
对feature进行监控
停车场图
敏捷项目监控
评审会议
回顾会议
回顾会议工具
回顾会议好处
敏捷项目收尾
SCRUM流程图
减少浪费
降低成本
准时化
自动化
持续改进
精益管理
找出非增值活动
找出浪费的地方
精益价值流
帮助定义完成
流程可视化
流程持续改进
工作量可视化
识别工作瓶颈
看板好处
如何看板
精益管理和看板
责任
公正
诚实
PMI道德规范
ACP
及早频繁交付可工作软件拥抱变化以人为本，与客户和team面对面沟通简单、高效、稳定、积极调整
敏捷开发核心思想：以人为本，适应变化
收藏
收藏
0 条评论
回复 删除
下一页
