第一次看这本书时候，我还在读大二，当时觉得这本书的名头很大，说是几十年来最好的软件图书，所以就在学校旁边的外图翻开看了下，不过很巧的是，这本书我就看了几页，就发现了旁边的移动编程有了几本新书，有几个比较少见的字眼，Android，所以我就开始了Android的学习，然后到现在的iOS。
这本书有几个章节我印象深刻，可能是跟我的真实项目相关吧，比较两年来也做了很多的项目，不知道公司领导会不会看到这篇文章，不过不要紧了，我就是一个程序员，在自己的博客，写点自己的想法。
1.人月
在我做过的项目中，有很多项目都会添加人手的事情发生，也有人会跟客户说如果进度来不及会添加人手。但是就像是书上提到的，人月是无法替换的，例如30人/月,不表示60个人就能缩短一半的时间，因为到沟通成本是n(n-1)/2的成本,例如:每当一个人加入到我的项目中，首先我要跟他讲整个项目的结构，然后在开发过程，他会不断的问我问题，原本我只需要很专心的开发就好了，到后面，我不断的被打断，当我的项目3个人以上时，我一天下来就需要不断的被打断，不断的回答各种问题，我的效率就被不断的降低了，不单单是这样，而且新加入的成员对于我们项目的合作方式也需要慢慢磨合。
2.外科手术队伍
到现在我还是无法同意公司现在的项目机制，首先我现在所在的公司是通过技能进行区分部门，例如Java部，手软部，php部，但是我们却是通过做项目来盈利，每次一个项目过来，我们都需要在各个部门中挑人，然后组建开发团队，即使跟以前类似的项目，也要让新人来练手，然后团队有个做过的人，进行指导。我一直无法明白，为什么要这样子，如果让原来的团队成员再来做这个项目，不是更快吗？如果有一个团队，里面的人都有各个的职能，随着他们不断的做项目，不断的进行合作，到后面越来越默契，效率不是更高吗？事实上我很不喜欢跟我不熟悉的人合作，因为很多东西又要重新说一遍，我又要去熟悉新人的做事习惯，去学习跟不同的人进行合作等等，这些都增加的开发难度。
3.概念的完整性
在一个项目中，项目经理显然是最重要的，他带领着团队的成员去实现一个目标，去完成项目，但是我在公司的项目的开发中，经常遇到放羊状态。很可笑的放羊状态，就是项目开始关心下，到后面很多事情就需要程序员自己决定了，然后程序员去问需求，去问UI等等，然后到项目延迟后，然后再来解决问题。还有一个就是项目的进度把控，做一个项目，经常遇到这个项目不知道什么时候完，不断延迟的项目是很打击项目成员的信心的。
4.前进两步，后退一步
瀑布模式是最简单的开发模式，所以到现在还有很多公司在使用。因为他简单易懂，但是我们做技术都明白一个道理，不变只有变化，这么多年了，还在用这个，难道就没有更好的方法去提高我们的开发效率了吗？肯定有的，只是肯不肯的问题，怎么做的问题。一条路对不对，走了才知道，很多时候我们都不敢走，因为不一定能有回头的机会，但是不表示现在的路就正确，因为未来是不可见，所以走不走都是一样，试试总比不试好。
建议大家看看这本书吧《人月神话》，有很感触的，我看得比较着急，但是受益匪浅！
