第一部分有效开发

第二章快速软件开发的策略

快速开发的总体策略

*避免典型错误

*打好开发基础

*管理风险 避免灾难

*采用面向进度的开发方式

开发速度的四维

*人员，过程，产品，技术

*人员

1.项目成员的选择

*有才能的人 更少和更好的人

*工作匹配 使任务和人员的技能和动机相匹配

*职业的晋升 帮助人员自我实现

*团队平衡 强调人员之间的互补和协调

*排除不称职的人员尽快！

2.项目组结构

3.人员激励

*过程

1.避免重复工作

2.质量保证

质量保证有两个目的：

A.基础的质量保证

B.在各个阶段用最少的时间代价，查出错误

我觉得还有以下目的：

C.对真实进度进行审核。因为有时程序员的进度是有水分的，需要通过测试将水分排出，获得真实进度情况。

3.开发基础

4.风险管理

5.资源目标

6.生命期计划

由于生命期计划是基本的项目管理，因此它是非常有用的。例如，你有一个高风险的项目，基于风险的生命期模型就非常适合，如果面对一个需求含糊的项目，则增量生命期模型更有益。生命期模型可以使你更容易确定并组织软件项目要进行的多种活动，从而更高效的工作。

7.面向客户的开发

现代软件的开发方式与典型的主机时代的开发方式相比，一个最为彻底的改变是更侧重于关注客户的需求和愿望。开发人员已经意识到：开发符合产品规格的软件只是完成了一半的工作，另一半是帮助客户配置出产品能够实现的功能，而实现这些功能所花的时间远远多于纸面上确定的产品规格所需的时间。将自己站在客户的角度考虑问题，是避免返工最好的方法，因为最终是客户来决定你花了12个月开发出来的东西，是不是合适。

*产品

1.产品规模

产品规模是对开发进度影响最大的因素，大项目耗费的时间多，小项目耗费的时间少，是最简单的原理，所以大幅度提高进度最直接的方式就是缩小产品规模，俗称砍需求。或者可以分阶段开发来临时缩小规模。

2.产品特性

对性能，内存，稳定性，可靠性要求很高的产品需要更长的时间周期。选择你的战略目标，如果进度排在首位，就不要同时设置太多其他因素去限制开发人员的手脚。

*技术

工具，控件，技术积累都是争取快速开发的关键。

开发速度的进化过程

基于承诺的快速开发

基于承诺的开发策略也是一只快速开发的方式，这种策略要求员工对项目总体进行承诺，并授予其自主权，然后看着他们每周工作60或80小时，直到最后他们完了(累垮)或者项目完了(完成)。

基于承诺的开发策略一般是通过磨练，汗水，决心来实现的。

对于公司来说，利用开发人员的承诺与责任心，用一个月的薪水压榨两个月的工作也是是很划算的。

然后其带来的弊端与风险太大：

1.无法保证项目是否完成

即使基于承诺，但也不是每个承诺都能兑现。导致完成不了的因素很多，且不可控，与承诺没有太大关系。

2.将导致长期激励问题

一旦员工全身心投入到承诺中，并最后面临失败，他们将变得沮丧，怨恨，士气低落。

3.不可重复

4.人力资源的浪费

参与项目的人员忘记了家庭，朋友，爱好，甚至他们的健康，去促使项目成功，这种献身不是必须的，通过周密，理性，知识化的管理和计划，可以用少许努力获得同样的结果。

第三章典型错误

错误对于开发进度的影响

任何最佳实践的使用，都只是项目成功的必要条件，而非充分条件。即使你做了一些正确的事情，只要做错一件事，就会使你前功尽弃，而滑向失败的深渊。

常见的典型错误

*人员

1挫伤积极性

2人员素质低

在很多案例中，人员的选择都着眼于尽快招到人，而不是在项目中能工作得最好的人。这种方法能让项目尽早的启动，但不一定能尽早的完成。

3对有问题的员工失控

4英雄主义

5项目后期加入人员

6办公室拥挤嘈杂

7开发人员与客户之间的摩擦

这种冲突往往来自缺乏有效沟通，缺乏沟通还会导致对需求的准确理解，对界面的设计不合理等。双方的摩擦和冲突会转移客户和开发人员双方的注意力。

8不现实的预期

有人认为树立现实的预期，是项目成功的前5个因素之一。(Standish Group)。这个错误容易发生在一线技术人员，或者一线管理人员身上。

9缺乏有效的项目支撑

快速开发有很多方面需要得到高层的支持，包括实际的计划，变更控制等。

10缺乏各种角色的齐心协力

11缺乏客户介入

没有用户的早期介入，充满了需求误解的风险。

12政治高于物质

13对现实充满想象

*过程

14过于乐观的计划

