现在即使是最大的开发公司也正逐渐转用敏捷方法，以寻求更高的生产率和更好的质量。但是，大规模敏捷开发很难，而且很难得到公开的案例研究。本书由HP公司的三个敏捷先驱亲笔撰写，展示了他们如何将大规模敏捷开发方法应用于任务关键型的软件开发环境： HP LaserJet打印机的固件。

本书描述了HP公司如何重建整个LaserJet Firmware打印机产品线，展示了敏捷如何在大型和复杂的产品交付过程中兑现其价值和优势。
如今，即使最大的软件开发组织也都开始转型为敏捷软件开发，寻求提高生产率以及提高质量的良方。然而大规模推广敏捷软件开发并非易事，市面上也没有太多可供参考的示例。在本书中3位来自HP的先锋为我们展示了一个完整的、真实的、作为企业最关键项目之一的成功案例——HP LaserJet 打印机固件。
本书讲述了意味深长的心路历程：敏捷原则是不是同样适用于需要重构大量遗留代码的情况？敏捷是不是能够应对交付日期紧迫又不断创新的情况？敏捷是否适合超过400人、业务群分布在多个国家和地区的情况？敏捷能不能一次性提高到10倍以上生产率，并持续提高？
我们的回答是：它能。虽然并不容易，但是我们做到了。

本书主要内容：
将业务目标、敏捷方法、企业级架构紧密结合到一起
关注开发过程中最严重的痛点，并用敏捷方法解决，以此节约大量成本
摒弃不适合大型组织的个别敏捷方法
用敏捷方法创建一个稳定的新架构
用度量来发现问题、讨论问题，实现敏捷流程的不断改进
利用持续集成和质量系统来降低成本、缩短交付日期以及实现自动化部署
用少干涉团队计划活动及轻量级的长远预测方法驯服计划兽
实现有效的项目管理和大型敏捷项目的责任管理
管理和权衡关于组织架构的关键决议
克服美国和印度开发团队之间的文化差异，形成两边的优势互补
选择正确的工具来获得组织内部生产力的数量级提升
使用变更管理原则支持企业灵活性
本书由管理层和架构师合作撰写，作者坦诚地介绍了成功的经验和失败的教训，同时还运用大量实例证明，在HP这样富有挑战的环境下依旧可行的实践方法。书中不仅展示了敏捷为大型组织带来的优势，而且系统地说明了如何实现这个目标。


作者简介
Gary Gruver HP LaserJet Core Firmware Lab的前总监，在HP工作了22年。他目前是Macys.com公司副总裁，负责产品发布、质量和公司运维。Gary既充分掌握了敏捷精髓，又能够在业务及财务上做出必要的决策，促使敏捷转型获得成功。

Mike Young　HP LaserJet Core Firmware Lab项目群经理，负责管理HP LaserJet Core Firmware Lab团队。Mike已经在HP LaserJet打印机开发部工作了18年。在此之前，他曾在Hughes航空公司负责设计卫星控制系统。在这个项目中，他是最主要的敏捷倡导者，负责查看度量报告，并独自处理那些可预见的问题，从而解决开发过程中可能遇到的瓶颈。

Pat Fulghum　HP LaserJet FutureSmart Firmware架构师，是敏捷开发团队的“百宝箱”。Pat在高压的工作环境中始终确保架构的完整性，同时他所设计的架构能够充分保障Firmware开发进程和质量。Pat还热衷于钻研技术及解决技术问题，他同样倡导任何能够提高开发人员生产效率的改进（编译时间、分流时间等），对我们“提高10倍生产率”的愿景充满热情。他已经在HP工作了24年。

译者简介
郑立　HP公司敏捷教练、CSP、管理咨询顾问和资深软件开发工程师，致力于敏捷技术的实践、研究和推广，曾发表论文《敏捷软件开发模型实施研究》，组织并参加了中国敏捷之旅（AgileTour）、 Scrum Gathering China、敏捷中国（Agile China）和其他敏捷活动。在软件开发流程和管理方面有深刻的认识，专注于提高企业级软件的开发效率和品质。译著有《敏捷技能修炼：敏捷软件开发与设计的最佳实践》。


