书摘——人月神话

date：2016-07-15
读书笔记

一、焦油坑

• 编程，一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。

二、人月神话

• 所有的编程人员都是乐观主义者。
• 系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
• 第二个谬误的思考方式是在估计和进度安排中使用的工作单位：人月。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
• 当任务在次序上的限制不可分解时，人手的添加对进度没有任何帮助。对于可以分解，但子任务之间需要互相沟通和交流的任务，常常所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用，从而添加更多的人手，实际上是延长了而不是缩短了时间进度。
• 软件任务的进度安排之经验法则：
  
  • 1/3计划
  • 1/6编码
  • 1/4构件测试和早期系统测试
  • 1/4系统测试、所有的构件已完成
• Brooks法则： 向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.）

三、外科手术队伍

• 优秀程序员与较差程序员之间的生产率的差异，常常能够达到令人吃惊5：1甚至10：1。
• Harlan Mills 建议一个10人左右的程序开发团队应该以类似外科手术的方式组建，而非一拥而上。其中包括：
  
  • 外科医生：首席程序员，定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。
  • 管理员+文秘：外科医生的老板，在人员、薪酬、办公空间等方面具有决定权。配有一个秘书，负责非产品文件和使项目协作一致。
  • 编辑+文秘：根据外科医生的草稿或口述，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护，并监督文档生成的机制。
  • 副手：外科医生的后备，主要作用是作为设计的思考者、讨论者和评估人员。
  • 程序职员：维护编程产品库中所有团队的技术记录。
  • 工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具的构建、维护和升级责任。
  • 测试人员：编写功能设计系统测试用例，还负责计划测试的步骤和为单元测试搭建测试平台。
  • 语言专家：掌握复杂编程语言的人，负责寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。
• 如果将外科手术团队的概念扩展至几百人参与的大型任务时，要保证每个部分的概念完整性得到彻底的提高，也就是说仅仅协调20个“外科医生”的思路而非其他人。

四、贵族专制、民主政治和系统设计

• 在系统设计中，概念完整性应该是最重要的考虑因素。也就是说，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
• 由于目标是易用性（simplicity），功能与概念的复杂程度的比值才是系统设计的最终测试标准。但是功能本身或者简洁都无法成为一个号的设计评判标准。
• 对于给定级别的功能，只有简洁是不够的，要能用最简洁和直接（straightforward）的方式来指明事情的系统是最好的。
• 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
• Blaauw指出，整个软件开发包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）和物理实现（realization）。在实际情况中，它们往往可以同时开始和并发地进行。

五、 画蛇添足

• 第二个系统是设计师们所设计的最危险的系统。一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地放在次要位置。
• 一个可以开阔结构师眼界的准则是为每一个小功能分配一个值：每次改进，功能x不超过m字节的内存和n微米。这些值会在一开始作为决策的向导，在物理实现期间充当指南和对所有人的警示。
• 项目经理应该坚持至少拥有两个系统以上开发经验架构师的决定，同时保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

六、贯彻执行

• 手册或者书面规格说明，是一个非常必要的工具，仅有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节：同样的，它也是结构师主要的工作产物。
• 规格说明的风格必须清晰、完整和准确。每条说明必须重复所有的基本要素，所有文字都要相互一致。
• 会议是有必要的，而会议分为两个级别：周例会和年度大会。周例会是每周半天的会议，由所有的结构师，硬件和软件实现人员代表以及市场计划人员参与，由首席系统结构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式在会议之前分发。
• 在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。然后实际上如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低。
• 随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。显然，很多此类问题需要文字澄清和解释，还有一些仅仅是因为理解不当。一种有用的机制是由结构师保存 电话日志。日志中记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并分发给用户和实现人员。
• 每个开发机构都需要一个独立的技术监督部分，根据规格说明检测机器和程序，查明每一个可能的缺陷和相互矛盾的地方，来保证其公正性。

七、为什么巴比伦塔会失败

• 项目成功的先决条件：

  • 清晰的目标；
  • 人力；
  • 材料；
  • 足够的时间；
  • 足够的技术；
  • 交流；
  • 组织。

• 团队之间的交流沟通：

  • 非正式途径：鼓励大量的电话沟通，从而达到对所书写文档的共同理解；
  • 会议：常规项目会议，一个接一个的简要的技术陈述能澄清成百上千的细小误解；
  • 工作手册：对项目必须产出的一系列文档进行组织的一种结构。

• 项目所有的文档都必须是工作手册结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