过于乐观的计划给团队施加额外的压力，为了满足乐观的计划，可能砍掉很多必要的工作，对开发人员的自信和生产率造成了长期和巨大的伤害。

15缺乏足够的风险管理

有时我们没有足够的风险意识，有时我们意识到了风险却没有制定对应的措施。

16承包人导致失败/客户方导致失败

17缺乏计划

18在压力下放弃计划

项目组制定了计划，但当项目遇到困难时就放弃计划。那么失败的原因不是在于放弃计划本身，而是不能制定替代计划，就一头栽进编码和麻烦中去。

19在模糊的项目前期浪费时间

模糊的前期一般是指项目开始之前的时间，通常是花在审批和预算上。通常在这个时期为后面节约出更多时间，是廉价的。

20前期活动不合要求

由于需求分析，概要设计，详细设计等工作，并不生成代码，对于急于砍掉不必要的活动的项目，他们很容易成为目标。

21设计低劣

22缺少质量保证措施

23缺少管理控制

项目过程中很少设置控制点，缺乏必要的计划拖延警告。想要保证项目可控，你必须随时准确说出项目所处的位置。

24太早或过于频繁的集成

这点可能无法完全认同，现在也有持续集成的观点。

25相遇估算时遗漏必要的任务

26追赶计划

27鲁莽编码

*产品

28需求的镀金

29功能蔓延

30开发人员的镀金

31又推又拉的交易

经理在批准进度顺眼的同时，又加入了新的功能。

32研究导向的开发

*技术

33银弹综合症

过于相信没有采用过的技术，当项目锁定这个技术，并期望以此来解决进度问题时，不可避免的遭遇挫折。

34过高的估计了新技术新方法带来的节省量

35项目中间切换工具

36缺乏有效的源代码控制手段

37没有总结出自己最差的实践

项目不停的做，却没有总结出自己的错误列表，那么你自己无法从以往的项目中学习，也无法与其他人其他团队交流。

第四章软件开发的基本原则

管理原则

简单的来说，管理原则由以下几个部分组成：判定产品规模，根据规模分配资源，制定资源计划，监控引导项目。

*项目估算和进度安排

1判定项目规模大小

2估算完成项目的代价

3基于估算制定计划

*计划编制

糟糕的计划比其他麻烦更经常地激起问题。与计划编制相关的问题举例如下：

*计划编制失败

*没签订好合同

*无效的变更控制

*不切实际的最终期限

*跟踪

制定了一个项目计划，就要监控他是否在按计划进行，包括对进度，费用，质量等目标的检查。典型的管理控制包括：任务列表，进度报告会，里程碑检查，预算报告及走查管理。典型的技术控制包括：技术方案确认(UML，流程图确认)，质量检查。

跟踪是一个基本的项目管理行为。如果你不跟踪项目，则无法管理项目。

度量

保持长期可持续运作的关键，是能够搜集基准数据来分析质量和生产率。

技术原则

*需求管理

需求管理就是收集需求，把需求记录成文档，电子邮件，编写界面串联脚本(原型)等形式，然后根据这些来跟踪设计和编码，并随时管理修改需求以适应随后项目的过程。

程序员对需求管理的抱怨太常见。

以下是一些需求管理的基础：

*需求分析方法。包括结构分析，数据结构分析和面向对象分析。

*系统建模实践。如类图，数据流图，实体关系图，数据字典和状态图等。

*沟通实践。

*需求管理和生命期模型的关系。如渐进交付，阶段交付，螺旋型，瀑布型，编码修正型等。

需求管理在两个方面对加快开发速度发挥着重要作用。第一，正规的需求管理中，需求收集往往比较从容。第二，正确把需求摆在首位，往往比被动这样花费少得多的时间。

*设计

*构建

*软件配置管理

质量保证原则

*易错模块

20%的模块中，集中了80%的错误。

*测试

单元测试10%到50%的漏洞。

系统测试20%到60%的漏洞。

剩下的40%要么通过技巧发现，要么最终被用户发现。

*技术回顾

1走查

走查不止包括代码部分，更加侧重于需求，设计。对于我们的项目，建议每个负责人审核每个模块的数据流图或流程图。

2代码阅读

3检查

检查的内容跟走查差不多，但是比走查正式得多。你可以使用它对需求分析，界面原型，设计，编码等差错。

检查过程如下：

检查会议之前，

“仲裁人”发布产品要被检查的消息。

“审阅人”在会议之前列出检查列表。

检查会议开始，

“作者”解释要被检查的内容。

“审阅人”鉴别错误。

“记录员”记录错误。

检查会议结束，

“仲裁人”写一份检查报告，说明每个漏洞和如果处理。

4技术回顾

按照指导来做

第五章风险管理

风险管理要素

风险管理工作就是在风险成为影响软件项目成功的威胁前，识别，着手处理并消除风险的源头。你可以在几个层次中管理风险：