大规模敏捷软件开发领域经典著作，由HP公司3位均拥有20年左右从业经验的敏捷先锋撰写，ThoughtWorks公司执行顾问Jim Highsmith作序推荐，Amazon全五星评价
全面展示跨越3个洲、4个国家和4个业务单位，拥有400位开发人员的大型团队成功实施敏捷方法获得巨大成功的全部过程和宝贵经验，为大规模开发团队应用敏捷方法提供详细指导

敏捷方法现在无处不在，特别是在软件研发领域，在这个领域几乎没有人可以对敏捷做到充耳不闻。在我们周围关于敏捷的图书、敏捷研讨活动和敏捷论坛比比皆是。如果再深入一点，所有关于敏捷的方法都从Scrum、极限编程（XP）和燃尽图（Burndown chart）开始，后来也有新的诸如大规模敏捷（Large-Scale Agile）这样的叫法和“Scrum of Scrums”这样的实践来应对复杂的超过7人的敏捷项目小组。有意思的是，不管上面哪种方法或者理论都融入了“快速响应”（quick to respond）的深层含义。
　　本书其实是在讲一个故事。一个关于如何将敏捷原则应用到大规模的代码库架构重建的同时，又持续创新和持续交付几百万美元的业务需求的故事。一个关于我们学习和掌握敏捷与精益的核心原则，然后结合我们的业务现实情况，有选择地使用敏捷活动，将对我们有意义的实践活动落地的故事。在这个故事中，我们不得不想一些方法将敏捷应用到我们的开发环境中，因为这些方法会大大提高我们的生产效率。在落地过程中，我们需要将敏捷的基本原则和具体的业务限制条件与需求相结合。有很多书籍和文献描述过关于如何实践小型的同地协作的敏捷团队。但是对于一个有400多位开发人员的团队（Firmware）、跨越4个国家、3个洲和汇报给4个业务单位的项目该如何实践敏捷？我们刚开始心存疑虑。我们需要对拥有数百万行代码、25年历史的HP LaserJet打印机架构做一次完整的重建，并且兼容之前所有的功能。同时我们还需要着眼于未来关键的功能创新，使得Firmware不再是一个驱动硬件的代码片段，而是一个跨越多种设备、能提供动态创新生态环境和功能强大的大脑。这个故事中的一切都发生在美国历史上经济下滑持续时间最长的时代之一，因此资源受到了限制。
　　正是这样的环境，驱使我们不断地创新来跨越这个困难。我们先前尝试过几次敏捷转型（从上至下或者从下至上），也积累了越来越多的成功经验。但是这次突如其来地碰到如此复杂的情况，使得我们要采取完全不同的方法来实践敏捷：考虑如何10倍以上地提高开发人员效率；考虑如何逐步实现架构而不是一次性完成架构建设；考虑每个季度发布产品并介绍新的功能给客户，来满足业务需求而不是一次就完成所有功能的建设和发布；同时也要考虑如何将质量建设考虑到每天、每个项目人员，将技术驱动的概念作为开发基础来替代先前如何分配开发人员以及产品功能需求应该花费多久来完成的传统思路。
　　本书中所描述的解决问题的方法更偏向于实践，是以HP公司中一个大型敏捷开发团队4年开发历程为基础，而不是学院派的描述。它描述的是我们如何有重点地选择业务重点和需求，以及在这个过程中我们所走过的一些弯路。本书也描述了敏捷中是如何允许甚至鼓励随时学习和调整我们转型的过程的。有些时候，发现某些方法适用的唯一办法就是排除那些不适用的办法。本书讲述了我们的转型如何在一个大型组织中提高生产率和各个小团队的灵活性，以及如何通过建立度量标准监控每个人的情况，进而从管理层面解决碰到的困难来降低沟通成本和跟踪开发进度。
　　我们写这本书是希望通过这个案例分析可以鼓励更多人开始他们的敏捷之旅，并认识到使用敏捷/精益方法在生产率上能够得到重大突破。这不是敏捷的教科书，因为已经有很多现成的敏捷教科书了。本书是为了让大型组织的领导层，通过简单阅读可以认识到未来变更的可能性和可变程度，以及如何开始变更。本书同时也希望成为在组织考虑敏捷转型的过程中，参与其中的每个人能为此感到兴奋并将其作为敏捷个人之旅动力源泉的催化剂。本书不是定义如何实施敏捷，因为敏捷技巧和方法只是软件生产过程中实现业务转型、提高生产率的工具而已。所以本书更多的是展示我们为什么要实施敏捷，以及如何实施。在本书中同时记载了在转型过程中我们生产效率的极大提高。通过敏捷我们成功地减少了70%的研发成本，同时将释放出来的资源投入到了创新和解决方案设计中。这是一个大规模的组织转型，给我们的业务带来的回报甚丰。我们希望可以通过分享这个故事，让读者了解很多问题其实是共性的，我们项目的问题也可能是你面临的问题，但是面临问题的同时，还需要不断地提高我们的竞争力把业务继续向前推进。
　　本书的另一个目的是给业务带头人或者行业专家带来一些启示。再进一步说就是：软件不仅对技术型的公司同时也对其他任何类型的公司在创造价值和控制成本方面起着很重要的作用。因此，掌握一套先进的软件管理办法，包括技术变更会对业务带来什么样的潜在影响变得越来越重要。本书会展示一个跟以往完全不同的方法，以及它是如何极大地影响开发成本比例结构与产品线的价值取向的。
　　本书（第1～5章）从建立什么样的基础来推行敏捷实施（针对大型组织）开始。
　　我们需要遵循的敏捷的核心原则是什么（第1章）？
　　在你们公司，你想优化的业务驱动是什么？你可以借用敏捷来让你的业务取得成功，而不是被它束缚直到所有人想放弃敏捷为止（第2章）。
　　如何实现一个可以覆盖所有功能的架构，以及如何用敏捷的方式使其就位（第3、4章）？
　　你想创建什么样的文化和管理风格？这一点对于在大型组织里推行敏捷极为有用（第5章）。
　　第6、7两章主要分析使我们提高10倍以上效率的流程细节（Nuts and Bolts）——持续集成、自动化多层次的质量保障、用户故事定义以及轻量级的开发能力预测。我们在整个过程中并不是一帆风顺的，一路上始终结合我们自己的经验并学习从失败经历中得到的教训。当你把敏捷引入到交付产品和功能的过程中时，对敏捷流程做调整以适应我们的环境是非常有必要的。
　　本书接下来的章节（第8～11章）讨论的是我们在庞大、分布式的组织环境中推行大规模敏捷碰到的一些调整，包括如何做项目管理、如何组织团队（职能型还是业务型）以及如何处理跨文化的团队协作。
　　第12～15章详细描述了大型企业级的一些工具、描述了敏捷案例研究后的业务改进、我们内部叫做“企业级敏捷”（enterprise agile）的新概念，以及如何定义firmware/software和其他业务合作伙伴的接口方式。随后我们在书中讨论了大规模敏捷和典型的敏捷应用起来有什么不同。
　　我们的敏捷之旅很早就开始了，而且已经经历了很长时间；这些改变如果压缩到一段时间内去做，那将是一件非常大的工程，所以这部分内容也是本书最重要的内容，第16章讨论了如何逐步取得成功而不是一蹴而就。
　　本书包括了从我们实践经验总结的最佳实践和我们观察到的所得，它同时也展示了如何把所学到的东西应用到一个完全迥异但是强烈需要提高生产率的情况中。所以加入我们这场敏捷之旅吧。尽管你的业务可能跟我们不同，但是不要错过我们推荐的那些极佳的实践（所有的实践在我们这里都在运行中）。跟随着强大的敏捷原则、个性、机遇和约束的指引，将敏捷精髓应用到我们的业务中去。
致谢
　　这里很想列出所有对本书有过帮助的人，但是限于篇幅，遗憾不能覆盖全了。在此首先感谢HP FutureSmart Firmware项目组的所有开发人员、测试人员及经理，是他们使这次变革得以实现。感谢他们的热情、创意、意愿以及承诺使得敏捷转型取得了一次全面的胜利。本书中所展现的概念、实践以及成就都和这个项目里每个人的参与密不可分。这是一场奇妙的敏捷之旅，再次感谢以上各位在这场旅程中的贡献。在这样一场历经艰辛的转型中，没有你们的协同工作和相互学习，这次转型将无从说起。对你们只能说：谢谢！
　　我们同样感谢HP公司副总裁、总经理Von Hansen的支持。是他带领我们进行转型，并鼓励着我们。他帮助我们推动整个转型的进行，一路上给我们足够的支持和鼓励。没有他的支持和积极帮助，我们的转型和这本书就都不会存在。
　　此外，我们还要特别感谢Jim Highsmith认识到本书最早手稿的价值，并一直给予我们支持和鼓励，才使得本书可以完稿。他帮助我们推广敏捷流程，帮助我们争取到需要的帮助，同时也让我们取得和敏捷社区相互学习的机会，对于以上这些工作，我们深感谢意。没有他的领导和支持，也就不会有这本书。
　　最后我们同样感谢所有花时间对本书初稿提供建议的人们。正是他们的帮助，使得本书内容更为精彩。他们是：Jim Highsmith、Jez Humble、Troy Pearse、Ajay Gupta、Arun Dutta、 Keith Moore、Luciano Rocha、Joe Longo、Frank Riskey、Kimon Papahadjopoulos、Steve Townsley、 Michael Turner和Phil Magnuson.

