《人月神话》
32周年中文纪念版
[美] 弗雷德里克 · 布鲁克斯 著
UMLChina 翻译组 汪颖 译
随着技术的发展,部分观点已不适用于现在的环境。但是核心观念依然适用。
新技术解决了很多实现软件系统时的困难,但设计系统的困难依然存在。
问题
大型系统开发中,只有极少数项目满足目标、进度、预算的要求。
原因
进度安排不合理
> 缺乏有效的估算技术,缺少跟踪和监督,没有持续估算项目
· 错误假设:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间
· 项目的时间依赖于顺序上的限制
> 进度与工作量相互混淆,通过增加人力以赶上进度
· “用人月作为衡量一项工作的规模”暗示着人员数量和时间是可以相互替换的
· 人数和时间互换仅适用于“某个任务可以分解给参与人员,并且他们之间不需要相互的交流”
· 人员增加导致沟通成本增加,人员的最大数量依赖于独立子任务的数量
沟通成本:重新分配任务、培训新人、额外的相互沟通
解决方案
$ 外科手术式队伍
> 大型项目的每个部分由一个团队解决,该团队以类似外科手术的方式组建。由一个人来完成问题的分解,其他人给予他所需要的支持。只需协调各团队中“外科医生”的思路——确定整个系统的概念完整性
> 少数人设计系统(贵族专制统治)
· 系统设计必须由一个人或非常少数互有默契的实现,以确保概念完整性
· 设计与实现分工
~ 可能导致:设计的功能过多,对实际情况中的成本考虑太少
~ 解决方法:设计者和实现者之间彻底、谨慎、和谐的交流
$ 贯彻执行系统概念设计
> 文档化的规格说明
· 形式化定义(精确定义系统设计)
> 不同层次的会议
> 多重实现(倒逼定义更整洁规范)
> 沟通日志(设计者记录实现者询问,整理合并后分发给实现者)
> 独立的测试组按照系统设计测试产品
$ 改善团队交流
> 结构良好且实时更新的项目工作手册、良好的组织架构)
$ 选择合适的语言、工具、文档(与时俱进)
$ 采用容易剔除bug的设计,加强测试
$ 控制系统各部分的规模
$ 考虑项目各阶段的变更(唯一不变的是变化本身)
$ 设定合适的里程碑,并对其跟踪监督
$ 跟踪维护项目文档
没有银弹
$ 没有任何技术或管理上的进展,能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。
> 软件开发中困难的部分——固有的概念复杂性
> 困难是决定说什么,而不是怎么说
> 软件系统无法规避的内在特性:复杂度、一致性(需要兼容各种场景)、可变性、不可见性(软件的客观存在不具有空间的形体特征)
$ 最有希望成为银弹的技术——快速原型化系统的方法和技术
> 把开发作为迭代需求过程的一部分
$ 其它技术/方法:增量式开发(类似快速原型化)、直接购买软件、聘用培养优秀的设计人员