注：

本文为《我的读书笔记之人月神话》系列的第四篇，欢迎指正。

=============================================================

交流：

作者先以“巴比伦塔的启示”为引子，提出了他所认为的项目成功的先决条件：

• 清晰的目标
• 人力
• 材料
• 足够的时间
• 足够的技术

本身这些条目都没有问题，但我觉得最后两点有待商榷。不可能等什么都准备到了“足够”的地步才去动手，特别是技术方面，在项目的进程当中去学习也是常有的事儿。

而巴比伦塔的失败，也证明了“交流”和“组织”（交流的结果）的重要性。

交流的可能途径：非正式途径；会议；工作手册

—————————————–

工作量：

以大型项目的数据为依据而研究所得的结论：

工作量=常数 * 指令的数量^1.5

由于我估计作者所从事的项目大都是操作系统级别的，所以书中很多指标都用类似“指令”这些指标来衡量。简单的讲，可以把这里的指令理解为系统的原子特征。指数型增长的趋势，倒也符合正常的逻辑推理。

复杂程度的指导原则：

编译器的复杂度是批处理程序的3倍，操作系统复杂度是编译器的3倍。

批处理和编译器我都写过，只不过那编译器是用高级语言Java写的而已，对于这个复杂度没有太深的体会。如果将来有机会接触到操作系统级别的复杂项目，那倒可以回过头来细细比较一下。

—————————————–

规模：

软件的规模是视其是否使整个应用系统更加有效而言的，并不在于它的绝对成本

• 仅对核心程序设定设定规模目标是不够的，必须把所有方面的规模都编入预算
• 在指明模块有多大的同时，确切定义模块的功能
• 培养开发人员从系统整体出发、面向用户的态度

时间与空间（占用的资源）

1. 项目的粗细程度决定所需的空间大小
2. 对于给定的功能，空间越多，速度越快

如何取得 空间<->时间 的折衷？

1. 从团队成员的编程技能上培训
2. 需要技术积累，开发公用单元构件

技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高

最后，以篇末最经典的一句话总结本文：

数据的表现形式才是编程的根本

注：

本文为《我的读书笔记之人月神话》系列的第三篇，欢迎指正。

=============================================================

这次谈得是贯彻执行的问题。换句话说，也就是如何确保一个拥有诸多结构师和编程人员的项目团队，对整个系统保持概念上的完整性？

最好的办法就是文档化的规格说明——手册！
这里的手册应该包括各种说明文档，设计文档，甚至备忘录，只要是对理解系统的设计有帮助的，应该都可以归入在内。

谈到手册，可能刚开始工作或者比较偏好编程的朋友会觉得比较头大，不太喜欢。刚开始的时候我也是如此，可随着时间的推移和工作经历的增多，却越来越发现手册的重要性。大到设计思想，小到会议记录，手册就像幻灯片一样将整个系统显示在你的面前。

那么，应该怎样书写文档（手册？manual？document？whatever），怎么样的文档才能算是好文档？

先来回答后面那个问题：

清晰、完整和准确：精确比生动更重要

好在搞技术的大多数都是理性思维，不会为了华丽辞藻在那边苦思冥想半天。

写到这里的时候忽又想起在之前那家日企得到的经验：尽量用简短的英文来描述，不用长句式。一来小日本不太擅长也不喜欢英语，二来长句式在理解上确实不如短句来的一目了然。

more…

注：

本文为《我的读书笔记之人月神话》系列的第二篇，欢迎指正。

=============================================================

效率一直是困扰每个团队，特别是项目经理的一个大问题。作者从他数十年的项目经验（大部分是硬件或硬软件结合，但也适用于纯软件）中总结了若干模式，用于有效提升大型项目的开发效率。让我们一起略窥究竟。

对于大型的团队，作者提出了一个“外科医生”的模型，即：

将整个系统（项目）划分为若干子系统，每一部分由一个独立的团队承担，每个团队采取类似外科手术的操作方式进行开发：一个外科医生（首席程序员，有决定权），护士（副手，熟悉系统，和别的团队沟通交流），管理员（控制财务、人员、工作地点等的机构管理），编辑（文档维护），程序员，测试员，专家，其他人员（……）

通常对10人左右的编程团队而言，上述角色分工就足够了，其中管理员和专家可以同时为多个团队服务。团队间的协调，也因人数（外科医生）的减少而提高了效率。

这样就提出了一些新的问题：如何保证整个系统设计概念的完整性？

more…

注：

本文为《我的读书笔记之人月神话》系列的第一篇，欢迎指正。

=============================================================

文章的开头是很美的一段：

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个月也可以完成。通俗的来讲，就是效率（或者说进度）会随着人数的增派而相应提升，从而缩短了整体的时间。事实上，在阅读此书之前，排除一些细小因素（比如人员个体差异等），我大体上也是这么想的。

不成立的原因有很多，作者给出了如下几点（每项后面的是我的注解，下同）：

1. 项目时间依赖于顺序上的限制

确实如此，但如果每个环节上都增派了人手，似乎对进度提升还是有帮助的。

2. 人员培训和交流的时间更多

这个就是我所说的个体差异了。但是交流成本的增加确实是我事先没有想到的。

3. 有些任务是不能拆解的，添加人手对进度没有帮助

碰到过类似情况，有一个任务在身，Leader分配了另外一人来帮忙，结果给他解释的功夫自己做完都足够了。

4. 人员的增加会引起模块的重新划分，从而导致测试的延长

没有想到过，但是觉得很有道理。

当然，对于何时成立的情况作者也给出了说明（如图所示）：

more…

《The Mythical Man-Month》，说起来这本书已经耳闻很久了，最近才有心思静下来阅读。这里将会收录一些在此过程中的摘录和心得体会，未必正确，仅供参考。

作者：
Frederick P.Brooks.Jr.

简介：

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的简介，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范……

//以下列表会持续更新直到阅读完毕

1. 《人月神话》读书笔记之一：进度
2. 《人月神话》读书笔记之二：效率
3. 《人月神话》读书笔记之三：执行
4. 《人月神话》读书笔记之四：规模