1危机管理：救火模式，在风险已经造成麻烦后才着手处理。

2失败处理，察觉到了风险并迅速反应，但只是在风险发生之后。

3风险缓解，事先制定好风险发生后的措施，但不做任何预防措施。

4着力预防，将风险识别和风险防范作为项目的一部分加以规划和执行。

5消灭根源，识别和消除可能产生的风险根源。

本章的目的是描述如果定位4和5层面上的软件进度风险。

总体来讲，风险管理由风险评估和风险控制组成。

*风险评估

风险评估由风险识别，风险分析，风险优先级组成。

*风险识别，就是提出潜在的可能破坏项目的风险列表。

*风险分析，评估每一个风险的可能性和影响，判定风险的级别。

*风险优先级，按风险影响大小排出一个风险优先级列表，这个风险列表将作为风险控制的基础。

*风险控制

风险控制由风险管理计划，风险化解和风险监控构成。

*风险管理计划：制定一个应对每个重要风险的应对方案，同时确保每一个单独的风险管理计划之间，以及与整体风险管理计划之间一致。

*风险化解：每个重要风险所对应的计划的执行。

*风险监控：就是对解决风险的过程进行监控，监控还包括识别新的风险并反馈到正在进行的风险管理中。

风险识别

*最常见的进度计划风险：

1功能蔓延

2需求镀金，开发人员镀金

3质量不定

4计划过于乐观

5设计欠佳

6银弹综合症

7研发导向的开发

8人员薄弱

9签约商失败

10研发人员与客户之间的摩擦

*进度计划风险的完整列表：

1计划编制风险

1计划，资源和产品定义全凭客户或上级口头指令，并且不完全一致。对于我们的项目，这点可以理解为产品经理太软弱，在开发过程中听凭客户定义产品范围。

2计划是优化过的，是“理想状态”。这点对于开发人员和经验比较少的项目经理，几乎是通病。他们对于计划过于乐观。

3计划忽略了必要的步骤。计划时间容易被想象成实现任务，而非设计+检查+实现+测试。

4计划基于特定的成员。而实际上那些成员无法进入项目。

5在限定时间内无法建成一定规模的产品。俗称无法完成的任务。

6产品规模比预估要大。或者是过程中，产品规模变得比预估要大。

7工作量大于估算。

8进度已经拖延。在计划编制时，如果当前进度已经落后，非常容易过于乐观的预估今后的速度。

9进度的延误造成生产率下降。

10目标日期提前，但是没有相应地调整产品范围或可用资源。

11一个任务的延迟，导致相关任务的连锁反应。

12涉足不熟悉的产品领域，花费在设计和实现的时间比预估要多。

2组织和管理

1项目缺乏一个有凝聚力的领导人。对于我们公司来说，这个风险天然存在。因为产品经理，项目负责人，商务，都无法单独全权对项目负责。期望以后项目部在开发阶段能全权对项目负责。

2由于前期乏力，项目被长时间搁置。

3解雇和削减开支，导致小组能力下降。

4仅由管理层或市场人员进行技术决策，导致计划进度延长。

5低效的项目组织结构，导致生产率降低。前期公司测试自成一个部门，这点我认为非常不利于项目快速开发。现在产品部门也正在造成同样的问题。

6管理层的决策时间/周期比预估要长。

7预算削减打乱项目计划。

8管理层做出了打击项目积极性的决定。

9非技术的第三方工作比预估要长。

10计划性太差，无法适应期望的开发速度。这点对于现在一部非常普遍，项目计划太差，监控太差，里程碑几乎没有，相应的进度预警几乎没有。

11项目计划由于进度压力而放弃。非常普遍。

12管理层强调英雄主义。

3开发环境

1设施没有及时到位。

2设施拥挤，杂乱和破损。杂乱的办公环境，说这个不知道算不算矫情。

3开发工具没有及时到位。

4开发工具不如期望的那样有效。如：需要时间熟悉新工具，新环境等。

5开发工具不是基于技术需求，不能提供计划所要求的性能。

6新工具的学习时间比预期时间要长。

4最终用户

1用户坚持新需求。

2用户对交付的产品不满意，要求重新设计和重做。这点很大程度上，是由需求细节沟通不充分导致，其次就是用户介入时间太晚，最后就是产品质量太差。

3用户不买进项目相关产品，导致项目功能残缺。比如短信接口，服务器等。

4最终用户的意见未被采纳，造成产品不得不重做。

5客户

1客户坚持新需求。

2客户对规划，原型和规格的审核/决策周期比预估要长。

3客户没有或者不能参与规划，原型，和规格审核，导致需求不稳定或耗时的变更。比这更可怕的是客户对原型审核过于草率。

4客户答复的时间比预期要长。比如回答或者澄清需求相关问题。

