首先我要说明的是题目有着双关的含义。
-
一层含义针对我而言，而这个“人月神话”是指Brooks老爷子的书籍《人月神话》，我很认可这本书中的大多数观点。
-
一层含义针对一些企业管理者而言，我从我的角度对某些企业的管理层提出质疑，为什么他们确实相信人月这个神话。
首先讲讲《人月神话》这本书
之前这本书的大名早就如雷贯耳，但是一想到是一本几十年前的老龄书籍，心里想着伴随着软件业日新月异的发展，这本书的观点一定也是老掉牙的，也就多次放弃了对这本书的阅读。直到前一阵为了收藏买了一本32周年中文纪念版，翻起阅读却惊奇地发现书中探讨的问题和大多数观点依然是当前软件业存在的，而一些解决方案也符合当今软件业的潮流。下面我摘录书中的几个观点与大家分享下。
-
焦油坑
乐观永远是软件行业的天敌。请记住：你做的不是一个软件，也不是一个系统，而是一个稳定易用的产品。往往你会乐观估计到软件完成或是系统集成成功这一步，那这样后面的日子对你来说就是噩梦。 -
人月神话
人月在大多数情况下始终是个神话。一个人十个月能完成的任务十个人一个月就能完成吗？一个很形象的例子，一个人怀胎十月你可以找十个人来怀胎一月吗？ -
概念完整性是产品质量的核心
虽然我们鼓励团队所有人对产品的架构设计、产品设计提出建议，但是一定要让其保持概念的完整。所以我们不能没有架构师和产品经理的决策。 -
瀑布模型是错误的
乌托邦很美好，但是太理想化，所以不可能实现。瀑布模型假定一切都按照既定步骤顺利的走下去，可能吗？ -
增量开发模型更佳
当今这是一种潮流，敏捷开发就是其中一种。今天，你敏捷了吗？ -
人就是一切（或者说，几乎是一切）
“21世界什么最重要？人才”，但是有了人才，你还要做到怎样管理人，激励人，与之良好合作。 -
没有银弹
某种编程语言、面向对象思想、某些开发流程...都曾经被当做IT业的银弹，最终呢？
.....
再讲讲企业相信的神话
"这个产品半年一定能完成，因为我们有昂扬的斗志，我们有不分白天黑夜的加班，我们还有大把的钱招新的人加入项目组为大家分担工作。"
半年后，产品未按期交付，"都怪你们这帮工程师，埋怨，降薪......",谁鸟你，遇到你这种管理者，最好的办法就是拍屁股走人。这样的管理者，推荐你去相信那本《人月神话》，而不是这种人月的神话。
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/1227220如需转载请自行联系原作者
yaocoder
