具体描述
现在有越来越多的大型产品开发组织开始使用精益思想、敏捷原则和实践方法、大规模Scrum开发来持续、快速交付价值和创新。但是，很多团体在进行面向实践的实施过程中遇到重重阻碍。为什么呢？因为他们没有对思考工具进行深层理解，也没有做到彻底的组织重新设计，这就像在贫瘠的土地上播种。现在，国际公认的顾问与畅销书作者Craig Larman和曾经带领诺基亚网络公司进行敏捷转型的Bas Vodde，利用他们带领和指导团队在大型、多地点、离岸的产品开发中采用精益和敏捷的长期经验，和以优秀团队为基础的敏捷组织的最佳研究，与大家分享一些实施精益和敏捷所必须的关键性思考和组织工具，将成功进行产品开发的种子播种到精益和敏捷企业的沃土中。
作者简介
Craig Larman，进行企业级实施和使用精益开发、敏捷原则和实践以及在大型、多地点、离岸开发中进行Scrum开发的管理和产品开发顾问。他是Valtechl；P度公司(国际咨询和离岸外包公司)的首席科学家。他的著作包括畅销书《敏捷迭代开发：管理者指南》(Addison—Wesley2004年出版)和《UML和模式应用：OOA／D与迭代开发导论》(第3版，Prentice Hall2005年出版)。
Bas Vodde，独立的产品开发顾问和大型Scrum教练。多年来，他发起并指导诺基亚网络公司企业范围的敏捷和Scrum的实施工作。他热衷于提高产品开发、关于组织和团队管理的学习和产品开发的研究，并积极参与编程工作。
译者简介：
孙媛是认证ScrumMaster，《Scrum简介》（Scrum Primer）和《Scrtim敏捷项目管理实战》（The Enterprise and Scrum）的主要翻译人员。现服务于ODD-E公司，该公司致力于在亚洲推广敏捷方法和Scrum技术。
李剑是ThoughtWorks咨询师，InfoQ中文站敏捷社区编辑，曾参与《硝烟中的Scrum和XP》、《实现模式》、《软件开发沉思录：ThoughtWorks文集》等图书的翻译工作。他一直在敏捷实施、面向对象分析与设计等方面为其他公司提供咨询服务，也致力于敏捷思想的传播和应用。
目录信息
前言
第1章 简介
1.1 思考工具和组织工具
1.2 行动工具
1.3 试验：尝试和避免
1.4 局限
第一部分 思考工具
第2章 系统思考
2.1 观察系统动力
2.2 理解心智模型
2.3 举例：“欲速则不达”动力
2.4 找到根源
2.5 发现和获悉局部优化
2.6 结论
推荐资源
第3章 精益思想
3.1 全面了解精益思想
3.2 背景
3.3 精益总结：精益思想屋
3.4 精益目标：持续快速交付价值
3.5 精益基础：精益思想中的经理—导师
3.6 支柱一：尊重他人
3.7 支柱二：持续改善
3.8 14项原则
3.9 精益产品开发
3.10 举例：“看板系统”分析
3.11 结论
推荐资源
第4章 排队论
4.1 尝试——在缩短周期时间上竞争
4.2 利用排队管理来减少周期时间
4.3 排队论
4.4 隐藏的批量：善于发现批量
4.5 隐藏的排队现象：善于发现排队现象
4.6 减少批量规模和周期时间带来的间接利益
4.7 在Scrum中使用排队管理
4.8 约束论
4.9 结论
推荐资源
第5章 错误的两分法
5.1 方法载荷和经验过程与Scrum
5.2 错误的两分法
5.3 避免——极端相对论
5.4 误解
第6章 掌握敏捷精髓
6.1 敏捷宣言：四项价值
6.2 Scrum：五项价值
6.3 十二条敏捷原则
6.4 敏捷管理原则
6.5 结论
推荐资源
第二部分 组织工具
第7章 特性团队
7.1 特性团队简介
7.2 避免——单一功能的团队
7.3 避免——组件团队
7.4 尝试建立——特性团队
7.5 转型
7.6 结论
推荐资源
第8章 团队
8.1 尝试——自组织团队
8.2 尝试——设立具有挑战性且实际可行的目标
8.3 尝试——跨功能团队
8.4 尝试——长期的团队
8.5 尝试——团队控制过程
8.6 尝试——团队管理外部依赖
8.7 尝试——专注的团队成员
8.8 尝试——多技能的员工
8.9 尝试——团队进行决策
8.10 尝试——公开团队矛盾
8.11 对组织产生的影响
8.12 结论
推荐资源
第9章 需求领域
9.1 尝试——一个产品负责人和一个产品待办事项列表
9.2 尝试——需求领域
9.3 转变到需求领域
9.4 工具
9.5 结论
第10章 组织
10.1 目标与策略
10.2 任务
10.3 结构
10.4 过程
10.5 奖金
10.6 人员
10.7 结论
推荐资源
第11章 大型Scrum开发
11.1 概述
11.2 尝试——为小于10个团队的大型Scrum开发准备的框架1
11.3 尝试——为多个团队的大型Scrum开发准备的框架2
11.4 扩展中遇到的问题
11.5 结论
第三部分 杂记
第12章 Scrum简介
12.1 传统软件开发
12.2 敏捷开发和Scrum
12.3 Scrum知识总结
12.4 Scrum中的角色
12.5 开始使用Scrum
12.6 Sprint计划会议
12.7 每日例会
12.8 更新Sprint待办事项列表和Sprint燃尽图
12.9 产品待办事项列表提炼
12.10 结束Sprint
12.11 Sprint评审会议
12.12 Sprint回顾会议
12.13 更新发布待办事项列表和燃尽图
12.14 开始下一个Sprint
12.15 发布Sprint
12.16 发布计划和原始产品待办事项列表提炼
12.17 应用程序或产品的开发
12.18 常见问题
12.19 使用Scrum的成果
推荐资源
参考文献
· · · · · · (收起)
读后感
说这本书能指导大型软件开发，我还真的不相信。 对于第一部分思考工具：参考了《第五项修炼》的系统思考和《精益思想》的理论，第6章掌握敏捷精髓实际上就是一个汇总； 对于第二部门的组织工具：《特性团队》有一定亮点，值得传统组织研究，组织一章也比较有意...
评分说这本书能指导大型软件开发，我还真的不相信。 对于第一部分思考工具：参考了《第五项修炼》的系统思考和《精益思想》的理论，第6章掌握敏捷精髓实际上就是一个汇总； 对于第二部门的组织工具：《特性团队》有一定亮点，值得传统组织研究，组织一章也比较有意...
评分对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧.
评分对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧.
评分Bas和Larman看上去绝对是两种不同类型的人，很奇怪他们能在一起写出这样一本书来。 总体而言，该书还是更多的从思想和组织层面对LEAN和AGILE在大型组织中的应用指明了些思路。对那些工作在大型组织内部的人从事精艺和敏捷无疑是有指导意义的，因为对大部分在大型组织中生活的人...
用户评价
老实说，我最初对这本书的期望并不算太高，因为市面上谈论敏捷的书籍实在太多了，很多都停留在教你如何开站会的表面功夫。然而，这本书的视角非常独特，它聚焦于“大型应用”这个关键词，这恰恰是大多数初级敏捷实践指南常常回避的领域。它没有回避复杂性，反而将复杂性视为必须被系统性解决的工程问题。我特别欣赏其中关于“架构演进”的章节，它讨论了如何在大规模项目中逐步解耦单体应用，而不是提出那种不切实际的“推倒重来”的建议。书中提出的那种“以小步快跑的方式重构核心领域”的理念，给我们团队提供了一张清晰的路线图，让我们不再惧怕那些看似无法触碰的“巨石”代码。更重要的是，它强调了跨职能团队之间的沟通和协作机制设计，这在大型项目导致的“筒仓效应”中至关重要。阅读这本书，感觉就像是跟随一位经验极其丰富的系统架构师在进行一对一的深度辅导。
评分我是一个痴迷于度量和数据驱动决策的人，这本书在数据量化方面的论述，真正击中我的靶心。很多敏捷实践者会陷入“看起来很忙”的假象中，而这本书则提供了一整套量化框架，来衡量我们是否真的在向“交付业务价值”靠近。它不仅仅关注吞吐量（Velocity），还深入探讨了前置时间（Lead Time）和周期时间（Cycle Time）在不同规模团队中的意义和陷阱。最让我眼前一亮的是，书中关于“风险指标和质量门”的讨论。在大型系统中，任何一个细小的质量漏洞都可能引发灾难性的后果，这本书没有将质量视为测试团队的责任，而是将其嵌入到整个开发生命周期，并提供了具体的指标来提前预警潜在的质量风险。这套方法论迫使我们重新审视了持续集成和持续交付管道的健壮性，让我们从“差不多就行”的心态彻底转向了对工程卓越的不懈追求。
评分从操作层面来看，这本书提供的模板和检查清单简直是救命稻草。我过去常常在推行新的流程时，花大量时间去构建内部文档和说服团队成员接受改变，但有了这本书作为“官方蓝图”，一切都变得顺理成河了。它对“跨团队依赖管理”的描述尤其细致入微，作者没有简单地提议“开个会议解决”，而是深入剖析了不同依赖类型（时间依赖、数据依赖、契约依赖）应采取的不同协调策略，并给出了具体的同步机制。这套系统化的方法论，极大地减少了我们在协调多个开发组时产生的摩擦和沟通成本。我惊喜地发现，书中的许多实践，即便在不完全采纳全套敏捷框架的前提下，单独提取出来应用到我们现有的工程实践中，也能带来立竿见影的改善效果。它不是一个僵化的教条，而是一个充满智慧的工具箱。
评分这本书简直是为那些在传统瀑布模型中摸爬滚打多年，如今试图向更现代、更灵活的开发范式转型的技术领导者量身定做的。我记得我翻开第一页时，那种感觉就像是终于找到了一个能把抽象的“敏捷”口号落地到实际操作层面的工具箱。作者并没有满足于仅仅介绍 Scrum 或 Kanban 的基本流程，而是深入探讨了在面对庞大、历史悠久的代码库和复杂的跨团队依赖时，如何安全、有效地引入增量变更。特别是关于“价值流映射”的部分，它彻底改变了我对识别和消除浪费的看法。过去我们总是在抱怨需求变更频繁，但这本书引导我们去审视整个交付管道的阻塞点，从需求提出到最终部署，每一个环节的延迟都被清晰地可视化了。我们团队现在正在尝试使用书中提到的“功能团队化”策略，虽然过程充满挑战，但可见的效率提升是毋庸置疑的。如果你的组织正处于转型的阵痛期，急需一套既有理论深度又有实战指导的参考，这本书绝对值得投入时间去精读。
评分这本书的哲学内核非常深刻，它超越了技术和流程层面，触及到了组织文化和领导力的核心议题。作者反复强调，规模化敏捷的真正挑战不在于技术，而在于如何建立一种鼓励实验、容忍失败、并赋予一线团队决策权的文化土壤。它并没有鼓吹“权威即真理”，而是倡导一种“发现式学习”的组织模式。在阅读过程中，我不断地将书中的理念与我当前组织层面的阻力进行对比，这本书提供的论据非常有力，帮助我更好地向上汇报，解释为什么某些传统管理方式是效率的毒药。它甚至探讨了如何在大型组织中，利用小规模、高自治的“细胞核”团队来驱动自下而上的变革，而不是等待自上而下的命令。如果你是一位渴望推动深刻组织变革的实践者，这本书提供的精神食粮和战略指导，其价值远超其纸面价格。
评分书中的几个思考工具让人眼前一亮，全书偏理论，大型产品组织敏捷转型中的痛点如需求管理，组织变革等并没有深度涉及。
评分随着部门改进的深入，越来越喜欢这本书
评分作者还是比较有理论深度，读过很多文献，也有实战经验。指南这本书的系统思考，精益，排队论等篇章写的很好，让我很好理解了新的事物。 但是，该书还是存在一定的书卷气。这样的变革通常不是只开发才能操作的。要想变革，还牵涉到行政管理，领导的看法。以及中层的人性考虑。 这些事情会是变革的阻力。 大型组织和中小最大的不同就是有不面向市场的食利群体的存在。而扁平化的组织和这个群体的存在是矛盾的。 这下岗的节奏就是最大的阻力。 尽管如此，本书还是写的很漂亮。值得一看。
评分经验越多收获越大
评分Bas Vodde的书。很好
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有