导图社区 敏捷项目管理（ACP）
- 202
- 6
- 1
- 举报
敏捷项目管理（ACP）
ACP敏捷项目管理，详细的总结了敏捷框架，敏捷行动，敏捷实施，定义产品愿景和产品路线图，计划发布与冲刺，全天的工作，展示工作和集成反馈。
编辑于2022-06-30 14:30:40- ACP
- 敏捷项目管理
- 敏捷行动
- 相似推荐
- 大纲
ACP敏捷项目管理
第四章 敏捷框架
本章要点： 1、发现敏捷的起源 2、了解精益、极限编程和Scrum 3、连接敏捷框架
敏捷方法的共性
在多次迭代中开发，称为迭代开发
强调简洁、透明和因地制宜
跨职能、自组织团队
将可工作软件作为测量进度的标准
敏捷项目管理是一种凭经验注意的项目管理方法，信奉：
透明度
检验
调整
精益
重点是实现商业价值和使产品开发之外的活动最小化
精益原则
整体优化
消除浪费
打造质量
持续学习
快速交付
建立亲密伙伴关系
保持成长
实践
不开发那些不太可能使用的特性
以开发团队为中心，因为他们创造的价值最大
让客户确定特性的优先级，他们知道哪些是最重要的。通过优先处理高优先级的事项来创造价值。
利用工具来支持并优化有关各方的沟通
极限编程
重点是客户满意度
极限编程原则
编码是核心活动
XP团队做大量测试
让客户和程序员之间直接沟通
对于复杂的系统，超越任何剧透功能的、某一层次的总体设计是必不可少的
实践
规划游戏
整个团队
编码标准
系统银鱼
代码集体所有权
可持续发展的步伐
结对编程
设计改进
简化设计
测试驱动开发
持续集成
重构
小版本发布
Scrum
核心是冲刺
角色
产品负责人
开发团队
Scrum主管
Scrum角色
干系人
敏捷导师
非Scrum角色
工件
产品待办列表
冲刺代办列表
只有开发团队可以变更
产品增量
事件
冲刺计划会议
每日例会
冲刺评审会议
冲刺回顾
内部会议，以行动为导向
第五章 敏捷行动：环境篇
本章要点： 1、创建你的敏捷工作环境 2、重新认识低科技沟通方式，并使用恰当的高科技沟通方式 3、找到并使用你所需要的工具
集中团队成员
面对面沟通
站起身参加Scrum每日例会小组讨论
使用简单低科技的工具沟通
从Scrum团队成员那里获得清晰的解释
时刻了解其他人正在做什么
向他人寻求帮助来完成任务
协助他人完成任务
设立专用区域
消除干扰因素
干扰因素会削弱开发团队的注意力、精力和表现。Scrum主管需要魄力和勇气来管理和转移干扰因素。
多个项目
多个任务
监管过度
外部影响
管理层
创建移动工作环境
可移动桌椅
笔记本
可移动白板
低科技沟通方式
面对面沟通
对团队人员透明
冲刺的目标
达成冲刺目标所必须的功能
在冲刺中已完成那些工作
在冲刺中接下来还要做什么
谁正在进行那些任务
还剩哪些任务要做
工具
一两块白板
大量不同颜色的便利贴
不同颜色的彩色笔
一块冲刺专用面板
高科技的沟通方式
不能集中办公的情况下
视频会议和网络摄像头
即时消息软件
基于网络的桌面共享
协作网站
第六章 敏捷实施：行动篇
本章内容要点: 1、设置敏捷角色; 2、在你的组织中创建敏捷价值观; 3、转换你所在团队的理念 4、精进重要技能。
建立敏捷角色
开发团队
需要做到
直接负责创建项目的可交付成果
自组织和自管理
跨职能工作
在理想情况下，在项目工期内专注于一个项目
在理想情况下，集中办公
优秀特质
创建产品
自组织和自管理
跨职能工作
专注且集中办公
产品负责人
需要做到
设定项目的战略和方向，并设定长期和短期目标
提供或有权获得产品专业知识
理解客户和其他业务干系人的需求，并将其传达给开发团队
对产品需求进行收集、管理以及优先级排序
对产品预算和盈利能力负责
决定已完成功能的发布日期
与开发团队每日协作，回答问题并作出决策
接受或拒绝冲刺阶段完成的工作
每轮乘次结束时，在开发团队演示成果之前介绍Scrum团队的这些成果
优秀特质
提供项目的战略和方向
提供产品专业知识
了解客户与其他干系人的需求
对产品需求进行管理和优先级排序
对预算和盈利能力负责
决定产品发布日期
与开发团队通力协作
接受或拒绝工作成果
在每次冲刺完成时展示已完成的工作成果
Scrum主管
需要做到
作为敏捷流程的教练，帮助项目团队和组织遵循Scrum价值观和实践
以被动和主动的方式帮助扫清项目的障碍，并保护开发团队免受外部干扰
促进干系人和Scrum团队的紧密协作
促进Scrum团队内部建立共识
保护Scrum团队免受组织层面的干扰
优秀品质
秉承Scrum的价值观和实践
扫请障碍
促进外部干系人和Scrum团队的紧密协作
引导建立共识
仆人式领导
其他人员
干系人
包括
客户
可能包括技术人员，例如基础架构师或系统管理员
可能包括法律部门，客户经理、销售人员、市场营销专家和客户服务代表
可能包括除产品负责人以外的产品专家
敏捷导师
以导师的身份服务于Scrum团队，但并不是团队的一部分
往往是组织以外的人员，他们能提供客观的指导，而无需考虑个人和政治因素
是敏捷方法的专家，在实施敏捷和运作不同规模的敏捷项目上拥有丰富的经验
建立新的价值观
Scrum的五大价值观
承诺
Scrum团队必须在作出承诺时面对现实，冲刺阶段尤为如此
整个Scrum团队必须对目标作出承诺
Scrum团队是务实的，必须确保每次冲刺都具有实实在在的价值
Scrum团队愿意对结果负责
专注
在空间与公司的干扰源分隔开
确保你不把时间浪费在于冲刺目标无关的活动上
要搞清楚需要做什么，并且只做需要做的事
平衡专注工作的时间与Scrum团队其他成员交流的时间
检查你是否保持专注
开放
确保团队中的每位成员都能访问相同的信息
保持鼓励他人采取开放的态度
组织谣言来化解内部政治
始终保持对他人的尊重
尊重
推崇开放
鼓励积极的工作环境
找出差异
用同等尊重的态度对待团队中的每位成员
勇气
认识到在过去没问题的流程在现在不一定行得通
准备好突破现状
用尊重迎接质疑
接纳其他价值观
改变团队理念
跨职能工作
鼓励每位团队成员做到
把他能做的工作的条条框框都放到一边
努力拓展技能
当他人遇到障碍时快速伸出援手
保持灵活性
自组织
承诺实现自己的冲刺目标
确定他们的任务
估算需求和相关任务所必须的工作量
专注于沟通
合作
共识决策
积极参与
自管理
允许领导权交换更替
依靠敏捷流程和工具来管理项目
定期以清晰易懂的方式报告进展
管理开发团队内部的问题
创建团队协议
检查与调整
积极参与
控制团队规模（5-9人）
好处
鼓励发展多样化的技能
促进良好的团队沟通
却奥团队齐心协力
促进联合代码所有权、跨职能工作以及面对面沟通。
行为成熟
积极主动
同甘共苦
信任做出正确决策的能力
第七章 定义产品愿景和产品路线图
本章内容要点 1、计划敏捷项目; 2、建立产品愿景; 3、创建产品特性和产品路线图。
产品价值图
阶段一：产品负责人确定产品愿景
四步
设定产品目标
创建声明的草案
需要明确
产品关键目标
客户
需求
竞争
主要差异
与产品和项目干系人确定愿景声明，并根据反馈进行修改
根据以下清单核查并与其他角色一起审核声明
愿景是否明确，是否切中要点，是否面向内部听众
声明是否有利说明了产品是如何满足客户需求的
愿景是否描述了最理想情况下的成果
业务是否足够具体且可以实现
愿景声明中所传递的价值是否和企业的战略目标相一致
项目的愿景声明是否令人信服
最终确定愿景声明
阶段二：产品负责人创建产品路线图
四步
识别产品需求
分解需求
按
主题
特性
史诗故事
用户故事
任务
可以把需求拆分成以上从大到小的规模
整理产品特性
需求分组时需要考虑
客户将会如何使用我们的产品
如果我们提供这个需求，客户还需要做什么？他们还可能希望做什么
开发团队能不能识别技术上的相似性和依赖性
产品特性的估算和排序
三步
给需求价值和工作量打分
在干系人的支持下，产品负责人决定需求对于客户和业务的价值
由开发团队决定创建每项需求所需要的工作量
计算相对优先级
相对优先级=价值/工作量
需求优先级排序
需要先确定
需求的相对优先级是什么
需求的先决条件是什么
哪些需求可以合并成一个可靠的发布
确定了优先级的用户故事列表被称为产品待办列表( Product Backlog
相关术语
工作量
估算
估算需求
需求排序或者优先级排序
价值
决定大致的时间框架
注意保存产品路线图
阶段三：产品负责人创建发布计划
阶段四：产品负责人、Scrum主管和开发团队一起为冲刺（迭代）做计划，然后着手在每个冲次会议中实现这些产品功能
阶段五：在每个冲刺过程中，开发团队通过每日例会来协商当天工作的重点
阶段六：Scrum团队进行冲刺评审
阶段七：Scrum团队进行冲刺回顾
只做必要的计划
检查与调整
产品负责人在冲刺中提供反馈，以此来帮助开发团队改进正在开发的产品
干系人在每个冲刺结束后的评审中为未来的改进提出反馈意见
Scrum团队在每个冲刺结束后的回顾中，讨论在本次冲刺中积累的经验教训，并改进开发流程
在新产品发布后,可以根据正在使用这些产品的用户的反馈来进行产品改进。
第八章 计划发布与冲刺
本章内容要点 1、分解需求并创建用户故事； 2、创建产品待办列表、发布计划和冲刺待办列表; 3、计划敏捷冲刺。
细化需求和估算
用户故事
内容
标题<用户故事的名称>
作为<用户或角色>
我想<采取这样的行动>
以便<我获得这样的益处>
必须
用户故事编码
用户故事价值和工作量估算
提出该用户故事的人员名字
检验
当我<采取行动>时，将产生<这一行为的描述>
创建用户故事的步骤
识别项目干系人
识别谁将使用该产品（识别客户）
确定产品需求和用户故事
分解需求
估算扑克
相似估算
发布计划
完成产品代办列表
应确保
包含对你的需求的描述
按优先级对用户故事进行排序
添加工作量估算
创建发布计划
建立发布目标
通过评审产品待办列表和产品路线图，来确定哪一个是支持发布目标的最高优先级的用户故事
指定发布日期
优化发布目标的用户故事
让开发团队接受首次发布并对这次发布许下承诺
冲刺计划
每次冲刺包括
在冲刺开始时进行冲刺计划
每日例会
开发时间--冲刺额主体
冲刺结束时进行冲刺评审和冲刺回顾
冲刺待办列表
为你的冲刺设立目标
选择支持这些目标的用户故事
将用户故事分解为具体的开发任务
创建一个冲刺待办列表，该冲刺列表包括
冲刺内按优先级排序的用户故事清单
每个用户故事的相对工作量的估算
开发每个用户故事的必要任务
完成每个任务的工作量（以小时单位）
燃尽图，用于显示开发团队已完成的工作状况
只有开发团队可以修改
每个任务的时长不应超过1天
备注
冲刺计划会议
用时间盒技术限制每一星期冲刺会议时间在2小时之内
会议
设置目标和选择用户故事
讨论并设定冲刺目标
评审来自产品代办列表的用于支持冲刺目标的用户故事，并修订他们的相关估算
确定团队在当前冲刺中可以做出哪些承诺
为冲刺待办列表创建任务
创建与每个用户故事相关联的冲刺待办列表任务。请确保任务围绕着完工定义的每一部分:巳开发、巳集成、已测试和巳归档;
再次检查确认团队可以在冲刺的可用时间内完成的任务;
每名开发团队成员应该选择他/她的首要完成任务
第九章 全天的工作
本章内容要点 1、计划每天的工作; 2、跟踪每天的进展; 3、开发并测试每天的工作; 4、结東一天的工作。
计划一天的工作：每日例会
内容
昨天，我完成了【列出完成的工作】
今天，我准备做【列出要做的任务】
我遇到的障碍是【如果有的话，列出具体障碍】
需遵循的准则
任何人都可以参加每日例会,但只有开发团队成员、Scrum主管和产品负责人可以发言
会议只关注当前的工作。
会议是为了促进团队交流合作而不是解决问题。
每日例会是为了团队成员个体之间的平等交流合作,而不是所有人向其中一人汇报状态,比如Scrum主管或产品负责人。
因为会议非常短,必须准时开始。
Scrum团队可以要求参会人员站着而不是坐着
跟踪进展
冲刺待办列表
任务板
冲刺中的敏捷角色
开发团队
选择需求最高的任务并尽快完成;
对某个用户故事不清楚的时候,要求产品负责人澄清
跟开发团队其他成员合作设计某个特定的用户故事,如有需要则寻求他人帮助,其他成员需要的时候你也要帮助他们;
组织同行评审彼此的工作;
根据冲刺需要接受你正常角色以外的任务;
根据确认的完工定义,开发出完整的功能
每天报告你的进展;
向S c r u m主管报告任何你自己无法有效解决的障碍;
完成你在冲刺计划时承诺的冲刺目标。
产品负责人
确保资金到位以保证开发的速度;
排定产品功能优先级列表;
面对开发团队的产品干系人的代表;
向产品干系人汇报项目成本及进度状态;
为开发团队详细解释用户故事,以保证团队完全理解用户故事要创建的功能;
对任何需求事项提供快速澄清和决定,以保证开发团队的工作持续进行;
解决 Scrum主管上报的业务障碍;
对已完成的用户故事里的功能做全面的评审并向开发团队提出反馈意见;
根据需要向产品待办列表中添加新的用户故事,并保证新的用户故事支持产品愿景、发布目标或冲刺目标;
展望下一个冲刺,并为下一个冲刺的冲刺计划会议准备好详尽的用户故事。
Scrum主管
必要时,对产品负责人、开发团队和组织进行培训,以保证敏捷价值的实现和敏捷实践的顺利开展;
保护开发团队不受外界干扰;
移除障碍,解决战术性的短期问题和潜在的战略性的长期问题;
促进 Scrum团队内达成共识;
和那些与 Scrum团队一起工作的干系人建立紧密的合作关系。
创建可交付功能
细化
开发
让开发团队结对完成任务
遵循开发团队商定好的设计标准。
在开发前先建立自动化测试。
如果在开发过程中出现新的、可有可无的功能需求,把它们加到产品待办列表中。
集成当天已完成编码的变更,一次一个集合。对已完成编码的变更进行测试,以保证变更1 0 0 %的正确。
进行代码评审以保证遵循代码开发标准。
在工作进行过程中,同步创建技术文档。
验证
自动化测试
单元测试
系统测试
静态测试
同行评审
产品负责人评审
第十章 展示工作和集成反馈
本章内容要点 1、展示工作并收集反馈; 2、评审冲刺并改进流程。
冲刺评审
准备演示
代码必须是经过充分的
开发
测试
集成
归档
冲刺评审会议
会议时长保持在每冲刺时长一周/一小时
在评审会议中手机反馈
冲刺回顾
计划回顾
哪些任务进行得比较好
哪些可以改进
将当前冲刺和之前的冲刺进行比较
冲刺回顾会议
以行动为导向
会议时长保持在每冲刺时长一周/45分钟
主要问题
冲刺中哪些任务进行的比较好?
我们想做哪些改变?
我们如何实施这些改变?
其他话题
成果
人员
关系
流程
工具
生产力
议程
准备目标
收集数据
产生顿悟
结束回顾
检查与调整
第十一章 为发布做准备
本章内容要点 1、让你的产品做好发布的准备; 2、让你的组织做好发布的准备 3、确保市场环境适合发布。
准备部署产品：发布冲刺
主要区别
发布冲刺包括了在开发冲刺中无法进行的测试和审批工作,比如性能测试、负载测试、安全测试、焦点小组和法律审查。
待办项
为最新版本的产品创建用户文档
性能测试、负载测试、安全测试和任何其他可以确保软件投产后正常运行的检查;
和企业级系统的整合,这项测试也许要花几天到几周的时间
完成发布前必须执行的一些强制性的组织或监管程序;
准备发布记录一关于产品变更的最终记录;
准备部署打包,使所有包含产品特性的代码可以同时迁移到生产环境中
将代码部署到生产环境中。
让组织为产品部署做准备
市场部
销售部
生产部
产品支持部
法务部
。。。
让市场为产品部署做准备
营销支持
客户测试
营销物料
支持渠道
第十二章 范围和采购管理
本章内容要点 1、发现敏捷项目中范围管理的不同; 2、使用敏捷过程管理范围和范围变更; 3、了解敏捷过程带给项目采购的不同方法; 4、管理敏捷项目中的采购。
敏捷中的范围管理
通过询问关于需求的关键问题，来评估新需求是否属于项目、发布或者冲刺中的一部分
评估新需求所需要的工作量
将这项需求和产品待办列表上的其他需求进项优先级比较，并根据优先级顺序，将其加入产品代办列表
敏捷中的采购管理
定义需求和选择供应商
供应商是否可以适应敏捷项目环境,如果适应,供应商有多少敏捷项目经验;
供应商是否可以与开发团队一起现场办公;
供应商和 Scrum团队间是否有可能建立积极合作的关系。
采购服务合同和成本方法
成本结构
固定总价项目
固定时间项目
工料项目
天花板项目
创建合同
供应商将要完成工作的描述
供应商可能使用的敏捷方法
供应商将要参加的会议
在每次冲刺技术后交可科工作的功能
完工定义
供应商将要提供的工件
供应商计划好将要投入计划中的人员
供应商是否将在你的公司现场办公
供应商是与其内部的 Scrum主管和产品负责人一起工作,还是同你的Scrum主管和产品负责人合作
如果供应商不使用敏捷方法,则描述供应商及其承担的工作将如何与买方的开发团队和冲刺进行整合。
针对采购的组织考虑
公司或组织的规模和经验
公司或组织的类型
公司或组织的文化
与供应商合作
合同收尾
第十三章 时间和成本管理
本章内容要点 1、理解敏捷项目时间管理的独到之处; 2、探寻如何在敏捷项目中管理时间 3、认识敏捷项目成本管理的不同之处; 4、领会敏捷项目如何管理成本。
时间管理
战略战术
早期的计划实际上就是战略级的
为每次发布和冲刺所做的详细计划都是战术级别的
一旦你的项目开始，Scrum团队的速率就可用于调整你的进度安排
确定一个敏捷项目的周期由以下因素决定
指定的截止时间
预算考虑
已完成的功能
速率
请避免在一个项目开始之前或者甚至在冲刺进行中,试图猜测S c r u m团队的速率。使用S c r u m团队实际的速率来预测整个项目可能持续多久以及相应的成本。
计算速率
在每次冲刺结束时,S c r u m团队检查已完成的需求并累加与这些需求相关的所有故事点,所得到的故事点总数就是这次冲刺中S c r u m团队的速率。
使用速率估算项目时间表
合计产品待办列表中剩余需求所对应的故事点数。
将步骤1 所得到的故事点总数除以速率,可以确定你需要进行的冲刺数量。
如果采用最悲观的估计,则使用开发团队已达到的最低速率;
如果采用最乐观的估计,则使用开发团队已达到的最高速率;
如果采用最可能的估计,则使用开发团队已达到的平均速率。
将冲刺的周期乘以剩余的冲刺数量,可以得到完成产品待办列表上故事点所需要的时间。
提升速率
移除项目障碍
规避项目障碍
消除干扰
征求团队意见
有用速率的一致性
一致的冲刺周期
一致的工作时间
一致的开发团队
从时间角度管理范围变更
优先级排序
将项目延期
提升团队速率
多团队时间管理
多团队工作分解
多团队结构
额外的每日例会（Scrum联席会议）
联合冲刺回顾
使用敏捷工件进行时间管理
产品路线图
产品待办列表
发布计划
冲刺待办列表
成本管理
创建初始预算
Scrum团队成本
硬件成本
托管成本
培训成本
团队费用杂项
创建一个自筹资项目
利用速率来确定长期成本
通过提高速率来降低成本
通过减少时间来降低成本
放弃低优先级需求
决定项目是否应该结束（V<AC+OC）
在产品待办列表中剩余需求的价值(V);
为完成产品待办列表中的需求所需工作量的实际成本(AC);
机会成本(OC),或者让 Scrum团队实施一个新项目所产生的价值
其他成本
使用敏捷工件进行成本管理
第十四章 团队活力与沟通管理
本章内容要点: 1、认识敏捷团队活力因何不同; 2、探究如何与敏捷团队共事; 3、理解敏捷项目沟通如何不同 4、领会敏捷项目中的沟通机制。
管理团队活力
走向自管理和自组织
支持团队：仆人式领导
倾听
同理心
治疗
意识
说服力
概念化
远见
管家
致力于人的成长
建立社区
专职的团队
保持团队成员再次只专注于一个项目，有助于防止被干扰
专职的Scrum团队成员清楚地知道每天将要做什么
专职的Scrum团队受到的干扰较少，因此犯错的几率也就越小
专职的Scrum团队成员能够对项目提出更多的创新
专职的Scrum团队中人们在工作时的幸福感可能更强
专职S的crum团队可以准确的计算出速率
跨职能团队
虽然任务切换降低了生产率,但是跨职能却是有效的,这是因为你并未改变你所工作的实际环境,你只是从不同的角度处理同样的问题而已。事实上,处理同一个问题的不同方面会增加知识的深度并提高你的能力,从而把工作做得更好
建立敏捷环境
使每个人都
感觉到安全
以积极的方式表达想法
挑战现状
坦诚所面临的挑战而不受到惩罚
申请那些可以改变项目的资源
犯错并从错误中学习
建议改变并让其他 Scrum团队成员认真考虑那些变化;
尊重 Scrum团队的同事;
受到 Scrum团队其他成员的尊重
限制开发团队规模（5-9）
利于沟通
避免形成小团队
足够多跨职能团队成员
管理分散团队的项目
分布式Scrum团队
孤岛式Scrum团队
分布式Scrum联席会议
集成式Scrum
沟通
使用视频会议技术模拟面对面谈话
如果在项目中不便安排多次,也请至少安排一次团队集中的现场会议。
使用在线协作工具
将Sc r u m团队成员的照片发布到在线协作工具上,或者甚至可以包含在电子邮件签名档中。
认识到时区的差异。
灵活适应时区差异
如果你对一次交谈或者一封邮件有任何疑问,请要求澄清。
要意识到S c r u m团队成员在语言和文化方面的差异,特别是当你和多个国家的团队一起工作时。
有时特地尝试讨论—些与工作无关的话题。
沟通管理
第十五章 质量和风险管理
本章内容要点 1、学习敏捷项目管理中优质的方法如何降低项目风险; 2、 了解积极地确保优质开发的方法; 3、领会如何利用自动化测试提高生产力; 4、理解敏捷项目方法如何降低风险。
主动型质量管理
良好实践
强调技术卓越和良好设计
将特定质量开发技术引入产品生产
测试驱动开发（TDD）
结对编程
同行评审
代码集体所有制
持续集成
开发团队和产品负责人之间进行日常交流
用户故事中包含验收标准
面对面沟通和集中办公
可持续开发（避免加班或过度加班）
对工作和行为进行定期检查和调整
自动化测试
步骤
在白天编写代码并进行自动化测试来支持用户故事
在白天结束前创建集成的代码构建
在夜晚运行自动化测试软禁已测试最新的构建
每天早上首先检查自动化测试的结果
立即修复任何发现的漏洞
类型
单元测试
回归测试
用户验收测试
功能测试
集成测试
性能测试
静态测试
风险
从根本上降低风险
完工定义
已开发
已测试
已集成
已归档
自筹资
从失败中快速抽身
风险的识别、优先级排序和响应
在工件或会议中提出并解决
第十六章 构建敏捷基础
本章内容要点 1、获得组织和个人的承诺 2、招聘合适的人员; 3、建立适当的环境; 4、开展培训获得持续的支持。
组织和个人的承诺
组织承诺