|
关于我们
 书单推荐 新书推荐 |
Scrum精髓：敏捷转型指南 
定 价：79 元
9 7 3 8 6 7 3 3 8 0 5 2 9  短短几年时间，Scrum跃升为敏捷首选方法，在全球各地得以普遍应用。针对如何用好、用巧这个看似简单的框架，本书以通俗易懂的语言、条理清晰的脉络阐述和提炼出Scrum的精髓。全书共4部分23章，阐述了七大核心概念：Scrum框架，敏捷原则，冲刺，需求和用户故事，产品订单，估算与速率，技术债；五大角色：产品负责人，ScrumMaster，开发团队，Scrum团队结构，经理：Scrum规划原则及四大规划活动：多层次规划、产品组合规划、产品规划和长期规划；冲刺四大活动：规划、执行、评审和回顾。 本书取自作者十多年的实践经验，对员工个体和管理层都具有重要的指导和参考意义，可以帮助企业导入Scrum方法实现敏捷转型，从而在动态的商业环境中以积极的心态拥抱变化，做出优秀、卓越的产品，成就创业、守业、常青基业。
上市以来雄踞亚马逊敏捷类畅销书榜首，热评如潮 Scrum精髓，一点就通，一本就够 揭示同类书不告诉你的主题和秘笈 适用于大多数敏捷过程的实用指南 适合团队成员、经理和执行负责人阅读的知识读本 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。作为业内领先的敏捷教练和培训师，KennethRubin用通俗易懂的语言和丰富的实例与我们分享他十多年的实践经验，诠释Scrum的价值观、原则和实践，描述一些灵活、可行的方法帮助我们用好Scrum。 针对Scrum新手和达人，本书从团队、产品和产品组合这三个层面来介绍、澄清和深化Scrum的相关原则和应用。Rubin曾帮助数百个组织成功应用Scrum，积累了相当丰富的实践经验和表达能力。作为这些经验和能力的结晶，本书图文并茂，通过通俗易懂的描述和两百多幅图对Scrum进行了阐述，这些图采用的是一种全新的视觉图标语言，用于描述Scrum的角色、工件和活动。 本书可以帮助团队成员、经理和执行主管了解Scrum常识，掌握可以拿来即用的通用词汇表，充分攫取Scrum的潜力，最终实现优秀团队能够做到持续、稳健发展的目标。
什么是Scrum？2 Scrum的起源3 为什么要用Scrum？5 Genomica取得的成果6 Scrum能给你带来帮助吗？6 复杂域9 繁杂域10 简单域10 混乱域10 无序11 事务性工作11 结语12 第Ⅰ部分 核 心 概 念 第2章 Scrum框架17 概述17 Scrum角色19 产品负责人20 ScrumMaster20 开发团队21 Scrum活动与工件21 产品列表23 冲刺25 制定冲刺计划26 冲刺执行28 每日例会29 完成31 冲刺评审32 冲刺回顾33 结语34 第3章 敏捷原则35 概述35 可变性和不确定性37 积极采用有帮助的可变性38 采用迭代和增量开发39 通过检视、调整和透明充分利用可变性42 同时减少各种各样的不确定因素43 预测和适应44 不到最后时刻，不轻易做决定44 承认无法一开始就把事情做对45 偏好适应性、探索式的方法46 用经济合理的方法接受变化48 平衡预测性的事前工作和适应性的刚好及时工作之间的关系51 经验认知52 快速验证重要的假设52 利用多个认知循环并行的优势53 妥善组织工作流程以获得快速反馈54 WIP56 批量大小要经济合理56 识别并管理库存以达到良好的流动57 关注闲置工作，而非闲置人员59 考虑延期成本61 进度63 根据实时信息来重新制定计划63 通过验证工作结果来度量进度63 聚焦于以价值为中心的交付64 执行65 快速前进，但不匆忙65 以质量为魂65 采用最小够用的仪式66 结语68 第4章 冲刺71 概述71 时长限定72 设定WIP数量限制72 强制排列优先顺序73 展示进度73 避免不必要的完美主义73 促进结束74 增强可预测性74 持续期短74 容易规划74 反馈快74 投入产出比高75 错误有限75 有助于“满血复活”75 检查点多76 一致的持续期77 有节奏感78 简化规划活动79 锁定冲刺目标80 什么是冲刺目标？80 共同承诺80 是变更，还是澄清？80 变更引起的后果81 注重实效83 异常终止84 完成的定义85 什么是完成的定义？86 完成的定义可以随时间演变88 完成的定义还是接收标准？89 完成还是完成-完成90 结语91 第5章 需求与用户故事93 概述93 利用对话96 逐步细化97 用户故事是什么？97 卡片98 对话99 确认100 详细程度101 好故事的INVEST原则104 独立104 可协商105 有价值106 可估算107 大小合适108 可测试108 非功能性需求109 知识获取型故事110 收集故事112 用户故事写作研讨会112 绘制故事地图113 结语115 第6章 产品列表117 概述117 PBI118 产品列表的四大特征119 详略得当119 涌现的120 做过估算的121 排列优先顺序的122 梳理123 什么是梳理？123 由谁来梳理？124 何时梳理？125 就绪的定义127 工作流管理128 版本的工作流管理129 冲刺的工作流管理130 产品列表有哪些，应该有多少？131 什么是产品？132 大型产品，层级化列表133 多个团队，一个产品列表135 一个团队，多个产品136 结语137 第7章 估算与速率139 概述139 何时估，估什么？141 组合列表条目的估算141 产品列表条目的估算142 任务估算143 PBI估算的概念143 团队估算144 估算不是承诺145 准确与精确146 估算相对大小147 PBI估算的单位149 故事点149 理想天149 规划扑克150 估算151 活动规则152 好处155 什么是速率？155 计算速率范围156 预测速率157 影响速率的因素158 速率的误用160 结语161 第8章 技术债163 概述163 技术债的后果165 爆发点不可预期165 交付时间延长166 缺陷数量可观167 开发和支持成本上升167 产品萎缩168 可预测性降低168 表现越来越差168 挫折感四处弥漫168 客户满意度降低169 技术债的起因169 如期完工的压力169 试图以错误的方式提高速率170 误区：减少测试可以提高速率171 债累债172 技术债必须加以管理173 管理应计技术债174 使用良好的技术实践174 使用强完成定义175 正确理解技术债经济175 让技术债可见178 让技术债在业务层面可见178 让技术债在技术层面可见180 偿还技术债181 并非所有技术债都应该偿还182 行将就木的产品183 一次性原型183 短命产品183 应用童子军规则 （有债就还）184 分期偿还技术债185 先偿还高息技术债186 一边做有客户价值的工作，一边偿还技术债186 结语188 第Ⅱ部分 Scrum的角色 第9章 产品负责人191 概述191 主要职责192 管理经济效益193 版本层面的经济考量193 冲刺级别的经济考量194 产品列表的经济考量195 参与规划195 梳理产品列表195 定义接收标准并验证196 与开发团队协作196 与利益干系人协作198 特征∕技能198 领域能力199 人际交往能力200 决策力200 责任心201 日常工作内容201 谁来担任产品负责人？204 内部开发205 商业开发206 外包开发项目208 组件开发209 产品负责人兼任其他角色210 产品负责人团队210 产品负责人代理211 首席产品负责人212 结语213 第10章 ScrumMaster215 概述215 主要职责215 教练215 服务型领导217 过程权威217 “保护伞”217 “清道夫”218 变革代言人218 特征/技能218 见多识广218 善于提问219 有耐心219 有协作精神220 保护团队220 公开透明220 日常工作内容221 履行角色222 谁来担任ScrumMaster？222 ScrumMaster是全职工作吗？223 ScrumMaster兼任其他角色223 结语225 第11章 开发团队227 概述227 专职团队227 主要职责228 冲刺执行229 每日检视和调整229 梳理产品列表229 冲刺规划229 检视和调整产品与过程230 特征/技能230 自组织231 跨职能的多样化和全面化233 T型技能234 火枪手态度236 沟通广泛237 透明沟通239 规模适中239 专注、有责任感240 工作步调可持续242 团队人员稳定243 结语245 第12章 Scrum团队结构247 概述247 特性团队与组件团队248 多团队之间的协调253 SoS253 版本火车255 结语258 第13章 经理259 概述259 塑造团队261 定义边界261 提供一个清晰而鼓舞人心的目标262 组建团队262 改变团队的人员组成263 授权团队264 培育团队265 激励团队265 发展团队能力266 建立职能领导力267 保持团队的完整性267 整改环境268 传播敏捷价值观268 移除组织层面的障碍268 使内部各个团队一致269 使外部合作伙伴一致269 管理价值创造流程270 采用系统化视角270 管理经济效益270 测量和报告271 项目经理272 Scrum团队中的项目管理职责272 保留单独的项目经理角色274 结语278 第Ⅲ部分 规 划 第14章 Scrum的规划原则283 概述283 假设事先无法制定完美计划284 事先规划有帮助，但不宜过度284 最后责任时刻才敲定计划286 关注适应与重新规划胜于遵循计划286 正确管理规划库存288 提倡更小、更频繁发布289 计划快速学习并在必要时 调头291 结语291 第15章 多层级规划293 概述293 组合规划295 产品规划（构想）295 愿景295 概要产品列表296 产品路线图296 版本规划298 冲刺规划300 日常规划301 结语302 第16章 产品组合规划303 概述303 时间安排303 参与者304 流程304 进度安排策略306 优先考虑生命周期利润307 计算延期成本308 估算要准确，不必精确311 流入策略312 应用经济过滤器313 到达率和离开率要平衡314 快速拥抱新涌现的机会316 为更小、更频繁发布做计划317 流出策略318 关注闲置工作， 而非闲置人员318 设立WIP限制319 等待整个团队一起行动320 WIP策略321 使用边际效益321 结语323 第17章 构想（产品规划）325 概述325 时间安排326 参与者327 过程327 示例：SR4U329 建立愿景330 创建概要产品列表333 定义产品路线图334 其他活动337 从经济合理的角度构想产品339 瞄准一个实际的信心阈值340 关注短期收益341 动作要快342 花钱买经验认知343 使用递增/暂行的资助方式344 快速学习并调头 （即快速失败）345 结语346 第18章 版本规划（长期规划）347 概述347 时间安排348 参与者349 过程349 版本约束351 固定一切352 固定范围和日期352 固定范围354 固定日期354 可变质量355 更新约束355 梳理产品列表356 细化最小可发布特性357 冲刺映射（PBI归位）358 版本规划：固定日期版本360 版本规划：固定范围版本365 计算成本367 沟通进展情况368 固定范围版本如何沟通369 固定日期版本如何沟通371 结语373 第Ⅳ部分 冲 刺 第19章 冲刺规划377 概述377 时间安排377 参与者378 流程378 冲刺规划的两种方式380 两段式冲刺规划381 一次性冲刺规划382 确定生产能力382 什么是生产能力？382 用故事点来表示生产能力384 用工时来表示生产能力385 选取PBI386 获得信心386 细化冲刺目标388 敲定承诺388 结语389 第20章 冲刺执行391 概述391 时间安排391 参与者391 流程392 冲刺执行规划393 工作流程管理394 并行工作和蜂拥式394 从哪个PBI开始397 如何安排任务397 需要完成哪些工作？398 谁来做具体工作？398 每日例会399 任务执行：强调技术实践399 沟通401 任务板401 冲刺燃尽图402 冲刺燃烧图404 结语406 第21章 冲刺评审407 概述407 参与者408 准备工作410 确定邀请谁参加410 安排活动日程411 确认冲刺工作完成411 演示准备工作412 确定谁做什么413 方式（方法）413 总结414 演示415 讨论416 调整416 冲刺评审的问题417 签字接收417 断断续续地参与417 大型开发工作418 结语419 第22章 冲刺回顾421 概述421 参与者423 准备工作424 定义回顾重点425 选择练习活动425 收集客观数据426 安排回顾日程426 方式（方法）427 营造氛围429 建立共同背景429 事件时间线431 情绪测震仪431 得出见解432 确定采取行动437 回顾结束438 贯彻执行438 冲刺回顾的问题439 结语442 第23章 前进之路443 Scrum，有完？没完！443 修行靠个人444 分享最佳实践444 使用Scrum探明未来之路446 整装待发！447 后记449 词汇表453 参考文献475
KennethRubin
Ken提供Scrum和敏捷培训与教导服务，旨在帮助企业以更高效、更经济合理的方式开发产品。作为一名认证的Scrum培训师，他曾为1.8万人提供过Scrum和敏捷培训，管理过面向对象项目与企业转型管理过程。他还为数千家公司（从初创公司到财富十强的企业）提供教练服务。Rubin是全球Scrum联盟的首任常务董事，Scrum联盟是一家非盈利机构，着眼于推广Scrum的成功应用。从事开发工作期间，Rubin也是一个能干的多面手，先后担任过Scrum产品负责人、ScrumMaster和开发人员。他的管理经历也很丰富，担任过CEO，COO，工程副总，产品管理副总和专业服务副总。他还是SucceedingwithObjects:DecisionFrameworksforProjectManagement一书的合著者，此书出版于1995年。他还独立开发了业内享有盛誉的OBA/D（对象行为分析与设计）方法论。 姜信宝喜欢新鲜事物，喜欢读书，喜欢分享，愿意和大家共同进步。Agile1001公开课联合发起人之一。CSP,CSM,PMP。热衷和推广敏捷，是国内敏捷社区的主要推动者之一。 米全喜IT行业的一名老兵，敏捷爱好者，在软件开发、测试、项目管理和运行方面都有一定的工作经验，目前从事金融行业IT流程管理工作。参与过《团队之美》、《编程 KennethRubin
推荐序—Mike Cohn
推荐序—Ron Jeffries 推荐序—李国彪 前言 致谢 第1 章引言 什么是Scrum？ Scrum 的起源 为什么要用Scrum？ Genomica 取得的成果 Scrum 能给你带来帮助吗？ 复杂域 繁杂域 简单域 推荐序—Mike Cohn 推荐序—Ron Jeffries 推荐序—李国彪 前言 致谢 第1 章引言 什么是Scrum？ Scrum 的起源 为什么要用Scrum？ Genomica 取得的成果 Scrum 能给你带来帮助吗？ 复杂域 繁杂域 简单域 混乱域 无序 常常被打断的工作 结语 第Ⅰ部分 核心概念 第 2 章 Scrum 框架 概述 Scrum 角色 产品负责人 ScrumMaster 开发团队 Scrum 活动与工件 产品 Backlog 冲刺 制定冲刺计划 目录 冲刺执行 每日例会 完成 冲刺评审 冲刺回顾 结语 第 3 章敏捷原则 概述 可变性和不确定性 积极采用有帮助的可变性 采用迭代和增量开发 通过检查、调整和透明性充分利用可变性 同时减少各种形式的不确定因素 预测与适应 保持选择开放 承认无法一开始就把事情做对 偏好适应性、探索式的方法 用经济合理的方法接受变化 平衡预测性的事前工作和适应性的刚好及时工作之间的关系 经过验证的认知 快速验证重要的假设 利用多个认知循环并行的优势 组织妥善工作流程以获得快速反馈 在制品 批量大小要经济、合理 识别并管理库存以达到良好的流动 考虑延迟成本 进度 根据实时信息来重新制定计划 通过验证工作结果来度量进度 聚焦于以价值为中心的交付 执行 快速前进，但不匆忙 内建质量 采用最小够用的仪式 结语 第 4 章冲刺 概述 时长限定 设定在制品数量限制 强制排列优先顺序 展示进度 避免不必要的完美主义 促进结束 增强可预测性 持续期短 容易制定计划 快速反馈 提高投入产出比 有限的错误 重新焕发活力 频繁的检查点 一致的持续期 节奏感的好处 简化计划过程 所做的变化不允许改变目标 什么是冲刺目标？ 共同的承诺 是变更，还是澄清 变更所引起的后果 注重实效 异常终止 完成的定义 什么是完成的定义 完成的定义可以随时间演变 完成的定义与验收标准的比较 完成还是完成-完成 结语 第 5 章需求与用户故事 概述 利用对话 逐步细化 用户故事是什么 卡片 确认 细化程度 好故事的INVEST 原则 独立 可协商 有价值 可估算 大小合适（小） 可测试 非功能性需求 目录 知识获取型故事 收集故事 用户故事编写研讨会 绘制故事地图 结语 第 6 章产品 Backlog 概述 PBI 哪种方法更适合好的产品Backlog 有何特征 详略得当 涌现的 做过估算的 排列好优先顺序的 修整 什么是修整 由谁来修整？ 何时修整？ 就绪的定义 工作流管理 版本工作流管理 冲刺工作流管理 有哪些产品Backlog，有多少个？ 什么是产品？ 大型产品——层级式Backlog 多个团队，一个产品Backlog 一个团队，多个产品 结语 第 7 章估算与速率 概述 何时估算，估算什么 产品组合Backlog 条目的估算 产品 Backlog 的估算 任务估算 PBI 估算的概念 团队估算 估算不是承诺 准确相比精确 相对大小估算 PBI 估算单位 故事点 理想天数 规划扑克 估算规模 活动规则 好处 什么是速率？ 计算速率范围 预测速率 影响速率 速率的误用 结语 第 8 章技术债 概述 技术债的后果 目录 不知何时爆发 交付时间增长 缺陷数量可观 开发支持成本上升 产品萎缩 可预测度降低 表现欠佳 普遍的挫败感 客户满意度降低 技术债的起因 按期完工的压力 尝试错误地提速 误区：减少测试可以提速 债累债 技术债必须加以管理 管理技术债的增长 使用良好的技术实践 使用强完成标准 正确理解技术债的经济效果 让技术债可见 让技术债在业务层面可见 让技术债在技术层面可见 维护技术债 并非所有技术债都应偿还 行将就木型产品 即扔原型 短命型产品 应用童子军规则（即遇技术债即维护） 增量地偿还技术债 先偿还高利息技术债 边做有客户价值工作边偿还技术债 结语 第Ⅱ部分 Scrum 的角色 第 9 章产品负责人 概述 主要职责 管理经济因素 版本发布层面的经济情况 冲刺级的经济情况 产品 Backlog 的经济因素 参与制定计划 修整产品Backlog 定义验收标准并验证这些标准是否得到满足 与开发团队协作 与利益干系人协作 特征∕技能 领域能力 人际交往能力 决策力 责任心 日常一天 谁应当成为产品负责人？ 内部开发 商业开发 外包开发项目 组件开发 目录 产品负责人兼任其他角色 产品负责人团队 产品负责人代理 首席产品负责人 结语 第 10 章 ScrumMaster 概述 主要职责 教练 服务型领导 过程专家 屏蔽干扰（在Scrum 中通常说“保护团队”） 移除障碍 变革推动者 特征/技能 知识渊博 善于提问 有耐心 有协作精神 给予保护的 透明 日常一天 履行角色 谁应该成为ScrumMaster ScrumMaster 是全职工作吗？ ScrumMaster 兼任其他角色 结语 第 11 章开发团队 概述 专门角色的团队 主要责任 冲刺执行 每日检查和调整 修整产品Backlog 规划冲刺 检查和调整产品和过程 特点和技能 自组织 跨职能的多样化和全面化 T 型技能 火枪手态度 高效沟通 透明沟通 大小合适 专注与承诺 可持续的工作节奏 保持团队持久 结语 第 12 章 Scrum 团队结构 概述 特性团队与组件团队 多个团队的协调 Scrum of Scrums 版本火车 结语 目录 第 13 章经理 概述 塑造团队 定义边界 提供一个清晰而鼓舞人心的目标 组建团队 改变团队的组成 授权团队 培育团队 激励团队 发展团队能力 建立职能领导力 保持团队完整性 调整并改造环境 传播敏捷价值观 移除组织层面的障碍 协调内部多个团队合作 使外部合作伙伴保持一致 管理价值创造的流程 采用系统性视角 管理经济状况 监控测量和报告 项目经理 Scrum 团队中项目管理的职责 保留单独的项目经理角色 结语 第 14 章 Scrum 的规划原则 概述 前期做不好计划 少量前期规划仍有益 最后责任时刻前仍可改变规划 关注适应与重新规划多过遵循计划 正确管理规划库存 偏好更小、更频繁地发布 必要时为快速学习与关键转折作规划 结语 第 15 章多层次规划 概述 产品组合的规划 产品规划（愿景） 愿景 高层次产品Backlog 产品路线图 制定版本计划 制定冲刺计划 制定每日计划 结语 第 16 章产品组合规划 概述 时机 参与者 流程 进度安排策略 为生命周期利润而优化 计算延期成本 目录 准确估算，而不用精确估算 流入策略 应用经济指标 平衡到达日期和离开日期 快速拥抱新涌现的机会 为更小、更频繁的发布做计划 流出策略 关注闲置工作，而非闲置人员 设定在制品限制 等待一个完整的团队 在制品策略 使用边际效益 结语 第 17 章构想（产品规划） 概述 时机 参与者 流程 SR4U 实例 愿景 建立概要产品Backlog 定义产品路线图 其他活动 以经济合理合理的方式建立构想 瞄准切实可行的信心门槛 关注短期范围 快速行动 为经验知识付出代价 使用递增的/暂行资金 快速学习和调头（也称快速失败） 第 18 章版本计划（长期计划） 概述 时间安排 参与者 过程 版本限制条件 固定全部特性 固定范围和日期 固定范围 固定日期 可变质量 更新限制条件 修整产品Backlog 细化最小可发布特性（MRF） 冲刺映射（插入PBI） 固定日期的版本计划 固定范围的版本计划 计算成本 沟通 对固定范围版本的进展情况进行沟通 对固定范围版本的燃尽图进行沟通 固定范围版本的燃烧图 结语 第Ⅳ部分 冲刺 第 19 章冲刺计划 概述 时机 参与者 流程 冲刺计划的方法 两段式冲刺计划 一次性冲刺计划 确定生产能力 什么是生产能力？ 用故事点表示的生产能力 用工时表示生产能力 选取 PBI 获得信心 优化冲刺目标 敲定承诺 结语 第 20 章冲刺执行 概述 时间安排 参与者 流程 冲刺执行计划 工作流动管理 并行工作和蜂拥式 从哪项工作开始 如何安排任务 需要完成什么工作 谁来做具体的工作？ 每日例会 任务执行——技术实践 沟通 任务板 冲刺燃尽图 冲刺燃烧图 结语 第 21 章冲刺评审 概述 参与者 准备工作 确定邀请谁参加 安排活动日程 确认冲刺工作完成了 为演示做准备 确定谁做什么 方法 总结 演示 讨论 调整 有关冲刺评审的问题 签字验收 断断续续地参与 大型开发工作 结语 第 22 章冲刺回顾 概述 参与者 准备工作 定义回顾的重点 选择需要完成的任务 收集客观数据 安排回顾工作 方法 营造氛围 共同的上下文 事件的时间线 情绪测震仪 找出见解 确定措施 选择见解 确定行动 见解 Backlog 结束回顾 进行到底 有关冲刺回顾的问题 结语 第 23 章前进的道路 终极状态是不存在的 找到自己的道路 共享最佳实践 使用 Scrum 发现前进的道路 心动不如行动__
预测与适应
在使用Scrum时，经常需要平衡预测性的事前工作与适应性的适时工作之间的关系。下面五个敏捷原则与这个主题相关： 保持选择开放 承认无法一开始就把事情做对 偏好适应性、探索式的方法 用经济合理的方法积极主动接受变化 在预测性的事前工作和适应性的适时工作之间做出平衡 保持选择开放 对于需求或设计，计划驱动的顺序开发方式要求在当前这个阶段就做出重要的决策并进行审批。而且，在进入下一个阶段之前必须先做出决策，即使这些决策依据的知识有限。 Scrum认为，不该单单因为通用过程要求此时做出决定，我们就得做出不成熟的决定。相反，在使用Scrum时，我们倾向于“保持选择开放”这个策略。这个原则常被称为“最后责任时刻”（LastResponsibleMoment，LRM）（PoppendieckandPoppendieck，2003），意思是推迟做出承诺，直到最后责任时刻再做出重要的、不可逆转的决定。那么，最后责任时刻是什么时候呢？这个时刻就是不做决定的成本大于做决定的成本时（参见图3.6）。此时，就需要做出决定了。 图3.6在最后责任时刻做出决定 为了领会这个原则，我们考虑下面这种情况。在产品开发工作的第一天，我们对自己的工作内容了解得最少。随后的每一天，我们的了解都能多一点点。既然如此，为什么要在第一天或者很早就做出所有最关键且（也许）无法逆转的决定呢？大多数人都倾向于等有更多信息之后再做出更明智的决定。在处理重要的或不可逆转的决定时，如果决策太早且有错，就会处于图3.6中决策成本的指数部分。更好理解决策之后，决策成本会下降（因为市场和技术的确定性增加，做出错误决策的可能性降低了）。这说明我们应该在掌握更多信息之后再做决策。 承认无法一开始就把事情做对 计划驱动的过程不仅要求有完整的需求和全面的计划，还想当然地认为事先就能“把事情做对”。但实际情况是我们基本上不可能事先就能以正确的方式得到所有需求，也不可能基于这些需求以正确方式得出详尽的计划。更糟糕的是，一旦需求有变，还得修改需求和计划基线以适应当时的实际情况（详情参见第5章）。 在Scrum中，我们承认自己不可能事先确定所有需求或计划。事实上，我们认为这样做可能很危险，因为可能漏掉重要的知识而产生大量低质量的需求（参见图3.7）。 图3.7计划驱动的需求获取与产品知识积累 图3.7表明，在使用计划驱动的顺序过程时，在早期产品知识积累有限的时候就产生了大量需求。这样做是有风险的，因为它使我们产生错觉，认为自己已经消除了结果不确定性。一旦了解得更多或事情有变，可能还会造成巨大的浪费（详情参见后文）。 在Scrum中，我们也会预先产生需求和计划，但原则是够用就好，一旦了解更多在建产品的相关知识，我们就会填充需求和计划的细节。毕竟，在开始构建前，即使我们笃定要以什么方式构建哪些特性，但在把早期的增量可交付物放到目标使用环境之后，还是会发现不对劲儿的地方。此时，种种实际情形都会推动我们改变初衷，去做真正适用、适时的东西。 偏好适应性、探索式的方法 使用（或利用）现在已知的东西并对未知的东西进行预测，这是计划驱动的顺序过程关注的重点。Scrum则更倾向于恰当运用探索式方法，在此基础上采用适应性的试错法。 探索指的是通过某些活动来获得知识，例如构建原型、创建概念验证、实施研究或进行试验。换句话说，则是面对不确定，我们通过探索来获取信息。 工具和技术对探索成本有很大的影响。在过去，软件产品开发的探索成本很高，因而采用预测性的、尽量一开始时做对的方法是有利的（参见图3.8）。 图3.8过去的探索成本 举个例子，我在佐治亚理工学院读大一时（上世纪80年代初），我用过几次打孔卡——跟打字机似的，如果出错或需要修改，是很烦人的。必须非常小心地为所有解决方案逐个做打孔卡，然后再排队等待使用大型机，可能得等上24小时才能验证解决方案是否正确，在这样的背景下，“快点试一试，看情况”这个理念是让人很难接受的。即使微不足道的排版错误，也至少得耽误一天的工夫。瀑布过程在面对不确定性时可以仔细考虑当前知识并做出预测，以求找到优化的解决方案，这种做法在经济上是合理的。 幸运的是，现在的工具和技术越来越好，探索成本也随之下降。从经济层面上不再是探索的阻碍。事实上，到如今，快速构建少量内容并根据用户反馈进行调整，其成本往往低于事先投入精力试图一次性做对所有事情。解决方案的目标使用环境（技术）如今已变得更加复杂，所以能够采取这种做法也是很值得庆幸的。 在Scrum中，只要具备足够的知识，就可以得出明智、合理的最终解决方案。然而，在面对不确定性时，不要一厢情愿地预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息得出明智、合理的最终解决方案。通过行动所获得的反馈可以帮助我们确定是否还需要进一步探索以及何时进行。 用经济合理的方法接受变化 我们都知道，使用顺序开发方式时，后期变更成本比早期变更成本高很多（参见图3.9，基于Boehm1981）。 图3.9顺序开发方式的变更成本曲线图 举个例子，分析阶段的变更可能只花1美元，但在后期测试阶段，同样的变更却可能花1000美元。为什么会这样呢？如果分析阶段出现的错误能在现阶段被发现，那么修正成本肯定不高。但如果直到设计阶段才发现这个错误，则不仅需要修正错误需求，可能还要修复基于这个错误需求所做的设计。每往后延一个阶段，错误的影响也越大，甚至出现这样的情况：分析阶段的小错误到测试或运行阶段演变成大错误。 为避免后期变更，顺序开发过程的做法是设法提高预测的准确度，澄清系统需求及其实现过程，再加以严格控制，力求最小化需求和设计变更。 不幸的是，早期活动阶段的过度预测往往适得其反。不仅无法消除变更，反而成为交付延期和预算超支的原因之一。为什么会出现这种有悖常理的事实呢？首先，为了消除昂贵的变更，我们被迫在每个阶段进行过度投资，即做一些不必要、不切实际的工作。其次，在尚未得到干系人对工作产品的反馈以验证我们的假设之前，我们被迫在过程早期对重要的假设进行决策。结果，根据这些假设而产生大量工作产品。后来，在这些假设被证实（或被推翻）或发生变更的时候（例如，需求的出现或演变），很可能得修改或放弃原有的工作成果，这样的情况时有发生。自我实现的预言，其经典模式莫过于此（参见图3.10）。 在Scrum中，我们认为变更是很正常的。我们相信，产品开发所固有的不确定性是无法事先通过加班加点来预测的。因此，必须准备好积极主动迎接变更。不过，在出现变更时，我们希望能比传统开发更经济的方式来处理，即使变更发生在产品开发工作后期。 因此，我们的目标是要让变更成本曲线尽可能长期保持平稳——即使在后期接受变更，开销也是经济合理的。图3.11说明了这个观点。 我们可以通过对在制品数量和工作流进行管理来实现这个目标，因此，与顺序开发相比，在使用Scrum时，变更成本受时间的影响更小。 不管使用哪种方式来进行产品开发，我们都希望有这样的关系：小的需求变更所造成的实现方式变更也相应较小，因而成本变更也小（不难想象，大型变更带来的成本显然更高）。我们从这种关系中希望得到的另外一个特征：不管变更请求何时出现，都要保持这种关系。 图3.10自我实现的预言 图3.11让变更成本曲线趋于平稳 在使用Scrum时，很多工作产品（例如详细需求、设计和测试用例）都是以刚好及时的方式产生的，以免创建非必需的工件。这样，在发生变更时，不必丢弃或重新修改的、基于假设而产生的工作或被迫做出的决定要少得多，因此可以让成本和变更请求的大小更加成比例。 使用顺序开发方式时，库存会随着时间的推移而增加，这意味着早期所建的工件和被迫做出的不成熟决定最终造成变更成本快速上升。这导致图3.11中传统开发方式的曲线在早期就出现拐点（曲线突然上升的那个点）。在使用Scrum开发时，到达某个时间点之后，变更成本和变更请求的比例也会变得很离谱，但这个时间点会出现得更晚一些（如图3.11中的Scrum曲线拐点所示）。 平衡预测性的事前工作和适应性的刚好及时工作之间的关系 计划驱动开发有一个基本的理念：事先得到详细需求和计划是至关重要的，并且做事情要有先后。在Scrum中，我们相信前期工作有帮助，但不宜过度。 在Scrum中，我们承认不可能事先精确获得所有需求和计划。这是否意味着不应该事先做需求和计划呢？当然不是！Scrum的要义是找到平衡点，即使平衡预测性的前期工作和适应性的刚好及时工作之间的平衡（参见图3.12，改编自Cohn2009中的图）。 在开发产品时，应该从经济合理的角度来设置平衡点，满足法规、监管和∕或公司的目标的前提下，尽量根据快速反馈持续进行调整，少做事前预测。 究竟怎样才算平衡？这在一定程度上由这几个因素推动：所建产品的类型、待建产品（结果不确定性）和产品构建方式（方法不确定性）的不确定程度以及开发中的限制。过度预测要求我们在普遍存在不确定性的情况下做出假设。过度调整可能会让我们处于动荡中，让人觉得工作效率低下、混乱。为了能够快速开发创新产品，在我们的工作环境中，一方面要调整，一方面也要通过刚好够的预测来取得平衡，以免陷入混乱。Scrum框架在秩序与混乱之间取得了很好的平衡。
你还可能感兴趣
我要评论
|
