第25章 生命期模型的选择
效果
缩短原进度的潜力
一般
过程可视度的改善
一般
对项目进度风险的影响
减低风险
一次成功的可能性
很大
长期成功的可能性
极大
主要风险
l选择生命期模型这个行为本身没有风险，但针对每个具体的生命期，都可能存在对应的风险。
主要的相互影响和权衡
l无。
关于生命期的更多内容请查看第7章。
第26章测量
测量不仅有激励员工的短期效益，在成本，质量和进度方面也有长期效益。测量为预估，进度，可见性提供了矫正机会。
效果
缩短原进度的潜力
好
过程可视度的改善
很好
对项目进度风险的影响
减低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l对某个测量标准过度优化。
对某个测量标准过度优化是有害的，常常导致开发速度减低到非常慢。
l在对员工评估中误用测量方法。
常犯的错误是用一个测量方法来评估一个具体的人。测量方案是跟踪项目的，不是跟踪某一个人的。
l从代码行中获得误导信息。
l数据的精确性问题
主要的相互影响和权衡
l为改善项目预算，制定进度计划，评估生产工具和评估编程实践提供了基础。
测量计划通过下列方法来支持快速开发：
l测量能提供状态可见性。
l测量能诱导人员的活动。
l测量能提高士气。
l测量能帮助设置实际期望。
1.应用测量
以下是高效应用测量的几个关键因素：
1.目标，问题，测量标准
一些机构常常因为测量无用的数据而浪费时间和金钱。目标，问题，测量标准有助于解决这个问题。
l确定目标。决定若何改善你的项目或产品。
l提出问题。决定哪些问题有利于达到目标。
l建立测量标准。
2.测量小组
建立一个独立的测量小组通常是一个好办法。因为有效的测量需要特殊的技巧。你并不一定需要一个全职的测量小组，因为测量是短期活动。
3.测量什么
成本和资源数据，更改和缺陷数据，过程数据，产品数据，
l数据粒度
大多数公司遇到的一个问题，就是数据收集的粒度太大，以至于无法使用。例如一个公司收集了项目总工花费多少工时，却没有收集总体说明，原型制作，体系结构，设计，实现等分别用了多少工时。工体工时对改善软件开发活动并没有太大作用。以下列出了计算时间的种类，为大部分项目提供了所需的颗粒度：
2.应用收集到的数据
1.Pareto分析
如果你关心开发速度，收集数据后最有力的办法就是Pareto分析，寻找那些花费了80%的时间，却只占任务列表20%的活动。
2.分析及测量
与机构收集过于粗糙的数据一样，另一个极端的例子就是收集了过多无用数据。一个原则是在收集工作上花较少的时间，而在分析上花较多的时间。
3.反馈
一旦建立了测量计划，测量结果就会影响开发者和管理者。机构常常忘记向开发者提供反馈信息。
向开发者提供反馈信息，有利于开发者认真对待测量计划。
4.基准报告
成功应用测量的关键
l建立一个测量小组。
l在合适的测量粒度下跟踪收集数据。
l提供测量反馈。
第27章小型里程碑
小型里程碑是一种项目跟踪和控制的好办法，它能很好的提供项目状态可视性。它实际上是通过消除不可控制的风险和不能发觉的进度滞后来获得快速开发的效果的。
效果
缩短原进度的潜力
好
过程可视度的改善
很好
对项目进度风险的影响
减低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l无。
主要的相互影响和权衡
l特别适合项目恢复。
l与日构建和冒烟测试结合使用，效果很好。
l能与渐进原型法，用户接口原型，需求说明和其他难管理的项目活动结合使用。
l增加项目跟踪工作量换来良好的可视性和控制性。
小型里程碑对于快速开发的支持可以归结为以下四点：
l提高状态可见性
l提高控制精确度
l改善激励
l减少进度风险
1.应用小型里程碑
小型里程碑可以通过技术领导或项目经理在具体项目上执行，可以由单个员工在个人工作范围内执行。
当执行小型里程碑时，详细需求分析的工作量将使开发人员犹豫不决，在大型项目中更是如此，同时大型项目又是容易失控的，因此在大型项目中坚持这种详细跟踪是非常必须的。
1.尽早启动小型里程碑
2.让开发者自己建立个人的小型里程碑
3.保持里程碑的小型特征
4.里程碑的二分性
如果允许开发人员报告90%完成里程碑，那么它就失去了意义。一定要确保里程碑二分性的严格。
5.制定一系列完整的里程碑
里程碑列表中一定要包含每一项任务。最常见的错误就是忽略了一些必要的任务，或者开发人员在他们脑海中存在另一些计划外的里程碑，不要允许这样的行为。
6.在短期计划中使用小型里程碑
小型里程碑适合对一个大的目标进行短期进度跟踪。一般来说是对一个主要里程碑的拆解。
7.定期评价进度和调整或重新制定计划
小型里程碑还有一个优点就是可以不断地比较计划和实际，然后根据实际进行调整。
小型里程碑在项目修复时非常有用(第16章)。
小型里程碑非常适合用于每日构建和冒烟测试(第18章)。
小型里程碑也适合于控制渐进原型(第21章)和用户接口原型法(第42章)。
第28章 外包
效果
缩短原进度的潜力
极好
过程可视度的改善
无
对项目进度风险的影响
增加风险
一次成功的可能性
大
长期成功的可能性
很大
主要风险
l把专业知识扩到其他公司去。
l失去对开发的控制。
l泄露机密信息。
l丢失进度可视度和对进度的控制。
主要的相互影响和权衡
l以失去控制和削弱公司内部开发能力，来换取减低成本和提高开发速度。
l减轻员工压力。
l减少人员变动。当冲忙上一个项目时，外包能人员部署上的变动。
1.应用外包
1.制定一个包括风险管理的管理计划
在管理计划中需要包含：供应商选择，合同洽谈，开发需求，控制需求变化，跟踪供应商进度，监督质量，审核产出等。你可以跟你的供应商一起制定管理计划。
2.了解合同管理
管理外包合同已经有成熟的知识体系了。可以参考《软件采集管理》
3.优先跟供应商沟通
即使觉得与供应商没什么可以沟通时，也需要定期跟他们沟通。
4.依靠一些公司内部的技术资源
5.留意不稳定的需求
无论项目是自行开发还是外包，第一步都是应该全力投入来确定一个稳定的需求。这样在项目的总价上不会出现更多的追加。
6.合同种类
这个可以参考PMP的采购管理。
7.承包商评估
成功应用外包的关键
l仔细选择供应商。
l与承包商签订详细的合同。
l至少要像自行开发项目一样管理好外包项目。
l把与供应商交流放在工作最重要的位置。
第29章原则性谈判
原则性谈判是一种基于改善沟通和创造双赢的策略，而不是单方获利的谈判技巧。它可以应用于需求分析，进度计划制定，性能修改讨论以及项目其他阶段。
效果
缩短原进度的潜力
无
过程可视度的改善
很好
对项目进度风险的影响
减低风险
一次成功的可能性
很大
长期成功的可能性
非常大
主要风险
l无。
主要的相互影响和权衡
l无。
第30章高效开发环境
效果
缩短原进度的潜力
好
过程可视度的改善
无
对项目进度风险的影响
没有影响
一次成功的可能性
大
长期成功的可能性
很大
主要风险
l以装饰为目标的办公环境会导致生产率下降。
l搬迁造成停工。
l由于软件开发人员的优越待遇会产生各种反应。
主要的相互影响和权衡
l小量增加成本，带来生产力的提高。
第31章快速开发语言
效果
缩短原进度的潜力
好
过程可视度的改善
无
对项目进度风险的影响
增大风险
一次成功的可能性
大
长期成功的可能性
很大
主要风险
l带来银弹错误和过高估计时间的节省。
l不能拖大道大型项目。
l鼓励鲁莽编程。
主要的相互影响和权衡
l小量增加成本，带来生产力的提高。
第32章需求修正
需求修正就是对产品说明进行仔细检查，如果发现不必要或过于复杂的需求，就去掉。由于产品成本和进度主要受到产品范围的影响，因此减少产品范围将有助于产品成本和进度。
效果
缩短原进度的潜力
很好
过程可视度的改善
无
对项目进度风险的影响
降低风险
一次成功的可能性
很大
长期成功的可能性
极大
主要风险
l删除一些必要的需求。
主要的相互影响和权衡
l无。
第33章重用
。
效果
缩短原进度的潜力
极好
过程可视度的改善
无
对项目进度风险的影响
降低风险
一次成功的可能性
低
长期成功的可能性
很大
主要风险
l如果重用部件质量不高，或没有经过仔细挑选，可能造成资源的浪费。
l花费工作量。
l错误的投入。
l对节约的过高估计。
主要的相互影响和权衡
l无。
人们有时认为重用只包含代码层面，而实际上每一项工作都是可以被重用的：代码，设计，数据，文档，测试材料，说明书，计划等。
第34章签约雇佣
第35章螺旋形生命期模型
螺旋形生命期模型是一个非常典型的生命期模型，它关注的重点在于发现和降低风险。它对快速开发方面带来的好处并不在于速度的加快，而在于不断减低项目的风险水平。能否成功运用螺旋形生命期模型，取决于尽责的，专心的和知识渊博的管理人员。
效果
缩短原进度的潜力
一般
过程可视度的改善
很好
对项目进度风险的影响
降低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l无。
主要的相互影响和权衡
l用增加针对计划的要求和实施的追踪，换来进展可视度的改善和风险的大幅度降低。
有关螺旋形生命期的详细内容，请参阅第7章的内容。
第36章阶段性交付
阶段性交付是一种生命期模型，在该模型中软件被分阶段开发。在通常情况下，首先开发最重要的功能。它并不能减少软件在开发上需要的时间，但能充分的提供开发进度标记，以及项目状态标记。
效果
缩短原进度的潜力
无
过程可视度的改善
好
对项目进度风险的影响
降低风险
一次成功的可能性
很大
长期成功的可能性
极大
主要风险
l目标偏离。
主要的相互影响和权衡
l利用小型里程碑，可以规划每个交付阶段。
l成功依赖于确定一个程序族。
l灵活性小于渐进原型和渐进交付。
l可以作为渐进交付的基础，用增加计划时的投入，换取进度可视性。
1.应用阶段交付
应用阶段交付，你必须在开始时，就对最终要交付的产品有清晰的概念。
运用阶段交付是较晚一些的活动，可以等到你需求分析和结构设计之后再开始着手考虑阶段交付相关的事情。
一旦完成了结构设计，为了应用阶段交付，你必须对一系列的版本做出计划。然后在每一个版本中完成详细设计，构建，测试等工作。
1.关注开发者
阶段交付要求每一个开发者都在阶段截至日期前完成开发。如果一个开发者没有完成，其他的版本都将受到影响。一些开发者习惯独自工作，按找他们自己的顺序来安排工作，还有一些开发者可能对阶段交付的强制性感到反感。如果你不能有效的解决这两个问题，而是放任开发者习惯自由，阶段交付将失去意义。
确保开发者接受计划，最好的办法就是在最初制定计划时，让开发者参与其中。
2.项目的种类
阶段交付能很好的应用于已经完全熟知的系统。如果你对产品中一些特性还没有完全了解，你就必须继续对产品深入了解，之后再做出阶段计划。
当你的用户急于使用产品中某一部分时，阶段交付将发挥更好的作用。在产品完全完成之前，如果你能提供客户他们继续的20%的功能，那么你对客户就提供了非常有价值的服务。
第37章W理论管理
通常一个项目涉及了很多带有各自利益的干系人，包括指挥者，开发者，用户，客户，维护者等。W理论提供了一种与各自利益一致的管理框架。它的基础是：开诚布公的了解各个干系人各自的利益，对冲突进行协商，然后组织项目，让所有干系人实现各自的需求。
效果
缩短原进度的潜力
无
过程可视度的改善
很好
对项目进度风险的影响
降低风险
一次成功的可能性
极大
长期成功的可能性
极大
主要风险
l无。
主要的相互影响和权衡
l取决于对原则性谈判方法的使用。
从以上表格来看，很多目标都是冲突的。如果组织没有对这些目标进行很好的协调，各方都会感到利益受损。
1.应用W理论
1.让所有人都成为获胜者
2.步骤一：确定公共获胜的前提
l了解人们希望如果获胜
l建立合理的期望
l将大家的任务与他们获胜条件相匹配
l营造一个支持项目目标实现的环境
3.步骤二：建立一个共同获胜的软件开发过程
l做一个现实的计划
l用计划来控制项目
l辨别并管理一方获胜一方失败，或双方失败的风险
l让大家都参与进来
4.步骤三：建立一个共同获胜的软件产品
除了成功的过程之外，你还需要去构建一个成功的产品：从客户看来，产品的外部特征，也包括内部质量，从最终用户看来，产品应该易学易用，而且可靠，从维护者看来，产品应该文档出色，编程风格严谨，容易修改。
第38章舍弃原型法
舍弃原型法，是指代码是为了探究系统成功关键因素而开发的，验证完成之后就被舍弃了。
效果
缩短原进度的潜力
一般
过程可视度的改善
无
对项目进度风险的影响
降低风险
一次成功的可能性
极大
长期成功的可能性
极大
主要风险
l保留一个舍弃型原型。
l没有有效利用建立原型的时间。
l不现实的进度和预算。
主要的相互影响和权衡
l无
1.应用舍弃原型法
1.用户界面
2.报告格式
3.图形格式
4.数据库组织
5.数据库性能
6.复杂计算的精确度和性能
7.实时系统中的关键时间部分
8.交互系统的性能
9.校验系统中部分功能可行性
第39章限时开发
限时开发能帮助提高开发团队的紧迫感，也有助于项目把重点放在产品上。限时开发是通过“让产品服从进度，而不是进度服从项目”的方式，来保障进度计划。限时开发获得成功的关键因素是获得管理人员和客户的同意，因为在必要时，需要削减功能而非延长进度计划。
效果
缩短原进度的潜力
极好
过程可视度的改善
无
对项目进度风险的影响
降低风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l将限时开发应用在不合适的项目上。
l为了保持特性数量而不顾质量。
主要的相互影响和权衡
l依赖于渐进原型的使用。
l用性能的控制来换取开发时间的控制。
l通常在RAD项目(项目修复)中，与JAD，渐进原型共同使用。
l当交付时间比交付内容重要时，可以与渐进交付共同使用。
l能很好的避免90-90问题。
很多项目都碰到这样的问题，当项目已经完成90%的时候，接下来的项目进度就停止了，这种状态能维持几个月甚至几年。
1.应用限时开发
1.使用限时开发的最低要求
l各功能优先级列表。
l切合实际的进度估计。
l适合的项目类型。限时开发最适合内部商业软件开发。需要大量手工代码的高度定制系统通常不适合限时开发。
l最终用户的充分介入。限时开发的成功取决于最终用户的反馈。
2.成功使用限时开发的关键
l只对可以在规定时间内完成的项目，使用限时开发。
l确保最终用户与管理层对系统的核心已达成一致。
l确保管理层已经同意，在进度压力下，可以剔除部分功能。
l在限时开发全程中，都需要保证质量。
l如果需要的话，宁可删除功能，都不能延长工期。
第40章工具组
工具组是指在公司内建立一个小组专门负责收集，评估，协调使用以及传播介绍各种新开发工具。这样可以减少尝试和犯错的次数，任何一个需要同时开发两个以上项目的单位都可以建立一个工具组。哪怕所谓的小组，只有一个非全职工作的人员。
效果
缩短原进度的潜力
好
过程可视度的改善
无
对项目进度风险的影响
降低风险
一次成功的可能性
大
长期成功的可能性
很大
主要风险
l无。
主要的相互影响和权衡
l无
第41章十大风险清单
十大风险清单，是一种能帮助我们监控软件项目风险的简单工具。
效果
缩短原进度的潜力
无
过程可视度的改善
很好
对项目进度风险的影响
降低风险
一次成功的可能性
极大
长期成功的可能性
极大
主要风险
l无。
主要的相互影响和权衡
l能够与其他实践结合使用。
详细内容，可以参阅第5章。
第42章构建用户接口原型
构建用户接口原型，就是构建一个用户接口来探究用户接口设计和系统需求。
效果
缩短原进度的潜力
好
过程可视度的改善
一般
对项目进度风险的影响
降低风险
一次成功的可能性
极大
长期成功的可能性
极大
主要风险
l不断装饰原型。
主要的相互影响和权衡
l能够与其他实践结合使用。
成功应用构建用户原型的关键
尽量为原型制作一个漂亮的外观。
重视最终用户的参与和反馈。
第43章自愿加班
自愿加班为开发人员提供了有意义的工作实践，也为管理人员提供了激励内部工作人员的机会。但是加班是不能持久维持下去的，适当的时候应该让开发人员恢复到正常的工作状态。
效果
缩短原进度的潜力
好
过程可视度的改善
无
对项目进度风险的影响
增加风险
一次成功的可能性
大
长期成功的可能性
极大
主要风险
l由于过分的进度压力和过度加班，导致进度反而降低。
l降低了因为需要而紧急加班的应变能力。
主要的相互影响和权衡
l需要采用具有人情味的和非强迫性的激励方法。
l通常用来支持小型里程碑，渐进生命期模型，限时开发等。
1.应用自愿加班
1.对开发者采用“拉”的方法，不要采用“推”的方法
激励开发人员，就像是向前移动一根绳子，你最好采用拉的方式，而推是没有太大作用的。
通常来说激励开发人员最好的5种方法：
l成就感。
l成长的可能。
l工作本身。
l个人生活。
l技术管理机会。
一个非常有效的方法，就是激励整个项目组。清晰地为小组设置目标，帮助小组建立集体感，并且让小组成员知道产生效果比努力工作更重要。
只看到形式，不注重激励是领导者“推”式加班的重要原因。在一个快速开发项目中，你需要关注的是做了多少工作，而不是员工在办公室呆了多长时间。
2.不要要求加班，它将产生更少的产出。
强迫超过开发人员愿意加班的时间，影响的不止是加班的那些时间，正常的工作时间也将受到影响。
3.不要采用加班来进行项目控制。
当项目被发现将要失去控制的时候，大部分管理者都让开发者更多加班来控制项目，但是加班本身就是项目失控的标志。处于控制下的项目不需要开发人员加班，一些开发者在可控项目下加班，只是因为他们对项目感兴趣，而不是需要加班来进行项目控制。
4.不管什么理由，不要过多加班。
不论是强制加班，还是自愿加班，都不要过度。因为过度加班将导致以下问题：
增加缺陷数量。
容易诱发开发人员思维不集中。
降低创造性。
加快资源消耗。
减少了自我教育和组织改进的时间。
减少了生产力。
D,�WF-�VF/��3��G�\
