The Tar Pit(焦油坑)
A ship on the beach is a lighthouse to the sea.
前方有坑,请绕行。
一个商用产品花费的时间是一个可用产品的9倍!
Joys
- sheer joy of making things;
- making things that are useful to other people;
- 复杂组件环环相扣,精妙配合,和预期一样运行的魅力;
- always learning,非重复工作带来的学习动力,无论是理论的还是实践的,或者都有;
- 计算机规矩、灵活,程序员只需要思考就可以凭想象创造,可以轻易的打磨和重做。
Woes
-
程序员要做到完美,完美遵守计算机规则;
-
目标是别人设置的,程序员要根据别人提供的生产资料工作 ;
one's authority is not sufficient for his responsibility.
-
依赖其他系统组件和程序,有可能是糟糕的设计、文档和实现;
-
设计概念很有趣,工作很大一部分确是捉虫;
-
调试可能是线性收敛的,更糟糕的情况是,最后一个bug需要花费比第一个bug更长的时间找到;
-
压死程序员的最后一根稻草,产品上线就落伍了
The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.
总结一下
This then is programming, both a tar pit in which many efforts have floundered and a creative activity with joys and woes all its own. For many, the joys far outweigh the woes.
The Mythical Man-Month(人月神话)
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
排期造成的软件失败是其他失败原因之和。
进度规划的失败原因
- 工时估算,估算的是一切顺利时的工时;
- 工时估算技术混淆了工作量和进度,潜意识的认为人和月可互换;
- 估算不准确;
- 进度跟踪地很差劲;
- 进度落后就增加人力,导致恶性循环。
Optimism
程序员时乐观主义者,可能是计算机技术吸引相信幸福结尾的人,也可能是琐碎的事情赶走了很多人,只留下了习惯性专注目标达成的人,也有可能是计算机的出现时间并不长,程序员就更年轻了,年轻人总是乐观的。不管程序员甄选的过程是如何工作的,结果是毋庸置疑的,这次程序肯定能运行,或者我刚发现了最后一个bug。
所以进度安排的第一个错误假设就是:一切顺利,每项任务只花费它应该花费的时间。
创作活动分为三个阶段:想法,实现和交互。创作的完成标志是有人阅读了这本书或者运行了这个程序,从而完成和作者的**交互。
程序的创作介质-计算机是很规矩的,所以我们在实现时预期不会遇到困难,因为我们的想法可能会出现错误,程序写的有bug,所以乐观主义是未经证明的。
在单个任务中,遇到delay的概率是有限的,但是大项目由很多任务组成,有些任务是端到端的,每个任务都进行顺利的概率就很低了。
The Man-Month
估算和进度安排的第二个错误想法就是工作量单位:人月。
成本跟人员和月数有关,但是进度和人月无关。
Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.
这句话隐含了人和月是可替换的。
当任务可被拆分给不同的程序员,且他们之间无需交流时,人和月是可以替换的,比如收小麦和摘棉花,但在系统编程中,这都不能说是近似正确。
新增的交流负担主要由两部分组成,培训和程序员间的交流。培训和新增人员个数是线性关系,但是成对的交流和新增人员个数是平方关系。
增加人力,实际上是延长了时间进度,而不是缩短。
Systems Test
顺序限制影响最多的是调试和系统测试,更糟糕的是,影响时间也和遇到的错误数目和微妙程度有关系。因此测试是编程中最被误排期的部分。
作者遵循如下的排期规则:
- 1/3时间计划(设计);
- 1/6时间编码;
- 1/4时间组件测试和早期系统测试;
- 1/4时间所有组件一起系统测试。
和传统的排期有以下不同:
- 计划的时间更长,即使如此,也不足够产出一份充分稳定的规范,也不足调研和探索新技术;
- 一半的排期用来调试;
- 编码时间只占用1/6总工期。
很多项目并不会给测试排一半的时间,但事实上确实花费了一半的时间。很多项目都是按照工期来的,直到或者说除了系统测试。没有分配给系统测试足够的时间是灾难性的,因为延期发生在排期结尾的时候,直到交付才意识到了问题。此时的延期有很严重的经济上和心理上的影响,因为项目已经全马力进行中,每日成本都是最多的。为了能搞按时交付,二次成本也很高,甚至超过了其他的成本。所以给系统测试预留足够的时间很重要。
怯懦的估算
顾客可以控制任务的计划完成时间,但是却不能控制实际进度。为了匹配客户的期望交付时间而进行错误的排期,在软件行业中比其他工程行业更普遍。没有量化的方法、没有支撑数据、主要靠经理的直觉,很难去做一个勇敢的,合理的甚至冒着失业的风险的预估计划。
有两份方法:
1. 开发推行生产率表,缺陷表和估算规则等,这些数据的分享将使整个行业将受益;
2. 在可靠的估算出现之前,项目经理要挺直脊梁,坚持自己的估计,确信自己的直觉比一厢情愿的预估更靠谱。
重新规划进度灾难
进度已经落后,只完成了第一个里程碑,项目经理有哪些选择呢:
- 交付时间不变,增加人力,假设只有第一个里程碑被错误的估计,需要增加比预想的多一些的人力;
- 交付时间不变,增加更多的人力,假设所有的估算都是低的,需要增加更多的人力;
- 重新安排进度,需要重新仔细、完整的审视,防止再次发生排期的情况;
- 砍掉一些任务。
前两个选择会导致
Adding manpower to a late software project makes it later
这就是去除神话色彩的人月。项目需要的时间依赖于顺序性限制,项目人数依赖独立的子任务。根据这两个性质,项目经理可以推算出使用更少人力和更长时间的排期(风险就是产品上线就落伍),并不能推出使用更多的人力和更少的时间的排期。
在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。