第一次看这本书时候,我还在读大二,当时觉得这本书的名头很大,说是几十年来最好的软件图书,所以就在学校旁边的外图翻开看了下,不过很巧的是,这本书我就看了几页,就发现了旁边的移动编程有了几本新书,有几个比较少见的字眼,Android,所以我就开始了Android的学习,然后到现在的iOS。

这本书有几个章节我印象深刻,可能是跟我的真实项目相关吧,比较两年来也做了很多的项目,不知道公司领导会不会看到这篇文章,不过不要紧了,我就是一个程序员,在自己的博客,写点自己的想法。

1.人月

在我做过的项目中,有很多项目都会添加人手的事情发生,也有人会跟客户说如果进度来不及会添加人手。但是就像是书上提到的,人月是无法替换的,例如30人/月,不表示60个人就能缩短一半的时间,因为到沟通成本是n(n-1)/2的成本,例如:每当一个人加入到我的项目中,首先我要跟他讲整个项目的结构,然后在开发过程,他会不断的问我问题,原本我只需要很专心的开发就好了,到后面,我不断的被打断,当我的项目3个人以上时,我一天下来就需要不断的被打断,不断的回答各种问题,我的效率就被不断的降低了,不单单是这样,而且新加入的成员对于我们项目的合作方式也需要慢慢磨合。

2.外科手术队伍

到现在我还是无法同意公司现在的项目机制,首先我现在所在的公司是通过技能进行区分部门,例如Java部,手软部,php部,但是我们却是通过做项目来盈利,每次一个项目过来,我们都需要在各个部门中挑人,然后组建开发团队,即使跟以前类似的项目,也要让新人来练手,然后团队有个做过的人,进行指导。我一直无法明白,为什么要这样子,如果让原来的团队成员再来做这个项目,不是更快吗?如果有一个团队,里面的人都有各个的职能,随着他们不断的做项目,不断的进行合作,到后面越来越默契,效率不是更高吗?事实上我很不喜欢跟我不熟悉的人合作,因为很多东西又要重新说一遍,我又要去熟悉新人的做事习惯,去学习跟不同的人进行合作等等,这些都增加的开发难度。

3.概念的完整性

在一个项目中,项目经理显然是最重要的,他带领着团队的成员去实现一个目标,去完成项目,但是我在公司的项目的开发中,经常遇到放羊状态。很可笑的放羊状态,就是项目开始关心下,到后面很多事情就需要程序员自己决定了,然后程序员去问需求,去问UI等等,然后到项目延迟后,然后再来解决问题。还有一个就是项目的进度把控,做一个项目,经常遇到这个项目不知道什么时候完,不断延迟的项目是很打击项目成员的信心的。

4.前进两步,后退一步

瀑布模式是最简单的开发模式,所以到现在还有很多公司在使用。因为他简单易懂,但是我们做技术都明白一个道理,不变只有变化,这么多年了,还在用这个,难道就没有更好的方法去提高我们的开发效率了吗?肯定有的,只是肯不肯的问题,怎么做的问题。一条路对不对,走了才知道,很多时候我们都不敢走,因为不一定能有回头的机会,但是不表示现在的路就正确,因为未来是不可见,所以走不走都是一样,试试总比不试好。

建议大家看看这本书吧《人月神话》,有很感触的,我看得比较着急,但是受益匪浅!