EdmondFrank's 时光足迹

この先は暗い夜道だけかもしれない それでも信じて進むんだ。星がその道を少しでも照らしてくれるのを。
或许前路永夜,即便如此我也要前进,因为星光即使微弱也会我为照亮前途。
——《四月は君の嘘》

重读人月神话



重读《人月神话》

何为《人月神话》?

今天,偶然地重读了一遍《人月神话》。在IT领域中,即使这本书出版距今已经超过十年,但其中的道理依旧盛行。

《人月神话》虽然是布鲁克斯博士在IBM公司研发并管理System/360计算机家族和OS/360软件支持包期间的项目管理经验,但是其经典程度堪称软件开发项目管理的典范。

什么成就了它的经典

翻开《人月神话》这本书的第一感受,这边书不像以往文绉绉的项目管理或软件工程手册。作者用他切身的经验,结合自己精彩的文笔,写出了一本有温度的指导。

书中的很多问题和案例都直击了一个软件开发流程当中出现的情景。作者以一些生动的比喻更为形象的让读者身感同受。

书中的精炼

前车之覆,后车之鉴。

在执行项目或任务过程中,一味地添加人员并不能加快项目的进度。
因为软件开发本质上是一项系统工作——错综复杂的关系下实践、沟通、交流的工作量非常之大,它很快就消耗了任务分解节省下来的个人时间。从而,添加更多的人手,实际上是延长了而不是缩短了时间进度。

研究表明,效率高和效率低的实施者之间个体差异非常大,经常能够达到数量级水平。

系统设计之中,概念的完整性应该是最重要的考虑因素,为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进。

简洁和直白都来自概念的完整性。在语法上,每个部分应使用相同的技巧;在语义上,应具有同样的相似性。因此,易用性实际上需要设计的一致性和概念的完整性。

在等待时,实现人员应该做什么?
整个创造性活动包括三个独立的阶段:体系结构、设计实现、物理实现,实际情况中,他们往往可以同时开始和并发进行。

坚持至少拥有两个系统或版本以上的开发设想,避免在设计第二个系统的时候就出现过分设计。

文档化的规格,手册不仅要描述包括所有界面在内的用户可见的一切,还要避免描述用户看不见的事物。后者是编程实现人员的的工作范畴,其设计和创造是不应该被限制的。

贯彻执行,计划书写的再完善,没有贯彻执行也是一张白纸而已。

巴比伦塔的管理教训:大型编程项目中的交流和组织能力非常重要。

团队之间的交流沟通方案:
非正式途径:电话、短信、邮件、一切即时通讯手段。
项目会议:常规会议,进度会议。
工作手册及项目文档:准备好开发相关的手册和交互文档。

团队组织的目的是减少所需要的交流和合作的数量,其最好的方法是人力划分和职责限定。

实践是最好的老师,但智者还能从其他地方有所收获。

工作量 = 常数 x 指令数量1.5次方

使用适当的高级语言,编程的生产率可以提高5倍。

书面记录决策是必要的。只有记录下来,分歧才会明朗,矛盾才会突出。书写这项活动需要上百次的细小决定,正是由于它们的存在,人们才能从令人迷惑的现象中得到清晰,确定的策略。

普遍的做法是,选择一种方法,试试看;如果失败了,没关系,再试试别的方法。不管怎么样,重要的是先去尝试。

在项目开发中应该构建 “试验性工厂” 和 “产品” 这两个步骤,不要把产品原型发布给用户。对于大多数项目而言,第一个开发的系统并不合用,它可能太慢、太大或难以使用,这样要解决所有的问题除了重新开始以外,没有其他的办法。

系统软件开发是 “减熵” 的过程,所以它本身是处于亚稳态的。软件维护是 “增熵” 的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。

系统各个组成部分的开发者都会做出一些假设,而这些假设之间的不匹配是大多数致命和难以察觉的bug的主要来源。

模块分割、模块独立、结构化编程、构件单元测试是避免系统性bug的良好手段。

需要什么样的文档?
(1)使用程序:每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很少总结性的内容,无法达到用户的要求,就是像描绘了树木,形容了树皮和树叶,但却没有一副森林的图案。
(2)目的:主要功能是什么?开发程序的目的是什么?
(3)环境:程序运行在什么样的机器、硬件配置和操作系统上?
(4)范围:输入的有效范围是什么?允许显示的合法输出范围是什么?
(5)实现功能和使用的算法:精确地阐述它做了什么?
(6)“输入——输出”格式:必须是确切的,完整的。
(7)操作指令:包括控制台及输出内容中正常和异常结束的行为。
(8)选项:用户的功能选项有哪些?如何在选项之间进行挑选?
(9)运行时间:在指定的配置下,解决特定规模问题所需要的时间。
(10)精度和校验:期望结果的精确程度?如何进行精度的检测?

团队在书中的倒影

我们团队一年来的开发弊端都有在书中的案例体现。

《人月神话》就像是一个个项目开发小组的倒影,项目交流成本、开发者效率的差异、开发人员各自独立的项目假设造成的隐藏bug、对项目进度的乐观预估,其中最为突出的莫过于是巴比伦塔的管理教训,沟通和有效组织的缺乏,直接拖缓了整个项目的进度。

我想,在经验中总结前进,最有效的莫过于《人月神话》开篇的第一章:前车之覆,后车之鉴。

                                            By 领沃EdmondFrank