我本来分到的书是《Agile project management with scrum》，奈何读了一章着实没有感觉，可能项目经历不够，真的很难站在高的角度去看懂该书，所幸栋梁那儿多了一本人月神话，光看封面和插图就很生动，于是就换了，以下是一点小小感悟。

      《人月神话》是软件工程方面的一本经典著作，作者布鲁克斯（Frederick P. Brooks）被誉为“IBM System/360之父”，他曾是这一系统的项目经理，后来在设计期任360操作系统的项目经理。由于这一工作，他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年，他还荣获美国计算机领域最高奖图灵奖。

　　 书中很雷到我的是Brooks提出的这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所以软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。就拿我们这次做的学术搜索会议助手项目来说，本来我们的scrum开始的就很早，初期进展也都不错，可哪怕是在这样大好的情况下，最终我们还是留下了两三个task没有得到很好的完成而被拖到beta版本中。

　　 书中又说到，系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。我们前期的准备就发现，经过一开始的头脑风暴后，确实需要一两个强大的人来扮演架构师的角色，很幸运的是，我们拥有像夏睿和海峰这样的队友。

　　 第七章说到了巴别塔项目失败的原因是缺乏交流和组织。书中说缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构，及时更新，每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式，它是可行的，但并不一定是最有效的，因为有利于交流的组织方式应该是网状的，但是完全的网状结构因为交流量太大，也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足。在一个大的项目中，有两个角色是很重要的，一个是生产者（producer），就是管理经理，另一个是技术总监（经理）。管理经理负责组织团队、分配工作、创建日程表等。很多时候，他建立内部交流和报告的模式，但是很多时候负责团队之外的交流。技术经理构造设计，确定模块，保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少，实干家也很少，有思想家特质的实干家是最少的。只有在3至6人的小项目中，管理经理和技术经理才可以是一个人。在更大的项目中，这两个角色应该由不同人担任，因为两者都需要全身心投入。也许我们的项目里，Cherry和Xiaolin，我和夏睿就分别扮演了这样的角色？另外虽然从一开始我们就很注重成员间的沟通，同时项目规模也很小，可仍然遇到了大家对某一功能认知不一致的问题，可以见得，巴别塔不能通天，沟通真的只能改进，问题实在不可避免。

　　 另外一个让我印象深刻的观点是：要保证一个项目的进度被大幅度推迟，制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达，要么没有到达，不应该是80%到达的。而我的经验是，制订进度表非常重要，而且要求制定者有很强的技术背景，这样才能对可能碰到的问题和可能花掉的时间做出更准确的估计，我们这次的项目中出现了burn down图的正斜率，希望通过学习和锻炼再也消失不见。

　 以上就是粗读《人月神话》的一点愚见，好书，以后有时间一定再读。BY 张宁