第1章
本书要解决什么问题

1.1　提供一种系统全面的方法

假定你是一个软件开发团队的负责人，你的老板找你聊天儿，让你想想办法，把开发速度再提上来一点，或者把上线质量再控制得好一点。你充满信心、充满干劲儿地答应下来。那接下来究竟该怎么办？凭直觉，或者借鉴最近管理上遇到的案例，或者灵光乍现想出几个改进点，还是根据最近看的几篇文章分析一下团队是不是也能做类似的改进？要么，组织团队成员一起聊聊，集思广益？

都不错。然而你怎么保证，你找到的待改进事项，就是抓住了团队当下最要紧的事情？你怎么保证，没有遗漏其他一些重要内容？

你需要一种系统全面的方法。

假定你带领的团队负责软件研发效能工具平台，这个团队从市面上挑选和引入好用的开发工具并部署运维，必要时做一些定制开发、工具间的集成，甚至自研工具，总之目标是服务好本公司数百名软件开发人员。现在要考虑今后一两年做哪些建设，重点投入哪些事项。

这时候，你怎么分析和确定团队的工作计划？你怎么保证，你做的计划抓住了当下最要紧的事情？你怎么保证，没有遗漏其他一些重要内容？

你需要一种系统全面的方法。

假定你是负责软件开发过程改进的专职人员，别人称呼你或者你自称敏捷教练、工程教练、DevOps教练。当然，你可以拿着Scrum这个锤子到处找钉子砸，或者拿着极限编程这一套锤子到处找钉子砸，或者拿着持续集成、持续交付、精益看板、TDD、微服务、云原生……

更理想的情况是，使用系统的方法，对你进驻的团队有一个全面的了解和全面的分析，梳理出它在软件开发过程方面应该做哪些改进，以及轻重缓急。然后再从你的工具箱里拿出匹配的合适的工具，叮叮当当。

你需要一种系统全面的方法。你需要有一种类似于对人进行体检的方法，对一个开发团队进行全方位、多层次的梳理，根据其所处的业务领域，当前采用的技术栈，当前使用的工具、流程和方法等实际情况，找出当前问题最突出、最值得改进的那些地方，甚至制定中长期的改进方案，一步一步扎扎实实地做。

即便你不是软件开发团队的负责人，即便你不负责软件开发工具的支持，即便你不是负责软件开发过程改进的专职人员，但是只要从事软件开发这个行当，你就会接触到软件交付过程，你就需要对它有一个总体的了解，对核心思想、基本思路、常见方法有一定的掌握。这正是本书要介绍的内容。