第三部分最佳实践
有些实践并不是马上就可以采用，有些甚至是相互排斥的，有些实践并不需要特殊的软件开发方式，而有些实践你必须从根本上改变你的项目开发方式。
本章讨论的最佳实践，是出于对以下类型的改善而言：
l缩短原进度的潜力
l过程可视度的改进
l对项目进度风险的影响
l一次成功的可能性
l长期成功的可能性
l主要风险
l主要的相互影响和权衡
第17章变更委员会CCB
CCB是控制软件产品变更的一种措施。它是通过召集个部门代表一起工作来进行的。CCB对批准和拒绝项目变更有最终决定权。CCB通过提高变更的可视性，减少项目中难以控制的变更数目等方法，对项目产生快速开发的效果。
效果
缩短原进度的潜力
一般
过程可视度的改善
一般
对项目进度风险的影响
减低风险
一次成功的可能性
很大
长期成功的可能性
很大
主要风险
l批准的变更太少或太多。
主要的相互影响和权衡
l可以和其他方法自由地混合使用。
第18章日创建和冒烟测试
日创建和冒烟测试是一个过程，在这个过程中，软件被每天完全创建并通过冒烟测试以检验基本运行情况。这个过程可以减少不成功的整合，质量低劣，和项目进展可视度差等情况。
效果
缩短原进度的潜力
好
过程可视度的改善
好
对项目进度风险的影响
减低风险
一次成功的可能性
很大
长期成功的可能性
极大
主要风险
l有过于频繁发布中间版本的压力。
主要的相互影响和权衡
l项目开销略微增加，换取集成风险的降低和可视度的改善。
l和里程碑一起使用效果特别好。
l对增量式开发模型天然支持。
这个简单的过程，在以下这些方面明显地节约时间：
l使集成风险降到最小。
l减少低质量风险。
l比较容易支持对缺陷的诊断。
当产品被每天创建和测试时，可以很容易的定位问题。比如17号的产品没有问题，18号出现问题，那么问题一定是17号和18号中间。如果周创建或月创建，问题的排查将在一周或一个月内。
l支持对项目进展的监控。
l可以提高士气
l可以改善客户关系
1.使用日创建和冒烟测试
1.日创建
日创建的最基本原则就是每天都创建产品。
2.检查失败的创建
为了日创建过程有效，必须保证被创建的产品有效。如果产品无效，则解决产品问题成为最优先的工作。
为了验证创建是成功还是失败，必须提前制定标准。这个标准不能太细致或严格，但也需要有严格的质量标准。成功的创建至少应该是：
成功的编译了所有文件。
成功的链接了所有文件。
不包含任何显示停止的缺陷。
通过冒烟测试。
3.每天进行冒烟测试
如果没有冒烟测试，日创建就没有任何意义。冒烟测试不需要进行详尽的测试，但必须要能够检测主要的问题。
4.成立创建组
在某些情况下，创建工作大到足以成为一个任务，你可以为日创建成立一个创建组。在工作量不大的情况下，也可以让质保人员做这件事。
5.只有有意义时，才将新代码增加到日创建中
日创建并非要每天都加入新代码。
6.新代码加入日创建的频率不能太低
7.在新代码加入日创建前，要求开发者进行冒烟测试
8.对破坏系统创建的情况建立惩罚
9.在早上发布创建
在早上发布创建和冒烟测试有几个好处：
测试可以测试那天最新的创建。如果下午创建，测试者不得不在剩余的时间内完成测试，这对测试是不公平的。
如果创建失败，开发将有更充裕的时间处理问题。
10.即使在压力下也要坚持创建和冒烟测试
当进度压力较大时，维护日创建需要做的工作似乎是负担，但这是错误的观点。因为在压力下，开发者将在设计，实现和测试阶段走捷径，或工作不如平常仔细，这将导致项目缺陷更多，越来越偏离轨道。
2.管理日创建和冒烟测试的风险
1.倾向于过早发布
3.日创建和冒烟测试的附加效果
有人认为，除了减少集成风险，提高质量和增加过程可视度之外，日创建和冒烟测试对改善产品质量有重要作用。
4.日创建和冒烟测试与其他方法的交互作用
日创建最好是跟小型里程碑(第27章)一起使用。
日创建也支持增量式开发方法(第7章)。
5.日创建和冒烟测试的成功关键
l每天进行创建。
l每天进行冒烟测试。
l冒烟测试随着产品的增长而增长。
l应该把一个良好的创建放在首位。
l日常工作中，一定要确保失败的创建只是例外，而不是常态。
l在压力下不要放弃。
第17章变更设计
变更设计包含了面向变更设计的一系列实践。应在软件生命期的早期，引入这些活动，使它们能够充分发挥作用。变更设计是否成功取决于下列活动的进展情况：识别可能发生的变更，制定可行的变更方案，隐藏设计变更结果以使变更不会对整个程序造成影响。如果这些活动完成得好，将为开发出更灵活的程序打下基础，而程序灵活性的提高，有利于当变更请求较晚提出时，降低对进度的冲击。
效果
缩短原进度的潜力
一般
过程可视度的改善
无
对项目进度风险的影响
减低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l过度依赖编程语言来解决设计问题，而不是采用面向变更设计的方法。
主要的相互影响和权衡
l能为增量式开发提供必要支持。
l设计时采用了软件重用工作方法。
一些非预期的变更，常常发生在设计完成和编码启动之后，这将对开发进度产生破坏性的影响。这种变更如果没有处理好，项目将被认为进展太慢，即使在变更之前进度是正常的。
1.采用变更设计
变更设计不是单一的设计方法，而是一种能够使软件设计灵活的一系列活动。下面列出了一些这样的活动：
l识别可能发生变更的区域。
l采用隐藏信息的方法。
l制定变更计划。
l定义程序族。
l采用面向对象的设计方法。
下面将分别介绍每项活动，其中有些活动是重叠的，但没一项活动都有其独特的作用。
1.识别可能发生变更的区域
变更设计能够成功的首要因素，就是识别潜在的变更。以下是经常发生变更的源头：
l软/硬件依赖性
l文件格式
l输入和输出
l非标准的语言特性？
l难以设计和实现的部分
l全局变量
l特殊数据结构的实现
l抽象数据结构的实现
l商业规则
l事件的处理顺序
l当前版本中好不容易才排除的需求
l当前版本中简简单单就排除的需求
l基本上不会包含在当前版本中的需求
l为下一版本规划的特性
2.采用信息隐藏的方法
一旦生成了潜在变更清单，就应该将与这些变更有关的设计结果，孤立在它自身的模块中。将可能变更的设计结果隐藏在它们自身的模块中，这种方法叫做“信息隐藏”。信息隐藏，在实践中发挥着极其巨大的作用。此外，信息隐藏也是机构设计和面向对象设计方法的部分基础。在结构设计中，黑盒的概念来源于信息隐藏，而在面向对象设计方法中，信息隐藏引出了封装和可视性的概念。
使用信息隐藏方法进行设计，首先需要把易于发生变更或特殊的复杂的设计，列出清单。然后设计各模块，将变更带来的影响隐藏在每一个设计结果中。
3.制定变更计划
对于那些可能发生变更的地方，制定变更计划。这里的变更计划，并非是一个进度计划，而是一个规范文档。规范中可以规定应用以下任何方法：
l模块采用抽象的接口，而非暴露细节的接口。
l使用命名的常量来定义数据结构的大小，而不是直接使用文字或数字。
l使用后赋值策略。
l使用表驱动策略。
l使用方法而非复制代码行。
l使用简单的方法，执行单一的功能。
l将无关的操作分开。
l将通用代码和专用代码分开。
上述这些都是非常好的软件工程方法，它们非常支持变更。
4.定义程序族
设计者在设计产品时，应该将各种版本中很少发生变更的部分放在树的根部。
定义程序族的好方法是：首先要确定最终用户使用的最小功能集，然后在此基础上确定最小的功能扩充。
第18章渐进交付
渐进交付是一种生命期模型：它在阶段交付的控制性和渐进原型的灵活性之间寻找平衡。它尽可能把某些选定的功能，在整个产品开发完成之前交付客户，从而有利于快速开发，并且也具有响应客户改变产品方向的能力。慎重地使用这种方法，可以提高产品质量，较少代码数量，使开发和资源检查分配更加均匀。
效果
缩短原进度的潜力
好
过程可视度的改善
极好
对项目进度风险的影响
减低风险
一次成功的可能性
较大
长期成功的可能性
极大
主要风险
1.目标偏离。
2.减弱了对项目的控制。
3.不切实际的项目进度和资金预算。
4.在开发过程中，开发者对开发时间的低效率使用。
5.早期的快速发展，导致对进度和预算不切实际的期望。
6.项目控制性降低。
7.项目发展方向和目标偏离。
8.缺乏用户反馈。？？？不理解
9.产品质量降低。
10.设计不佳。
11.缺乏可维护性。
12.开发者效率低下。
主要的相互影响和权衡
l从阶段交付和渐进原型中发展出来。
l其成功取决于对未来变化的预见。
l提高了在项目中期进行矫正的能力。
l提前和频繁交付，能提供更多控制点，帮助估算。
l造成每隔几周就能推出新产品的假象。
l可以提高开发者和客户的士气。
l较早获得客户反馈。
有些人去超市前，会列出一个需要购买的商品清单；还有一些人完全没有清单，他们到超市后，看到什么好就买什么；大部分人则处于两者时间，他们会先准备一份商品清单，但是到超市后，多多少少会进行一些调整。
在软件生命期模型中，阶段交付就是准备商品清单的人。阶段交付可以为客户提供明确的进度标志，在管理上也具有很高的控制性，但是缺乏灵活；渐进原型就是完全没有清单的人。渐进交付非常灵活，但缺少管理上的控制性；渐进交付就是准备清单但还是会调整的人。渐进交付就是将阶段交付的控制性和渐进原型的灵活性结合在一起。它的利弊取决于在实际案例中，它更加偏向哪一边。
渐进交付通过以下途径对快速开发予以支持：
l减低最终产品与需求不符的风险。避免返工。
l对于定制软件，它通过提前和经常性的交付，来提供开发过程的可视度。
l对于商业封装软件，它支持更频繁的版本更新。
l由于在每次渐进交付后允许进行进度调节，因而减少了进度估算错误。
l通过提前集成，降低集成风险。
l有利于鼓舞士气。
1.应用渐进交付
首先你应该对客户需要什么有一个初步概念，并以它为基础建立一个系统框架和核心。框架应该尽可能多地预见系统的走向，核心则应该是由那些不被客户反馈而影响的功能组成。建立在核心之上的细节都可以是不确定的，但核心必须坚定地保持一致性。
正确地确定系统核心，是使用渐进交付的关键。
对于渐进交付，你可以从渐进原型的基础上开始，逐步向阶段交付的方向发展，以便增加控制性。也可以从阶段交付开始，向渐进原型发展，以增加灵活性。比如你已经规定了123阶段的产品，但45阶段并不确定。
2.何时使用渐进交付
如果你对系统了如指掌，并且不希望出现意外的话，最好用阶段交付而不是渐进交付。因为这时你更多的是需要控制性，阶段交付能够提供更好的控制性和可视度。
如果你对系统知之甚少，并且希望活动意外的惊喜的话，最好用渐进原型而不是渐进交付。因为渐进交付需要你掌握系统核心内容，对渐进原型来说，就不必要。
渐进交付不仅可以用在全新系统开发上，也可以用在现有系统改造上。
第19章渐进原型
渐进原型是一种生命期模型，系统以逐步增加的方式进行开发，以便随时根据客户或最终用户的反馈来修正系统。对于任何一个高风险领域而言，渐进原型都是适用的。
效果
缩短原进度的潜力
极好
过程可视度的改善
极好
对项目进度风险的影响
增大风险
一次成功的可能性
较大
长期成功的可能性
极大
主要风险
1.不切实际的进度和财政预算。
客户，用户或市场人员看到快速开发的原型时，对真实产品的开发也会抱有不切实际的进度期望。当客户发觉实现产品比产出原型的速度慢很多时，他们就会失望。
2.项目可控性降低。
对于渐进原型来说，在项目开始时，并不知道要多久才能完成。让客户始终看到项目进展标记，可以在一定程度上减少这种风险。
3.缺乏最终用户或客户反馈。
原型法并不能保证获得高质量的用户反馈。因为当用户看到原型时，并不能完全明白所看到的东西。常见的情况是，客户被那些活灵活现的原型软件所倾倒，以至于根本就不去理解那些花哨东西下面的真实含义。如果他们轻易的同意了你的原型，事实上你会发现他们并不理解他们看到的东西。所以，一定要保证用户和客户能够认真分析原型以便提供有意义的反馈意见。
4.产品性能不佳。
有以下因素导致性能不佳：在产品设计时没有考虑性能问题；在最终产品中保留着大量原型时期的代码。
你可以考虑以下步骤来降低质量不佳的风险：及早考虑性能问题；不要匆匆忙忙不顾质量低开发原型。
5.建立原型的时间没有被充分利用。
项目在原型阶段常常会浪费时间，因为原型法是一种探索性的不断反复的过程，很难做到精细管理。
想要高效利用原型开发阶段的时间，需要不断跟踪项目并对优先级进行控制。在原型阶段需要以小时或天来分割任务。
想要避免在原型阶段浪费时间，还有一定要注意，就是避免使用缺乏经验的开发人员。
6.不切实际的质量期望。
7.设计不佳。
8.缺乏可维护性。
9.目标偏离
由于客户与最终用户会直接接触到原型，这时会导致他们对未来的要求不断增加。除了跟他们交流控制之外，还可以使用变更管理方法来控制目标偏移。
主要的相互影响和权衡
l牺牲项目的控制性，来换取较多的客户反馈和过程可视度。
l可以与用户界面原型法和一次性原型法结合使用。
l可作为渐进交付的基础。
渐进原型是一种软件开发方法：你首先选择系统的一部分完成，然后以此为基础演化出系统的其余部分。与其他原型发不同的是，在渐进原型中，原型是不被丢弃的。
对于渐进原型来说，它是一种探索型方法，通过较早发现风险来支持快速开发。对于不同的项目，不确定的部分也是不一样的。所以你首先要确定从哪里作为系统开发的起点，这个起点通常是系统中最直观或风险最高的部分。
第20章目标设定
人的激励是增加生产力的最重要因素，目标设定正是利用了这一规律。在设定目标时，只是简单的告诉开发人员你想得到什么，开发者通常就会为了达到你附加的“最近目标”而努力工作。然而，无法将项目划分为一系列小而清晰的目标，是目标设定的主要障碍。
效果
最短进度目标
最小风险目标
最高可视度目标
缩短原进度的潜力
很好
无
无
过程可视度的改善
无
好
极好
对项目进度风险的影响
增大风险
减小风险
减小风险
一次成功的可能性
大
大
大
长期成功的可能性
很大
很大
很大
主要风险
1.如果目标发生变化，则会大大影响士气。
主要的相互影响和权衡
l有助于限时开发，自愿加班以及激励员工。
第21章检查
检查是一种正式性的技术回顾，参与者都应该受过良好的训练，并被赋予特定的角色。这种正式检查比测试更有助于发现错误，无论是发现错误的比例，还是发现每个错误需要的时间。
效果
缩短原进度的潜力
很好
过程可视度的改善
一般
对项目进度风险的影响
降低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l无。
主要的相互影响和权衡
l可与其他快速开发方法结合使用。
更多内容，可以参看4.3节。
第22章联合应用开发JAD
JAD是一种对需求进行定义并设计用户界面的方法。在JAD过程中，用户，开发者，管理人员通过会议，一起设计产品，共同澄清与系统相关的细节问题。JAD更关注与商业问题，而非技术问题。它的好处在于更快更好的收集需求信息，从而避免后期需求变更。JAD的成功依赖于JAD小组领导人的有效管理，依赖关键用户，关键管理者和关键开发者的参与，依赖参与者在JAD会议中的合作。
效果
缩短原进度的潜力
好
过程可视度的改善
一般
对项目进度风险的影响
降低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
1.由JAD会议产生不切实际的效率期望。
参与者只看到能够这么快速的建立原型，却不知道建立系统将花费长的多的时间，所以对项目容易产生不切时间的期望。
可以通过两种方式来减小这种风险：第一，需要花费时间来制定一个可行的开发进度表。第二，你可以选择一种增量开发模型与JAD配合使用。增量开发能让人感觉系统的进度较快。
2.由JAD会议产生的对剩余工作量过早的，不精确的预估。
由于在JAD会议期间，一直无法对估算进行修正，将导致预估不精确。因此，在JAD规划阶段做出的预估，在完成JAD设计后，一定要进行修正。
主要的相互影响和权衡
l与增量开发模型结合，能获得最好的效果。
l可以跟快速开发语言和原型工具结合。
l由于最终用户参与到设计中来，使得用户满意度大大提高。
l避开了组织之间的障碍。在JAD讨论中，群体行为将暴露对立的需求以及政治分歧，将有机会提前解决这些问题，从而避免这些因素在后期导致项目失败。
lJAD应该与一种增量式生命模型结合使用，比较渐进交付，阶段交付，渐进原型等(参考7，20，21，36章)。增量式生命模型可以使JAD设计讨论之后能较快交付部分软件。
lJAD加原型法(参考21，38，42章)。
JAD的本质就是一系列由管理人员，最终用户，开发者召开的会议。JAD是开发之前弄清用户需求的最有力方法之一。它通过以下方式使项目受益：
l使上层管理人员能尽早参与到开发过程中。这种较早参与有助于缩短项目周期。
l缩短了明确用户需求的过程。
l能尽早发现有问题的产品功能。
l有助于第一次就获得正确的需求。
l有助于第一次就获得正确的用户界面。有些产品不断变更，就是因为用户不能接受产品界面。
l可以防止组织内的相互牵制。因为许多项目都受到内部矛盾的阻碍，JAD方法在设计阶段就把决策者召集在一起，能尽早把这些矛盾摆到桌面上，使问题能尽早解决。
1.使用JAD
JAD由JAD规划阶段和JAD设计阶段两个主要过程组成。在传统意义上，这两个阶段都属于需求阶段，但又属于不同的层次。
JAD规划阶段，其重点在于构思出系统总体上的功能。该阶段主要产物是系统目标，首要方向和大致工程进度，以及是否需要继续进一步开发。同时它还需要对JAD设计阶段进行规划。
JAD设计阶段，重点在于导出更进一步的用户需求。其目的是进行用户层次上的软件设计。JAD设计阶段，实际上是广泛使用了原型方法，其产物是用户界面设计，数据库模型，以及进一步细化的预算和进度计划。
1.JAD规划
JAD规划侧重于需求和计划。其目标是高层次需求，定义系统边界，对JAD设计进行规划，生成JAD规划文档，以及获得对JAD的认可。
l定制
定制的目的在于，是JAD规划会议合适于特定的项目需要。主要工作有：
n引导参与者了解JAD过程。
n组织JAD小组。
n为特定项目设定JAD任务和结果。
n为JAD规划讨论准备材料。
通常参与规划的并不是设计人员，而是相对较高位置的管理人员。
l讨论
JAD讨论是区别于其他需求采集方法的关键所在。JAD讨论的关键因素包括：一个受过良好训练的主持人，管理人员和其他关键决策者的参与，结构化方法的使用，工作不被打断的保证，以及良好的会议管理方法。
l时间限制
JAD讨论一般持续1到10天，它是一个团队活动，必须保证所有参与者都全职出席。
l设施
JAD讨论应该在非工作地点，比如酒店，会议室等。JAD设施必须保证参与人从日常工作中脱离出来。JAD设施应该准备可视化设备，计算机，本子，笔，白板等。
l角色
JAD讨论包含一系列角色：
n讨论主席。他是对JAD成功与否起决定性作用的人。
n执行赞助商。他肩负着系统的财政重任。这种人是规划讨论之后决定项目是否实施的关键人物。
n最终用户代表。他是代表最终用户的关键人物。有权利和义务对项目做出负责任的决定。
n开发者。他们的工作是转变用户观点，告诉他们一个完美的系统是不可能的；他们还应该回答关于系统的问题，功能，费用，时间，方案等；开发者应该避免使用“是”或“否”等词语来回答问题。
n书记员。他来自开发部门，主要任务是记录讨论过程发生了什么。他的工作是主动参与讨论，主动询问并澄清问题，提醒前后不一致的地方。
n专家。他们是被邀请来提供专业支持的。专家并非需要每天都参与会议，只有需要他们帮忙的时候才有必要参与。专家对于JAD来说是一种资源，而非参与者。
l常见问题
n关键人员无法保证全程参加。
n过多的参与者，导致JAD小组涣散。一个完整的JAD小组应该在8个人以下。
l在讨论中发生了什么
一个典型的JAD规划讨论，要进行以下8项内容：
n介绍总体方向。向小组介绍讨论目的，时间以及各项议程。
n定义高层需求。勾画出系统概况，包括确定系统需要满足的商业需求，系统目标，预期效果，系统可能包含的功能，各项功能的先后次序，系统策略和未来构想。
n限定系统边界。
n确定并预测JAD设计所包含的阶段。
n确定JAD设计阶段的参加人员。
n安排JAD设计的进度。
n记录讨论要点和思路，将规划讨论的问题，解决方案和思路制成文档。
n讨论总结。
在规划时，每个活动的过程都大致相同：JAD主席提出任务，参与者提出想法，每个想法被提出，参与者就要对它进行检验，最后书记员记录每个问题的决定，如系统目标，系统功能，大致次序，系统边界，JAD设计阶段的规划等。
l整理
整理应该尽可能多的记录讨论过程中产生的结论。JAD规划的讨论结果有：
n系统目标列表。
n详述可能出现的系统功能。包括功能本身，功能需要满足的商业需求，功能带来的效益，并对每个功能的投资回报率进行预估，以及每个功能的优先级。
n限制系统边界。包括系统不包含的功能列表。
n与其他系统的接口。
nJAD讨论中未能解决的事情。包括问题描述，负责人，预计解决的日期。
n下一步的计划。
2.JAD设计
JAD设计的核心是用户需求和用户界面设计。其作用是定义详细的用户需求，系统边界，屏幕和报表设计，开发原型，以及收集编辑校验数据。
l定制
跟JAD规划一样，定制主要是为讨论做准备，包括硬件准备，会议室准备，参与人员培训等。
l讨论
通常JAD设计阶段的讨论比规划讨论要长，从几天到10多天不等。
参与角色类似，但赞助商可以不参与了，除非需要他们的协助。开发代表将非常忙碌，因为白天他们参与讨论，晚上需要制作原型。最终用户代表必须是多个，他们必须全程参与以便对产品的设计，实现和测试进行讨论。
l在讨论中发生的事情
n介绍总体方向。向小组介绍讨论目的，时间安排，以及各项议程。
n回顾JAD规划中形成的系统需求，需求边界。
n制作工作流程表。介绍各项工作的流程。
n设计用户界面和报表。
n明确处理需求。包括数据量，运算速度，安全需求等。
n定义接口需求。明且有哪些外部系统需要交互。
n明确数据分组以及各项功能。
n记录讨论要点和思路。
n讨论总结。
JAD设计相比一对一的需求采集高效很多，因此将节省大量时间。
l整理
n完成JAD设计文档。
n完成原型。
n让参与者都审核设计文档和原型。
n将结果交付给赞助商。
迅速从JAD设计过度到功能设计和开发是非常重要的，如果间隔太久，可能导致需求过时。
2.JAD成功的关键
l经验丰富的讨论主席。
l确保赞助商参与JAD过程。
l确保关键人员全职参与JAD过程。
l精心对参与人员做好准备工作。确保他们理解JAD目标。
lJAD结束后，帮助用户建立切实的期望。
lJAD结束后，采用一种增量的生命期模型开发项目。
