今天这篇阅读笔记主要讨论《人月神话》中的“人月神话”以及组建“外科手术队伍”。
首先介绍一下什么是人月神话。我以前听人月神话的时候总是觉得很玄幻，以为这是一个神话故事之类的。我相信很多刚刚听到这个词汇的人都会这么认为，但是经过阅读发现，人月神话并不是神话故事。这是一种软件开发过程中的度量单位。估计完成一个项目大概需要多长时间，比如需要12人月，则可以理解为需要3个人工作4个月。
那么怎么又称为神话呢？因为使用人月这种度量方式，在很多情况下衡量一个一项工作的规模是一个危险和带有欺骗性的神话。因为在以上关于人月的介绍中，根据这种计算方式，似乎人和月是可以等价互换，互相补充弥补的，但实际情况并不是如此。并不能用增加人的数量来减少开发的周期，这是一种愚蠢的想法和做法。
人们在对项目进行估计的时候往往是非常乐观的，这是我们应该保持的一种良好的心态，但是我们更要从实际问题出发，遵循客观规律，不能盲目的乐观。当人月可以互为转化时，这说明这个项目的每个模块的关联性很小，团队成员之间的交流也不会很多，而且交流起来会非常简单，只有基于这种情况下，人月的内涵才能够充分的得到体现，这种度量方式才能很好的阐述人月可以等价互换的理念。但是事实往往并非如此。每一个项目，项目的各个模块的联系都是非常紧密的，而且很多模块之间是由时间先后顺序的，这些因素决定了人月模型并不适合。当人的数量大大增加时，并不能有效的缩短项目的完成时间，相反，还可能会增加项目的时间。
试想一下，当团队人数比较少时，每个人负责的工作量可能会比较大，但是每个人之间的交流会变得相对来说更加简单，而且交流的时间会比较少，而当人数比较多时，因为各个模块并不是孤立的，要考虑到其他的模块的实现方式，所以交流会变得困难起来，这样无疑就增加了时间开销，而且这种事件开销在一个项目中会占用大量的时间。
那么关于人月之间存在的这种矛盾，我们该如何解决呢？
一是，开发并推行生产率图表、缺陷率、估算规则等等，而整个组织最终会从这些数据的共享上获益。
二是，在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多。
总之，项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。 从这两个数值可以推算出进度时间表， 该表安排的人员较少， 花费的时间较长（ 唯一的风险是产品可能会过时）。相反，分派较多的人手， 计划较短的时间，将无法得到可行的进度表。
下面介绍另一种解决方案，组建“外科手术队伍”。这是一种团队模式，通过这个模式，理论上来说能够大大提高团队开发效率，并在一定程度上有效缩减开发时间。
软件开发过程中存在以下这几种情况：
优秀程序员和较差的程序员之间生产率的差异。
一拥而上的开发方法是高成本的、 速度缓慢的、 不充分的， 开发出的是无法在概念上进行集成的产品。
对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发， 而对于大型系统， 则需要大量的人手。
对于上述情况和存在的矛盾，我们可以通过组建“外科手术队伍”来进行解决。这个队伍的核心是外科医生，他需要亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。其他的人要对他进行支持和服务。其他人员还包括：副手（工作和外科医生相同，但不进行实现），管理员（对财务、人员等进行管理）、编辑（整理文档）、秘书（两个，负责项目的协作一致）、程序职员（负责技术记录，类似于构建大师的工作）、工具维护人员（提供特殊工具，保证所需服务可靠运行）、测试人员（设计提供测试案例）、语言专家（解决语言使用上的问题）。
通过这个队伍，是系统在客观上达到了概念一致性，同时也确保了工作概念上的一致性。同时由于是外科医生和副手两个人建立起来的系统，因此便于交流，减少了不必要的时间开销，同时也是体系结构更加清晰明确。而剩余人员的智能的专业化分工使得他们的工作能够更加高效。