计算机\程序设计

描绘了惠普公司如何重建整个LaserJet Firmware打印机产品线，展示了敏捷是如何在大型和复杂的产品交付过程中兑现其价值和优势。
如今，即使最大的软件开发组织也都开始转型为敏捷软件开发，寻求提高生产率以及提高质量的良方。然而大规模推广敏捷软件开发并非易事，市面上也没有太多可供参考的示例。在本书中三位来自HP的先锋为我们展示了一个完整的、真实的、作为企业最关键项目之一的成功案例——HP LaserJet 打印机固件。
本书讲述了意味深长的心路历程：敏捷原则是不是同样适用于需要重构大量遗留代码的情况？敏捷是不是能够应对交付日期紧迫又不断创新的情况？敏捷是否适合超过400人、业务群分布在多个国家和地区的情况？敏捷能不能够一次性达到10倍以上生产率，并保持不断地提高的目标？
我们的回答是：它能。虽然并不容易，但是我们做到了。
本书主要内容：
• 将业务目标、敏捷方法、企业级架构紧密结合到一起
• 关注开发过程中最严重的痛点，并用敏捷方法解决，以此节约大量成本支出
• 摒弃不适合大型组织的个别敏捷方法
• 用敏捷方法创建一个稳定的新架构
• 用度量来发现问题、讨论问题，实现敏捷流程的不断改进
• 利用持续集成和质量系统来实现降低成本、缩短交付日期以及自动化部署
• 用少干涉团队计划活动及轻量级的长远预测方法驯服计划兽
• 实现有效的项目管理和大型敏捷项目的责任管理
• 管理和权衡关于组织架构上的关键决议
• 克服美国和印度之间的文化差异，形成两边的优势互补
• 选择正确的工具来获得组织内部生产力的数量级提升
• 使用变更管理原则支持企业灵活性
本书由管理层和架构师合作撰写，作者坦诚地介绍了成功的经验和失败的教训，同时还运用大量实例证明，在HP这样富有挑战的环境下依旧可行的实践方法。书中不仅展示了敏捷为大型组织带来的优势，而且系统性地展示了如何实现这个目标。

