1、理解敏捷
1.1项目管理现代化
- 项目管理需要变革
- 敏捷项目管理简介
- 敏捷项目管理是一种项目管理方式，该方式聚焦于商业价值的尽早交付 项目产品和流程的待续改进、范圉的灵活性、团队的投入以及交付能反映客户需求且经过充分测试的产品
- 敏捷项目运作：敏捷方法是基于经验型控制法 种根据实际项目中的现实观测而做出决策的流程
- 透明性 每一位敏捷项目成员都知道即将做什么以及项目进展如何
- 经常性 检查投资于产品并运行项目的人应该定期评估该产品和流程
- 适应 对细小问题做快速调整，如果检查结果表明你应当做出改变，那么立即改变
敏捷项目特点
个体和互动 高于流程和工具；
- 可工作软件 高于详尽的文档；
- 客户合作 高于合同谈判；
- 响应变化 高于遵循计划
敏捷宣言四项核心价值
- 价值1 : 个体和互动高于流程和工具
- 价值 2: 可工作软件高于详尽的文档
- 价值3 : 客户合作高于合同谈判
- 价值 4: 响应变化高于遵循计划
敏捷12原则
- 第1条，我们最优先考虑的是尽早和持续不断地交付有价值的软件，从而使客户满意
- 第2条，即使在开发后期也欢迎需求变更 敏捷过程利用变更可以为客户创造竞争优势
- 第3条，采用较短的项目周期（从几周到几个月），不断地交付可工作软件
- 第4条，业务人员和开发人员必须在整个项目期间每天一起工作
- 第5条，围绕富有进取心的个体而创建项目 为他们提供所需的环境和支持，信任他们所开展的工作
- 第6条，不论团队内外，传递信息效果最好且效率最高的方式是面对面交谈
- 第7条，可工作软件是度届进度的首要指标
- 第8条，敏捷过程倡导可待续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐
- 第9条，坚待不懈地追求技术卓越和良好的设计，从而增强敏捷能力
- 第10条，以简洁为本，最大限度地减少工作量
- 第11条，最好的架构、需求和设计出自于自组织团队
- 第12条，团队定期地反思如何能提高成效，并相应地协调和调整自身的行为这些敏捷原则为开发团队提供了实践指南
附加白金原则
- 抵制形式化
- 团队思考与行动
- 可视化而非书写
1.3为什么敏捷工作更有效
评估敏捷方法的收益
敏捷方法如何优干传统方法
敏捷框架具有明显的优势，包括更大的灵活性和稳定性、更少的非生产性工作、更快的高质址交付、更高的开发团队绩效、更严格的项目管控和更快的失败检测
敏捷项目团队
产品负责人
- 产品负责人是敏捷项目团队成员之一，是产品和客户商业需求方面的专家 产品负责人关注商业客户和产品需求的优先级，并且通过为开发团队提供产品说明以及最终的验收来支待开发团队
- Scrum主管
- Scrum 主管通常作为开发团队和能使开发效率变缓的干扰因素之间的缓冲剂， Scrum 主管同时提供关千敏捷过程的专业知识，帮助消除那些阻止开发团队前进的障碍， Scrum 主管同时负责促进共识的建立以及干系人之间的沟通
- 开发人员
- 测试人员
- 其他交付人员
敏捷项目优点
- 更大的灵活性和稳定性
- 减少非生产性任务
- 更高的质量 更快的交付
- 提高团队绩效
- 速度更快 失败成本更低
相关人员收益
高管层
- 效率
- 提升投资回报率的机会
- 软件能够更早交付上市
- 产品质量更高
- 收益机会加速
- 项目能够实现自我创收
- 产品开发和客户
- 提升对变更的适应
- 更大的价值
- 管理层
- 更高的质量
- 更少产品和过程的浪费
- 准时制的开发
- 客户和干系人的参与
- 对千面对面沟通的偏好
- 建立在开发上的变更
- 对软件可工作性的强调
- 强调价值
- 更少、更短、更专注的会议；
- 减少形式主义；
- 刚好够的文档
- 客户和项目团队共同对产品的质量和价值负责
开发团队
精益：实现商业价值和使产品开发之外的活动最小化
- 整体优化
- 消除浪费
- 打造质量
- 持续学习
- 快速交付
- 建立亲密伙伴关系
- 保持成长
- 极限编程： 一种流行的产品开发方法，主要应用于软件领域，它推动软件开发的实践走向极致
- 编码是核心活动
- XP 团队做大量测试
- 让客户和程序员之间直接沟通
- 对千复杂的系统 超越任何具体功能的 某一层次的总体设计是必不可少的
- Scrum：Scrum 是软件开发中最流行的敏捷框架 Scrum 种迭代的方法，它的核心是冲刺 (Scru 的迭代术语）
2.2将敏捷付诸行动：环境篇
创建物理环境
- 集中团队成员
- 设立专用区域
- 消除干扰因素
- 创建移动工作环境
低科技沟通方式
高科技沟通方式
- 视频会议和网络摄像头
- 即时消息软件
- 基于网络的桌面共享
- 协作网站
选择工具
- 选择工具的目的
-
2.3将敏捷付诸行动：行为篇
建立敏捷角色
开发团队成员
直接负责创建项目的可交付成果
- 自组织和自管理， 开发团队成员确定各自的任务以及完成这些任务的方式
- 跨职能工作
- 在理想情况下 在项目工期内专注于一个项目
- 在理想情况下 集中办公
产品负责人
- 设定项目的战略和方向，并设定长期和短期目标；
- 提供或有权获得产品专业知识；
- 理解客户和其他业务干系人的需求，并将其传达给开发团队；
- 对产品需求进行收集、管理以及优先级排序；
- 对产品预算和盈利能力负责；
- 决定已完成功能的发布日期；
- 与开发团队每日协作，回答问题并做出决策；
- 接受或拒绝冲刺阶段完成的工作；
- 每轮冲刺结束时，在开发团队演示成果之前介绍 Scrum 团队的这些成果
scrum主管
- 作为敏捷流程的教练，帮助项目团队和组织遵循 Scrum 价值观和实践；
- 以被动和主动的方式帮助扫清项目的障碍，并保护开发团队免受外部干扰；
- 促进干系人和 Scrum 团队的紧密协作；
- 促进 Scrum 团队内部建立共识；
- 保护 Scrum 团队免受组织层面的干扰
干系人
- 包括客户；
- 可能包括技术人员，例如基础架构师或系统管理员；
- 可能包括法律部门 客户经理 销售人员 市场营销专家和客户服务代表；
- 可能包括除产品负责人以外的产品专家
敏捷导师
- 以导师的角色服务千 Scrum 团队，但并不是团队的 部分；
- 往往是组织以外的人员，他们能提供客观的指导，而无需考虑个人和政治因素；
是敏捷方法的专家，在实施敏捷技术和运作不同规模的敏捷项目上拥有丰富的经验
建立新的价值观
承诺
承诺意味着参与和投入
- Scrum 团队必须在做出承诺时面对现实，冲剌阶段尤为如此
- 整个 Scrum 团队必须对目标作出承诺
- Scrum 团队是务实的 必须确保每次冲刺都具有实实在在的价值
- Scrum 团队愿意对结果负责
专注
- 在空间上与公司的干扰源分隔开
- 确 保你不把时间浪费在与冲刺目标无关的活动上
- 要搞清楚需要做什么 并且只做需要做的事
- 平衡专注工作的时间和与 Scrum 团队其他成员交流的时间
- 检查你是否保持专注
开放
- 确保团队中的每位成员都能访问相同的信息
- 保持井鼓励他人采取开放的态度
- 阻止谣言来化解内部政治
始终保持对他人的尊重
尊重
推崇开放
- 鼓励积极的工作环境
- 找出差异
用同等尊重的态度对待团队中的每位成员
勇气
认识到在过去没问题的流程在现在不一定行得通
- 准备好突破现状
- 用尊重迎接质疑
- 接纳其他价值观
改变团队理念
- 跨职能工作 ：为了创建产品而完成不同类型任务的意愿和能力
- 把他/ 她能做的工作的条条框框都放到一边
- 努力拓展技能
- 当他人遇到障碍时快速伸出援手
- 保持灵活性
自组织：确定如何着手进行产品开发工作的能力和职贡估算需求和相关任务所必需的工作量
- 承诺实现自己的冲刺目标
- 确定他们的任务
- 估算需求和相关任务所必需的工作量
- 专注于沟通
- 合作
- 共识决策
- 积极参与
自管理 ：保持工作正常运作的能力和职责依靠敏捷流程和工具来管理项目工作
- 允许领导权交换更替
- 依靠敏捷流程和工具来管理项目工作
- 定期以清晰易懂的方式报告进展
- 管理开发团队内部的问题
- 创建团队协议
- 检查与调整
- 积极参与
控制团队规模 ：确保开发团队成员人数在 5人到 9人之间
- 鼓励发展多样化的技能；
- 促进良好的团队沟通；
- 确保团队齐心协力；
- 促进联合代码所有权 跨职能工作以及面对面沟通
行为成熟 ：工作积极性高，并对结果负责
- 积极主动
- 同甘共苦
-
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全天的工作
计划一天的工作 每日例会
跟踪进展
- 冲刺待办列表
任务扳
- 待办项
- 进行中
- 待验收
- 已完工
冲剌中的敏捷角色
创建可交付功能
- 细化：产品负责人和开发团队一起细化用户故事，但开发团队对最后的设计有最终决 定权 如果开发团队需要对需求进一步澄清，产品负责人要能够随时提供咨询
- 开发
- 验证
- 自动化测试
- 单元测试
- 系统测试
- 静态测试
- 产品负责人评审
- 同行评审
- 识别障碍
结束一天的工作：每天结束的时候，开发团队会通过更新冲刺待办列表来报告任务进展——哪些 任务完成了，新开始的任务还剩多少小时的工作盘 有些 Scrum 团队所用的软件还 可以根据 冲刺待办列表的内容自动更新冲刺燃尽图。
3.4展示工作和集成反馈
冲剌评审：冲刺评审 在冲刺中展示并评审开发团队完 成的用 户故事的一个会议，任何对在冲刺中完 成的工 作感兴趣的人都可以参加，这 味着所有干系人都有机会了解产品的进展并提出反馈意见。渍示
准备演示开发
- 测试
- 集成
- 归档
冲刺评审会议
- 在评审会议中收集反债
冲剌回顾
让市场为产品部署做准备
范围变更概述
管理范围变更
- 通过询问关于需求的一些关键问题 来评估新需求是否属千项目 发布或者冲刺中的一部分
- 评估新需求所需要的工作量
- 将这项需求和产品待办列表上的其他需求进行优先级比较．井根据优先级顺序 将其加入产品待办列表
如何在敏捷项目中管理采购
定义需求和选择供应商
定义需求
- 产品愿景阶段 开发团队可能开始考虑有助于实现产品目标所必备的工具和技能 在此阶段，可能只是谨慎地研究需求，而不启动采购过程
- 产品路线图阶段 开发团队开始考虑需要创造的特定的特性，并可能知道一些创造产品所必备的商品和服务
- 发布计划 开发团队对千产品了解得更多，并且可以识别那些有助千达成发布目标的特定的商品或服务
- 冲刺计划 开发团队处于开发的第一线，可能会识别一些对本次冲刺而言很迫切的需求
- 每日例会 开发团队的成员提出遇到的阻碍 对商品或者服务的采购可能会帮助团队移除这些障碍
- 全天工 开发团队的成员在共同合作中相互沟通 某些具体的需求可能从开发团队成员之间的谈话中产生
- 冲刺评审 项目干系人可能会为了那些需要采购商品或服务的后续冲刺而识别新的需求
- 冲刺回顾 开发团队可能会讨论某种特定的工具或服务本能如何对过去的冲刺产生作用，同时对后续的冲刺提出采购建议
选择供应商
- 供应商是否可以适应敏捷项目环境，如果适应，供应商有多少敏捷项目经验
- 供应商是否可以与开发团队一起现场办公
- 供应商和 Scrum 团队间是否有可能建立积极合作的关系
采购服务的合同和成本方法
- 成本结构
- 固定总价项目-启动时就有设定的预算
- 固定时间项目-设有具体的截止期限
- 工料项目-比固定成本或者固定时间项目更具开放性
- 天花板项目-项目的工料具有固定的价格上限
- 创建合同
- 供应商将要完成工作的描述
- 供应商可能使用的敏捷方法
- 如果供应商不使用敏捷方法 则描述供应商及其承担的工作将如何与买方的开发团队和冲刺进行整合
- 针对采购的组织考虑
- 公司或组织的规模和经验
- 公司或组织的类型
- 公司或者组织的文化
- 与供应商合作
-
4.2时间和成本管理
敏捷项目时间管理 的不同之处
如何在敏捷项 目中管理时间 早期的计划实际上就是战略级的
- 为每次发布和冲刺所做的详细计划都是战术级的
- 一旦你的项目开始 Scrum 团队的速率就可用千调整你的进度安排
从时间角度管理范围变更
多团队时间管理
- 多团队工作分解
- 多团队结构
- 额外的每日例会：为 Scnun 联席会议 (the Scrum of Scrums ), 这种每日例会一般在各个团队的例会之后开始 ，各开发团队派出代表，彼此之间以及和上一级的集成 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 团队时 你就可以准确地计算出速率 团队的开发速度
跨职能团队
建立敏捷环境
限制开发团队规模：
- 关于敏捷项目团队活力的一个有趣的心理学看点是开发团队的人员数量 开发团队通常有 5-9 名成员 最理想的人数是 名；如果增加或减少两名成员，你仍然可以受益 将开发团队保待在 5-9 名成员的规模，使团队有足够多样化的技能去实现需求，从纸面转化成最终产品 沟通与协作在小团队中更容易 开发团队成员可以轻松地，与其他人交互并取得共识 当你的开发团队有超过 名成员的规模，团队的成员常常被分为多个子小组，进 而形成多个“竖井” 虽然这是正常的社会人的行为，但是子小组对一个力争实现自 管理的开发团队来说．可能意味着分裂 此外，它与更大的开发团队沟通也会更困 难．因为有更多的沟通渠道，也会有更多的机会丢失或者曲解一个消息 当你的开发 团队超过 人，你经常需要另外一个人来帮忙，而他的职责就是帮助管理沟通
管理分散团队的项目
- 使用视频会议技术模拟面对面谈话
- 如果在项目中不便安排多次 也请至少安排一次团队集中的现场会议
- 使用在线协作工具
- 将 Scrum 团队成员的照片发布到在线协作工具上 或者甚至可以包含在电子邮件签名档中
- 认识到时区的差异
- 灵活适应时区差异
- 如果你对一次交谈或者一封邮件有任何疑问 请要求澄清
- 要意识到 Scrum 团队成员在语言和文化方面的差异，特别是当你和多个国家的团队一起工作时
- 有时特地尝试讨论—些与工作无关的话题
如何在敏捷项目中管理沟通
- 理解敏捷项目沟通方法
状态和进展报告
请你每天跟踪冲刺和项目的进展 每日例会 、任务板、 冲刺待办列 表、产品待办列表 、燃尽图和冲刺评审是你用于沟通状态和进展的主要工具
4.4质量和风险管理
质量管理
如何在敏捷项目中管理质量
质量和冲刺
主动型质量管理
- 强调技术卓越和良好设计；
- 将特定质量开发技术引人产品生产；
- 开发团队与产品负责人之间进行日常交流；
- 用户故事中包含验收标准；
- 面对面沟通和集中办公；
- 可持续开发；
- 对工作和行为进行定期检查和调整
持续追求卓越技术和良好设计
质量开发技术
- 测试驱动开发
- 结对编程
- 同行评审
- 代码集体所有制
- 持续集成
产品负责人和开发团队
用户故事和验收标准
面对面沟通
可持续发展
定期检查和调整
自动化测试
- 执行步骤
- (I) 在白天编写代码并进行自动化测试来支持用户故事；
- (2) 在当天结束前创建集成的代码构建；
- (3) 在夜晚运行自动化测试软件以测试最新的构建；
- (4) 每天早上首先检查自动化测试的结果；
- (5) 立即修复任何发现的漏洞
测试类型
- 单元测试 测试产品代码的独立单元或最小组成部分
- 回归测试 测试整个产品的开始到结束，包括之前测试过的需求
- 用户验收测试 产品干系人甚至部分产品终端用户评审并验收最终产品
- 功能测试 确保产品符合用户故事中的验收标准的测试
- 集成 根据需要确保本产品与其他产品不产生冲突的测试
- 性能测试 测试不同场景中产品在特定系统上的运行性能
- 冒烟测试 通过测试系统中少量但重要的部分来帮助确定整个系统正常运行的可能性
-
风险管理
如何在敏捷项目中管理风险
从根本上降低风险
完工定义
- 已开发 此需求必须巳经开发完毕
- 已测试 产品必须经过测试证明可以正常工作且没有任何故障
- 已集成 开发团队必须确保此需求与整个产品以及任何相关系统不产生冲突
- 已归档 开发团队必须已经书面记录此需求的开发过程
- 自筹资 Self- funding 项目
从失败中快速抽身
- 所有产品开发都伴随 定程度的风险 冲刺中的测试引入了从 败中快速抽的理念：敏捷项目的开发团队经过几次冲刺后即可识别导致项目停滞不前的关键问题，而不必在大量资金和精力投入到需求 设计和开发后才发现这些问题 这种定 量风险的减轻可以为组织节省大揽资金
5、确保敏捷成功
5.1构建敏捷基础
组织和个人的承诺
组织承诺
- 聘请有经验的敏捷专家创建 项可行的转型计划，并指导公司实现该计划；
- 在公司第 一个敏捷项目团队成员的培训上就要开始有所投入；
- 为支持精简的敏捷方法，允许 Scrum 团队放弃瀑布式的过程、会议和文件；
- 为每个敏捷项目提供所需的 Scrum 团队成员，他们是开发团队、产品负责人和Scrum主管
- 为敏捷项目提供专职的 Scrum 团队成员；
- 鼓励开发团队跨职能工作，提供自动化测试工具；
- Scrum 团队集中办公提供后勤支持；
- 允许 Scrum 团队自管理；
- 给敏捷项目团队应有的时间和自由来进行必要的测试与试错；
- 过程中要给予敏捷项目团队鼓励，成功后要进行庆祝
个人承诺
- 参加培训和会议，并愿意学习敏捷方法；
- 以开放的心态接受变革，愿意尝试新的流程，并努力培养新的习惯；
- 抵制回到旧有流程的诱惑；
- 愿意为项目团队成员中缺乏敏捷技术方面经验的伙伴提供指导；
- 不怕犯错误，从错误中学习；
- 在冲刺回顾时老老实实地反思，并承诺努力改进；
- 积极融入跨职能的开发团队；
- 放下自我，成为团队的一分子
- 为团队的成功和失败承担责任；
- 主动进行自我管理；
- 积极参与每个敏捷的项目
如何获得承诺
- 一个获得承诺的重要途径是在本组织当前的项目中识别存在的问题并用敏捷的方法提供可行的解决方案 敏捷项目管理可以解决许多问题，包括产品质址、客户满意、团队士气、预算和工期超时，以及项目整体失败等问题
- 何时是转型到敏捷的最佳时机
- 当你需要证明敏捷项目管理的必要性的时候
- 当你考虑做精确预算的时候
- 当你开始一个新项目的时候
- 当你有了新的领导层的时候
- 当你正要进入一个新的市场或行业的时候
选择正确的项目团队成员
- 开发团队
- 用一个词来形容就是多才多艺；
- 愿意做跨部门的工作；
- 计划冲刺并围绕这一计划进行自管理；
- 理解产品需求，并对工作量进行估算；
- 向产品负责人提供技术意见，以便他／她可以理解需求的复杂性，并做出适当的决定；
- 根据情况做出调整，通过调整过程 标准和工具来优化自己的工作业绩
- Scrum主管
- 用一个词来形容就是影响力
- 有足够的组织影响力，能够消除外界的干扰，保证项目团队成功地使用敏捷方法
- 对敏捷项目管理足够了解，以便在整个项目过程中能够帮助项目团队坚持执行敏捷过程；
- 具有指导开发团 达成共识的沟通技巧和说服力
- 充分信任团 ，并允许开发团队自我组织和管理
- 产品负责人
- 用一个词来形容就是果断；
- 非常熟悉客户要求和业务需求；
- 有对产品需求进行优先级排序和再排序的决断力和业务授权；
- 要对产品待办项进行持续的更改；
- 将致力与其余的 Scrum团队 成员合作，直到整个项目结束；
- 有获得项目资金和其他资源的能力
- 敏捷推动者
- 用一个词来形容就是充满激情；
- 对公司流程做出决策；
- 让组织对敏捷流程显现的好处充满期待；
- 为项目团队建立敏捷流程的整个过程中提供支持；
- 为取得第一个项目和以后的项目的成功召集所需的团队成员；
- 积极推进流程升级，消除不必要的于扰和敏捷之外多余的过程
- 敏捷导师
- 用一个词来形容就是经验丰富；
- 成为敏捷过程的专家，尤其要熟悉你的组织所选择的敏捷过程；
- 熟悉不同规模的项目；
- 不接管项目就能够提供有用的建议和支待；
- 能够在项目开始时的第 次冲刺过程中帮助指导项目团队 并且在整个项目
- 期间解答疑问 能够与开发团队的成员、 Scrum 主管和产品负责人很好的合作共处；
- 试着跳出部门或组织之外，用局外人的视角看问题
- 项目干系人
- 用一个词来形容就是参与；
- 在最终产品决定上，能够尊重产品负责人；
- 有意愿有能力参加冲刺评审，并提供产品反馈意见；
- 理解敏捷流程 提供项目于系人与项目团队的其他成员相同的培训，这样会让他们更加容易接受新的管理流程；
- 愿意接受敏捷管理的项目信息模式，例如产品待办列表和冲刺待办列表；
- 当产品负责入和开发团队有问题的时候，能够不厌其烦地详细解答；
- 能够与产品负责人和其他项目团队成员协同工作
- 创建适合敏捷的环境
- 敏捷流程的良好使用
- 透明 ——项目状态和即将到来的流程更改应该是公开的 项目团队和整个组织内的人应该了解项目的详细信息
- 检查 ——把握敏捷流程提供的有规律的机会，来获得项目运行的第一手信息
- 调整 通过跟进检查做出必要的修改，使项目在整个项目期间持续得到改进
- 专职的 Scrum团队
- 集中工作的 Scrum 团队
- 受过良好训练的项目团队
持续地支持敏捷
现在的流程
- 未来的流程
- 循序渐进的计划
- 收益
- 潜在的挑战
- 成功因素
建立转型团队
构建意识和培养热情
- 人员教育
- 强调好处
- 使用各种沟通工具
- 共享实施计划
- 开放的心态
确定一个试点项目
- 恰当的重要性
- 足够的曝光度
- 明确和可控
- 切实可衡量的
确定成功的度量标准
充分培训
制定产品策略
制定产品路线图 产品待办列表和估算
运行你的笫一次冲刺
犯错 收集反馈 加以改进
成熟
推广
- 播种新团队
- 重新定义衡量指标
- 有条不紊地推广
- 识别新的挑战
- 持续学习
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 人点赞
