软件工程管理——《人月神话的读书笔记》(chapter2~chapter10)
chapter 2 人月神话
在对于任务分解上，看似越多的人会减少个人工作的时间，实则不然，人员的增多会导致其他方面诸如培训和交流之间的开销的增加，导致很快会消耗掉任务分解所节省下来的时间，有时未必会减少时间。不要妄图以减少时间为目的进行相关的人员方面的变动，或是项目上的调整，提速是可以的，但是首先不要贪心，其次记住欲速则不达。不是人越多效率越高。乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。虽然从理论上来说，在系统开发的过程中错误的数量的确应该为0，事实上我们永远都不可能做到，甚至尽量减少到最低也是很难的，在测试的时候就需要花上更多的时间，虽然未必会找到最后一个bug，但是总比花的时间少要来的好得多… 当项目进度落后之后你会怎么做？作为项目经理，亚力山大啊…如果增加人手，可能造成的风险会滚雪球一样增长，通常项目管理会因为人的因素而增加太多的不确定性，这个是特别难估计的部分，或许这就是为什么项目经理也是越老越吃香的原因，可以通过经验来进行项目初期的预算估计以及项目计划的制定，但是，当有新的技术手段出现时，使用经验进行估算显然是不是用的，那么有没有一个优秀的估算模型进行计划的制定呢？？？系统开发的时间安排 1／3 计划 1／6 编码 1／4 构件测试和早期系统测试 1／4 系统测试，所有构件已完成 需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。
思考，”The Cathdral and the Bazaar”一文中提到的关于开源软件的管理方式是违背了Brooks法则的，但是仍旧能够成功，为什么？？？？
chapter 3 外科手术队伍
其实现在的大多数团队都是采用了这种开发方式进行开发，但是正如作者所提出的问题一样，如何组建一个大规模的团队是最重要的事情，并且，如果逐层按照小型队伍的组建方式进行大型队伍的建立，那么在决策阶段不可避免会产生冲突，如何解决此种冲突矛盾？如何协调各个小型团队之间的工作进度以及团队交流？这些研究表明，效率高和效率低者之间个体差异非常大，经常能够达到数量级的水平。 Mills的建议 大型项目的每一个部分有一个团队来解决，但是该队伍以类似外科手术的方式组建，并非一拥而上 10人程序开发队伍的沟通模式
chapter 4 贵族专制、民主政治和系统设计
最危险的情况就是设计的过程中程序员觉得无事可做，出于无所事事的状态，实际上对于硬件和软件平台的熟悉以及前期知识的掌握理论上应该放在这个部分进行。此时的状态应该是设计师大致设计出了系统的雏形以及确定了系统中所涉及到的相关软件技术和硬件平台，所以程序员应该可以依据此进行相关信息的搜索和知识的补足，直到完整的设计完成，开始进行编码。我主张在系统设计概念中，概念完整性应该是最重要的考虑因素。 体系结构同实现必须仔细地区分开来。体系结构陈述的是发生了什么，而实现描述的是如何实现。 对于贵族专制的问题，必须回答＂是＂或者＂否＂。就只能存在少数结构师而言，答案是肯定的…这实际上是一种无需任何歉意的贵族专制统治。
Chapter 5 画蛇添足
中国人讲的＂艺高人胆大＂，＂擅泳者溺＂大概有一点点这样的意味，一开始的时候往往小心谨慎，通常是人之常情，这会是第一个项目无论是在项目周期上还是项目具体实现上均大致符合预期发展，不会带来较大的出入的原因，在第二个项目的设计上，往往就会出现“因为有经验了，所以觉得可以根据第一次成功的背景将一些次要方案加入设计的想法。”往往会失败，不仅仅是作项目，很多事情都会是这样（难道这也有心理学的解释么哟喂…）。 所以解决这个问题的关键？如果是搭配两个结构师进行设计（一个老鸟一个新手），那么风险是降低了，但是新手一旦进行独立的真正意义上的第二个项目时间是不可避免还是会遇到同样的问题，因此项目经理或是负责人员分配的高管必须尤其注意这个问题，或者让这种第二次设计放在一个所需承担风险较小的项目中？减少因项目失败而带来的损失。或是系统评估人员需要首先对于设计出的系统方案进行评估，每一次的改进或是功能的设计划分都需要进行自习的后果评估和风险评估后才能进行实施？ …这种书果然要看实际的案例才能分析啊啊…（我果然不是PM的料（ーー；））在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会仔细谨慎地工作。 一种普遍倾向是过分的设计第二个系统，向系统添加很多的修饰功能和想法，他们曾在第一个系统中被小心翼翼地放在次要位置。
Chapter 6 贯彻执行
这一章主要讲的是文档和例会的重要性，文档是各个项目组成员之间沟通的唯一方式，例会是解决问题的好方法。在进行文档写作时需要注意的是要用至少两种语言或者形式进行描述，一种为主要描述的方法，另一种为辅助描述的方法。这样可以保证无论是开发人员还是项目组的其他人员均可对于该项目有较为准确地认识。 但是最重的项目实施完毕后很有可能与最初的设想是不一致的，此时应该尽量以机器上的代码和以测试完毕可运行的程序为准，而非强求按照文档规定进行修改，除非出入极大（我感觉这种情况不大可能发生，周例会的时候就是为了避免或者说规避这种风险的产生）。进一步根据文档的小修小改可以作为下一阶段的迭代目标以趋于理论上的美好（好吧…这又是程序员的天生乐观的气质…（ーー；））。 在文档纂写的过程中，为什么需要同一人员进行纂写呢…因为文档需要有前后的一致性和连贯性，若是多人纂写的文档最后还是交由一两人进行整理较为妥当，并且在文档纂写的过程中，最好对于相关术语单独构建编写术语表进行文档中提到的一些相关术语的解释较好（我感觉啊…大型项目还是有必要弄个，简单的搞个表格什么的，不然写到最后基本上就忘记了…个人观点）。 规范的文档其实还是蛮重要的，口头上的沟通一是没有什么规范性可言，二是口语化的东西太多，即便是书面化了都会有这样那样多样化的表达，更别说是口头的…所以吧…文档和例会这种我们平时基本不屑的东西是必不可少的，我们之所以没有感受到其重要性那是因为我们没有参与过大型项目的开发，甚至中型规模的都没有…手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节，同样的，它也是结构师主要的设计产物。 精确往往比生动更重要。 通常的周例会每周一次，每次半天。 定期组织的例会建议上为每6个月一次。解决周例会中堆积起来的问题。 当文档和机器产生冲突的时候以机器为准，因为文档更容易修改。
Chapter 7 为什么巴比伦塔会失败
巴比伦塔具备了所有的我们认为的必备条件，为什么还会失败呢。原文中是上帝制造了混淆，使得各个部落之间互相猜忌最终导致了项目的彻底失败。在实际的项目中，可以说这种混淆是不可避免会存在的，不是人为主观制造，首先一个项目在需求的获取过程中就会存在着用户与需求获取人员之间的理解差异，或许同样的一句话，经过获取人员的理解转述后就会有不一样的意义，更别说转义为书面语言正式成为文档，即便是在看文档的过程中，再规范的文档都会有令人迷惑的部分，此时就体现出了交流的重要性，团队中的每个人员都有必要进行积极的交流，以求在交流的过程中消除混淆，保证项目的正常进行。 团队之间的交流途径，通过可能的所有途径：他们还缺乏两个方面﹣交流，以及交流的结果﹣组织。工作手册不是一个严格的项目技术文档。非正式途径：电话… 会议：常规项目会议 工作手册：在项目的开始阶段应该准备正式的项目工作手册。我的理解是这个所谓的工作手册在今天看来实际上就可以说是项目的wiki（注意这本书的作者是在1986年写的啊啊啊啊）和show diff的选项。 •大型项目的组织结构它是对项目必须产出的一系列文档进行组织结构的一部分在各个职能安排何划分中，产品经理和技术主管的角色安排是最难的，通常情况下，会有几种方案：让我们考虑一下树状编程队伍，以及要使他们有效，每棵子树所必须具备的基本要素： 1、任务（a mission） 2、产品负责人（a producer） 3、技术主管或结构师（a technical director or architect） 4、进度（a schedule） 5、人力的划分（a division of labor） 6、各部分之间的接口协议（interface definitions among parts）在构建大型开发团队时，往往还是产品经理作为决策者，我们可不可以这样认为，在以后的公司诉求中，会有这么一种情况发生，就是技术主管可以先由小的项目开始进行锻炼，加上相关管理知识的学习以及在大型项目中充当副手见习的经验渐渐转型为可以胜任产品经理工作的人？ 也就是说，一个好的公司运作，不仅仅是要有好的技术人才，其实更需要的是一个产品经理对其产品进行高瞻远瞩式的决策以减少相应的损失。 综上，团队内外量好的沟通以及良好的团队架构均是一个项目能否成功的关键所在。1、技术主管和产品经理是同一个人。适用于6人左右的团队，通常这两种技术兼具的人相当少。 2、产品负责人指挥，技术主管充当左右手。这种情况相当难，很难在技术主管不参与任何管理工作的同时，建立起其在技术上的权威。 3、技术主管作为总指挥，产品经理作为其左右手。还是适用于小型团队。
Chapter 8 胸有成竹
根据Portman的数据说明我们可以看出，在项目进行过程中仅仅通过项目的技术部分的工作对于项目整体做出完全的估算是不切实际的，其中一点就是，其实对于技术工作的估算就是有很大难度的，我们通常都会有一定的偏差值，多数情况下都是过多估计了技术所花费的时间，实际上花在非技术层面上的时间更多（ーー；）•Portman的数据 日志显示，事实上他的团队仅仅用了50%的工作周来进行实际的编程和调试，估算上的失误完全可以由该情况进行解释。简言之，估算对于每个人年的技术工作时间数量作了不现实的假设。这个表示的实际上是大型复杂系统开发的现状。生产率同样的被划分为两个类别：控制程序的生产率大约是600指令每人年，语言翻译大约是2200指令每人年。总结：生产率会根据任务本身复杂和困难程度表现出显著差异。 在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的3倍，操作系统的复杂度是编译器的3倍。实际上现在大多数的程序构建均是使用高级语言完成的，极少情况下使用低级的指令语言或是机器语言。那也可以认为说是针对不同的项目，使用不同的语言进行开发也是对于生产率有一定的影响的，但是，就项目整体而言，未必会有很大的生产率上的提高，毕竟花在编程上的时间并不是最多的，这个部分也不是最难的。 这一章比较难有一个形象的认识，虽然Brooks用了大量的数据加以说明，但是因为没有参与过，也没有管理过大型的项目，因此，还是没有比较形象的认识，故，以后再慢慢回味吧，暂且只记结论。•对于常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要的注释，并可能存在错误的情况。 •使用适当的高级语言，编程的生产率可以提高5倍。
Chapter 9 削足适履
当时的系统硬件资源十分宝贵，所以在进行系统开发的时候必须详细计算好所占用的系统的硬件资源以谋取软件和硬件的一个较大的获得的利益，但是在硬件显得看上去如此廉价的今天，我们还是要注意这个问题，怎样合理地利用有限的硬件资源才是关键，浪费用户硬件资源的软件都不是好软件(<_<)，在每一次软件的计划开发中都应当是恰当地使用硬件资源，而不是无节制地浪费。•作为成本的程序空间 同任何开销一样，规模本身不是坏事，单不必要的规模是不可取的也就是说，首先还是对于项目大小最好由于个较为彻底和详细地认识，并且对每个部分能够做醋比较好的划分，再次是沟通沟通沟通，不管多大的项目还是沟通最重要。每个开发者都应当为别人，从项目整体角度考虑为最终的用户考虑，而不是一味追求技术上的创新和自己模块的最优化。对于项目经理而言，规模的控制既是技术工作的一部分，也是管理工作的一部分。 第一个道理很清楚：在制定驻留空间预算一样，应该制定总体规模的预算；在制定规模预算一样，应该制定后台存储访问的预算。 第二个道理也很清晰：在指明模块有多大的同时，确切定义模块的功能。 第三个教训，项目本身很大，缺乏管理和沟通，以至于每个团队成员都认为自己是争取小红花的学生而不是构建系统软件产品的人员。也就是说，第一个方法实际上就是在设计软件实现时将其每个部分的粒度设计的比较细，最好可以使用户独立进行定制，这样一来实际是减少了开发人员的负担，使其只需要关注小粒度的部分，设计时需要注意设计好每部分的接口即可。 第二个观点是设计公共库，最好是两个，一个是以空间换时间，另一个是以时间换空间。并且我觉得公共库的开发更符合软件重用的思想。也更容易维护。•空间技能 技能一：功能交换尺寸。 技能二：考虑空间﹣时间的折衷。实际上计算机所做的大部分的工作就是数据的处理，所以在整个处理的过程中数据结构是怎样的回直接对于程序性能的好坏有很大的影响。数据表现形式是程序的根本
Chapter 10 提纲挈领
这章的内容相当少也相当简单，主要阐述的就是文档的重要性，就和章节标题所显示的那样﹣提纲挈领，其实这就是文档主要的工作。 一开始的时候我们其实都会很疑惑文档到底是用来做什么的，甚至在很长的一段时间里面，大家都是糊差事，糊弄完文档了事，认为文档是一个十分无关紧要的鸡肋，实际上并非如此，我们认为其无关紧要，甚至很多时候都是弄完代码之后再进行文档的补足，表面上看起来可以交出比价理想的差事，实际上是因为我们所参与的项目规模十分十分的小（可以用微型来解释么(<_<)）。 在大型，其实是比较正式的一个项目中，我们要写的文档其实是十分必要而且作用也是十分重要的，规定了软件大致的骨架，其实也是团队内部同志们之间进行交流的一项较为有利的依据。 最近的敏捷也好，极限也好，有同志们简单的觉得是不需要写文档的，代码即文档。我觉得不妥，除非队员之间默契度十分的高，或者是项目各项需求及边界规范的十分明确，大家不会有任何歧义，否则文档就是必要的，哪怕是只言片语…又或者是，除非代码风格十分优秀，可以保证注释的质量相当的高，另当别论。•为什么要有正式的文档 首先，书面记录决策是很有必要的。只有记录下来，分歧才会明朗，矛盾才会突出。 第二，文档能够作为同其他人的沟通渠道。 最后，项目经理的文档还可以作为数据基础和检查列表。