5客户坚持要做技术决策而导致进度延迟。

6客户对开发进度管理过细，导致进展很慢。

7客户提供的组件无法与开发的产品匹配，导致额外的设计和集成。

8客户提供的组件质量较差，导致额外的设计工作，以及额外的客户关系维护工作。雅漾就是这个情况，碰到这种情况，一定要通过邮件确认客户问题，以免最后被客户反咬。

9客户不接受交付的软件，尽快已经满足了所有的规格。这种情况，一般客户会用我方一些小错误作为不接受交付的理由。

10客户期望的开发速度是开发人员无法达到的。

6承包商/客户方

1承包商/客户方没有按承诺交付组件。

2承包商/客户方提交的组件质量太差。

3承包商/客户方没有买进项目开发必要的工具。

7需求

1需求已经成为项目基准，但变化还在继续。

2需求定义欠佳，而进一步定义却会扩张项目范围。出现这种情况，一般就是产品经理的原型不细致。所以在审核原型的时候，一定要细致。

3添加额外的需求。做好需求管理，不管新需求是小是大。

4产品定义含混的部分比预期的要大。

8产品

1错误发生率比较高的模块，需要比预期更多的时间测试，设计和实现。

2矫正质量低下的产品，需要比预期更多的时间测试，修复。

3使用不熟悉的新技术。

4由于产品功能错误，导致需要重新设计和实现。

5开发额外不需要的功能(需求镀金)。

9外部环境

1产品依赖政府规章。

2产品依赖正在草拟的标准。

10人员

1招聘人员所花的时间比预期要长。

2作为先决条件的任务无法完成。

3开发人员与管理层关系欠佳。

4成员没有全身心的投入产品。

5缺乏激励机制，士气低下。

6缺乏必要的规范，增加了工作失误与重复工作。

7项目结束前，人员流失。

8项目后期加入新员工。

9项目组成员无法有效的一起工作。

10项目组成员之间冲突。

11有问题的成员，没有尽早的调理开发组，导致其他成员不满。

12最佳人员没有进入项目组。

13人员不足。

14任务分配不合理。

15人员工作的进展比预期要慢。

16管理人员怠工，导致计划和进度失控。参考何飞创业期，何飞和我的怠工状态，是项目计划和进度失控。

17开发人员怠工，不仔细，导致工作遗漏，质量低下。

11设计和实现

1设计过于简单，导致需要重新设计和实现。

2设计过于复杂，导致一些不必要的工作。

3设计质量底下，导致重复设计和实现。

4使用不熟悉的方法。

5产品采用太底层的语言或技术。

6一些必要的功能，无法使用现有的代码和实现。开发人员必须要用新的库或自行开发。尽快完善代码库。

7代码和库质量低下。

8分别开发的模块，无法有效集成。参考后台和移动端集成，参考移动端之间的一致性。

12过程

1大量纸面工作，拖慢了进度。

2过程跟踪不准确。

3前期工作不真实。

4质量跟踪不准确。

5太不正规。缺乏对软件开发策略和标准的遵循。我们应该在这个地方。

6过于正规。教条的遵循软件开发策略和标准。

7向管理层撰写进程报告，占用开发人员大量时间。

8风险管理粗心，导致没有发现重大项目风险。

9项目风险管理花费的时间，比预期时间长。

风险分析

在确定了项目存在哪些风险之后，下一步就是分析每个风险可能造成的影响。以下是一些风险分析方法。

*风险影响量

风险影响量是一种非常有用的风险分析方法，它常被写成RE，Risk Exposure。风险的一个定义就是“不希望的损失”。风险暴露量就等于“不希望的损失”的概率乘以造成损失之后的损失程度。举例来说就是：你认为实际进度比计划要延长4周的概率是25%，那么风险影响量就是25% x 4周= 1周。

你可以建立一个由风险，发生概率，损失大小，影响量组成的风险评估表。

风险影响量的缺点是：主观意见对风险结果影响比较大，因为你必须给出概率和损失大小的数值，所以不能指望它有多精确。

下面将描述怎样预估损失大小和风险概率。

*预估损失大小

损失大小通常比风险概率更容易预估。例如：如果你的项目可能在2月1号通过，最迟应该是在3月1号，那么你的风险损失就是一个月。

如果有时损失大小不容易直接估算出来，还可以将损失拆分成更小的部分，分别评估。

*预估风险概率

风险概率的预估有很强的主观性。以下是一些提供主观预估精确度的方法：

1由最熟悉项目的人评估。应该是目前最适合我们的。

2 Delphi法或少数服从多数的方法。每个人独立的对风险概率预估。然后一轮轮讨论，直到达成共识。

3打赌法。比如：设备如果及时到位，你赢得125块，如果没有到位，你输我100块，逐步调整赌注，直到双方都满意。那么设备无法及时到位的风险就是100/125 = 44%。

