第5章 快速开发中的Core Issues
人们感觉许多软件项目进展缓慢，但是，不同项目却以不同的方式“缓慢着”。有一些项目确实龟速前进，而另外一些项目则是因为无法达到预先估算的进度目标而“显得”慢。
软件项目暗藏着太多的变数，以至于根本无法为其设定一个百分之百准确的进度计划。任何一个软件项目，它绝不可能有一个项目完成的特定日期，而只会存在完成日期的范围：有些日期范围在概率上更有可能完成项目，而有些日期范围则不太可能完成项目。该完成日期范围的概率分布图如下图示。
Tom DeMarco建议，应把项目的进度计划制定为该项目有50%的可能性按时完成，如下图所示。
DeMarco的break-even scheduling strategy对彻底理解开发速度慢的本质很有帮助。我们可以把上面的图划分成三个部分：
只要项目在图中的“事实快速开发区”的时间范围内顺利完成，都说明项目的客观开发速度是令人满意的。
但是，客观的开发速度快并不能让客户主观上认同开发速度快。要让客户同样也“感觉”到项目的开发速度快，需要做到两点：
l 在项目估算阶段就要制定一个现实的、不过于乐观的进度计划，而不要给用户承诺下不现实的期望。
l 在项目进展过程中，定期地向客户汇报项目的进展，以使用户了解项目的当前状况。
第6章 生命期规划
Lifecycle model（生命期模型）的主要功能是确定一种次序，软件项目以这种次序来制定规格、建立原型、设计、实现、复审（review）、测试及完成其它任务。生命期模型是一个软件项目的最重要规划之一。软件经理必须意识到：要从各种生命期模型中挑选出项目最适合的一种生命期。
6.1 纯瀑布模型
瀑布模型是所有生命期模型的老祖宗。在瀑布模型中，项目由初始的software concept直到system testing，从始至终按照一定顺序向前推进。在每个阶段结束时，项目会举行一次review，以决定是否已经准备好推进到下一个阶段。如果review的结果认为项目还没有准备好进入下一阶段，那么项目就会继续留在当前阶段，直到它准备好为止。
瀑布模型是文档驱动的，这意味着各个阶段之间的主要工作成果是文档。在纯瀑布模型中，阶段之间也是不连续的——它们互不重叠。下图显示了瀑布生命期模型的推进方式。
当有一个稳定的product definition或使用一种被充分理解的技术解决方案时，纯瀑布模型特别适合。
但是，纯瀑布模型通常存在以下的问题：
l 最大的问题是缺乏灵活性。如果要在项目后期回溯之前的阶段，会付出高昂的代价。
l 正规的文档化会给项目和团队带来较多的负担。
l 进度可视性不强，仅在每个阶段结束时提供项目状况可视性。
6.2 Spiral Lifecycle Model（螺旋模型）
螺旋模型是一种以风险为导向的生命期模型，它把一个软件项目分解成一个个小项目（miniproject），每个小项目都标识一个或多个主要风险因素，直到所有主要风险因素都被解决。在这里，“风险”的概念比较宽泛，它可以是未被充分理解的需求、未被充分理解的架构、潜在的性能问题、底层技术方面的问题，等等。在所有的主要风险因素都被解决之后，螺旋模型就终止了。
| 最佳实践：Spiral Lifecycle Model（螺旋模型） 1. 螺旋模型的基本想法是：从一个小范围的关键中心地带开始寻找风险因素，制定风险解决计划，并交付给下一步骤，如此迭代。每次迭代都把项目扩展到一个更大的范围。 2. 每个迭代都包括以下6个步骤： (1) 确定objectives，alternatives和constraints。 (2) 识别并解决风险。 (3) 评估alternatives。 (4) 开发本次迭代可供交付的产品并检查其正确性。 (5) 规划下一个迭代过程。 (6) 交付给下一个迭代（如果你想继续的话）。 3. 螺旋模型可以和纯瀑布模型组合使用，如下图所示。
|
6.3 Staged Delivery（阶段式交付）
阶段式交付的特点是不会在项目结束的时候一并交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。下图显示了阶段式交付模型的工作流程。
阶段式交付的主要优点是：它允许你将有用的功能更早地交到你的客户手中使用，而不是在项目结束的时候才把一个具有100%功能的项目交付。阶段式交付的另一个好处是能更早地提供进度标识，这样的进度标识对于将进度压力保持在可控范围内很有价值。
| 最佳实践：Staged Delivery（阶段式交付） 1. 在完成了需求分析和架构设计之后，再考虑是否采用阶段式交付模型。阶段式交付适合于已经被充分理解的系统。如果你并不确定你的产品应该具有哪些features，那么阶段式交付并不适合。当你完成架构设计时，你必须对产品有了足够充分的理解，才能去规则每个交付阶段。 2. 如果决定了使用阶段式交付，那么就制定出一个详细的交付阶段规划。规划交付阶段时应注意： (1) 给每个阶段定义一个主题（theme），通过主题确定每个阶段要交付哪些feature。 (2) 按照重要性程度对theme进行排序，先交付重要的主题，再交付次要的主题。 (3) 一定要让开发人员参与到交付阶段的规划中来。跟开发人员一道来确定每个阶段的主题和主题的次序，确保各阶段的安排在技术上可行，确保所有开发人员都认可这份规划。 3. 严格按照交付阶段规划，在每个阶段中，都要完成详细设计、构建、测试，并在各个阶段末交付一个可工作的产品。但是，并不必把每个阶段的版本都交付给用户。 4. 在阶段式交付中应注意防范feature creep的风险。阶段式交付对用户需求变更并没有太多的灵活性。 |
6.4 Evolutionary Delivery（渐进交付）
渐进交付与阶段式交付相似但又不同。它可以把软件中某些选定的部分更早地交付，但它未必能把整个软件更早地交付。渐进交付还具有一定的响应客户要求而修改产品方向的能力。渐进交付是贯穿整个项目的，如果你想要使用它的话，就需要在项目开始之前就做好规划。渐进交付的工作流程如下图所示。
| 最佳实践：Evolutionary Delivery（渐进交付） 1. 在完成需求分析之后，确定是否使用渐进交付。如果你对欲建立的系统有一个基本的理解，但同时又认为客户需求很可能在今后会发生变更，那么就可以考虑使用渐进交付。 2. 一旦决定采用渐进交付，那么首先要设计一个architecture和system core。Architecture应该尽可能地预见系统未来的走向，而core则应由那些不会因客户反馈而改变的较底层的系统功能组成。 3. 对每次交付迭代，先制定交付规划，决定本次迭代要开发的功能。注意：一定要确保先开发系统必需的功能。开发与测试完成之后，向客户演示这个系统，以获得他们的反馈。根据客户的反馈，再制定下一次迭代的交付规划，开始下一次迭代。 4. 重复这个循环，直到消耗完时间或金钱、直到完成计划的迭代次数、或者直到客户满意为止。 |
6.5 为你的项目选择最合适的生命期模型
软件经理必须意识到：对于任何特定的软件项目来说，最好的生命期模型完全取决于项目本身的需求；没有一个生命期模型能适用于所有项目。
| 最佳实践：为项目选择最合适的生命期模型 1. 在需求分析完成之后，便决定项目要采用哪种生命期模型。 2. 选择生命期模型时，参考下面的表格。
|