快速软件开发 学习笔记 之五

第7章 Estimation（软件估算）

7.1 软件估算的故事

做软件估算是很困难的，但许多人（包括各级软件经理、客户和开发人员）都不明白软件估算为什么会如此困难。软件估算难做的原因在于：软件开发是一个[/b]gradual refinement[/b]（逐渐改进）的过程。[/b]由于开始时对待开发软件的认识比较模糊，所有对开发时间和工作量的估算也比较模糊。只有随着对软件本身的认识逐渐清晰，估算才可能逐渐清晰。这其实意味着软件估算是一个逐渐改进的过程，这个过程可以用下图所示的估算收敛图来表示。





估算收敛图告诉我们：对整个项目的估算应该是开始时比较笼统，随着项目的进行才逐渐变得准确起来。

鉴于软件估算是一个动态过程，将在整个项目过程中得到改进，因此应该在软件项目的每个major milestone[/b]到达时修正估算，以获得更准确的估算，并向客户汇报最新的估算结果。[/b]

7.2 软件估算的过程与技巧

软件估算的过程如下图所示。





所谓product size（产品规模），是指某个软件项目在非常普通的意义上的total scope（总范围）。它包含feature set的深度和广度，以及项目的难度与复杂度。项目早期考察product size的最准确的方法是function point（功能点）；而当项目进展到设计阶段时，product size一般通过模块数和class的数量来度量；而当项目进展到实现与测试阶段时，product size一般由代码行数来度量。

估算effort（工作量）就是基于对产品规模的估算结果去估算项目需要多少人月可以完成。常用的工作量估算方法包括：

l  利用估算软件从size estimate直接得到effort estimate。

l  利用表7-1将以代码行衡量的size estimate转换成effort estimate。

l  使用你所在组织的历史数据来确定先前的项目完成相同product size所花费的工作量。除非你有令人信服的理由表明新项目和以前挖规模的项目是有区别的，否则我们假定它们的工作量是成正比的。

软件项目估算的第三步是得到schedule estimate。常用的进度估算方法包括：

l  利用组织的历史数据。

l  利用下面的公式：进度（单位：月）= 3.0 x 人月1/3。例如，如果你已估算出一个项目要65人月，那么这个公式打出最佳进度是12个月（3.0 x 651/3）。它还暗示最佳团队大小是5或6个人员（65/12）。

l  利用表7-1进行估算。

 

 

表 7-1 常规进度估算表

产品规模 （代码行）	系统软件	业务软件	盒装软件
进度（月）	工作量（人月）	进度（月）	工作量（人月）	进度（月）	工作量（人月）
10 000	10	48	6	9	7	15
15 000	12	76	7	15	8	24
20 000	14	110	8	21	9	34
25 000	15	140	9	27	10	44
30 000	16	185	9	37	11	59
35 000	17	220	10	44	12	71
40 000	18	270	10	54	13	88
45 000	19	310	11	61	13	100
50 000	20	360	11	71	14	115
60 000	21	440	12	88	15	145
70 000	23	540	13	105	16	175
80 000	24	630	14	125	17	210
90 000	25	730	15	140	17	240
100 000	26	820	15	160	18	270
120 000	28	1 000	16	200	20	335
140 000	30	1 200	17	240	21	400
160 000	32	1 400	18	280	22	470
180 000	34	1 600	19	330	23	540
200 000	35	1 900	20	370	24	610
250 000	38	2 400	22	480	26	800
300 000	41	3 000	24	600	29	1 000
400 000	47	4 200	27	840	32	1 400
500 000	51	5 500	29	1 100	35	1 800

 

以下是进行项目估算时要注意的原则：

1.       进行估算之前必须先明确功能特性需求。只有对系统需求有了充分理解之后，才能对其进行费用和进度的估算。

2.       留出估算的时间，并做好规划。草率匆忙做出的估算不会是准确的估算。

3.       避免无准备的估算。只在正式的估算后才提供估算结果。没有做正式的估算之前，总是回答：“我需要做完估算之后才能给出结果。”

4.       使用以前项目的度量数据进行估算，不要凭空想和猜测做估算，不要犯wishful thinking的典型错误。

5.       同开发人员一道进行估算。有开发人员参与而得到的估算结果会更加准确。

6.       条件（人员、资源或产品需求）发生变化后，应重新估算，以适应最新的情况。

7.       不要在估算中遗漏常见任务。下面是一些常被遗漏的任务：

l  向客户或用户演示程序。

l  出席变更控制会议。

l  分出时间为现有系统提供维护或技术支持。

l  修复缺陷。

l  与缺陷跟踪相关的行政事务，与QA部门的协调。

l  对用户文档的支持，技术文档的复审。

l  软件集成。

l  各种假期，公司聚会或部门聚会。

l  培训。

7.3 Estimate Refinement（估算修正）

软件项目估算本身就是一个动态发展的过程，因此在项目进行过程中，应该不断地修正估算结果，以反映出团队成员对项目当前状况的最新判断。软件经理应该做到以下两点：

l  提前向客户解释软件估算的过程（估算收敛图），并承诺在定期的里程碑提供不断改进的估算结果。

l  估算结果应该以范围值的形式给出，而不应该以单点估算的形式给出。

例如，下表就是一个很好的示例。团队领导提供一定范围内的估算，随着项目进行，范围不断收敛。

项目节点	估算结果（单位：人月）
Initial product concept	25 – 400
Approved product concept	50 – 200
Requirements specification	90 – 200
Product design specification	120 – 180
Detailed design specification	145 – 180
Final	170

 