4使用形容词标准。如非常可能，很可能，可能，或许，不太可能，不可能，根本不可能等，让成员选择风险对应的形容词，然后把形容词转化为量化的评估。

*整个项目的延期和缓冲

对风险影响量的评估，最终需要反映到整个项目预期上来。所以在进度计划制定过程中，应该加上风险影响量的时间。

之前何飞的做法，是在进度计划上，直接加10%到30%的时间，以应对风险，这种做法比较粗糙，建议使用风险影响量。

风险优先级

一旦建立了风险列表，下一步就是确定每个风险的优先级。

首先，按照风险影响量从大到小排序，就形成了一个粗略的优先级列表。如果能成功的处理影响量较大的主要风险，就有希望超出预期计划完成项目了。一般情况下，你最好花时间控制影响量大的主要风险。

然后，根据实际情况，将影响量没有在前面，但是概率或损失很大的风险提高优先级。

风险控制

确定了风险优先级列表，就可以准备对它进行控制了。本节描述风险控制的三个方面：风险管理计划，风险化解，和风险监控。

*风险管理计划

编制风险管理计划的重点是制定一个计划，以处理高优先级的风险。

风险管理计划可以理解为一段一段的风险管理描述，例如每个风险由谁引起，表现形式是什么，可能什么时候发生，在哪发生，为什么发生以及是怎样发生的，并描述风险监控，关闭已经化解的风险，确定紧急风险等。

*风险化解

1避免风险

不要做冒险活动。

2将风险从系统的一部分转移到另一部分

有时系统中一个部分的风险，在另一个部分则不是风险。比如说服客户自己设计业务模块，而不是自己设计。

3购买关于风险的信息

4消除产生风险的根源

5接受风险

6发布风险

让上级领导或客户提前知道风险以及可能后果，如果发生了，他们也就没有这么惊讶了。

7控制风险

定制风险无法化解时的处理方案。比如：分配额外的资源来测试令人担心的模块等。

8记住风险

以下是一些风险，已经对应的控制方法：

*风险监控

当我们定制了风险防范计划之后，虽然风险还是存在的，并且风险在项目过程中，会增大，或减小，所以需要对风险进行监控。

1前十个风险列表

最有效的风险监控工具之一就是每周前十个风险列表。列表包括：风险当前级别，以前级别，上表次数，风险名字，风险化解进展。每周对风险列表进行更新。下面是个示意表：

对于快速开发项目，项目经理和项目经理的上司每周都应该审核前十个风险列表。它最有意义的地方是促使你定期查看风险情况。

2中间检查

在每个小里程碑后进行一次风险检查是非常有益的。

3风险官员

为了防止项目经理和开发人员忽视计划中的风险，有些企业任命了全职的风险官员，专门警告项目风险。

第二部分快速开发

第六章快速开发中的核心问题

一个标准是否可以适应所有情况

你需要怎样的开发方法

*进度计划有严格限制的产品

对于确实需要全力以赴提高开发速度，而不注重成本，可预测性的产品来说，它与典型产品有着不同的时间价值曲线：

*表面上的快速开发

某些项目中，客户，用户，上级或者产品提出“快速开发”的需求，有时还希望低费用，低风险。他们其实也不知道这样的要求是否过分，或者是否真的过分。

在你得到消息要在限定的时间内“快速开发”时，应该充分挖掘你所面对的真实需求。各种表面上号称需要“快速开发”的项目，实际上是还有其他需求。

1防止失控状态

如果一个软件组织有失控，拖延工期，或者超出预算的历史，如果一个客户有被其签约商拖延工期，超出预算的历史，都会造成客户要求“快速开发”。但是在这种情况下，客户真正的需求是能在规定的进度和预算下完成。

在这种情况下，你真正需要的是较好的风险管理，预算管理和进度控制来保证项目顺利进行。

2可预测性

在很多情况下，客户需要将软件产品与市场，发布会，公司计划等其他项目协调在一起。这时你需要较好的风险管理。

3最低费用

对于软件开发项目，客户希望费用最低的情况并不罕见。在这种情况下，他们口里说着快速开发，其实是需要降低费用。

但是在实际上，最短的开发周期跟最低的费用并不是同义词。

4渴望加班

在一些情况下，客户或者上级利用他们对进度的关系，来掩饰他们希望开发者提供免费加班。

这种情况是很容易区分的，在这种情况下，客户强烈关系进度，但是无法提供与之对应的费用或资源。如果客户对项目进度的关心让你感到压力，那么它的重要性足以让客户增加对项目的支持。

*你真正需要的是全力以赴的开发