• 技术说明几乎是必不可少的，不仅仅需要记录思路，而且还应记录可追溯到最早设计的文字和章节，并对产品提出建议或解释设计。
• 使用项目手册的第二个原因是控制信息发布，确保信息能够到达所有需要它的人的手中。
• 当编程人员仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。这种方法的先决条件是精确、完整地定义所有接口。

• 团队组织的目的是减少所需的交流和合作的数量。 减少交流的方式是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时，树状管理结构反映出对详细交流的需要会相应减少。要使它行之有效，每棵子树所必须具备的基本要素有：

  1. 任务（a mission）；
  2. 产品负责人（a producer）；
  3. 技术主管或结构师（a technical director or architect）；
  4. 进度（a schedule）；
  5. 人力的划分（a division of labor）；
  6. 各部分之间的接口定义（interface definitions among the parts）。

• 产品负责人和技术主管之间的关系有以下三种可能：

  1. 产品负责人和技术主管是同一个人。 这种方式可以非常容易地应用在小型的队伍中，而在大型的项目中则不容易获得应用。
  2. 产品负责人作为总指挥，技术主管充当其左右手。 难点在于技术主管不参与任何管理工作的同时，建立其在技术决策上的权威。要达到这一点，产品负责人和技术主管必须在技术理论上具有相似的观点；他们必须在主要的技术问题出现之前，先私下讨论这些问题；产品责任人必须对技术主管的技术才能表现出尊重。
  3. 技术主管作为总指挥，产品负责人充当其左右手。 对小型团队来说是最好的选择。

八、胸有成竹

• 研究表示，工作量是规模的幂函数，也就是说一个项目的实际工作量随着其规模的增长呈指数速度增长。
• 通常情况下，团队也许只能用50%的工作实际来进行实际的编程和调试，另外的50%时间浪费于包括机器的宕机时间、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等。因此如果项目估算时对每个人年的技术工作时间数量做出了不现实的假设，那么就会必然导致项目的延误。
• 生产率会根据任务本身复杂度和困难程度表现出显著差异。其指导原则是：编译器的复杂度是批处理程序的3倍，操作系统复杂度是编译器的3倍。
• 使用适当的高级语言，编程的生产率可以提高5倍。

九、削足适履

• 对于项目经理而言，规模控制即使技术工作的一部分，也是管理工作的一部分。他必须研究用户和用户需求，以设置待开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。
• 项目经理可以做两件事来帮助他的团队取得良好的“空间-时间”折中。一是确保他们在编程技能上得到培训，而不仅仅是依赖他们自己的才能和先前的经验。特别是使用新语言或者新机器时，培训显得尤其重要。若要熟练使用，其往往需要快速的学习和经验的广泛分享，也许它应该伴随新技术特别的奖励或者表扬。
• 另外一种方法是意识到编程需要技术积累，需要开发很多公共单元构件。公共库开发是一件重要的实现工作，它可以与系统设计工作并行进行。
• 精湛的技艺出自创造，精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。战略上的突破有时是一种新的算法，但更常来自数据或表的重新表达——这是程序的核心所在。
• 由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据，最终获得非常好的结果。实际上，数据的表现形式是编程的根本。

十、提纲挈领

• 如果要制造一台机器，有以下关键文档：
  
  • 目标：定义待满足的目标和需求，定义迫切需要的资源、约束和优先级。
  • 技术说明：计算机手册加功能规格说明。它是在计划新产品时第一个产生，并且最后完成的文档。
  • 进度
  • 预算：预算不仅仅是约束。对管理人员来说，它还是最有用的文档之一。预算的存在会迫使其制定技术决策，更重要的是，它促使和澄清了策略上的一些决定。
  • 组织结构图
  • 工作空间的分配
  • 报价、预测、价格：**这三个因素互相牵制，决定了项目的成败。
• 在软件项目中，项目经理聪明的做法都是：首先立刻正式生成若干正式的小文档，以作为自己的数据基础，然后再要求提供和其他经理类似的文档。
  
  • 内容：目标。定义待完成的目标、迫切需要的资源、约束和优先级。
  • 内容：产品技术说明。以建议书开始，以用户手册和内容文档结束。速度和空间说明是关键的部分。
  • 时间：进度
  • 资金：预算
  • 地点：工作空间分配
  • 人员：组织图
• 首先，书面记录决策是必要的，只要记录下来，分歧才会明朗，矛盾才会突出，人们才能从令人 迷惑的现象中得到清晰、确定的策略。
• 第二，文档能够作为同其他人的沟通渠道。项目经理的基本职责是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是作出决定。
• 最后，项目经理的文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整。

