Measure Twice，Cut Once ：Upstream Prerequisites

Important of Prerequisites
** 软件项目的成败很大程度上在构建活动开始前就已经注定了，如果计划不充分，那么在构建期间能做的只能是尽量减小损害。
** 构建活动是整个开发中最昂贵的部分，但糟糕的设计会导致2次3次构建，甚至更多。
** 使用高质量的实践方法是那些能创造高质量软件的程序员的共性，而这些高质量的实践方法就是在任何时候都强调质量.
** 测试只是质量保证策略的一部分，而且不是最有影响力的部分，测试不可能检测出 “制造了一个错误的产品” 或者“使用错误的方法制造正确的产品”之类的缺陷，这样的缺陷必须在构建活动开始之前解决。 -- 而且就算在测试时检测出来了也是为时已晚。
** 由于构建活动是在软件项目的中间，在开始构建之前的前期准备工作已经或多或少为这个项目的成败打下了基础，如果你在构建时看到有失败的危险，就应该退回到前期准备工作中。
** 准备工作的中心目标就是降低风险：好的项目规划者能够尽可能早的将主要的风险清除掉。

Causes Of Incomplete Preparation
* 作前期准备的人员并不具备完成这一任务的专业技能。项目规划、分析出全面准确地需求、创建高质量的架构等活动都需要一定的技能，而这些技能不是能轻而易举能获得的。
* 程序员们想尽快开始编码
* 管理者们想尽快开始编码  -- 这是最常见，也是最无奈的。

前期准备的重要性的论据
* Appeal to Logic 从管理的角度看，作计划意味着确定项目所需要的时间、人数。从技术的角度讲，作计划意味着弄清楚想要作什么，防止建造出错误的东西。有时候用户一开始并不完全确定自己想要什么，因此值花费比理想情况多的力气找出他们真正想要的。
* Appeal to Analogy 在真实的食物链里，位于底层的动物如果有病毒，那么就会传染给上层的动物，如果很不幸食物链的每一层都有病毒，那么顶层的动物将感染整个食物链中所有种类的病毒。在软件开发中，程序员是软件食物链的最后一环，架构师吃掉需求，设计师吃掉架构，程序员吃掉设计。
如果需求有缺陷，那么缺陷就会传递给架构，如果架构本身再有缺陷，那么前面的缺陷将累加起来传递给设计，要是设计又有缺陷，那么到了构建时，程序员将不得不为前面所有的错误付出代价，而且开发出来的软件也将满是缺陷。-- 书中给出了好几种类比，我觉得食物链的比喻最好。
* Appeal to Data 通过一组数据对比，得到一各原则：发现错误的时间要尽可能接近引入错误的时间，缺陷在软件开发过程中存在的时间越长，对后续的工作损害就越大。由于需求是最先开始的工作，需求如果不正确，对项目的损害最严重。-- 事实上也的确如此，做过项目地程序员都痛恨需求变更。

Problem-Definition Prerequisite
** 也被称为 "产品设想/product vision"、“设想陈述/vision statement”、“任务陈述/mission statement”、“产品定义/product definition”,这里称为“问题定义/problem definition”。问题定义只定义了问题是什么，不涉及任何可能的解决方案，它应该只是一个简单的陈述，并且听起来像个问题。例如“我们跟不上Gigatron的订单了”就是一个合格的问题定义，而“我们需要优化数据自动采集系统,使之跟上Gigatron的订单”就不太好,因为提到了具体的解决方案.
** 问题定义在具体的需求分析之前,需求分析就是对所定义的问题的深入调查.问题定义应该从客户的角度描述问题,最好的解决方案未必是一个计算机程序.-- 这里书中举了个例子,有些搞笑,我自己也经历过这样的问题,用程序很难解决的问题，人工操作却轻轻松松。
** 未能定义问题的处罚是双重的，你浪费了时间去解决错误的问题，而正确的问题没被解决。

Requirements Prerequisite
** 需求详细描述系统应该做什么，这是达成解决方案的第一步。也被称为“需求开发/requirements development”，“需求分析/requirements analysis”，“分析/analysis”，“需求定义/requirements definition”,“软件需求/software requirements”，“规格书/specification”，“功能规格书/functional spec”，“规格/spec”

Why Have Official Requirements
* 明确的需求有助于确保是用户而不是程序员驾奴系统的功能。如果需求明确，用户就可以自行评审，也可以避免程序员在编程时区猜测用户想要的是什么。
* 明确的需求有助于避免争论，如果程序员对“程序应该做什么”意见不一致，可以查看需求说明书以解决分歧。
* 明确的需求有助于减少需求变更，如果编码时出现一个代码上的错误，可能只需要修改几行代码就可以了，但如果编码时出现一个需求上的错误，其后果
往往十分严重。
* 充分详尽的描述（Specfiy）需求是项目成功的关键，甚至比有效的构建技术更重要！

The Myth of Stable Requirements
** 需求不可能不变。 -- 我觉得这样表达比较直接： Stable Requirements is Myth.
** 对一个典型的项目来说，在编写代码之前，客户无法可靠的描述他们想要的是什么。开发过程能够帮助客户更好的理解自己的需求，这是需求变更的主要来源。 -- 那些一塌糊涂的需求不在此列。

在构建期间处理需求变更
* 确保每个人都知道需求变更的代价。如果客户提出新的需求，那么一定要让他知道这样做的代价——进度和成本。
* 建立一套变更控制程序。客户改变他们的想法，认识到需要更多的功能，这不是坏事，问题在于频繁的更改需求。如果有一套固定的变更控制程序，那么大家都很愉快——你知道只需要在特定的时候处理变更，而客户知道你打算处理他们的提议。
* 使用能适应变更的开发方法。
* 注意项目的商业案例。
* 放弃这个项目。-- 呵呵，老外就是直接啊。

转载于:https://www.cnblogs.com/jxhwei/archive/2006/09/06/496302.html