现实中的项目，客户希望你在低费用，短时间里，提供质量最好的产品。往往你只能三选二。在短时间里，提供低质量的产品往往是最错误的做法。因为如果你准时发布了低质量的产品，客户不认为你准时发布了产品，而是你发布了低质量的产品。对应到我们项目组，也就是一直存在的细节问题。认为项目很急，所以在细节问题的处理上太粗心。

按时完成的可能性

我们感觉开发速度缓慢，一部分原因是有些工作确实缓慢，另一部分原因是没有达到预期的速度，所以显得缓慢。对于第二种情况，我们的对策是维护两套进度，一套用来真实的控制项目，另外一套给上海和客户，用来降低客户预期。

软件项目包含太多可变因素，通常不能100%精确地设定开发进度。

上面的图表达了几个假定：

l完成一个项目，都有一个最快完成速度的极限值。

l完成一个项目，没有一个最慢完成速度的极限值。

l完成几率曲线的前一段和后一段形状不同。

很多项目最初瞄准了不可能开发的区域，最终落在了缓慢开发的区域。

建议安排好项目进度，使按时完成的可能性达到50%是比较合理的做法。

感知与现实

即使按时完成任务，要知道开发速度慢的感觉与事实上的速度慢一样能影响你的项目成果。即使我们一直不停的在做，也没有理由期望客户缄默的等待几个月，直到项目结束。应该意识到让客户定期知道项目的进度情况是我们工作的一部分。

不切实际的用户期望

如果项目进度制定在一个不可能的区域内，但在有效区域完成，人们还是认为这是一个失败的项目。尽管它是在给定资源条件下，以有效的进度完成。

有时候，客服开发速度慢的感觉，需要确保合理的用户期望，并提供稳定的项目进展报告。

克服慢速开发的感觉

两种方法克服慢速开发的问题：

l将事实上的慢速开发重新定位。

将实际进度缩短，将进度移动到有效开发区域。

l将感觉上的慢速开发重新定位。

拜托痴心妄想，延长计划进度时间，缩小计划于实际的差距。

时间都去哪里了

*典型的观点

许多项目开始于需求定义之前，如果这一阶段没有经过良好的定义和管理，可能会延续很长一段时间。

*软性问题

1返工

对具有缺陷的需求，设计，代码进行返工，普遍需要花费整体开发费用的40%。在早期对缺陷进行修正是最廉价的。因而避免返工是一个缩短项目执行时间的有利机会。

2功能蔓延

典型的项目经验告诉我们，25%的需求会发生变化，有些时候更多。对本质的需求变化不加以限制是开发效率的首要错误。所以避免功能蔓延，需求镀金对项目进度是很有好处的。

3需求定义

一般情况下，需求定义要花费项目全部时间的10%到30%。而且由于需求收集是一种无所限制的工作，也就可能会花费大量不必要的时间。在需求定义阶段适当的督促，对项目进度很有帮助。在需求定义期间，包括联合应用开发，渐进原型，阶段交付和不同的风险管理方法，将在其他章节中介绍。

4模糊的项目前期

开发速度的权衡

最初的资源股价和进度往往不能被接受，这不是因为项目经理或程序设计者的工作有差错，而是由于用户通常希望得到的比他们提供的资源要多。如果工作不能与可行的进度和资源想适应，那么他们要么就得到的更少，要么就是导致时间和资源增加。

*进度，费用和产品的平衡

*质量的权衡

对软件产品的质量要求分为两种：

第一种是要求软件有较低的缺陷率。由于低缺陷率与短的开发周期分身就是匹配的，在这种情况下没有更好的办法为了进度来权衡质量。

第二种是要求产品包括高质量产品应有的特性，可用性，健壮性，有效性等。对之中质量要求的关注会延长开发时间，因此也就使我们需要相对于进度去平衡这种质量要求。

*个人效率的权衡

在尝试达到个人最大生产力和最求进度最快之间存在冲突。达到每个人最大生产力的最简单办法就是保持小规模团队，而最求进度最快最简单的方法就是扩大团队人数。因此意味着快速开发并不总是生产力最高的。

典型的进度改进模式

如上图，典型开发过程中，计划虽然好看，但是很少有机会完成。从典型开发到有效开发要完成的最大部分工作是从痴心妄想转变到有意义的项目计划。如下图：

如上图，有效开发的项目中，进度的分布范围是较狭窄的。有两个原因：一是人们学会了怎样实际地设置目标，二是人们学会了如何较快的开发软件。

向快速开发前进

后续章节中将描述实现快速开发的方法：

l生命期计划

l估算

l进度计划

l面向客户开发

l激励

l团队合作

l团队结构

l生产力工具

l项目矫正

以上的部分内容我们在前面曾经讲过，之所以我们在下面还要讨论，是因为以上内容是获得最快开发速度的关键方法。

第七章生命期计划

任何软件开发都要经历一个“生命期”，包括从1.0版本在某个人脑中闪现到6.74b版本在最后一个用户的机器上最后一次使用之间的所有活动。