十一、未雨绸缪

• 对于大多数项目，第一个开发的系统并不合用。因此，管理上 的问题不再是“是否构建一个试验性的系统，然后抛弃它？”你必须这么做。问题是：“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？”将原型发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用起来极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。
• 我从不建议顾客所有的目标和需求的变更必须、能够或者应该整合到设计中。项目开始时建立的基准，肯定会随着开发的进行越来越高，甚至开发不出任何产品。
• 变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。
• 通常来说，软件编程小组失败的主要原因是管理控制得太少，而不是太多。
• 不愿意为设计书写文档的原因，不仅仅是由于惰性或者时间压力。相反，设计人员通常不愿意提交尝试性的设计决策，再为它们进行辩解。“通过设计文档化，设计人员将自己暴露在每个人的批评之下，他必须能够为他书写的一切进行辩护。”
• 管理人员需要参与技术课程，高级技术人才需要进行管理培训。项目目标、进展和管理问题必须在高级人员整体中得到共享。只要能力允许，高层人员必须时刻做好技术和情感上的准备，或者管理团队亲自参与开发工作。
• 在程序发布给顾客使用之后，并不会停止变化。发布后的变更被称为“程序维护”。对于一个广泛应用的程序，其维护总成本通常是开发成本的40%或更多。该成本受用户数目的影响很大，用户越多，所发现的错误就越多。
• 程序维护中的一个基本问题是——缺陷修复总会以固定（20%~50%）的几率引入新的bug。所以整个过程是前进两步，后退一步。
• 系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

十二、干将莫邪

• 项目经理必须考虑、计划、组织的工具首先是计算机设施。它需要硬件和使用安排策略；它需要操作系统，提供服务的方式必须明了；它需要语言，语言的使用方针必须明确；然后是实用程序、调试辅助程序、测试用例生成工具和处理文档的字处理系统。
• 机器支持可以有效地划分成目标机器和辅助机器。目标机器是软件所服务的对象， 程序必须在该机器上进行最后测试。辅助机器是那些在开发系统中提供服务的机器。
• 程序库与其管理十分重要。首先，每个组或者编程人员分配一个区域，用来存放他的程序拷贝、测试用例以及单元测试需要的测试辅助平台。而当开发人员准备将软件单元集成到更大的部分时，他想集成经理提交一份拷贝，后者将拷贝放置在系统集成子库中。此时，原作者不可以再改变代码，除非得到了集成经理的批准。

十三、整体部分

• 贝尔实验室的项目经理提出：“关键的工作是产品定义。许许多多的失败完全是因为那些产品未精确定义的地方而导致的。”细致的功能定义、仔细的规格说明、规范化的功能描述说明以及这些方法的实施，大大减少了系统中必须查找bug数量。
• 测试规格说明：在编写任何代码之前，规格说明必须提交给外部测试小组，以详细地检查说明的完整性和明确性。
• 系统开发（软件开发）可以划分为体系结构设计、设计实现和物理编码实现，每个步骤都可以使用自上而下的方法很好地实现。
• 以上流程进一步精细化。最初，通过比较粗略的任务定义和大概的解决方案得到主要结果。然后，对该定义和方案进行细致的检查，以判断结果与期望之间的差距。同时，将上述步骤的解决方案在更细的步骤中进行分解，每一项任务定义的精化变成了解决方案中算法的精化，还可以伴随着数据表达方式的精化。
• 控制变更。 在测试期间进行严密控制是硬件调试中一项令人印象深刻的技术，它同样适用于软件系统。首先，必须有人负责。他必须控制和负责各个构件单元的变更或者版本之间的替换。
• 注意，必须拥有完整的测试用例，在添加了每一个新构件之后，都要用它们来测试子系统。因为那些原来可以在子系统上成功运行的用例必须在现有系统上重新运行，对系统进行回归测试。

十四、祸起萧墙

• 严格控制项目的第一步是指定进度表。进度表上的每一件事被称为“里程碑”，它们都有一个日期。里程碑的选择只有一个原则，那就是必须是具体的、特定的、可度量的事件，能够进行清晰定义。

• 对于大型开发项目中的估计行为，有以下三种结果：

  1. 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何糟糕，它都不会有太大的变化。
  2. 活动期间，对时间长短的过高估计会随着活动的进行持续而下降。
  3. 过低估计在活动中不会有太大变化，一直到计划的结束日期之前大约三周左右。
