读了《人月神话》

《人月神话》
32周年中文纪念版
[美] 弗雷德里克 · 布鲁克斯 著
UMLChina 翻译组 汪颖 译

随着技术的发展，部分观点已不适用于现在的环境。但是核心观念依然适用。
新技术解决了很多实现软件系统时的困难，但设计系统的困难依然存在。

 

问题

大型系统开发中，只有极少数项目满足目标、进度、预算的要求。

 

原因

进度安排不合理

> 缺乏有效的估算技术，缺少跟踪和监督，没有持续估算项目

· 错误假设：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间

· 项目的时间依赖于顺序上的限制

> 进度与工作量相互混淆，通过增加人力以赶上进度

· “用人月作为衡量一项工作的规模”暗示着人员数量和时间是可以相互替换的

· 人数和时间互换仅适用于“某个任务可以分解给参与人员，并且他们之间不需要相互的交流”

· 人员增加导致沟通成本增加，人员的最大数量依赖于独立子任务的数量

沟通成本：重新分配任务、培训新人、额外的相互沟通

 

解决方案

$ 外科手术式队伍

> 大型项目的每个部分由一个团队解决，该团队以类似外科手术的方式组建。由一个人来完成问题的分解，其他人给予他所需要的支持。只需协调各团队中“外科医生”的思路——确定整个系统的概念完整性

> 少数人设计系统（贵族专制统治）

· 系统设计必须由一个人或非常少数互有默契的实现，以确保概念完整性

· 设计与实现分工

~ 可能导致：设计的功能过多，对实际情况中的成本考虑太少

~ 解决方法：设计者和实现者之间彻底、谨慎、和谐的交流

$ 贯彻执行系统概念设计

> 文档化的规格说明

· 形式化定义（精确定义系统设计）

> 不同层次的会议

> 多重实现（倒逼定义更整洁规范）

> 沟通日志（设计者记录实现者询问，整理合并后分发给实现者）

> 独立的测试组按照系统设计测试产品

$ 改善团队交流

> 结构良好且实时更新的项目工作手册、良好的组织架构）

$ 选择合适的语言、工具、文档（与时俱进）

$ 采用容易剔除bug的设计，加强测试

$ 控制系统各部分的规模

$ 考虑项目各阶段的变更（唯一不变的是变化本身）

$ 设定合适的里程碑，并对其跟踪监督

$ 跟踪维护项目文档

 

没有银弹

$ 没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。

> 软件开发中困难的部分——固有的概念复杂性

> 困难是决定说什么，而不是怎么说

> 软件系统无法规避的内在特性：复杂度、一致性（需要兼容各种场景）、可变性、不可见性（软件的客观存在不具有空间的形体特征）

$ 最有希望成为银弹的技术——快速原型化系统的方法和技术

> 把开发作为迭代需求过程的一部分

$ 其它技术/方法：增量式开发（类似快速原型化）、直接购买软件、聘用培养优秀的设计人员