《人月神话》有感,好书,推荐

      我本来分到的书是《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 张宁

posted @ 2011-10-25 00:11 OMG! 日记 阅读(...) 评论(...) 编辑 收藏