何为人月神话？
人是程序员，月是时间
1个人干10个月如果等同10个人干1个月
这就叫神话
写在开头
最初听到这个书名，是在大一刚开始学Java基础的时候听到老师推荐的。当时还听到了《Thinking in Java》，《Effective Java》，较这些高端霸气上档次的书名相比之下，《人月神话》更像是在讲故事的书，而且还是带有奇幻色彩。最近一段时间拜读了这本神作，的确是在讲故事，是讲一个失败的经验故事，没有奇幻色彩，通过失败经验反思软件项目推进过程中的各类可能出现的情况。
有人曾这样评论：这本书不是教你该怎么做，而是教你不应该怎么做。它基本上是对一个伪常识的否定，而不是教你用什么方法把事情做得更好。
从对编程、软件开发一脸懵逼的小白，到毕业后进入开发岗位。
站在一个从业者角度来看：40年前的一本书，现在仍畅销，不是没有原因的。从虽然不懂你在讲什么但是好像很有道理，到切实参与到软件开发流程中，作为执行实现者，体会明显不同，这里对感触较深的章节分享一下自己的理解。
人月神话
-
缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。
何为合理的时间进度？合理一词如何定义，在目前快速迭代开发的市场大环境中，时间就是首要考虑因素，抛开系统复杂度、实现技术难点等项目核心问题。从时间的角度去给项目下定义我觉得就是不合理的，我想一个优秀的产品是需要时间锤炼的，慢工出细活。从用户交互、使用体验到后续维护运营、拓展升级，一个优秀的产品必经之路。若一次性开发一次性使用那我想时间的确是第一要义，我想这类情况也不在书作者的考量范围之内吧。
软件产品的迭代，更像是一个孩子从咿呀学语到长大成人的过程，合理的时间进度就是18年。这样来讲，揠苗助长是否合理我想我们心中都有答案了。
-
良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
谈到烹饪，高级菜品所需要的食材极为讲究，包括调料用量，火候把控，成菜摆盘。这样的菜品就是大厨们精心雕琢的艺术品。那艺术品的创造和不需要充裕的时间呢？这里我觉得和第一点很类似，都是强调了时间对产品质量的影响。
谈到烹饪了，来一张国宴名菜开水白菜的皂片：这还是我认识的白菜吗？
-
所有的编程人员都是乐观主义者：“一切都将运作良好”。
这点上我觉得我有发言权，作为开发人员，必须自信，我写的代码就是没有bug，不信你点，你再点，咦，你咋这样点呢？不是应该那样点吗？
在线翻车，2333，一切都将运作良好是站在正常操作的角度上，问题是无法控制用户的操作啊，难道可以心灵控制，让用户按照你的思路操作？软件开发本身就是服务行业，我们的金主客户才是上帝，你忒让上帝看到这个产品一切运作良好。
乐观可取，必须乐观，生活都这么难了，再不乐观可咋整。
在开发过程中，开发人员要站在用户的角度上考虑问题，考虑可能出现的各类突发状况以及应对方案。
-
由于编程人员通过纯碎的思维活动来开发，我们期待在实现过程中不会碰到困难。
面向用户开发，产品依托于业务需求。关于业务需求，我觉得对业务的深入了解是增量式的，绝不可能一口吃下个大胖子的。在日常开发编码中可能遇到这样那样的业务问题，逐步进行增量式的业务填坑。考虑到整体业务的闭环，基于业务闭环需要考虑某处的业务设计是否合理，考虑角度仍然不能仅从开发者，更多的应该是使用者。
-
但是，我们本身的构思是有缺陷的，因此总会有bug。
perfect plan，是反复修改出来的，而不是从一开始就存在。既然软件开发是服务行业，无法总是满足用户日益增长或变化的需求，正因为这样才需要迭代升级，逐步完善，朝着设计出一个perfect software目标而前进。
这里讲到的缺陷涵盖的不限于设计缺陷、编码缺陷等，但是最终的缺陷体现方式都是产品出现的Bug。开发太难了~~
-
围绕着成本核算的估计技术，混淆了工作量和项目进展。
人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。这句加粗变色的文字我觉得是章节的核心思想。
一个女人怀胎十月才能生下一个宝宝，难道十个女人怀胎一个月就能生下一个宝宝？
一盘西红柿炒蛋一个厨师需要做十分钟，难道十个厨师一分钟搞定？
软件开发是增量式的，是需要前置工作驱动后续发展的，不是基于人员的独立工作。是几个人共同创造一个软件产品，而不是每个人各自做自己的，最后简单的组装。
带有些许讽刺意味的人月神话类似理论，的确实实在在的存在。在成本与盈利需求面前，永远存在这这样的不可调和好的矛盾。如何调和这两者之间的矛盾，若问我我也答不上来，我想着不单单是经验不足，更多的是我所了解的软件开发是存在于
乌托邦里的吧。就像上学时书本是我们认知和理解的权威渠道。如今，社会现实这个万花筒，并非我们想象中的那样。还是太年轻~~~
-
在若干人员中分解任务会引发额外的沟通工作量 —— 培训和相互沟通。
这点也是一个项目推进过程中的痛点问题，我以实际经验来讲沟通成本太大，甚至大到夸张都不足为过。
就像几个人一起在跑马拉松，突然有个人参与进来，但是不明确路线，而且进度缓慢，你在半路，而他在起点。这时候就需要有人放慢速度甚至回退与在起点的成员对接，然后继续带领新加入的成员向前追赶。可是，时间一直在流逝啊~，时间可不会等人的。
又谈到了时间，真的是句句呼应全文中心思想。
-
关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
这里我想对三分之一的计划安排谈谈自己的看法：
需求阶段计划的一部分必定包括需求分析阶段，需求分析在整个软件开发流程中是具有重要地位的，作为前置工作的基础。完善的需求分析，合理的需求落地要求是必要的。正所谓，良好的开端是成功的一半。
从用户角度出发，通过需求采集、需求分析、需求筛选，到需求落地进行开发。这一个需求从无到有，从笼统到明确过程是必要且必须的。我很佩服那些能够把想法落实成文字，转换成实际需求进行产品设计的人。这些人才是软件产品的拓荒者和布道者。
-
作为一门学科，我们缺乏数据估计。
数据估计，关系到对项目整体进度的把控和管理，这里经验的重要性就很明显了。经历过就是和没经历过不一样，或许人家踩过的坑比你吃过的盐都多。经验这个能力评定无法量化，但是能力的体现是通过产品来反映的。
优秀的PM会有一股无形的力量，把控着全局。
-
我们对自己的估计技术不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。
勇气，可不是来首《勇气》就能有的，乌托邦式的软件开发存在于纸面而非现实。那么，在面对现实时，《勇气》能给你勇气吗？
-
Brooks法则：为进度落后的项目增加人手，只会使进度更加落后。
-
任务重新分配本身和所造成的工作中断；
-
培训新人员；
-
额外的相互沟通。
-
从三个方面增加项目必要的总体工作量：
-
总结
其实说了这么多，还只是书中的冰山一角，纸面上的内容虽然让人很有感触，但是落实成行动还是一个艰难的过程。
为何艰难呢？试错成本太高。回顾历史，变革往往代表着推翻重新构建，谁又能保证别人的经验也适用于自己呢？作者通过实际例子告诉我们不要这样做，但是又有多少人相信了呢？就算相信了又有多少人真正理会并践行了呢？
以上内容纯属个人想法，不喜勿喷，如有雷同，是你抄我~~。
以书中结束语作为本次分享的结束语吧：
软件工程的焦油坑在将来很长一段时间内会继续使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者在刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的工程管理方法的最佳应用；良好的自我判断以及能够使我们认识到自己的不足——上帝所赐予的谦卑。