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