Brooks法则:向进度落后的项目中增加人手,只会使进度更加落后。
我们刚刚接触软件编程,对于在软件功能的实现、程序设计人员面临的困难我也能略微理解了。项目的时间依赖于顺序上的限制,人员的最大数量依赖于独立子任务的数量。对于一个或多个项目说,有这样一个运作规律:以前公司大多会采取人海战术,但进度没有提前,反而整天加班,最后用户不满意,开发人员整天郁闷,结果是用户对公司失去了信任。开发人员呢,旧人一一辞职,新人几乎天天引进,但做法并没有改变,情况也没有好转,公司自然没有发展。
人月之所以不能成为神话,正是因为增加人手的同时也增加了人与人之间的交流,即培训和相互沟通。我们所有的进度都是以“人月”代码产量来衡量的. 而增加"人"并不能缩短"月"的量。同时,缺乏正确的进度安排是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大。
“开发并推行生产率图表、缺陷率图表、估算规则等等,而整个组织最终会从这些数据的共享上获益。”这与我们团队的周活动总结表、时间记录日志、缺陷记录日志、学习进度条有一定的相似之处,可见创建并记录这些数据是一个明智之举。其中的一个原因我认为是由于我们的乐观主义,通常实际出现的缺陷数量比预想的多得多。
之前的团队合作中也出现过类似的问题,通常在讨论时会忽略一些功能在具体实现上所需的难度有多大,导致遇到问题时压力变大。
我们团队的人数自然是不变的,所以,在今后的团队合作中更要注重分工和进度的安排,高效地完成我们的项目。