人月神话笔记

Notes 人月神话 Project Management

创建时间:2022-01-31 14:34

字数:2.8k 阅读:

评论:

软件活动的根本任务
- 打造构成抽象软件实体的复杂概念结构
软件活动的次要任务1
- 使用编程语言来表达这些抽象实体，在空间和时间的限制下将他们映射成机器语言

一个相互牵制的概念结构是软件实体必不可少的部分，它包括：数据集合，数据条码之间的关系，算法以及功能调用等。这些要素本身是抽象的，体现在不同的表现形式下的概念构造是相同的。

软件系统无法规避的内在特性
- 复杂度
  - 元素之间的交互，使得软件的复杂度比非线性增长要高得多
  - 软件的复杂度是根本属性，抽掉复杂度的软件实体描述实际上也去掉了一些本质属性。所以我们无法做太多的简化的
- 一致性
  - 软件工程当中没有太多的一致性，更多的核心开发工程师本身的理念
- 可变性
  - 软件中的功能，功能属性很容易感受到变更的压力
- 不可见性
  - 软件是不可见以及无法可视化的
    - 例如几何抽象是强大的工具，包括机械制图，以及化学分子模型，但是软体的客观存在不具有空间的形体特征

编程系统产品(Programming Systems Product) 开发的工作量是供个人使用的，独立开发的构件程序的9倍。估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又加强了3倍的工作量，这些高成本的构件在根本上是相互独立的
编程行业满足了我们内心深处的创造渴望和愉悦所有人的共有情感，提供了5种乐趣
- 创建事物的快乐
- 开发对其他人有用的东西的乐趣
- 将可以活动，相互齿合的零部件组装成类似迷宫的东西，这个过程体现出的令人神魂颠倒的美丽
- 面对不重复的任务，不断学习的乐趣
- 工作在如此易于驾驭的介质上的乐趣—— 纯粹的思维活动 —— 其存在，移动和运转方式完全不同于实际物体
同样，这个行业有一些内在固有的烦恼
- 将做事方式调整到追求完美是学习编程的最困难部分
- 权威不等同于责任；真正的权威来自于每次任务的完成
- 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外
- 人们通常希望项目在接近结束的时候，软件项目能收敛得快一些，然而，情况却是越接近完成，收敛得越慢
- 产品在完成前总面临着陈旧过时的威胁，只有实际需要的时候，才会用到最新的设想
缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大
所有编程人员都是乐观主义者，一切都将运作良好
由于编程人员通过纯粹的思维活动来开发，我们期待在实现过程当中不会碰到困难。但是我们本身的构思是会有缺陷的，因此总会有bug
围绕着成本核算的估计技术，混淆了工作量和项目进展。人月是危险的，因为它暗示着人员数量和时间是可以相互替换的。
在若干人员中分解任务会引发额外的沟通工作量 — 培训和相互沟通。
Brooks法则：为进度落后的项目增加人手，只会使得进度更加落后
- 增派人手可能增加的工作量
  - 任务重新分配本身和所造成的工作中断
  - 培训新人员
  - 额外的相互沟通