(美)Gary Gruver, Mike Young, Pat Fulghum 著：暂无简介

郑立 译：暂无简介

几个月前的一天，机械工业出版社华章分社关敏编辑联系我，说有本描述HP公司FutureSmart敏捷组织转型的书，问我是否愿意翻译。在看到本书的完整书名后我立刻就答应下来。作为HP公司的敏捷教练，我有幸参与了全书所描述的案例（当时我不知道他们已经把整个过程记录出书了），现在又成为这本书的翻译者，真是让人深感荣幸。我也希望从一个内部人士的角度，为大家还原这次敏捷转型的前因后果，更加精确地折射出作者想要表达的思想。
　　这本书另外吸引我的地方是，我们请了Jim Highsmith和Jez Humble等业界大师给我们做敏捷咨询。虽然作者和我本人在敏捷方面也有多年经验，但是对于如何正确掌握敏捷原则和使用敏捷实践，不得不承认我们跟大师之间还有差距。这个差距不在于对敏捷知识的了解程度，更多的是在不同环境下，敏捷应该如何接地气，如何加上精益理念，从短期到长期，设计出一条正确的转型之路。只有正视差距才有进步的空间，因此希望读者在阅读本书时，可以更多地从“为什么”的角度去思考转型过程中的种种决定。
　　我把敏捷转型分为三种：个人转型、团队转型和组织转型。这三种类型是相互关联的。通常来说，组织转型必然包括个人和团队转型，团队转型又包括个人转型。但是反过来，这个关系是不成立的。现实中，很多公司的转型其实是团队转型，因为只是在项目层面上做了改进，可以这么说，即使所有团队都做了敏捷转型，也不能称为组织转型，因为这样没有体现出敏捷为组织带来的好处。组织敏捷转型的目标其实只有一个，就是获得最大的投资回报，解决企业存在的最大问题。如果脱离这个目标，就丧失了转型的动力和方向。所以在组织转型之前，一定要提前思考这些问题。在这个案例里，我们通过四年的努力实现了预期的效果。
　　在翻译这本书之前，我也为一些企业做过敏捷咨询，大、小公司都有，但我接触的这么大刀阔斧的转型是第一个。能把整个过程记录下来，展示给大家的也是第一个。所以如果你所在的公司正在进行转型，或者将要进行转型，那么阅读这本书肯定会使你受益良多。
　　这里不得不再次提起前述两位大师与一般敏捷咨询师相比的过人之处。他们不仅真正带过敏捷团队，做过多年咨询工作，还具备一定的开发和架构能力。这三项能力，也是入职敏捷咨询师的基本门槛。此外，他们还有大型企业管理的经验，这是很多人所不具备的。正是因为有了这种经验，在大型企业转型的过程中，他们对存在的问题，以及将会发生的问题都有很好的预判和解决方案。因此本书不仅对转型企业有帮助，对从事敏捷咨询工作的人也有很好的借鉴作用。
　　市面上有很多书是介绍敏捷方法、敏捷概念的。大部分是从作者的角度重新解释以及扩展敏捷实践，再掺杂一些实践的具体例子，从而起到教学作用。而本书是立足于实例，将敏捷方法融入到实例中去，因此大家看到的不再是分离的工程实践，而是一个完整的系统敏捷产品团队将敏捷实践相互贯穿的框架（或者称为体系）。各个工程实践之间应该如何协作、敏捷实践和传统方法的利弊等，都展现得非常清楚。真实实例和教学实例的另一个区别就是，在真实实例里，所采取的实践方法是调整后最适合企业当前或者未来发展的方法，而不是教科书里的方法。这在本书中也强调了多次，作者自己也多次申明他们不是学院派的，案例所采用的敏捷实践可能跟业界所推崇的不一样，但肯定是最适合当前团队的。这里我举个小例子，案例中400多人的团队，我们并没有强制推荐使用Scrum。从业界80%的敏捷团队都使用Scrum的角度来说，这似乎有点不可想象。但这就是事实，原因有很多。而当你了解案例中为什么不强制采用Scrum后，你也会突然发现其实Scrum也有其局限性。就是这种类似的情形，会让读者感受到敏捷在落地的过程中必然要去适应实际业务环境。形式都可能会改变，而唯一不变的是敏捷宣言和原则。
　　在IT领域，其实很多公司都开始了敏捷转型，但很少能看到鲜活的例子，或者能拿出来让其他公司做参考的例子。业界像微软、谷歌等公司其实已经做得非常好了，微软甚至把TFS都设计成支持Scrum模式。然而，即使如此，很多同行还是很少能够知道这些公司究竟是怎么实现这一步的。面对这么多员工、这么多办公区，如何能把开发模式统一转变过来呢？人们多半只知道他们转型后的结果，而忽略了转型的过程。而“东施效颦”往往只能以失败告终。
　　本书描述的案例除了规模较大之外，还有一个特点就是团队比较分散。除了美国之外，HP公司在亚洲和欧洲等地也有许多开发人员，这就是典型的分布式开发方式。对于大型企业来说，为了节约成本、加快开发速度都会选择这个方式，但是如何真正地利用好这一模式，解决地区差异、语言文化差异，是转型的关键。
　　本书有太多卖点我想介绍，不过还是留给读者自己发掘吧，那样会更有意思。如果把看书比成吃饭的话，那么有些书是快餐，可以很快吸收，但是营养不足；有些书是满汉全席，需要细细品味，慢慢咀嚼，很久才能消化。而这本书可以看作是日式料理，我们吃到的都是最精华的部分，每部分的内容都是原汁原味，而且营养绝对丰富。
　　翻译图书虽然很煎熬，之前《敏捷技能修炼》一书的翻译经历让我有过切身体会，但是这本书有太多我无法拒绝的理由。在付出业余时间和收获知识的同时，最后想表达一下对家人的爱意，特别是太太怀孕期间还认真帮我校验书稿，以及大女儿常常露出的可爱笑容，都让我感受到温馨，让家庭充满了乐趣。快乐的生活使我能够坚持本书的翻译，也希望能把这种快乐渗透到书里，传递给各位读者。