假定有一个6个月的进度计划，你计划4周内达到第一个里程碑，而实际花了5周。当你错过进度日期时，该怎样对进度计划进行recalibration（再校准）呢？有三个选项：

1.       假设你可以在接下来的阶段中挽回这一周的损失。

2.       把整个进度计划顺延一周。

3.       把整个进度计划乘以拖延的幅度，在这个例子中是25%。

在绝大多数情况下，错过里程碑时，最应该做的事情是选项3。错过里程碑，实际上说明你的估算与实际进度之间存在差异，所以必须把这种差异体现到对估算结果的修正中去，这就是估算结果的再校准。选项1和选项2都没有对进度计划进行修正，这会导致进度计划与实际进度之间的脱节越来越严重，最终使进度计划落空。

第8章 安排进度计划

8.1 Overly Optimistic Scheduling（过于乐观的进度计划）

在软件制定过于乐观的进度计划早已屡见不鲜。长期工作在极度的进度压力下成为软件行业的普遍现象。产生过于乐观的进度计划有深层次、多方面的原因，下面列举若干：

l  为了赶在某些特定时间前展示或出售产品，如计算机展会、新税法出台前、圣诞节期间等。

l  管理人员和客户拒绝接受仅给出范围的估算，而是按照他们所认为的“最佳情况”单点估算来制定进度计划。

l  项目管理人员和开发人员为了享受挑战的乐趣或在压力下工作的刺激，而故意缩短进度计划。

l  管理部门或市场部门为赢得投标而故意缩短进度计划。

l  开发人员为获取经费以开发自己感兴趣的项目，而违心地缩短计划。

l  项目管理人员认为较紧的进度计划能够促进开发人员努力工作。

l  高层管理部门、市场部门或某些重要客户希望在特定时间内完成，而项目人员无法说服他们。

l  项目初期制定的进度计划是合理的，但在开发过程中，新的feature不断加入使得原来合理的计划相对于新的需求来说，变成了过分乐观的进度计划。

l  进度估算过程本身不够充分。

过于乐观的进度计划给一个软件项目带来巨大的危害，下图对比展示了具有准确进度安排的项目和具有过于乐观的进度计划的项目的差异。







因此，我们应该反对过分乐观的进度计划，因为它减少了计划的有效性，影响了开发人员的个人生活，损害了客户关系，导致项目频繁换人，产品质量低下，并由于妨碍个人技术进步而使整个行业元气大伤，并使人产生开发人员言而无信的印象。过于乐观的进度计划的最大危害在于：这样的计划不起任何作用，不但没有缩短实际进度，反而使其变长了。

8.2 战胜进度压力

过于乐观的进度计划在多数情况下是由公司高层、客户、市场人员按照主观意愿强加给开发团队的。即使开发团队通过认真细致的项目估算获得了合理的进度计划，这份进度计划也未必会被管理层或客户所接受。这个时候，开发团队与客户就需要进行沟通和谈判，以达成共识。在这个谈判的过程中，可以使用原则谈判法。

最佳实践：Principled Negotiation[/b]（原则谈判法）[/b] 1.       谈判之前，应确认自己拥有正确的心态：谈判不是为了击毁对手，而是应该努力促成达到共识，从而取得双赢。因此不能把谈判当成你死我活的角斗，而应从解决问题的角度进行协商。 2.       提出对双方都有利的各种备选方案。作为技术人员，不要简单地说“这做不到”，而应该尝试仔细审视项目的进度、资源和产品这三个方面的因素，多提供一些备选方案来供管理人员和客户选择。下面是一些常见的变通之处。 与产品相关的变通之处[/b] l  把某些需要的功能移到下一个版本实现。很少有人提出需求以后就马上要所有需求就实现。 l  分阶段交付产品，最重要的功能最先交付。 l  完全砍去一些feature。费时但可以灵活增减的feature包括：与其它系统的集成程度、与原有系统的兼容程度、以及性能。 l  与某些feature不必精雕细琢，只需实现到某种程度即可。 l  放宽各feature的详细功能需求。可以通过使用一些现成的商业组件来尽可能贴近功能需求。 与项目资源相关的变通之处[/b] l  如果处于项目早期，可增加开发人员。 l  增加高层次的开发人员（例如特定领域的专家）。 l  增加测试人员。 l  增加行政方面的支持。 l  提高对开发人员的支持力度。例如：更安静、更独立的工作间，速度更快的计算机，有技术人员随时可对网络或机器故障进行维修，同意为开发所需的各种服务提供高额支出，等等。 l  少做官样文章。从务实的角度考虑项目的运作。 l  提高最终用户的参与度。最好在项目组中配备一个能对feature set拍板的全职的最终用户。 l  提高主管人员的参与度。 与进度计划有关的变通之处[/b] l  在详细设计、产品设计或至少是需求分析完成之前，只提出一个schedule goal（进度目标），而不是为整个项目设定一个确切期限。 l  如果是在项目初期，则在修正product concept、功能要求和详细设计时，可以探求缩短开发时间的方法。 l  应同意先给出进度估算范围或大概的进度估算值，然后随着项目的进展逐步准确。   3.       坚持客观标准。由于过于乐观的进度计划多是由于wishful thinking产生的，因此在谈判中坚持客观标准不动摇就显得特别重要。这里的“客观标准”就是指由科学的估算过程得到的估算结果，这是必须坚持的底线。指出不可实现的进度计划的不合理之处并表示拒绝接受，这才是真正地替客户利益着想。与其承受后期的进度与费用严重超支和信用受损，倒不如在前期就坚决拒绝不合理的进度计划。