人月神话读书笔记

第一章作者将软件系统开发比作吞噬了恐龙、剑齿虎等史前巨兽的焦油坑，许多大大小小的团队被软件开发的焦油坑所吞噬。

作者首先介绍了变成系统产品的演进，指出程序、编程系统、编程产品、编程系统产品几个概念间的区别，其中只有编程系统产品才是真正可用的面向用户的产物。

然后作者分别介绍了编程的乐趣和苦恼，当然这部分见仁见智，人类的悲欢毕竟并不相通。

人月神话
第二章作者主要介绍了软件开发项目在进度安排上经常出现的问题。也就是书名人月神话的出处。首先，由于我们对项目开发的进度估计过于乐观，我们估计出来的工作量通常会低于实际需要的工作量，尤其是对测试所需时间的安排常常是进度估算失误的重灾区，这应该是很多有经验的开发者会在估时的时候乘以一个固定的系数的原因(1.5 或者 2 甚至 3)。其次人员和时间的关系并非总是反比的关系，如果任务属于可以完全分解的理想状态话，是可能达到人员越多时间越少的反比效果的，但是，任务越复杂也就越难以分解，那任务中的沟通需求就会占用更多的时间，甚至可能导致人员越多，项目所需的时间越长。进而可以得出结论：当进度落后的时候，无脑增加开发人手可能并不能加快开发进度，甚至有可能导致进度更加缓慢。向进度落后的项目中增加人手，只会使进度更加落后，这也被成为 Brooks 法则。

外科手术队伍
基于上一章的结论：更大的队伍不一定能带来更快的开发进度，那么，问题来了，什么样的队伍才是合适的呢，小团队固然高效，但是你不能指望一个 20 人的小团队在合理的时间内去开发一套完整的操作系统吧？作者在这一章里给出了解决方案：将大项目合理地划分成更小的系统，各个外科手术队伍分别开发这些更小的系统。当然外科手术队伍只是一个小团队的方案，具体细节我认为已经不再具有很大的参考价值，但是精干的小型队伍这一理念仍然很有价值。

这里我联想到大企业病的问题，企业规模的扩大必然会导致人浮于事、效率低下的问题，于是如今一些大企业都会将企业的业务分割给各个小团队来负责，一个很著名的例子就是亚马逊的两个披萨的原则，有效地避免了大团队的导致的低效问题。

贵族专制、民主政治和系统设计
接上一章：短小精干的队伍带来了新的问题，如何对大项目进行合理的分割？这依赖于一个很重要的前提：概念的完整性，具体而言是指在项目的开发过程中，应该有一个一以贯之的明确的目标和清晰界定的范围，否则随着人员的变动和时间的变迁，这个项目可能会逐渐演变成四不像(我最近在参与的一个项目就是如此，人员的变动导致了项目功能、技术栈的变迁，项目的周期被极大地拉长)。而如何产生概念的完整性呢？答案是贵族专制，少数人决定一个概念并厘清边界，然后据此分割执行，否则人多嘴杂，必然会导致项目在讨论中变成奇怪的样子。