生命期模型的主要功能是为开发活动确定一种次序，一种标准。

人们最熟悉的模型是瀑布生命期模型，但是它的弱点也同样著名。作为一个项目骨架，你选择的生命期模型对项目的成功和任何其他计划一样重要，并帮助你一步一步接近目标。如果你选择了合适的生命期模型，就可以提高开发速度，提高质量，加强项目跟踪控制，减少成本，降低风险或改善用户关系。选择了错误的生命期模型，也必定会导致工作拖沓，劳动重复，无谓的浪费和挫折。

纯瀑布模型

1说明

尽管存在许多问题，纯瀑布模型是其他模型的基础，是一个比较有效的生命期模型。

在瀑布模型中，项目始终按照一定顺序的步骤从初始概念进展到系统测试。项目确保在每个阶段结束时进行检查，判定是否可以开始下一个阶段的工作。

文档驱动。意味着主要工作成果是通过文档传递。在瀑布模型中，各阶段不连续也不交叠。

降低计划管理费用。因为你可以预先完成所有计划，文档产生并提供了贯穿生命期过程的充分说明。

2适合情境

当你有一个稳定的产品定义和很容易被理解的技术解决方案时，瀑布模型特别合适。在这种情况下，瀑布模型可以帮助你及早发现问题，提供稳定的需求。

对于那些容易理解但很复杂的项目，采用瀑布模型很合适。

3缺点

缺乏灵活性。必须在项目开始阶段就说明全部需求。

编码修正模型

1说明

编码修正模型是一种不太有用的模型，但是比较常见。如果你没有明确的选择其他生命期模型，也许你就不自觉的在用编码修正模型。编码修改也被称为鲁莽编码。

当你使用编码修正模型的时候，你是从一个大致想法开始，可能有一个正式规范，可能没有，然后你结合设计，编码，调式和测试方法，完成开发。如下图：

2适合情境/优点

编码修正模型有两个优点：第一，不需要什么成本。你不需要在编码工作之外付出成本，比如项目规划，文档编制，质量保证等。第二，只需要极少的专业知识。任何有编码技能的人都能使用它。

对于一些非常小的，用完就丢的软件，原型，验证程序等，这种模型还是很合适的。

3缺点

对于其他项目来说，这种模型是非常危险的。因为它不提供项目进展，质量评估，风险识别等。

螺旋模型！

1说明

螺旋模型是一种以风险为导向的生命期模型。它把项目分解成一个个小项目，每个小项目都标识一个或多个主要风险，直到所有主要风险都被确认。“风险”的概念在这里有所外延，它可以是需求或者是框架没有被理解清楚，潜在的性能问题，根本的技术问题，等等。

它的基本思路是，从一个小范围的关键中心开始寻找风险，制定风险计划，并交付给下一步骤。如此迭代，每次迭代都把项目扩展到更大的规模。每次迭代都包括一下六个步骤：

（1）确定目标，方案和约束条件。

（2）识别并解决风向。

（3）评价备选方案。

（4）开发本次迭代可供交付的内容，并检查它们的正确性。

（5）规划下一个迭代过程。

（6）交付给下一步骤，开始新的迭代过程。

2适合情境/优点

可以采用不同的方法把螺旋模型和其他生命期模型结合在一起使用。比如使用螺旋模型将项目分解，将风险降低到可以接受的水平后，再采用瀑布模型或其他模型来执行项目。

通常都是在螺旋模型中，把其他生命期模型引入作为迭代过程。

螺旋模型最重要的优势就是，随着成本的增加，风险程度随之降低。时间和资金花得越多，风险越小。

螺旋模型至少提供和瀑布模型一样多的管理控制。在每个迭代结束前都设置了检查点。

螺旋模型能使你对任何无法逾越的风险都提前预知。

3缺点

螺旋模型唯一的缺陷就是比较复杂。需要责任心，专注和管理方面的知识。通过目标和里程碑，来决定项目是否已经准备好进行下一轮迭代。

如果项目的目标明确，风险适度，你就没有必要采用螺旋模型。

生鱼片模型

1说明

纯瀑布模型最大的弱点不是这些活动本身，而是模型把活动看作是不连续的，有顺序的阶段来处理。因此，可以针对这个弱点，来调正模型，进化成各种修改后的瀑布模型，生鱼片模型就是其中一个。

传统瀑布模型允许在阶段之间，存在最低限度的重叠。而生鱼片模型建议的是一种大幅度的重叠。

2适合情境/优点

对比纯瀑布模型，生鱼片可以充分减少文档需求。

如果你在一个小的，定义得很好的项目，那么这种模型可以用到最有效的模型。

3缺点

因为阶段是重叠的，所以将会导致里程碑非常不明确，很难精确进行过程跟踪。

