赞
踩
在众多软件项目中,缺乏合理的时间进度是造成项目滞后的主要原因,它比其他所有因素加起来还大。
我们不禁要问导致这种普遍性灾难的原因是什么呢?
FrederickP.Brooks.Jr给出了以下几个原因:
1)估算技术缺乏有效的研究,隐含地假设一切都运行良好
2)将进度和工作量相互混淆,隐含地假设人和月可以互换
3)对估算缺乏信息,导致不会有耐心地持续地进行估算这项工作
4)对进度缺少跟踪和监督
5)当意识到进度偏移时,下意识的反应是增加人力
Note:可以反思下,看看自己在项目运行的过程中有没有犯过以上一个或者几个错误。
乐观主义
“这次它肯定会运行”,或者“我刚刚找出了最后一个错误”
你是不是经常假设一切都运行良好,每一项任务仅花费它所“应该”花费的时间?
Dorothy Sayers将创造活动分为3个阶段:
1)构思
2)实现
3)交流
首先我们构思出一个事物;接着通过介质(墨水,电线、钢笔等等)将它实现;然后当某人阅读书本或者使用你创造出来的事物(比如打印机),也就是和作者沟通,从而创造过程结束。
耗时费力的阶段就是实现,只有在实现的过程中,才能发现我们构思的不完整性和不一致性。在实现的过程中,活动实施的介质(木头、油漆、电器等)很难把握,往往对构思的
实现造成许多意料之外的困难。
物理介质的不可控,思路的不完整性 使构思实际实现起来需要花费大量的时间和汗水。
大部分情况下,你可能会抱怨物理介质(为什么突然没电了,为什么机器运行这么慢等等),为什么不按我们设定的“思路”走,这个设定的思路就是---一切都运作良好,每一项任务仅花费它所'应该'花费的时间。其实,你是给过程加上了主观的乐观主义色彩。
单个任务,在“一切都会运转良好” + “不会延迟”上具有概率上的可能性。然而大型的开发编程活动中,都包含很多任务,各个任务之间还有相互关联,前后关系,所以所有任务叠加都能实现“一切都会运转良好” + “不会延迟”的概率变得很小,甚至接近于无。
人月
成本的确随着开发人员的人数和时间的不同,有很大的变化,进度却并不是如此。
人数和时间互换仅适用于:某个任务可以分解给参与人员,并且他们之间不需要相互交流。这在割小麦,收棉花的工作中是可行的,在系统编程中近乎不可能。
由于次序上的限制,任务无法分解时,人手的添加对进度没有帮助。不管多少个母亲,孕育一个生命都需要10个月。
对于任务可以分解,但子任务之间需要沟通和交流的任务,必须在计划中考虑沟通的工作量。沟通所增加的负担由两部分组成:
1)培训:类似于广播,1 vs 多
2)相互交流:N vs M
相互交流这种情况会随着人数的增加,变得越来越不可收拾,按n(n-1)/2递增。
软件开发本质上是一项错综复杂关系下的一种实践,沟通交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间,导致添加人手,实际上是延长了而不是缩减了时间。
系统测试
不为系统测试安排足够的时间简直是一场灾难
软件任务的进度安排,作者给出了自己使用多年的经验法则:
1/3 计划
1/6 编码
1/4 构件测试和早起系统测试
1/4 系统测试,所有的构件已完成
分配了近乎一半时间给测试,编码时间仅占1/6。很少有项目允许给测试分配一半的时间,但大多数项目的测试实际上花费了项目的一半时间。为了避免二次成本,早期的进度策划时,允许充分的系统测试时间是非常重要的。
空泛的估算
为了满足顾客期望的日期而造成的不合理的进度安排,在软件领域比其他的任何领域要普遍的多。
解决方案:
1)开发并推行生产率表、缺陷率、估算规则等等
2)挺直腰杆,坚持自己的估计
重复产生的进度灾难
向进度落后的项目中增加人手,只会使进度更加落后。
当一个项目落后于进度的时候,通常的做法是什么呢?自然是增派人手,但这可能有帮助,也可能无法解决问题。
设想一个估计需要12人月的任务,分派给3个成员4个月完成,在每个月的末尾安排了可测量的里程碑A、B、C、D。
现在假定两个月后,第一个里程碑没有达到。项目经理面临的选择有哪些呢?
1)假设任务必须按时完成,且仅仅是任务的第一部分估计不当。剩余9人月的工作量,时间还有两个月,即需要9人月/2个月=4.5个人每月。需要在原来的3人的基础上再增加两个人。
2)假设任务必须按时完成,并且整个任务估计偏低。并且还有18人月的任务。因为只剩下两个月,所以需要9个人每月,在3人的基础上增加到9人每月。
3)重新安排进度。在新的进度安排中分配充分的时间,保证工作仔细、彻底的完成。
4)削减任务。
前两种情况,坚持把不经调整的任务在四个月内完成是灾难性的。以第一种为例,不论在多短的时间内,聘请到多能干的两位新员工,他们都需要接受一位有经验职员的培训。如果培训需要一个月,那么将会在原基础上3人月的任务。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。