《人月神话》-第19章-20年后的《人月神话》
文章目录
核心观点—概念完整性和结构师
概念完整性。一个整洁、优雅的编程产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。用户所感受到的产品概念完整性是易用性中最重要的因素。
结构师。委派一名产品结构师是最重要的行动。结构师负责产品所有方面的概念完整性,这些是用户能实际感受到的。结构师开发用于向用户解释使用的产品概念模型,概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者,同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时,其卓有成效地体现用户的利益。这个角色是全职工作,只有在最小的团队中,才能和团队经理的角色合并。结构师就像电影的导演,而经理类似于制片人
将体系结构和设计实现、物理实现相分离
结构师方案的重用。对于大型系统,即使所有实现方面的内容都被分离出去,一个人也无法完成所有体系结构的工作。所以,有必要由一位主结构师把系统分解成子系统,系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。每个部分拥有自己的结构师,他必须就体系结构向主结构师汇报。显然,这个过程可以根据需要重复递归地进行。
概念完整性是产品质量的核心
开发第二个系统所引起的后果盲目的功能和频率猜测
为大型用户群设计。个人计算机革命的一个结果是,至少在商业数据处理领域中,客户应用程序越来越多地被商用软件包所代替。而且,标准软件包以成百上千,甚至是数百万拷贝的规模出售。源厂商支持性软件的系统结构师必须不断地为大型的不确定用户群,而不是为某个公司的单一、可定义的应用进行设计。许许多多的系统结构师现在面临着这项任务。
设计通用工具比设计专用工具更加困难,这是因为必须为不同用户的各种需要分配权重。
盲目的功能。对于如电子表格或字处理等通用工具的结构师,一个不断困扰他们的诱惑是以性能甚至是易用性为代价,过多地向产品添加边界实用功能。
功能建议的吸引力在初期阶段是很明显的,性能代价在系统测试时才会出现。而随着功能一点一点地增加,手册慢慢地变厚,易用性损失以不易察觉的方式蔓延。
定义用户群。用户群越大和越不确定,就越有必要明确地定义用户群,以获得概念完整性。设计队伍中的每个成员对用户都有一幅假想的图像,并且每个设计者的图像都是不同的。结构师的用户图像会有意或者无意地影响每个结构决策,因此有必要使设计队伍共享一幅相同的用户图像。这需要把用户群的属性记录下来,包括:
- 他们是谁;
- 他们需要(need)什么;
- 他们认为自己需要(need)什么
- 他们想要(want)的是什么。
频率。对于任何软件产品,任何用户群属性实际上都是一种概率分布,每个属性具有若干可能的值,每个值有自己的发生频率。结构师如何成功地得到这些发生频率?对并未清晰定义的对象进行调查是一种不确定和成本高昂的做法。经过很多年,我现在确信,为了得到完整、明确和共享的用户群描述,结构师应该猜测(guess)或者假设(postulate)一系列完整的属性和频率值
总结:为用户群的属性明确地记载各种猜测。清晰和错误都比模糊不清好得多。
图形界面的成功
通过类比获得的概念完整性。例如：使用指针选择图标——对人手拾起东西的模拟。
命令表达和双光标的问题。
用户功能和易用性
从新手向熟练用户的逐渐过渡
由于实施强制性的体系结构,可成功地实现设备的直接整合。跨应用概念完整性的巨大价值
没有构建舍弃原型——瀑布模型是错误的
最大的错误：隐含地假设了使用传统的顺序或者瀑布开发模型
瀑布模型的第二个谬误是它假设整个系统一次性被构建——必须存在逆向移动
增量开发模型更佳——逐进地精化
构建闭环的框架系统
首先应该构建实时系统的基本轮询回路，为每个功能提供子函数调用（空的）
在每个阶段，我们都拥有一个可运行的系统。
在每个功能基本可以运行之后，我们一个接一个地精化或者重写每个模块——增量地开发
我们在所有时刻都拥有一个可运行的系统,因此:
- 我们可以很早就开始用户测试
- 我们可以采用按预算开发的策略,彻底保证不会出现进度或者预算超支的情况(以允许的功能牺牲作为代价)。
Parnas产品族
Microsoft的“每晚重建”方法
在我们第一次发布产品之后,我们会继续发布后续版本,向已有的可运行系统添加更多的功能。为什么最初的构建过程要不一样呢?因此,从我们第一个里程碑开始(第一次发布有三个里程碑),我们每晚重建开发中的系统(以及运行测试用例)。该构建周期成了项目的“心跳”。每天,一个或多个程序员一测试员队伍提交若干具有新功能的模块。在每次重建之后,我们会获得一个可运行的系统。如果重建失败,我们将停止整个过程,直到找到问题所在并进行修复。在任何时间,团队中的每个人都了解项目的状态。
增量式开发和快速原型
Harel将原型精彩地定义成:
仅仅反映了概念模型准备过程中所做的设计决策的一个程序版本,它并未反映受实现考虑所驱使的设计决策
关于信息隐藏,Parnnas是正确的,我是错误的
- 面向对象
- ADT
- 继承
人月到底有多少神话色彩?Boehm的模型和数据
无论安排多少人手,几乎没有任何项目能够在少于3/4的计算出的最优时间内获得成功!
人就是一切
人件。它所表达的观点是:“我们行业的主要问题实质上更侧重于社会学(sociological)而不是科学技术( technological)。”它充满了很多精华,如“管理人员的职责不是要人们去工作,而是创造工作的可能。”它涉及了如空间、布置、团队的餐饮等世俗的主题。 DeMarco和Lister在Coding War Games项目中提供的数据显示,相同组织中开发人员的表现之间以及工作空间同生产率、缺陷水平之间存在令人吃惊的关联
比如：顶尖人员的空间更加安静、更加私人、保护得更好以免受打扰
项目转移。 DeMarco和 Lister对团队融合给予了相当大的关注。团队融合是一个无形的,却非常关键的特性。我观察到,很多地点分散的公司,把项目从一个实验室转移到另一个。我认为,其忽视了团队融合这个管理中非常重要的因素。
放弃权利的力量
Microsoft的 Jim McCarthy向我描述了他在解放团队方面的经验:
每个队伍(30~40人)拥有自己的任务、进度,甚至如何定义、构建发布的过程。团队由4或5位专家组成,包括开发、测试和书写文档等。对争论进行仲裁的不是老板,而是团队。我简直无法形容授权和由团队对项目自行负责成功与否的重要性
(近年来)关键的措施是将权力向下委派。改进的质量、提高的生产率和高涨的士气,这就像是魔术!我们的小型团队,没有中心控制。团队是流程的所有者,并且必须拥有一个流程。他们有不同的流程。他们是进度计划的所有者,但能感受到市场的压力。这种压力导致他们使用和利用自己的工具
最令人惊讶的新事物是什么?数百万的计算机
微型计算机革命改变了每个人使用计算机的方式
微型计算机革命改变了每个人开发软件的方式
全新的软件产业——塑料薄膜包装的成品软件
传统软件产业。在1975年,软件产业拥有若干可识别的但多少有些差异的组成部分,如今它们依然存在:
计算机提供商:提供操作系统、编译器和一些实用程序;
- 应用程序用户:如公共事业单位、银行、保险公司和政府机构等,它们为自己使用的软件开发应用程序包;
- 定制程序开发者:为用户开发私用软件包,这类承包商大多数工作在国防项目上,这些项目的需求、标准和行销步骤都是与众不同的;
- 商业包开发者:那个时候是为专业市场开发大型应用,如统计分析软件包和CAD系统等。
操作系统世界已经统一了
塑料薄膜包装的成品软件产业
买来开发——使用塑料包装的成品软件包作为构件
元编程。 Hypercard stacks、 Excel模板和 Minicad函数的开发有时被称为元编程( metaprogramming),为部分软件包用户进行功能定制的过程。
我们可以识别出四个层次的软件成品用户。
- 直接使用用户。他们以简便直接的方式来操作,对设计者提供的功能和接口感到满意
- 元程序员。在单个应用程序的基础上,使用已提供的接口来开发模板或者函数,主要为最终用户节省工作量
- 外部功能作者,向应用程序添加自行编制的功能。这些功能本质上是新应用语言原语,调用通用语言编写的独立模块。这往往需要命令中断、回调或者重载函数技术,向原接口添加新功能
- 元程序员,使用一个或多个特殊的应用程序,作为更大型系统的构件。他们是需求并没有得到满足的用户群。同时,这也是能在构建新应用程序方面获得较大收获的用法。