• 对软件开发队伍来说，进取是非常必要的。进取提供了缓冲和储备，使开发队伍能够处理常规的灾祸，可以预计和防止小的灾祸。
• 采用PERT或者关键路径技术才能判断哪些工作进度的偏移会对项目造成重大的影响。它能显示谁需要什么样的东西，谁位于关键路径上，在哪里发生滞后会影响最终的完成日期。另外，它还指出一个任务在成为关键路径以前，可以落后的时间。
• 每个老板都需要两种信息：需要采取行动计划方面的问题，用来进行分析的状态数据。出于这个目的，他需要了解所有开发队伍的情况，有两种方式可以被采用：
  
  1. 减少角色冲突。首先老板必须区别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。
  2. 评审机制。不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁、明确的里程牌是这种评审的基础。大型项目中，可能需要每周对某些部分进行评审，大约一个月左右进行整体评审。
• 对计划和控制职能进行适度的技术人力投资是非常值得赞赏的。它在项目的贡献方式和直接开发软件产品方面差异较大。作为监督人员，计划和控制小组明白地指出了不易察觉的延迟，并强调关键的因素。他们是早期的预警系统，防止项目以一次一天的方式落后一年。

十五、另外一面

• 公共应用程序的用户在时间和空间上都远离它们的作者，因此对这类程序，文档的重要性更是不言而喻。对软件编程产品来说，程序向用户所呈现的和提供给机器识别的内容（程序源代码）同样重要。
• 不同用户需要不同级别的文档。某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。
• 针对使用程序。每个用户都需要一段对程序进行藐视的文字，而且文档中需要指明：
  
  1. 目的。主要的功能是什么？开发程序的原因是什么？
  2. 环境。程序运行在什么样的机器、硬件设置和操作系统上？
  3. 范围。输入的有效范围是什么？允许显示的合法输出范围是什么？
  4. 实现功能和使用的算法。精确地阐述它做了什么。
  5. “输入——输出”格式。必须是确切和完整的。
  6. 操作指令。包括控制台及输出内容中正常和异常结束的行为。
  7. 选项。用户的功能选项有哪些？如何在选项之间进行挑选？
  8. 运行时间。在指定的配置下，解决特定规模问题所需要的时间？
  9. 精度和校验。期望结果的精确程度？如何进行精度的检测？
• 针对验证程序。除了程序的使用方法，还必须福袋一些程序正确运行的证明，即测试用例。这些用例可以根据输入数据的范围划分成三个部分。
  
  1. 针对遇到的大多数常规数据对程序主要功能进行测试的用例。它们是测试用例的主要组成部分。
  2. 数量相对较少的合法数据测试用例，对输入数据范围边界进行检查，确保最大可能值、最小可能值和其他有效特殊数据可以正常工作。
  3. 数量相对较少的非法数据测试用例，在边界外检查数据范围边界，确保无效的输入能正确的数据诊断提示。
• 针对修改程序。调整程序或者修复程序需要额外相对多的信息。关于系统的内部结构，一份清晰明了的概述应该包含：
  
  1. 流程图或子系统的结构图。
  2. 对所用算法的完整描述，或者是类似算法的参考资料。
  3. 对所有文件规划的解释。
  4. 数据流处理的概要描述——获取数据或程序处理的序列以及在每个处理过程完成的操作。
  5. 初始设计中，对已预见修改的讨论；特性、功能回调以及出口的位置；原作者对可能会修改的地方以及可能处理方案的一些意见。另外，对隐藏缺陷的观察也同样很有价值。
