《敏捷项目管理》-马克• C • 莱顿
2021-04-26 11:04:07 2 举报AI智能生成
登录查看完整内容
敏捷项目管理的实战思维导图。通过本图，你可以学到 在数周内而不是数月内完成你的软件开发；使用敏捷技术降低项目风险，并提升核心收益 ；将敏捷理论付诸实践；避免项目管理普遍存在的误区。该图适合企业管理者 、项目管理者及团队 项目管理认证师以及想了解和学习敏捷项目管理相关知识和技能的初学者和需要考证的项目管理人员阅读。
作者其他创作
大纲/内容
敏捷项目管理
1、理解敏捷
1.1项目管理现代化
项目管理需要变革
敏捷项目管理简介
敏捷项目运作
透明性每一位敏捷项目成员都知道即将做什么以及项目进展如何
经常性检查投资于产品并运行项目的人应该定期评估该产品和流程
适应 对细小问题做快速调整，如果检查结果表明你应当做出改变，那么立即改变
敏捷项目特点
项目成功率
范围蔓延
检查与适应
1.2敏捷宣言与原则
敏捷宣言
个体和互动 高于流程和工具；
可工作软件 高于详尽的文档；
客户合作 高于合同谈判；
响应变化 高于遵循计划
敏捷宣言四项核心价值
价值1 : 个体和互动高于流程和工具
分支主题
价值 2: 可工作软件高于详尽的文档
价值3 : 客户合作高于合同谈判
价值 4: 响应变化高于遵循计划
敏捷12原则
第1条，我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意
第2条，即使在开发后期也欢迎需求变更 敏捷过程利用变更可以为客户创造竞争优势
第3条，采用较短的项目周期（从几周到几个月），不断地交付可工作软件
第4条，业务人员和开发人员必须在整个项目期间每天一起工作
第5条，围绕富有进取心的个体而创建项目 为他们提供所需的环境和支持，信任他们所开展的工作
第6条，不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈
第7条，可工作软件是度届进度的首要指标
第8条，敏捷过程倡导可待续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐
第9条，坚待不懈地追求技术卓越和良好的设计，从而增强敏捷能力
第10条，以简洁为本，最大限度地减少工作量
第11条，最好的架构、需求和设计出自于自组织团队
第12条，团队定期地反思如何能提高成效，并相应地协调和调整自身的行为这些敏捷原则为开发团队提供了实践指南
客户满意度、质量、团队工作、项目管理
附加白金原则
抵制形式化
团队思考与行动
可视化而非书写
1.3为什么敏捷工作更有效
评估敏捷方法的收益
敏捷方法如何优干传统方法
敏捷框架具有明显的优势，包括更大的灵活性和稳定性、更少的非生产性工作、更快的高质址交付、更高的开发团队绩效、更严格的项目管控和更快的失败检测
敏捷项目团队
产品负责人
产品负责人是敏捷项目团队成员之一，是产品和客户商业需求方面的专家 产品负责人关注商业客户和产品需求的优先级，并且通过为开发团队提供产品说明以及最终的验收来支待开发团队
Scrum主管
Scrum 主管通常作为开发团队和能使开发效率变缓的干扰因素之间的缓冲剂， Scrum 主管同时提供关千敏捷过程的专业知识，帮助消除那些阻止开发团队前进的障碍， Scrum 主管同时负责促进共识的建立以及干系人之间的沟通
开发人员
测试人员
其他交付人员
敏捷项目优点
更大的灵活性和稳定性
减少非生产性任务
更高的质量 更快的交付
提高团队绩效
速度更快 失败成本更低
相关人员收益
高管层
效率
提升投资回报率的机会
软件能够更早交付上市
产品质量更高
收益机会加速
项目能够实现自我创收
产品开发和客户
提升对变更的适应
更大的价值
管理层
更高的质量
更少产品和过程的浪费
准时制的开发
客户和干系人的参与
对千面对面沟通的偏好
建立在开发上的变更
对软件可工作性的强调
强调价值
更少、更短、更专注的会议；
减少形式主义；
刚好够的文档
客户和项目团队共同对产品的质量和价值负责
开发团队
一个明确的成功定义（通过在需求开发期间共同制定冲刺目标和验收标准）
独立组织开发活动的权力与尊重；
他们所需要的客户反馈，从而为产品提供价值；
专职 scrum 主管的保护，从而清除障碍和防止破坏；
人性化可持续的工作步伐；
个性化发展和项目改进的学习文化；
非编码时间最小化 的结构
2、走向敏捷
2.1.敏捷框架
敏捷方法
精益
整体优化
消除浪费
打造质量
持续学习
快速交付
建立亲密伙伴关系
保持成长
极限编程
编码是核心活动
XP 团队做大量测试
让客户和程序员之间直接沟通
对千复杂的系统 超越任何具体功能的 某一层次的总体设计是必不可少的
Scrum
2.2将敏捷付诸行动：环境篇
创建物理环境
集中团队成员
设立专用区域
消除干扰因素
创建移动工作环境
低科技沟通方式
高科技沟通方式
视频会议和网络摄像头
即时消息软件
基于网络的桌面共享
协作网站
选择工具
选择工具的目的
组织与兼容性限制
2.3将敏捷付诸行动：行为篇
建立敏捷角色
开发团队成员
直接负责创建项目的可交付成果
自组织和自管理， 开发团队成员确定各自的任务以及完成这些任务的方式
跨职能工作
在理想情况下 在项目工期内专注于一个项目
在理想情况下 集中办公
产品负责人
设定项目的战略和方向，并设定长期和短期目标；
提供或有权获得产品专业知识；
理解客户和其他业务干系人的需求，并将其传达给开发团队；
对产品需求进行收集、管理以及优先级排序；
对产品预算和盈利能力负责；
决定已完成功能的发布日期；
与开发团队每日协作，回答问题并做出决策；
接受或拒绝冲刺阶段完成的工作；
每轮冲刺结束时，在开发团队演示成果之前介绍 Scrum 团队的这些成果
scrum主管
作为敏捷流程的教练，帮助项目团队和组织遵循 Scrum 价值观和实践；
以被动和主动的方式帮助扫清项目的障碍，并保护开发团队免受外部干扰；
促进干系人和 Scrum 团队的紧密协作；
促进 Scrum 团队内部建立共识；
保护 Scrum 团队免受组织层面的干扰
干系人
包括客户；
可能包括技术人员，例如基础架构师或系统管理员；
可能包括法律部门 客户经理 销售人员 市场营销专家和客户服务代表；
可能包括除产品负责人以外的产品专家
敏捷导师
以导师的角色服务千 Scrum 团队，但并不是团队的 部分；
往往是组织以外的人员，他们能提供客观的指导，而无需考虑个人和政治因素；
是敏捷方法的专家，在实施敏捷技术和运作不同规模的敏捷项目上拥有丰富的经验
建立新的价值观
承诺
承诺意味着参与和投入
Scrum 团队必须在做出承诺时面对现实，冲剌阶段尤为如此
整个 Scrum 团队必须对目标作出承诺
Scrum 团队是务实的 必须确保每次冲刺都具有实实在在的价值
Scrum 团队愿意对结果负责
专注
在空间上与公司的干扰源分隔开
确 保你不把时间浪费在与冲刺目标无关的活动上
要搞清楚需要做什么 并且只做需要做的事
平衡专注工作的时间和与 Scrum 团队其他成员交流的时间
检查你是否保持专注
开放
确保团队中的每位成员都能访问相同的信息
保持井鼓励他人采取开放的态度
阻止谣言来化解内部政治
始终保持对他人的尊重
尊重
推崇开放
鼓励积极的工作环境
找出差异
用同等尊重的态度对待团队中的每位成员
勇气
认识到在过去没问题的流程在现在不一定行得通
准备好突破现状
用尊重迎接质疑
接纳其他价值观
改变团队理念
跨职能工作
把他/ 她能做的工作的条条框框都放到一边
努力拓展技能
当他人遇到障碍时快速伸出援手
保持灵活性
自组织
承诺实现自己的冲刺目标
确定他们的任务
估算需求和相关任务所必需的工作量
专注于沟通
合作
共识决策
积极参与
自管理
允许领导权交换更替
依靠敏捷流程和工具来管理项目工作
定期以清晰易懂的方式报告进展
管理开发团队内部的问题
创建团队协议
检查与调整
控制团队规模
鼓励发展多样化的技能；
促进良好的团队沟通；
确保团队齐心协力；
促进联合代码所有权 跨职能工作以及面对面沟通
行为成熟
积极主动
同甘共苦
信任做出正确决策的能力
3、敏捷工作
3.1定义产品愿景和产品路线图
价值路线图
阶段 1: 产品负责人确定产品愿景
阶段2： 产品负责人创建产品路线图
阶段 3: 产品负责人创建发布计划
阶段 4: 产品负责人 Scrum 主管和开发团队一起为冲刺， 也被称为迭代（做计划）， 然后着手在每个冲刺中实现这些产品功能
阶段 5: 在每个冲刺过程中 开发团队通过每日例会 来协商当天工作的重点
阶段6：Scrum 团队进行冲刺评审
阶段 7: Scrum 团队进行冲刺回顾
定义产品愿景
(1) 设定产品目标；
产品关键目标
客户
需求
竞争
主要差异
(2) 创建愿景声明的草案；
(3) 与产品和项目干系人确认愿景声明 并根据反馈进行修改
(4) 最终确定愿景声明
创建产品路线图
(1) 识别产品需求井且把它们加到路线图中
(2) 将产品需求按逻辑分组
(3) 大致估算实现需求所需的工 并且对产品需求进行优先级排序
(4) 设想一 路线图上各个分组 大致时间框架
3.2计划发布与冲刺
细化需求和估算
用户故事
一种对某个产品需求的简单描述，具体来说就是需求是什么、为谁完成
创走用户故事的步掾
(1) 识别项目干系人
识别客户
确定产品需求和创建用户故事
(2) 识别谁将使用该产品
(3)和干系人协作 写下产品将需要达成的需求 井用我在本章前半部分所提到的格式去创建你的用户故事
3.3全天的工作
计划一天的工作 每日例会
跟踪进展
冲刺待办列表
任务扳
待办项
进行中
待验收
已完工
冲剌中的敏捷角色
创建可交付功能
细化
开发
验证
自动化测试
单元测试
系统测试
静态测试
产品负责人评审
同行评审
识别障碍
结束一天的工作
3.4展示工作和集成反馈
冲剌评审
准备演示
测试
集成
归档
冲刺评审会议
在评审会议中收集反债
冲剌回顾
计划回顾
冲刺回顾会议
准备目标
收集数据
产生顿悟
决定做啥
结束回顾
3.5为发布做准备
准备部署产品- 发布冲剌
让组织为产品部器做准备
市场
销售
生产
产品支持
法务部
让市场为产品部署做准备
营销支持
客户测试
营销物料
支持渠道
4、敏捷管理
4.1范围与采购管理
敏捷项目范围管理的不同之处
如何在敏捷项目中管理范图
理解项目范围
愿景
产品路线图
发布计划
冲刺计划
每日例会
冲刺评审
冲刺回顾
范围变更概述
管理范围变更
通过询问关于需求的一些关键问题 来评估新需求是否属千项目 发布或者冲刺中的一部分
评估新需求所需要的工作量
将这项需求和产品待办列表上的其他需求进行优先级比较．井根据优先级顺序 将其加入产品待办列表
敏捷管理在范围管理中的角色
敏捷项目采购管理的不同之处
如何在敏捷项目中管理采购
定义需求和选择供应商
定义需求
产品愿景阶段 开发团队可能开始考虑有助于实现产品目标所必备的工具和技能 在此阶段，可能只是谨慎地研究需求，而不启动采购过程
产品路线图阶段 开发团队开始考虑需要创造的特定的特性，并可能知道一些创造产品所必备的商品和服务
发布计划 开发团队对千产品了解得更多，并且可以识别那些有助千达成发布目标的特定的商品或服务
冲刺计划 开发团队处于开发的第一线，可能会识别一些对本次冲刺而言很迫切的需求
每日例会 开发团队的成员提出遇到的阻碍 对商品或者服务的采购可能会帮助团队移除这些障碍
全天工 开发团队的成员在共同合作中相互沟通 某些具体的需求可能从开发团队成员之间的谈话中产生
冲刺评审 项目干系人可能会为了那些需要采购商品或服务的后续冲刺而识别新的需求
冲刺回顾 开发团队可能会讨论某种特定的工具或服务本能如何对过去的冲刺产生作用，同时对后续的冲刺提出采购建议
选择供应商
供应商是否可以适应敏捷项目环境，如果适应，供应商有多少敏捷项目经验
供应商是否可以与开发团队一起现场办公
供应商和 Scrum 团队间是否有可能建立积极合作的关系
采购服务的合同和成本方法
成本结构
固定总价项目-启动时就有设定的预算
固定时间项目-设有具体的截止期限
工料项目-比固定成本或者固定时间项目更具开放性
天花板项目-项目的工料具有固定的价格上限
创建合同
供应商将要完成工作的描述
供应商可能使用的敏捷方法
如果供应商不使用敏捷方法 则描述供应商及其承担的工作将如何与买方的开发团队和冲刺进行整合
针对采购的组织考虑
公司或组织的规模和经验
公司或组织的类型
公司或者组织的文化
与供应商合作
合同收尾
4.2时间和成本管理
敏捷项目时间管理 的不同之处
如何在敏捷项 目中管理时间
早期的计划实际上就是战略级的
为每次发布和冲刺所做的详细计划都是战术级的
一旦你的项目开始 Scrum 团队的速率就可用千调整你的进度安排
从时间角度管理范围变更
多团队时间管理
多团队工作分解
多团队结构
额外的每日例会
联合冲刺回顾
使用敏捷工件进行时间 管理
敏捷项目成本管理的不同之处
如何在敖捷项目中管理成本
创建初始预算
硬件成本；
软件，包含许可证成本；
托管成本；
培训成本；
团队费用杂项，比如额外的办公用品、团队午餐、差旅费和可能需要的任何工具的费用
创建一个自筹资项目
利用速率来确定长期成本
通过提高速率来降低成本
通过减少时间来降低成本
确定其他成本
使用敏捷工件进行成本管理
4.3团队活力与沟通管理
敏捷项目团队活力的不同之处
如何在敏捷项目中管理团队活力
走向自管理和自组织
支持团队 仆人式领导
倾听—— 仔细倾听 Scrum 团队其他成员的心声，将帮助 crum 团队发现需要互相帮助的领域 为了移除障碍，仆人式领导可能不仅要倾听人们所表达的内容，还要挖掘他们没有说出的话语
同理心——仆人式领导尽力去理解 Scrum 团队中的成员并换位思考，同时促进他们相互之间的理解
治疗——在敏捷项目中，治疗意味着弥补那些不能以人为本的过程所带来的损害。在这些过程中，人被看作是设备和可更换的零件 许多传统项目管理方法可以被称之为“不以人为本"
意识 ——在敏捷项目中，为了更好地服务 Scrum 团队，团队里的人们可能需要知道许多不同层级的活动
说服力 ——仆人式领导依靠的是其公信力，而不是自上而下的权威 强大的说服力和组织级的影响力将帮助 Scrum 主管在公司或者组织内为 scrum 团队摇旗呐喊 此外，仆人式领导还能够将这种说服力传授给 Scrum 团队的其他人，从而帮助维护和谐的氛围并建立共识
概念化 ——在敏捷项目中， Scrum 团队的每个成员都可以使用概念化技能 敏捷项目的发展规律鼓励 Scrum 团队超越自我，大胆想象 无论是为了产品开发还是团队活力，仆人式领导都将有助于培养 Scrum 团队的创造力
远见 ——再次冲刺回顾都能提高 Scrum 团队的预见能力 通过定期检查他们的工作成果、过程和团队活力， Scrum 团队可以不断调整，并明白如何为后续冲刺做出更好的决策
管家 ——仆人式领导是 Scrum 团队需求的“管家"'"管家”意味着信任 Scrum团队成员彼此信任，坚信对方会关注团队和项目整体上的需要
致力于人的成长——成长对于 Scrum 团队形成跨职能工作的能力至关重要人式领导将鼓励和推动 Scrum 团队的学习和成长
建立社区—— 一个 Scrum 团队就是一个自己的社区 仆人式领导将帮助建立和维持社区里的“正能量”
专职的团队
保持团队成员再次只专注于一个项目 有助于防止被干扰
专职的 Scrum 团队成员清楚地知道每天将要做什么
专职 Scrum 团队受到的干扰较少 因此犯错的几率也就越小
专职的scrum 团队成员能够对项目提出更多的创新
专职的scrum 团队中人们在工作时的幸福感可能更强
当你拥有一个每周工作时间相同的专职 Scrum 团队时 你就可以准确地计算出速率 团队的开发速度
跨职能团队
建立敏捷环境
限制开发团队规模
管理分散团队的项目
使用视频会议技术模拟面对面谈话
如果在项目中不便安排多次 也请至少安排一次团队集中的现场会议
使用在线协作工具
将 Scrum 团队成员的照片发布到在线协作工具上 或者甚至可以包含在电子邮件签名档中
认识到时区的差异
灵活适应时区差异
如果你对一次交谈或者一封邮件有任何疑问 请要求澄清
要意识到 Scrum 团队成员在语言和文化方面的差异，特别是当你和多个国家的团队一起工作时
有时特地尝试讨论—些与工作无关的话题
敏捷项目沟通管理的不同之处
如何在敏捷项目中管理沟通
理解敏捷项目沟通方法
状态和进展报告
4.4质量和风险管理
质量管理
敏捷项目质量管理的不同之处
如何在敏捷项目中管理质量
质量和冲刺
主动型质量管理
强调技术卓越和良好设计；
将特定质量开发技术引人产品生产；
开发团队与产品负责人之间进行日常交流；
用户故事中包含验收标准；
面对面沟通和集中办公；
可持续开发；
对工作和行为进行定期检查和调整
持续追求卓越技术和良好设计
质量开发技术
测试驱动开发
结对编程
代码集体所有制
持续集成
产品负责人和开发团队
用户故事和验收标准
面对面沟通
可持续发展
定期检查和调整
执行步骤
(I) 在白天编写代码并进行自动化测试来支持用户故事；
(2) 在当天结束前创建集成的代码构建；
(3) 在夜晚运行自动化测试软件以测试最新的构建；
(4) 每天早上首先检查自动化测试的结果；
(5) 立即修复任何发现的漏洞
测试类型
单元测试 测试产品代码的独立单元或最小组成部分
回归测试 测试整个产品的开始到结束，包括之前测试过的需求
用户验收测试 产品干系人甚至部分产品终端用户评审并验收最终产品
功能测试 确保产品符合用户故事中的验收标准的测试
集成 根据需要确保本产品与其他产品不产生冲突的测试
性能测试 测试不同场景中产品在特定系统上的运行性能
冒烟测试 通过测试系统中少量但重要的部分来帮助确定整个系统正常运行的可能性
静态测试 测试代码的规范性而并非软件的可用性
风险管理
敏捷项目风险管理的不同之处
如何在敏捷项目中管理风险
从根本上降低风险
完工定义
已开发 此需求必须巳经开发完毕
已测试 产品必须经过测试证明可以正常工作且没有任何故障
已集成 开发团队必须确保此需求与整个产品以及任何相关系统不产生冲突
已归档 开发团队必须已经书面记录此需求的开发过程
自筹资 Self- funding 项目
从失败中快速抽身
风险的识别 优先级排序和响应
5、确保敏捷成功
5.1构建敏捷基础
组织和个人的承诺
组织承诺
聘请有经验的敏捷专家创建 项可行的转型计划，并指导公司实现该计划；
在公司第 一个敏捷项目团队成员的培训上就要开始有所投入；
为支持精简的敏捷方法，允许 Scrum 团队放弃瀑布式的过程、会议和文件；
为每个敏捷项目提供所需的 Scrum 团队成员，他们是开发团队、产品负责人和Scrum主管
为敏捷项目提供专职的 Scrum 团队成员；
鼓励开发团队跨职能工作，提供自动化测试工具；
Scrum 团队集中办公提供后勤支持；
允许 Scrum 团队自管理；
给敏捷项目团队应有的时间和自由来进行必要的测试与试错；
过程中要给予敏捷项目团队鼓励，成功后要进行庆祝
个人承诺
参加培训和会议，并愿意学习敏捷方法；
以开放的心态接受变革，愿意尝试新的流程，并努力培养新的习惯；
抵制回到旧有流程的诱惑；
愿意为项目团队成员中缺乏敏捷技术方面经验的伙伴提供指导；
不怕犯错误，从错误中学习；
在冲刺回顾时老老实实地反思，并承诺努力改进；
积极融入跨职能的开发团队；
放下自我，成为团队的一分子
为团队的成功和失败承担责任；
主动进行自我管理；
积极参与每个敏捷的项目
如何获得承诺
何时是转型到敏捷的最佳时机
当你需要证明敏捷项目管理的必要性的时候
当你考虑做精确预算的时候
当你开始一个新项目的时候
当你有了新的领导层的时候
当你正要进入一个新的市场或行业的时候
选择正确的项目团队成员
用一个词来形容就是多才多艺；
愿意做跨部门的工作；
计划冲刺并围绕这一计划进行自管理；
理解产品需求，并对工作量进行估算；
向产品负责人提供技术意见，以便他／她可以理解需求的复杂性，并做出适当的决定；
根据情况做出调整，通过调整过程 标准和工具来优化自己的工作业绩
用一个词来形容就是影响力
有足够的组织影响力，能够消除外界的干扰，保证项目团队成功地使用敏捷方法
对敏捷项目管理足够了解，以便在整个项目过程中能够帮助项目团队坚持执行敏捷过程；
具有指导开发团 达成共识的沟通技巧和说服力
充分信任团 ，并允许开发团队自我组织和管理
用一个词来形容就是果断；
非常熟悉客户要求和业务需求；
有对产品需求进行优先级排序和再排序的决断力和业务授权；
要对产品待办项进行持续的更改；
将致力与其余的 Scrum团队 成员合作，直到整个项目结束；
有获得项目资金和其他资源的能力
敏捷推动者
用一个词来形容就是充满激情；
对公司流程做出决策；
让组织对敏捷流程显现的好处充满期待；
为项目团队建立敏捷流程的整个过程中提供支持；
为取得第一个项目和以后的项目的成功召集所需的团队成员；
积极推进流程升级，消除不必要的于扰和敏捷之外多余的过程
用一个词来形容就是经验丰富；
成为敏捷过程的专家，尤其要熟悉你的组织所选择的敏捷过程；
熟悉不同规模的项目；
不接管项目就能够提供有用的建议和支待；
能够在项目开始时的第 次冲刺过程中帮助指导项目团队 并且在整个项目
期间解答疑问 能够与开发团队的成员、 Scrum 主管和产品负责人很好的合作共处；
试着跳出部门或组织之外，用局外人的视角看问题
项目干系人
用一个词来形容就是参与；
在最终产品决定上，能够尊重产品负责人；
有意愿有能力参加冲刺评审，并提供产品反馈意见；
理解敏捷流程 提供项目于系人与项目团队的其他成员相同的培训，这样会让他们更加容易接受新的管理流程；
愿意接受敏捷管理的项目信息模式，例如产品待办列表和冲刺待办列表；
当产品负责入和开发团队有问题的时候，能够不厌其烦地详细解答；
能够与产品负责人和其他项目团队成员协同工作
创建适合敏捷的环境
敏捷流程的良好使用
透明 ——项目状态和即将到来的流程更改应该是公开的 项目团队和整个组织内的人应该了解项目的详细信息
检查 ——把握敏捷流程提供的有规律的机会，来获得项目运行的第一手信息
调整 通过跟进检查做出必要的修改，使项目在整个项目期间持续得到改进
专职的 Scrum团队
集中工作的 Scrum 团队
受过良好训练的项目团队
持续地支持敏捷
选择一个好的试点项目
拥有一位敏捷导师
充分的沟通
准备好继续前进
5.2成为变革代理人
在你的组织中实施敏捷
制定实施策略
现在的流程
未来的流程
循序渐进的计划
收益
潜在的挑战
成功因素
建立转型团队
构建意识和培养热情
人员教育
强调好处
使用各种沟通工具
共享实施计划
开放的心态
确定一个试点项目
恰当的重要性
足够的曝光度
明确和可控
切实可衡量的
确定成功的度量标准
充分培训
制定产品策略
制定产品路线图 产品待办列表和估算
运行你的笫一次冲刺
犯错 收集反馈 加以改进
成熟
推广
播种新团队
重新定义衡量指标
有条不紊地推广
识别新的挑战
避免陷阱
预防性问题
6、敏捷项目管理重要且有用的信息
6.1敏捷项目管理的十大好处
更好的产品质量
采取积极的方法预防产品质擞问题；
追求技术卓越、良好设计和可持续开发；
即时定义并详细阐述需求，以便对产品特点的认知更清晰；
为用户故事制定验收标准、以便开发团队更好地理解以及产品负责人更准确地验证；
把持续集成和每日测试融合千开发过程中，使开发团队能够将问题解决于萌芽阶段；
利用自动化测试工具， 从而做到白天开发 晚上测试、早晨修正错误；
进行冲刺回顾，使 Scrum 团队不断改进过程与工作；
使用完工定义来完成工作：已开发、已测试、已集成和已归档
更高的客户满意度
把客户看作合作伙伴，使客户全程参与并关注项目；
产品负责人是产品需求和客户需求方面的专家（参看第 章和第 章，了解更多关于产品负责人角色的信息）；
保持对 品待办列表的更新并调整优先级以快速响应变化
在每一次冲刺评审时向客户演示可工作的功能
更经常的发布使产品交付上市更迅速；
具有自筹资项目的潜力
更高的团队士气
加入自 管理团队使人有创造性 创新力 更显得专业化；
聚焦于可持续工作实践让人不至于因为压力或过度劳累而倒下；
采用仆人式领导方法帮助 Scrum 团队自管理，从而有效避免命令与控制方法的使用；
Scrum 团队服务的 Scrum 主管可以帮助消除障碍，并为开发团队屏蔽外部干扰
提供支持和信任的环境，提高人们的整体动力和士气
面对面交谈有助千减少因误解产生的挫折；
跨部门合作让开发团队成员学到新的技能，并通过教授别人而得到进步
增强合作和责任感
每一天开发团队、产品负责人和 Scrum 主管都在一起密切工作；
组织冲刺计划会议，使开发团队能够安排自己的工作；
由开发团队组织的每日例会上，其成员围绕已完成工作、后续工作和工作障碍进行报告；
通过冲刺评审，开发团队可以演示并与干系人直接讨论产品；
通过冲刺回顾，让开发团队成员能够在每个冲刺完成后审视所做的工作并为以后的实践推荐更好的做法；
集中工作，使开发团队成员之间能即时沟通和协作；
通过估算扑克和举手表决，达成决策共识
定制化团队结构
开发团队可以按成员特定的工作风格和个性来构建团队结构 按工作风格构建的组织有这些好处
开发团队也可以根据其成员特定的技能分组或根据产品特性的类型进行分工协作
Scrum 团队可以兼顾团队成员职业和个人生活来制定决策
更多相关的测量指标
基于每个开发团队的实际绩效和能力来确定项目时间表和预算；
针对项目需求，由开发团队自己而非他人提出项目需求估算；
根据开发团队的知识和能力，使用相对估值而不是按小时数或天数来制定工作量
开发团队对项目了解更多后，再按例行规则精确估算工作量、时间和成本；
每天更新冲剌燃尽图，以便准确提供开发团队在每个冲刺的绩效指标；
比较未来开发成本与未来开发价值，帮助项目团队确定结束项目和重新投资到新项目的时间
提高绩效可视性
Scrum 团队 、干系 、客户， 以及任何组织内想了解项目的人中，构建一个、开放的 坦诚的 、高价值的交流平台
每天对冲刺绩效进行评估，并更新冲剌代办列表 冲刺代办列 表可供组织里的任何人查阅
通过每日站会发布开发团队每天的进展和障碍 尽管在每日站会上只有开发团队才可能发言， 但项目团队其他成员也可参加
使用任务板和张贴冲刺燃尽图在开发团队 区展示每天 的实际工作进展
在冲刺评审会议中展示成就 组织中任何人都可以参加冲刺评审会议
增加项目控制
允许组织适应变化对固定时间、固定价格的项目调整优先级；
拥抱变化，使得项目团队能对外部因素如市场需求作出反应；
每日站会让 Scrum 团队能够在问题出现时快速解决；
每日更新冲刺代办列表意味着冲刺燃尽图可以准确地反映冲刺业绩，让 scrum团队能够有机会在问题发生时就立即做出调整；
在面对面交谈中移除沟通上的障碍并解决问题；
冲刺评审让项目干系人看到产品的开发状态，并在发布前对产品提供投入；
冲刺回顾使 Scrum 团队能够在每次冲刺的后期做出积极的调整，以提高产品质量和开发团队绩效，并优化项目流程
提高项目可预测性
在项目初期投资开始，冲刺开发能在很短时间内，要么失败，要么知道产品或方法可行
从最初的冲刺开始，始终都在开发可工作的产品，所以敏捷项目不会完全失败
在每次冲刺中开发已定义的需求，这样不管未来项目发生什么变化项目发起人都能得到完整的、实用的特性
自筹资项目产生的早期回报，使组织支付的项目前期费用更小
6.2敏捷项目管理的十大关键测量指标
冲剌目标成功率
项目总工期
产品上市时间
项目总成本
投资回报率
ROY 预算中的新请求
资金调配
满意度调查
团队成员流动率
6.3敏捷项目管理的十大关键资源
敏捷项目管理在线说明
www.dummies.com/cheatsheet/agileprojectmanagement
Scrum 联盟
http: //Scrumalliance.org
敏捷联盟
www.agilealliance.org
美国项目管理协会的敏捷社区
www.pmi.org/agile
敏捷领导力网络
http: //agileleadershipnetwork.org
雅虎 Scrum 开发群
http: //groups.yahoo.com/group/Scrumdevelopment
InfoQ
www.infoq.com/agile
platinumedge
http : //platinumedge.com
http: //xprogramming.com/what-is-extreme-programming
精益文库
www.leanessays.com
0 条评论
回复 删除
下一页
