注：
本文为《我的读书笔记之人月神话》系列的第二篇，欢迎指正。
=============================================================
效率一直是困扰每个团队，特别是项目经理的一个大问题。作者从他数十年的项目经验（大部分是硬件或硬软件结合，但也适用于纯软件）中总结了若干模式，用于有效提升大型项目的开发效率。让我们一起略窥究竟。
对于大型的团队，作者提出了一个“外科医生”的模型，即：
将整个系统（项目）划分为若干子系统，每一部分由一个独立的团队承担，每个团队采取类似外科手术的操作方式进行开发：一个外科医生（首席程序员，有决定权），护士（副手，熟悉系统，和别的团队沟通交流），管理员（控制财务、人员、工作地点等的机构管理），编辑（文档维护），程序员，测试员，专家，其他人员（……）
通常对10人左右的编程团队而言，上述角色分工就足够了，其中管理员和专家可以同时为多个团队服务。团队间的协调，也因人数（外科医生）的减少而提高了效率。
这样就提出了一些新的问题：如何保证整个系统设计概念的完整性？
今早出门，把门关上的那一刻，又发现忘带钥匙了，手里还提着那沉重的电瓶。
这次运气没有那么好，打电话给房东不在家，只好晚上再说了。
大热天的挤了一个钟头的公交车，真是受罪不小。看来这个健忘症该治治了，俺还那么年轻的说。
有谁知道什么食物有助于提高记忆力的，吱个声吧。
注：
本文为《我的读书笔记之人月神话》系列的第一篇，欢迎指正。
=============================================================
文章的开头是很美的一段：
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
美食的烹调需要时间；片刻的等待，更多美味，更多享受。—- Menu on restaurant Antoine, New Orleans.
相信所有的饕客都会对此感同身受，频频点头。作者可能是想藉此说明，软件开发就如同美食烹调，都是循序渐进，有章可循的。贸然跃进，可能只会适得其反。
接下来，开篇就提出了全书最重要的观点：人月(Man Month)不能互换。
长期以来有一种观点认为，一个软件项目，如果需要3个人做4月的话，那么4个人做3个月也可以完成。通俗的来讲，就是效率（或者说进度）会随着人数的增派而相应提升，从而缩短了整体的时间。事实上，在阅读此书之前，排除一些细小因素（比如人员个体差异等），我大体上也是这么想的。
不成立的原因有很多，作者给出了如下几点（每项后面的是我的注解，下同）：
确实如此，但如果每个环节上都增派了人手，似乎对进度提升还是有帮助的。
这个就是我所说的个体差异了。但是交流成本的增加确实是我事先没有想到的。
碰到过类似情况，有一个任务在身，Leader分配了另外一人来帮忙，结果给他解释的功夫自己做完都足够了。
没有想到过，但是觉得很有道理。
当然，对于何时成立的情况作者也给出了说明（如图所示）：
《The Mythical Man-Month》，说起来这本书已经耳闻很久了，最近才有心思静下来阅读。这里将会收录一些在此过程中的摘录和心得体会，未必正确，仅供参考。
作者：
Frederick P.Brooks.Jr.
简介：
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的简介，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范……
//以下列表会持续更新直到阅读完毕
通常，在一些有定时自动执行功能（类似于计划任务）的系统中，画UML图的时候经常会出现这样的争议：
到底系统时钟（定时器）可以作为Actor来画吗？
下面的文件可能正好解答了你的疑惑：点击查看
如果你只想简单的知道答案，Here it is：不推荐。
处理方法：
详情可参阅上述附件。