《人月神话》读书笔记 第3篇
第15章：另一面
第16章：没有银弹
第17章：再论“没有银弹”
第18章：《人月神话》：是与非？
阅读《人月神话》马上就要接近尾声了，发现后面讲的内容越来越专业，但是对于我们正在进行的团队合作启发很大。前几天老师在课堂上给他们看了他统计整理的个人与每个团队第一个冲刺阶段的进度表格，看到有些严格按照要求每天有进度，有些则相反，也可能是完成了但是没有及时汇报进程。那“项目怎么会被延迟了？……延迟的时间是一天一天积累下来的。”目前我们做的都是一些小软件，那大项目的延迟将会很明显，一推再推就有可能被推迟至按年计算，那都不是人月的问题了。
“复杂度不仅仅导致技术产生困难，还引发了很多管理上的问题。它是全面理解问题变得困难，从而妨碍了概念上的完整性；它使所有离散出口难以寻找和控制；它引起了大量学习和理解上的负担，使开发慢慢演变成了一场灾难。”在开发的初始我们一直想做个比较好的小游戏，不论是从哪个方面来说，都希望能达到一个很专业的水平，但是经过讨论后发现，很大程度上局限于当前的水平，不能把结构做太复杂，算法同样，用我们熟练的、理解的，否则将会给自身带来很大的负担，重要的是可能会影响整个团队的进度。类似我做后期的工作时，我的PS并不是很好，很久不用也基本也要重新拾起，那么也不必那么麻烦，用美图秀秀能解决的就干脆的做完了。
我们目前做的目的是什么？一切都是为了满足用户的需求，并且更加要明白“用户：他们是谁？他们需要什么？他们认为自己需要什么？他们想要的是什么？”制定好大致的方向，再分析各个点进行任务。这也是为什么要一直强调用户需求的重要性。否则，做出来的软件没有用户，或者不满足用户的需求，都是无意义的。
最后是关于“银弹”这一个论点，上课大家也都展开了激烈的辩论，有或者是没有都说得非常有道理，是与否都是要经过团队每一个成员的再三思考后讨论得到。要银弹则不会因为长时间的争论而拖延进程，可能造成团队的不稳定；不要银弹也许可以找到更和谐的解决方式而不必经历最后会闹变扭，但也许会稍微牺牲一些时间。实际上，也要依据团队的性质（包括成员的性格）而采取不同的方法，因为到最后总要有个决定。