从实践项目开发反思人月神话

再给我1800秒，我就能完成这个功能。———TIME PLUSER小组

人月神话，初听时容易联想到“嫦娥奔月”之类的故事，令人对软件工程产生奇特的幻想。然而了解一番才知道二者相去甚远。所谓人月，指的是人力和自然月，是项目的工作量单位。

这个概念来自于《人月神话》，其作者布鲁克斯被认为是IBM360系统之父，Brooks以在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验写下了这本书，提出了著名的“人月神话”，“没有银弹”。中文版下载

在这本书中，Brooks首先就将大型软件开发比做焦油坑，焦油坑吞噬了史前巨兽，就像庞大的软件开发任务吞噬了貌似强大的团队的热情和信心。

在我们组完成软件工程实践项目的最初，我们也非常相信自己的能力，信誓旦旦“要搞出一些事情”，大胆的选择了难度不低的题目，进行各种美好的设想。
接下来不断地讨论（争吵），修改完成的预期，大抵就能理解老师所讲，为何往届的学长学姐们组队完成任务之后，能达到“吵崩”的状态。

那么问题的症结在哪里看看《人月神话》，大概能找到一些答案。

• 人月神话（第二章）
• 分工、沟通、协作（第三、四、六、七章）
• 合理评估，不断变更、更精简的设计（第八、九、十、十一章）
• 工具、测试及项目管理（第十二、十三章）
• 其他思考：没有银弹第十六、十七章）

人月神话（第二章）

在我们分工、合作完成任务的时候，我们经常喜欢安排某人花费有上限的时间完成一个任务，软件开发也是同理，我们喜欢用人月去衡量工作量，暗示自己人力和时间是可以互换的。但是1个人100天可以造完一栋房子并不等于100个人1天可以造一栋同样的房子，所谓“人力”和“生产力”之间是单纯的线性关系就是一个“神话”。

布鲁克斯说：向开发进度滞后的项目增派人手更会减慢项目的开发。

这听起来是十分夸张的。但是对应到实践项目的时候，我们花费大量的时间决定产品的预期效果，商讨了技术实现的细节。在后期想找一位合适的用户提出新意见前，为用户介绍我们现有的所有功能以及实现的局限性都面临着相当大的困难，这个新加入的角色，需要从需求入手，重新把握这个项目的实现进度，比我们三个人继续头脑风暴还要难。

分工、沟通、协作（第三、四、六、七章）

为何巴比伦塔是失败的
一个优秀的开发团队，每个人都有理由相信自己的优秀。
但是仅仅如此是远远不够的，清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。

如果想实现效率的最大化，每个人必须发挥出最好的实力。
可是上面提到，使任务进展更加缓慢的一个可能原因，在于新成员需要花费时间了解项目进度、融入开发群体。这样才能确保需求被完全覆盖。

像我们的项目开发一样，A写好一段代码，实现了B的需求，而C，则尝试读懂代码，观察功能的实现，从而尝试增删改。一方面需要不少的时间，另一方面，同时由于大家的代码都是“一环套一环”去传参，跨界尝试修改其余成员的代码，胡乱的混合在一起，都可能导致软件的崩溃。

其实通过实验七可以感受到，需求分析、用户用例设计的好，类似面向对象模块化做得好，完成了合理分工、降低了代码耦合度，可以降低不少协作难度。
但只要彼此之间哪怕还有一个参数在传递，就不能不沟通协作。A可以独立完成一个函数，规范其参数和输出，但是只要使用这个函数的B有不同的想法、认为这个函数难以使用，就不得不对其做出更多的修改。反复的修改，大大降低了效率。所以沟通必须是顺畅的。

合理评估，不断变更、更精简的设计（第八、九、十、十一章）

工具、测试及项目管理（第十二、十三章）

其他思考：没有银弹第十六、十七章）

来源：Leafy_wang