第二章 过程改进，没有灵丹妙药

    曾经走在一个公共场所，比如机场的出入口通道或公园，是否突然有一群狂徒冲你而来，想要教化你或者恐吓你甚至就因为你貌似傲慢无礼而要揍你。跟他们当中的任何一个人讲理，逻辑和推理都失去意义。在他们眼里，只有疯狂的信仰和不容辩驳的真理。即使你完全赞同他们，也不容你质疑或理论。你必须相信，你不能怀疑，哪怕一点点。

    五香熏牛肉（Pastrami）是一种加入各种各样的香料熏制成的牛肉。——译者注

    这让我很不爽。我的意思是说我真的巨不爽。我有我自己的头脑，我想完全独立地思考。不是只在聚会或者社交场合，而是所有情境下。问一下“为什么”并搞清楚“怎么做”，这才是人性独立的要义。

    你可能会认为，我这样的见解应该成为不明就里而无法进行软件调试的开发者的标准。但就像一些致力于宗教、政治斗争和环境保护的人所具有的狂热一样，软件开发者也强烈地推崇一些新兴的软件开发方法，比如极限编程（eXtreme Programming，XP）、敏捷方法和团队软件过程（Team Software Process，TSP）。

    做任何事情都要适中

    我非常喜欢这些开发模式所提倡的思想和方法。但面对一个虔诚的追随者，如果我问为什么要这样做，或者当我建议对规则或实践做一个很小的改动，以使它更适用于我的实际工作的时候，那就不一样了！这好比把一只魔戒摆在哈比人的面前——他顿时露出獠牙，发根直立。对于一些开发者来说，极限编程和敏捷方法已经成为一种迷信。而对于另外一些开发者来说，团队软件过程是一种忠诚度的风向标——你跟我们非友即敌。

    请原谅我的务实，原谅我使用自己的头脑，原谅我不迷信灵丹妙药，而坚持去做实用的事。我不会因为“你必须得这么做”而去做。我的行为原则是，要对这样做会成功而用其他方法就会失败这两方面都能有相当充分的理由。

    作者注：这样的“夸夸其谈”经常使大家笃信我在文章中论及的主题思想，我以前总以此为傲，但这次不会了。只有极端主义者才说“迷信”无害，我可不是极端分子。

    俭则不匮

    是什么让我关注“精益”呢？是的，本栏目的标题。虽然在极限编程、敏捷方法和团队软件过程中有很多奇妙的东西，但至少有一个概念它们是共同的：减少无为的浪费。这恰恰是精益设计和制造的重点，而精益是源自于丰田汽车公司的一个概念，它比极限编程、敏捷方法和团队软件过程要早30多年。但是，极限编程、敏捷方法及团队软件过程使用不同的路子处理浪费问题，通过了解精益模式，我们可以更好地理解这些模式方法是怎么实现的。

    因此，冒着触动一些狂热者敏感神经的危险，听我娓娓道来。精益的精髓就是以最少的投入换取向用户提供最大的价值。它采用一种“拉模式”及“持续改进”的方法来做到这一点。拉模式其实很简单：“不需要，就不做”，这就减少了无用的、不必要的、无价值的工作；而持续改进则重在减少浪费和提供一种平稳的客户价值流。

    作者注：非常感谢Corey Ladas，因为是他首先把我引入了精益（lean）、公理设计（Axiomatic Design）、Scrum、质量功能展开（Quality Function Deployment，QFD）、集合设计（SetBased Design）、Kaizen改善、普氏概念选择法（Pugh Concept Selection）的世界。除了这些理论，他还有很多很多其他出色的想法。我们曾经在一起共事了两年，后来他离开了团队，之后他的位置再也没人能够补上。他现在和另一位出色的前团队成员Bernie Thompson在一起，维护一个精益软件工程的网站。

    精益理论对有损于客户价值流的浪费归纳为以下7种类型：

    ·过量生产

    ·运输

    ·多余动作

    ·等待

    ·过程不当

    ·库存

    ·缺陷

    这些显然是制造业的术语，是吗？它们不可能跟软件有关联，是吗？显然你太天真了。所有这7种浪费都直接跟软件开发有关，我视其为软件开发“7宗罪”。以下我将谈谈如何通过极限编程、敏捷方法、团队软件过程及一般性常识来规避它们。

    过量生产

    第一种浪费是供过于求，但愿这永远也不要发生。是否有一种软件产品符合需求规范而无需删减任何功能模块呢？是否有一种软件产品存在客户从来用不着的功能模块呢？这些问题既复杂又平常，即宽泛又耐人寻味，既似无关紧要又劳人伤神……过量生产太恐怖了，它会导致难以置信的浪费。

    极限编程通过短而紧凑的循环周期来解决这个问题。它注重与客户的持续交流，以及开发者之间的持续沟通。这保证了所有人都知道其他人在干什么，并且总是有较高的客户认可度。结果，几乎所有完成的工作都是对客户有价值的。当然，微软的客户是庞大的，因此微软的很多团队都使用敏捷方法。

    敏捷方法是各种精益方法的一个总称，它包括极限编程。确切地说，敏捷方法不是指某项具体的技术，而是一种整体的方法论，它为软件开发提供了很多有趣的方法。其中之一称为Scrum项目管理方法（Scrum的命名来自于一个橄榄球术语）。开发团队定期地跟客户代表碰头，通常每30天一次，以展示工作进展、重新安排工作的优先次序以及进行过程改进。跟极限编程一样，团队成员也每天开会更新各自的进度和讨论工作中遇到的难题。

    通过每月对工作优先次序的重新安排和每日对工作的重新组织，一个Scrum团队把自身的关注点锁定在了客户看重的东西上面，几乎没有任何工作是多余的。通过定期性的过程改进，价值流可以不断地被优化。