• 试图努力维持不同文件之间的同步关系，是一件非常费力不讨好的时间。更合理的方法是：每个数据项包含两个文件都需要的所有信息，采用指定的键值来区别，并把它们组合到一个文件中。具体来说，把文档整合到源程序中，而不是同时维护一份机器可读的程序以及一系列包含记叙性文字和流程图的人类可读性文档，对正确维护是直接有力的推动。同时它能保证了编程用户能方便、及时地得到文档资料。这种程序被称为自文档化（Self-Documenting）。
• 文档是我们和前人都不曾成功背负的重担。作为基本目标，我们必须试图把它的负担降到最小。有以下几个方法和技巧：
  
  • 方法：
    
    1. 借助那些出于语言的要求而必须存在的语句，来附加尽可能多的“文档”信息。因此，标签、声明语句和符合名称均可以作为工具，用来向读者表达尽可能多的意见。
    2. 尽可能地使用空格和一致的格式来提高程序的可读性，表现从属和嵌套关系。
    3. 以段落注释的形式，向程序中插入必要的记叙性文字。段落注释能提供总体把握和真正加深读者对整件事情的理解。
  • 技巧：
    
    1. 为每次运行使用单独的任务名称。维护一份日志，记录程序运行的目的、时间和结果。
    2. 使用包含版本号和能帮助记忆的程序名称。
    3. 在过程（PROCEDURE）的注释中，包含记叙性的描述文字。
    4. 尽可能地为基本算法提供参考引用，通常它会指向更完备的处理方法。这样，既节省了空间，还允许那些有经验的读者能非常自信地略过这一段内容。
    5. 显示和算法书籍中的传统算法的关系。（更改、定制细化、重新表达）
    6. 声明所有的变量。采用助记符，并使用注释把DECLARE转化成完整的说明。注意，声明已经包含了名称和结构性描述，需要增加的仅仅是对目的的解释。通过这种方式，可以避免在不同的处理中重复名称和结构性的描述。
    7. 用标签标记处初始化的位置。
    8. 对程序语句进行分组和标记，以显示与算法描述文档中语句单元的一致性。
    9. 利用缩进表现结构和分组。
    10. 在程序列表中，手动添加逻辑箭头。它们对调试和变更非常有帮助，还可以补充在页面右边的空白处（注释区域），成为机器可读文字的一部分。
    11. 使用行注释或标记任何不很清楚的事情。
    12. 把多条语句放置在一行，或者把一条语句拆放在若干行，以吻合逻辑思维，体现和其他算法描述一致。

十六、没有银弹

• 所有软件活动包括：根本任务，即打造构成抽象软件实体的复杂概念结构；次要任务，即使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言。
• 对于更好地构造异常复杂的抽象概念结构，有以下几点建议：
  
  • 仔细地进行市场调研，避免开发已上市的产品；
  • 在获取和制定软件需求时，将快速原型开发作为迭代计划的一部分；
  • 有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能；
  • 不断挑选和培养杰出新生代的概念设计人员。
• 软件开发中困难的部分是规格说明、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。
• 现代软件系统中无法规避的内在特性：复杂度、一致性、可变性和不可见性：
  
  • 复杂度。 规模上，软件实体可能比任何由人类创造的其他实体更复杂，因为没有任何两个软件部分是相同的（至少在语句的级别上）。而由软件的复杂度造成了很多经典的软件产品开发问题：团队成员之间的沟通非常困难，导致了产品瑕疵、成本超支和进度延迟；列举所有可能的状态变得十分困难，影响了产品的可靠性；函数调用变得困难，导致程序难以应用；结构复杂，程序难以在不产生副作用的情况下用新函数扩充；还造成很多安全机制状态上的不可见性。
  • 一致性。软件开发必须遵循许多认为惯例和系统，并随着接口的不同而改变，随时间的推移而变化，而且这些变化不是必需的，仅仅由于它们是不同的人设计的结果。
  • 可变性。软件实体经常会遭受到持续的变更压力。部分原因是因为系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。另外的原因是因为软件可以容易地进行修改。
  • 不可见性。软件是不可见的和无法可视化的。软件的客观存在不具有空间的形体特征。因此，没有已有的几何表达方式，从而剥夺了一些具有强大功能的概念工具的构造创意。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了思路相互之间的交流。
• 针对概念上根本问题的颇有前途的方法：
  
  • 需求精炼。开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。详细的需求包括了所有的人机界面，与机器和其他软件系统的接口。因此，软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。所以，在计划任何软件活动是，要让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一部分，这是非常必要的。
  • 快速原型。软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能。同时，原型不必受到相同硬件速度、规模或者成本的限制。原型通常展示了应用程序的功能主线，但不处理任何如无效输入、退出清除等异常情况。原型的目的是明确实际的概念结构，使客户可以测试一致性和可用性。
  • 增量开发。软件系统应该以增量的方式开发。即，首先系统应该能够运行，即使没完成任何有用功能，只能正确调用一系列伪子系统。接着，系统一点一点被充实，子系统轮流被开发。增量化开发使逆向跟踪很方便，并非常容易进行原型开发，每一项新增功能，以及针对更加复杂数据或环境的新模块，从已经规划的系统中有机地增长。这种开发模式对士气的推动也是令人震惊的。即便是非常简单的系统出现时，即便是一个简单的长方形，开发人员的热情和工作动力也会成倍地增长。