同样有两年经验而且在受到同样培训的情况下，优秀的专业程序员的生产力是较差的程序员的10倍。
一位首席程序员，类似于外科手术队伍的团队架构提供了一种方法—— 既能获得由少数头脑产生的产品完整性，又能够得到多位协助人员的总体生产率，还彻底减少了沟通的工作量。
概念完整性是系统设计中最重要的考虑因素
- 为了获得概念的完整性，设计必须由一个人或者具有共识的小型团队来完成
- 为了获得概念的完整性，就必须有人控制这些概念，这实际上是一种无需任何歉意的贵族专制统治
功能和理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能
尽早交流和持续沟通能够使得结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工
交流
- 巴比伦项目的失败是因为缺乏交流以及交流的结果 —— 组织
- 因为左手不知道右手在做什么，从而进度灾难，功能的不合理，以及系统的缺陷纷纷出现。由于存在对其他人的各种假设，团队成员之间的理解开始出现偏差了。
项目工作手册
- 项目工作手册是对项目必须产生的一些列文档进行组织的一种结构
- 每一个团队成员应该了解所有的材料
- 实时更新很重要
- 工作手册的使用者应该将注意力集中在上次阅读之后的变更以及关于这些变更重要性的评述上
- 每个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口
组织架构
- 团队组织的目标是为了减少必要的交流和协作量
- 为了减少交流，组织结构包括了人力划分(Division of labor) 和限定职责范围(Specialization of function)
- 组织内的交流是网状的，而不是树状结构，因此所有的特殊组织机制都是为了进行调整，来克服树状组织结构中交流缺乏的困难
在大型团队当中，各个小组倾向于不断的去做局部优化，来满足自己的目标，而比较少的考虑对用户的整体影响。这种方向性的问题是大型项目的主要危险
从系统整体出发和面向用户的态度是软体编程管理人员最重要的职能
文档的规范，目标，用户手册，内部文档，进度，预算，组织机构图，和工作空间分配
- 每个文档本身就可以作为检查列表或者数据库
项目经理的基本职责是使每个人都向着相同的方向前进
项目经理的主要日常工作是沟通，而不是做出决定；文档使得各项计划和决策在整个团队范围内得到交流
用户的实际需要和用户感觉会随着程序构建，测试和使用而发生变化。
对于文档，需要采用定义良好的数字化版本将变更量子化
程序员不愿意为设计书写文档，不仅仅是因为惰性，更多的是源于设计人员的踌躇 —— 要为自己尝试性的设计决策进行辩解。
只要管理人员和技术人员的天赋允许，老板必须对他们的能力培养给予极大的关注，使得管理人员和技术人员具有互换性；特别是希望在技术和管理角色之间自由的分配人手的时候
具有两条晋升线的高效组织机构存在着一些社会性的障碍，人们必须警惕并积极的同它做持续的斗争
程序维护基本上不同于硬件的维护：主要由各种变更组成，入修复设计缺陷，新增功能，或者是使用环境或者配置变换引起的调整
对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或者更多
Campbell指出了一个显示产品生命期中每月bug数的有趣曲线，其先是下降，后面是上升
每次修复之后，必须重新运行先前所有的测试用例，确保系统不会以更隐蔽的方式被破坏
所有的修改都倾向于破坏系统的架构，增加了系统的混乱程度(熵)。即使是最熟练的软件维护工作，也只是延缓了系统退化到不可修复的混乱状态的进程，以致必须重新进行设计。
项目经理应该制定一套策略，并为通用工具的开发分配资源，与此同时，还必须意识到专业工具的需求
调试是系统编程中较慢和较困难的部分，而漫长的调试周转时间是调试的祸根
在编写任何代码之前，规格说明必须提交给外部的测试人员，来详细的检查说明的完整性和明确性。开发人员自己无法完成这项工作。
开发大量的辅助测试平台和测试代码是很值得的，代码量甚至可能有测试对象的一半
项目是怎么样被延迟了整整一年的时间的….. 一次一天。一次一天的进度落后比重大灾难更难以识别，更不容易防范和更加难以弥补。
根据一个严格的进度表来控制大型项目的第一个步骤是制定进度表，进度表由里程碑和日期组成
- 里程碑必须是具体的，特定的，可度量的事件，需要能够进行清晰的定义
慢性进度偏离是士气杀手。
状态的获取是困难的，因为下属经理有充分的理由不提供信息共享
老板的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告，毫无惊慌地接收报告，决不越俎代庖，将能够鼓励诚实的汇报。
必须有评审机制，使得所有成员可以通过它了解真正的状态。出于这个目的，里程碑的进度和完成文档是关键。
程序修改人员所使用的文档中，除了描述事情如何，还应当阐述它为什么那样。对于加深理解，目的是非常关键的，即使是高级语言的语法，也不能表达目的

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com