Chapter 3: Measure Twice, Cut Once: Upstream Prerequisites
3.1 Importance of Prerequisites
能创造出高质量软件的程序员通常使用高质量的实践方法，在项目的初期、中期、末期都强调质量。项目末期的测试检查不出诸如“制造了一个错误的产品”或者“使用错误的方法制造的正确的产品”之类的缺陷，这些缺陷需要在构建活动之前解决。
准备工作的中心目标是降低风险，软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划，准备工作的重点集中在改进需求分析和项目规划。
前期准备往往是不周全的：分配去做前期准备活动的人员往往并不具备完成这一任务的专业技能；有一些程序员确实知道如何进行前期工作，但是他们却并没有做，因为他们不能够抵抗“尽快开始编码”的欲望；管理者们不理解、不支持花时间进行前期准备的程序员。
Utterly Compelling and Foolproof Argument for Doing Prerequisites Before Construction
诉诸逻辑：从逻辑上来讲，准备工作是做任何事情之前都需要做的事情。编码之前的准备工作，可以弄清楚要做的东西到底是什么，以免浪费时间和金钱，走进毫无必要的死胡同。
诉诸类比：建造软件系统和任何其他花费人力财力的项目是相似的，如果在建造一座房屋前，不做任何准备和设计工作，直接丢给农民工去做，这样是造不出合格的房子的。
数据说话：研究表明，在构建活动开始前清除一个错误，返工的成本仅仅是在软件开发的最后阶段做同样事情的十分之一到百分之一。发现错误的时间，要尽可能接近引入该错误的时间。缺陷修复的成本随着“从引入缺陷到检测到该缺陷之间的时间”变长而急剧增加。
3.2 Determine the Kind of Software You’re Working On
不同种类的软件项目，需要在“准备工作”和“构建活动”之间做出不同的平衡。开发商业系统的项目往往受益于高度迭代的开发法，这种方法的“计划、需求、架构”活动与“构建、系统测试、质量保证”活动交织在一起。性命攸关的系统往往要求采用更加序列式的方法，“需求稳定”是确保“超高等级可靠性”的必备条件之一。
迭代开发法与序列开发法的比较
迭代方法往往能够减少“前期准备不足”造成的负面影响，但是他不能完全消除此影响。
序列式开发法依赖测试发现缺陷，绝大部分缺陷修正工作推迟到项目快结束时进行，使得成本较高。迭代开发法在项目进行过程中一点点地吸收消化返工，使得总体成本较低。
使用迭代开发法，成本将在整个项目过程中分次支付，而不会聚集到项目末尾一次性支付。项目结束，实际总成本是相似的，但是迭代开发的分期支付，使得成本看起来没那么高。
无论使用迭代开发还是序列开发，只要进行前期准备，就可以减少成本。绝大多数的项目开发不会完全选择序列化开发或者是迭代开发。
迭代开发法与序列开发法的选择
下列原因会让你选择更加序列化的方法
- 需求相对稳定
- 设计直截了当、理解透彻
- 开发团队对这一应用领域非常熟悉
- 项目的风险很小
- “长期可预测性”很重要
- 后期改变需求、设计、和编码的代价可能较昂贵
下列原因会让你选择更加迭代的方法
- 需求并没有理解透彻，或者出于其他理由，认为它是不稳定的
- 设计很复杂或者有挑战性，或者两者都有
- 开发团队对这一应用领域不熟悉
- 项目包含许多风险
- “长期可预测性”不重要
- 后期改变需求、设计、和编码的代价很可能较低
事实上，软件开发中，适用迭代开发法的情况比适用序列式开发法的情况多的多。
3.3 Problem-Definition Prerequisite
问题定义是指在开始构建前，对系统要解决的问题做出清楚的陈述。问题定义只定义了问题是什么，而不涉及任何可能的解决方案。问题定义为随后的开发过程打下基础，应该用客户的语言来书写，从客户的角度来描述问题。 如果解决的是计算机本身相关的问题，则使用计算机术语陈述问题是恰当的。
3.4 Requirements Prerequisite
需求详细描述软件系统应该做什么，这是达成解决方案的第一步。
明确的需求有助于确保是用户（而不是程序员）驾驭系统的功能、避免争论。重视需求有助于减少开始编程开发之后的系统变更。充分详尽的描述需求，是项目成功的关键。没有好的需求，可能对问题有整体把握，但是却没有击中问题的特定方面。
稳定点需求是软件开发的圣杯。一旦需求稳定，项目就能有序、可预测、平稳的完成从架构到设计到编码到测试等一系列工作。但是永不变更的需求只是一个美好的愿望。需求变更的主要来源是，随着项目的推进，客户对项目的理解也越深入。
构建期间，最好的处理需求变更的方式：
- 评估需求的质量
- 确保每一个人都知道需求变更的代价
- 建立一套变更控制程序
- 使用能适应变更的开发方法
- 放弃这个项目
- 注意项目的商业案例
[需求核对表]
3.5 Architecture Prerequisite
软件架构师软件设计的高层部门，是用于支撑更细节的设计的框架。架构的质量决定了系统的“概念完整性”，继而决定了系统的最终质量。架构将工作分为几部分，使得多个开发者或者多个开发团队可以独立工作。
没有良好的软件架构，可能瞄准了正确的问题，但是却使用了错误的解决方案，也许完全不可能有成功的构建。
架构变更如同需求变更，对软件构建影响很大，越早发现架构缺陷，修正成本越低。
架构的典型组成部分
程序组织、主要的类、数据设计、业务规则、用户界面设计、资源管理、安全性、性能、可伸缩性、互用性、国际化/本地化、输入输出、错误处理、容错性、架构可行性、过度工程、关于买还是造的决策、关于复用的决策、变更策略、架构的整体质量。
[架构核对表]
3.6 Amount of Time to Spend on Upstream Prerequisites
花费在问题定义、需求分析、软件架构上的时间，根据项目的需要而变化。运作良好的项目会在前期工作上投入10%~20%的工作量和20%~30%的时间。
如果需求不稳定，则需要预留更多的时间给需求分析师修订需求，或者自己解决需求方面的问题。
[前期准备核对表]
Key Points
The overarching goal of preparing for construction is risk reduction. Be sure your preparation activities are reducing risks, not increasing them.
If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. Attention to quality at the beginning has a greater influence on product quality than attention at the end.
Part of a programmer’s job is to educate bosses and coworkers about the software-development process, including the importance of adequate preparation before programming begins.
The kind of project you’re working on significantly affects construction prerequisites—many projects should be highly iterative, and some should be more sequential.
If a good problem definition hasn’t been specified, you might be solving the wrong problem during construction.
If good requirements work hasn’t been done, you might have missed important details of the problem. Requirements changes cost 20 to 100 times as much in the stages following construction as they do earlier, so be sure the requirements are right before you start programming.
If a good architectural design hasn’t been done, you might be solving the right problem the wrong way during construction. The cost of architectural changes increases as more code is written for the wrong architecture, so be sure the architecture is right, too.
Understand what approach has been taken to the construction prerequisites on your project, and choose your construction approach accordingly.