郑立

译者序
序
前言
第1章　敏捷原则与敏捷实践 / 1
1.1　《敏捷宣言》背后的原则 / 2
1.2　我们所采用的敏捷/精益原则 / 4
1.3　快速指引：敏捷与瀑布模型的对比 / 8
1.4　小结 / 9
第2章　让敏捷辅佐业务目标 / 11
2.1　背景：HP FutureSmart Firmware案例分析 / 12
2.2　HP FutureSmart Firmware成本和周期驱动优先 / 13
2.3　HP FutureSmart Firmware架构和流程重构的价值主张 / 16
2.4　通过业务分析确立开发目标 / 18
2.5　小结 / 20
第3章　让架构支撑业务目标 / 21
3.1　现有架构的挑战 / 22
3.2　支撑业务的架构：动态演进以及前向兼容 / 23
3.3　持续改进和易于维护的架构 / 27
3.4　小结 / 29
第4章　如何用敏捷理念稳固新架构 / 31
4.1　迭代地重构架构 / 32
4.2　取得进展 / 33
4.3　薄片模型 / 34
4.4　架构演示过程中实现文化上的转变 / 36
4.5　小结 / 37
第5章　大型组织实施敏捷的真正秘密 / 38
5.1　根据群众意愿而改变 / 40
5.2　沟通从度量开始 / 41
5.3　敏捷管理的迭代模型 / 43
5.3.1　小里程碑目标 / 44
5.3.2　将目标关联起来跟踪 / 45
5.3.3　沟通 / 46
5.3.4　学习 / 48
5.3.5　敏捷式调整 / 48
5.4　小结 / 49
第6章　持续集成和质量系统 / 50
6.1　减少编译资源和时间：持续集成　/ 51
6.2　通过持续集成实现高质量：自动化分层测试 / 61
6.2.1　L0测试 / 63
6.2.2　L1测试 / 64
6.2.3　L2测试 / 65
6.2.4　L3测试 / 66
6.2.5　L4测试 / 67
6.2.6　发布流水线的持续改进 / 67
6.3　自动发布流水线带来的生产率 / 68
6.4　企业级软件系统特别需要注意的几个地方 / 70
6.5　小结 / 73
第7章　驯服计划兽 / 74
7.1　用初略预测和趋势观察预测 / 77
7.1.1　初略预测：让R&D部门尽早介入初始工作 / 77
7.1.2　趋势观察预测：快速反馈需求提出者（他们想在什么时候要这个功能） / 79
7.2　清晰的优先级 / 81
7.3　及时的用户故事定义 / 84
7.3.1　对系统工程师角色的投入 / 86
7.3.2　让市场人员负责1-N需求列表 / 89
7.3.3　引入技术架构师 / 90
7.3.4　让项目经理成为“功能开发组长” / 90
7.3.5　重用需求和测试标签来增加可扩展性 / 91
7.3.6　用实物代替估算交付 / 93
7.4　说服业务人员：敏捷计划也可行 / 95
7.5　小结 / 98
第8章　在大型创新组织中做估算的难点 / 101
8.1　瀑布模型和挑战 / 102
8.2　敏捷方法 / 103
8.3　敏捷方法面临的挑战：大型架构的成本投入 / 106
8.4　改变管理模式并将管理和业务方向相结合 / 109
8.5　小结 / 111
第9章　大型组织敏捷中的项目管理 / 112
9.1　统筹和排优：项目群经理 / 113
9.2　全权负责：部门经理 / 114
9.3　健壮性和扩展性：架构师 / 115
9.4　将高层整合到一起 / 116
9.5　小结 / 117
第10章　组织级方法：管理劣势项 / 118
10.1　测试责任制组织 / 119
10.2　组件型和功能型组织方式 / 122
10.3　传统项目管理与Scrum自我管理 / 125
10.4　小结 / 127
第11章　横跨美国和印度文化的高效敏捷开发模式 / 128
11.1　经验1：提问权限 / 130
11.2　经验2：确保互访时间 / 130
11.3　经验3：从小成功开始 / 131
11.4　经验4：利用时区差异 / 132
11.5　经验5：关注培训——不放松 / 132
11.6　经验6：人是团队的根本 / 133
11.7　通过组织调整最大限度使用海外团队 / 134
11.8　小结 / 137
第12章　正确的工具：对生产率有量级的提升 / 138
12.1　公共开发环境 / 139
12.2　为自动化测试创建模拟和仿真环境 / 141
12.3　支持可扩展的测试架构：公共测试框架 / 142
12.4　自动化测试最重要的一点：虚拟机供应系统 / 144
12.5　实时的度量和跟踪 / 148
12.6　集成的工具集 / 149
12.7　好的工具值得投入 / 150
12.8　小结 / 151
第13章　真实世界的敏捷结果：HP FutureSmart Firmware / 152
13.1　解放资源到创新 / 153
13.2　R&D和开发人员生产效率 / 156
13.3　提升对现有产品的支持 / 158
13.4　小结 / 159
第14章　提高企业管理灵活性 / 160
14.1　敏捷转型对其他R&D组织和质量系统的影响 / 162
14.2　敏捷转型对产品群组的影响 / 163
14.3　敏捷转型对非R&D的产品生产组的影响 / 165
14.4　组织灵活性的边界在哪里 / 166
14.5　HP FutureSmart Firmware敏捷转型后的变更管理 / 167
14.6　小结 / 170
第15章　规模化敏捷结果和我们预期的不同之处 / 172
15.1　敏捷推广的不同期望 / 173
15.2　注重团队灵活性而不是运作方式 / 174
15.3　改变部署流水线 / 176
15.4　拥抱敏捷带来的变化 / 176
15.5　企业级的任务追踪和持续改进 / 177
15.6　小结 / 178
第16章　启程 / 179
16.1　想清楚第一步踩在哪里 / 180
16.2　FutureSmart转型的下一步 / 181
16.3　决定你的第一步 / 183
16.4　小结 / 185
附录A　敏捷软件的十二条原则 / 186
参考文献 / 188