软件开发的本质
精益的思想来自于生产制造业。精益在制造业中被广泛应用，但是精益思想并不能直接用于软件开发。很多把精益植入软件开发的尝试都失败了，原因是“制造”好的软件并不是一个生产制造的过程，而是一个开发的过程。
“开发”和“制造”是两个非常不同的过程。我们可以把“开发”比作是创造菜谱，而“制造”是根据菜谱来做菜。“开发”一个菜谱是一个学习的过程，这个过程包括不断尝试和失败。你不能期望一个高级厨师第一次就尝试成功一道新菜。事实上，开发菜谱需要尝试许多不同的变化，从而创造出最好的菜。
当厨师“开发”出一个菜谱，那么就只需要根据这个菜谱来准备这道菜。这个过程就是“制造”。制造过程只是一个重复做菜谱的过程，这个过程的变化（不确定性）是很小的。下表显示了“开发”与生产制造的不同：
| 开发 | 生产 |
|---|---|
| 设计菜谱 | 做菜 |
| 质量是适应用户使用 | 质量是符合需求 |
| 不确定性的结果是好的 | 不确定性会导致不良的结果 |
| 迭代会产生价值 | 迭代是浪费 (或者说是重复工作) |
开发 vs 生产
| 开发 | 生产 |
|---|---|
| 设计菜谱 | 做菜 |
| 质量是适应用户使用 | 质量是符合需求 |
| 不确定性的结果是好的 | 不确定性会导致不良的结果 |
| 迭代会产生价值 | 迭代是浪费 (或者说是重复工作) |
质量的观念
在制造业，质量定义为符合要求。在服务行业，有一种不同的质量观念。
服务的角度看质量
Walt Disney设计了迪士尼。迪士尼是一个几百个演员表演的巨大舞台。在这里，这些“演员”让每一位游客都享受到了很棒的时光。游客的需求是拥有一段与众不同的欢乐时光。迪士尼的所有员工都努力确保让游客有一段高质量的经历和体验。
迪士尼的质量要求
在迪士尼，电车的驾驶员也都是演员。一个朋友告诉我一个故事。在迪士尼里的电车上，一位驾驶员注意到一个小姑娘在她回迪士尼旅馆的路上哭。驾驶员问小女孩为什么哭，小女孩说在米老鼠旁边的人太多了，她不能靠近米老鼠。驾驶员继续前行，当这辆电车到达旅馆后，有个米老鼠正等着这位小女孩。小女孩很激动很高兴。而这位驾驶员也很好的完成了自己的工作，为小女孩提供了一个高质量的体验。
——Mary
从服务的角度看质量需要考虑每一位客户的不同想法，目的是为他们提供高质量的体验。在服务经济中，质量并不意味着符合合同要求。质量意味着要满足许多不同客户不断变化的期望。
软件开发中的质量
质量在软件开发中是指一个系统需要有感知完整性 Perceived Integrity（外部完整性）和概念完整性 Conceptual Integrity（内部完整性）。感知完整性意味着产品要拿到功能、易用性、可靠性的平衡，并且经济成本合适。概念完整性意味着系统的是一个有机的高聚合的整体。这在构建完整性（内建质量）一章中会着重描述软件的完整性。
如果一个软件系统解决了客户的问题，并使用方便高效，那么这个客户会感知到完整性（外部完整性）。这与任何不确定性都没有关系，不管问题是否没有理解到位，或一直在变化，抑或一直依赖于与外部因素。一个系统的感知完整性是指这个系统可以持续高效的解决问题。也就是说，设计的质量指实现目标或满足最终用途，而非仅仅符合要求。
变异性（不确定性）
当你思考迪士尼世界中的服务质量，你会发现每一个游客都与不同的期望。对的，大多数人都会期望主题公园是干净的，设施是可工作的。但如果你只提供给所有客户同一种体验，那么你的主题公园不会广泛受欢迎。与制造一个产品不同的是，提供一种服务需要考虑客户期望的不确定性或者说是变异性。变异性在制造业中是敌人。制造业认为所有客户的期望都是一致的不变的，所以制造是每时每刻用同一种方式去生产。
于是，人们认为变异性（不确定性）是不好的，人们尝试去建立标准流程，去减少不确定性，以求每个时刻都拿到可以重复的结果。但是开发的目标并不是生产可以重复的结果。开发是为每一个独一无二的客户生产合适的解决方案。
设计周期
设计不是一个自上而下、一蹴而就的过程。设计是一个探索问题解决方案的学习过程，包括不断的研究、实验、拿到结果反馈调整。软件开发就像所有的设计过程一样，是一个不断学习的过程。
一次性把事情做对？
为了解决以前没有解决过的问题，我们需要很多信息。对于复杂问题，最好的解决路径是用科学方法：观察、建立假设、设计实验验证假设、做实验、看结果是否和预期一致，然后不断调整。一个有趣的现象是，在科学方法的学习过程中，如果你的假设一直是对的，那么你不会学到很多知识；而当假设失败的概率为50%时，你学到的知识最多、拿到信息最多。
关于软件开发有两个观念。一个是鼓励开发人员第一次就把设计和代码写到最好。第二个流派则更倾向于不断进行一个小的快速的尝试、验证、调整的开发周期。第一种方式没有给知识学习留下空间，这种观念相信知识的学习可以通过系统的思考和评审完成。这种第一次把事情做对的方式也许可以解决一个结构化的确定的问题。但是不断的尝试、验证、调整的方式更适合非结构化的不确定的问题。
如果第一次把事情做对的方式在你的组织中广泛应用，那么你要问自己为什么会这样，这种方式在该组织中的价值何在。就像Yourdon指出的，“软件的逻辑经常需要重写三四遍才能达到优雅专业”。为什么呢？难道我们很高兴把代码反复写多遍？
你的目的应当是要平衡这两种方式——不断实验和系统的思考及评审。如果每次验证的成本很高，那么你会在开始前尽量考虑周全并加强评审。而如果实验的成本相对低廉，并且你希望更快速的学到更好的知识，那么实验是个高效的选择。通常情况下，实验、同伴评审检视、迭代的组合方式能有个不错的效果。