具有子项目的瀑布模型

1.说明

纯瀑布模型的另一个问题是，必须在上阶段全部完成后，才进入下一个阶段。但在实际工作中，系统某些部分可能比较简单，有些地方比较复杂，而由于复杂的问题，导致简单的部分也无法开始。因此，我们可以把系统分成几个相对独立的子项目，每个子项目都按自己的节奏进行，这就形成了一个具有子项目的瀑布模型。

2.适合情境/优点

这种模型比较适合于系统包含多个相对独立的项目。

3.缺点

具有子项目的瀑布模型，主要的风险在于子项目之间的相关性无法预料。为了解决这个风险，你可以等到架构设计完成，排查相关性之后，再拆分子项目。

降低风险的瀑布模型

1.说明

纯瀑布模型的另一个问题是，必须在开始架构设计之前，就完整的定义需求。这在实际工作中非常困难。所以我们可以在瀑布模型中引入螺旋模型，以便确定和降低风险。

2.适合情境/优点

降低风险的瀑布模型比较适合开发一个高风险内核的项目。不止在需求阶段，在项目任何阶段都能引入螺旋模型以降低风险。

3.缺点

降低风险的瀑布模型跟螺旋模型一样，就是比较复杂。

渐进原型！

1.说明

渐进原型通常是从最显著的方面开始，向客户展示完成的部分，然后根据反馈信息继续开发项目，一直重复这一过程，直到用户认为原型已经足够好，然后结束工作，交付作为最终产品的原型。

2.适合情境/优点

在需求变化很快的时候，用户很难提出明确需求的时候，开发人员对于最佳架构没有把握的时候，渐进原型都特别有用。

3.缺点

渐进原型主要的缺点是，你不可能在开始的时候知道产品总时间需要多久。

另一个缺点就是，渐进原型很容易退化成编码修正模型。所以要注意，真正的渐进原型，包含真正的需求分析，设计和可维护的代码。渐进原型每次重复时的实际进展是比较小的。

阶段交付！

1.说明

阶段交付可以持续地在确定的阶段向用户展示软件。和渐进原型不同，在前期你就明确的知道整体分为多少阶段，每个阶段完成哪些内容。

2.适合情境/优点

阶段交付模型，在整个周期内，持续不断的产出阶段性成果，把有用的功能交付到客户手中。

阶段交付能够提供有形的阶段进度产出。这样的进度产出能够使项目进度压力更加可控。

3.缺点

阶段交付的主要缺点是，如果管理层面和技术层面缺乏仔细的规划，工作就无法进行。

使用阶段交付模型需要注意的问题是：

在管理层面上，你需要确信所规划的阶段对用户非常有意义，而且在工作安排上保证员工能及时在阶段最后期限完成。

在技术层面上，你需要确信考虑了不同产品组成部分的技术依赖性。通常会犯的一个错误就是把一个在第二阶段就需要用到的组件，放在了第四个阶段才开发。

面向进度的设计

1.说明

面向进度的设计模型，类似于阶段交付，相同点是都在连续的阶段规划产品。差异是面向进度设计模型，在开始的时候不必知道究竟能达到什么样的预定目标。你可能规划了五个阶段，由于一些限制，仅仅完成了前三个阶段。

2.适合情境/优点

面向进度的设计模型，能确保你在一个确定的日期发布产品。

该模型的关键在于按优先级区分系统特性，规划开发阶段。比如windows系统中包括了一些小程序，比如计算器，写字板，画笔等，可以为这些小程序采用面向进度的设计模型，来保证他们不影响windows的开发和发布。

是否使用本模型，取决于你对自己的工作规划是否有信心。如果你非常有信息，那么面向进度的设计是个低效的模型，如果你不是那么自信，这个模型就很有用了。

3.缺点

面向进度的设计模型，最大的缺点是如果你不明白所有阶段，就会浪费时间去指定，架构和设计你不需要的特性。

渐进交付！

1.说明

渐进交付是一种跨越了渐进原型和阶段交付两种模型的生命期。渐进交付跟渐进原型比较类似，区别是取决于你计划满足用户需求的程度。如果你计划满足用户的绝大部分需求，渐进交付就跟渐进原型差不多。如果你计划满足少量的需求，渐进交付就跟阶段交付差不多。

渐进交付于渐进原型最大的差别不在方法上，而是工作重点上。渐进原型中，你强调系统看得见的样子，然后回来补系统漏洞；在渐进交付中，你在乎的是系统的核心。

增量开发方法

增量开发方法包括螺旋型模型，渐进原型，阶段交付，渐进交付。

面向开发工具的设计

商品软件

当你兴冲冲的准备做一个新系统时，一个常常被忽略的选择就是可以直接购买商品软件。

为项目选址最快的生命期模型！