人月神话笔记

结合实际，做点笔记！》》》》》》

第一章：焦油坑

      1.项目是也有困难，也有乐趣的！（当然有队友有指导更好）

     2.写程序不难。构建系统需要产品化，文档化，工作量大概是写程序的9倍！

     3.不断完成对任务调整；通过完成任务才能获取到权威。 （哈哈哈，打怪升级）

---

第二章：人月神话

      1.时间进度安排在一个项目当中至关重要！其中里程碑的设置和任务追踪是重要手段。

     2.人员之间协作肯定增加沟通成本！

     3.Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。

---

第三章：外科手术队伍

      1.小型，精干队伍最好------（思维尽量可能少）

     2.一位主要成员进行对整个项目的构思，其他成员负责协作生产，减少交流和沟通的工作量

---

第四章：贵族专制，民主政治和系统设计

     1.概念完整性是系统设计中最重要的的考虑因素！！！！！

     2.为了获取概念的完整性，系统必须是由一个人或者一个小团队完成设计工作！ （符合外科手术队伍的做法

      为了保证这个，专制也没有所谓！作为Leader，需要对这个负责，考虑方面方面。作为开发，必须全力辅助

      leader完成他的想法。）

---

第五章：画蛇添足

      1.尽早的沟通交流和持续沟通能够使结构师有较好的成本意识，使开发人员获得设计的信心，

     并且不会混淆各自的责任分工。（前期没有沟通和任务分配，团队根据变化的需求来协调工作，

     从而导致团队成员不清晰自己责任；架构工作与开发人员分离，增加无谓的学习成本）

---

第六章：贯彻执行

      1.出于精确性的考虑，我们必须采用形式化地设计定义（各种需求文档，设计文档）；

     同样，我们需要记述性定义来加深理解（日志，会议记录）

     2.项目经理最好的朋友就是他每天要面对的对手---独立的产品测试机构/小组（呵呵，我们没有测试，呵呵）

---

第七章：为什么巴比伦塔会失败？

      1.巴比伦塔项目失败的原因是因为缺乏交流以及交流的结果---组织。（组织太松散，也没有做到单一问责，

     结果就是一问三不知，各个人都说不是我的问题。

     项目开始的时候干系人管理没做好，关键路径分析没做，就有了这样一拖再拖的情况。

     场景：

          开发：”这个任务可能有点困难。。。“

          老板：”没问题的啊！如果真有问题，找XXX，他都知道的！“

          开发：”好的，这个东西先等XXX为我们准备好“

     几天后：

          老板：”任务完成情况怎样？“

          XXX：”这个不不太清楚喔，等我去问问“

          老板：”反正这个不是难事，看看教科书就可以找到了，不要这个地方拖时间，快步前进“

          开发：”这个在关键路径上的啊，没有怎么做“

     又过了几天：

          老板：”项目进展如何？“

          开发：”等XXX的资料啊！“

          XXX：”掌握了一些资料，先拿去看看吧“

     时间过去两周了！也没做出来什么～

      2.”因为左右不知道右手在做什么，从而进度灾难，功能的不合理和系统缺陷纷纷出现。“由于其他人的各种

     假设，团队成员之间的理解开始出现偏差！（这个就是为什么我现在都做的一个事情：接到任务后，不是马上做，

     而是通过邮件，复述一次任务，通过图表或者规格的方式，确认任务！！）

     另外，如果对团在办公室方放置一个DashBoard, What a wonderful world!不过团队没有这个理念，也就算了。

     反正在信息共享方面，基本上就是60年代的水平。

     3.”每一位团队成员都应该了接所有的材料（工作手册）。“想说的是，每个团队成员都应该能够看到

     所有的材料，网页即可以满足要求 （但是！！但是！！我们网页没有啊，哪里有人去维护wiki,只有一个dropbox

     东西也不全，需要的时候再去向负责的人一个一个去问！这效率，这些做，啧啧！）

     3.1什么！还想实时更新，我也只能呵呵后了！人家70年代用纸介质都能做到事情，现在随便上一个团队协作网站（还免费！！）

     都能做到事情，我们就是没人做！

     4.人力划分（division of labor）和限定职责范围（specializtion of function）。嗯嗯！！

     组织的交流是网状的，不是树状的。嗯嗯！！

---

第八章：胸有成竹

      1.程序开发呈程序规模的指数增长。 看出来了。。。。

---

第九章：削足前进

      1.大型团队中，各个小组倾向于不断局部优化（你们这帮程序的。。），以满足自己的目标，而较少考虑对

     用户的整体影响。这种方向性的问题是大型项目的主要危险！

---

第十章：提纲携领

      1.每个文档本身就可以作为检查列表或者数据库(数据库？？？)

     2.项目经理的基本职责是使每个人都向着相同的方向前进。项目经理的日常工作是沟通，而不是做决定

     （哈哈哈，还做那种不知道描述的UI设计阿，我们项目经理，给跪了）

---

第十一章：未雨绸缪

      1.对于编程产品而言，这样的中间步骤同样是必须的。 （测试步骤）

     2.有这么一个说法：开发人员交付的是用户的满意程度，而不仅仅是实际的产品

     3.前进两步，后退一步--程序维护（别傻了，在这里前进都没时间，还后退。。当然也没人意识到后退）

     4.对于一个广泛使用的程序，起维护成本通常是开发成本的40%或者更多。

    （为什么我们的移动端程序一个星期就开发出来了啊！没人用咯～～）

---

第十二章：干将莫邪

     这章讲技术，没太多说的。

---

第十三章：整体部分

     1.在编写任何代码之前，规格说明必须提交给外部测试小组，以详细检查说明的完整性和明确性。开发人员自己

     无法完成这项工作。（哈哈哈哈，还外部需求评审，内部评审都随便搞。当然，我们这里开发人员也评审不了，

     都是业务说了算）

     2.必须有人对变更和版本进行控制和文档化（当年我也做过SCM！）,团队成员应使用开发库的各种受控拷贝工作。

     3.每日构建！ （哈哈哈哈，一周构建？或者说随时构建，或者说老板想构建就构建？哈哈哈哈）

---

第十四章：祸起萧墙

     1.根据一个严格的进度表来控制大型项目的第一步是指定进度表，进度表由里程碑和日期组成。（咋一看，我们这个

     还有，但是总是觉得哪里不对劲，一时说不上？太粗凑了，不可测不可量化任务的原因？拍脑袋的原因？）

     2.里程碑必须是具体的，特定的和可度量的事件。（符合，是因为里程碑测量太泛了，可以分开几个方面，所以导致     

     实际上里程碑不能度量）

     3.不存在关键路径进度的替代品，使人们能够辨别计划偏移的情况。（沉痛的教训！不做关键路径，就不知道需要什么资源

     关键资源没有，工作完全不能开展！老板拍桌，开发呵呵也没用，就是只能干等。）

     4.PERT图为那个使人泄气的借口，“其他的部分反正会落后”提供了答案。（好吧，这个不太理解，可能需要到PERT的项目

     看过才知道是怎么一回事）

     5.状态的获取是困难的，因为下属有充分理由不提供信息共享。

          1）怕骂不告诉你

          2）就不想合作

          3）估计自己能搞掂不麻烦你

          4）老板对于坏消息的态度也非常影响

---

第十五章：另外一面

     1.最小化文档负担的三个关键思路

        1）声明关于文档信息

        2）使用空格和嵌套，让文档好看

        3）段落注释，插入必要的笔记