人月神话
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
16
•目标与开发策略的正常变化是无可避免的要事先做好准备
•高级语言的使用，编译时操作，引用的声明整合与自文档技术可减少变更引发的错误
•要尽可能的为设计书写文档
•只要管理人员与技术人才天赋容许老板必须对他们能力培养给予极大关注使其具备互换性
•程序的维护由各种变更组成 •对于一个广泛使用的程序其维护成本是其开发成本的40%或更多 •维护成本受用户数目影响用户越多出现的错误越多 •每次修复后必须重新运行先前所有测试用例确保系统不被隐式破坏
22
谢谢观赏!
23
17
•实现设计的人员越少接口越少产生的错误就越少
•在修复缺陷时有20%~50%引进新BUG
18
干将莫邪
•项目经理要制定策略并为通用工具的开发分配资源
•开发操作系统队伍需要有自己的目标机器进行调试开发 •分配给某个小组的连续目标时间块是好的安排方法
•高级语言有利于生产率的提高BUG的减少 •系统软件开发中交互式编程生产率是原有的2倍
•项目工作手册对项目产生的文档进行组织的一种结构 •尽早且仔细设计工作手册结 构 •每一个团队人员应该能够看到所有材料
•每个人不需要看到每件事的目标只需了解接口
11
•团队组织是为了减少交流与协作量
•人力划分与限定职责范围
•不允许双重领导 •组织中的交流是网状的而不是树状结构
12
胸有成竹
•仅对编码部分时间估计后乘以任务其他部分相对系数无法得出对整项工作的精确估计
•规模预算不仅在占据内存方面是明确的且与分配的功能相关联 •不要过于倾向局部优化要考虑用户整体影响 •突破点在于新型算法 •培养开发人员从系统整体出发面向用户的态度是软件编程管理员最重要职责
14
提纲挈领
•不管文件有多少总是有少数文档是关键枢纽
•关键文档:目标用户手册内部文档进度预算组织机构图与空间分配 •不管多大的项目，项目经理都应在早期对上述文档进行规范化
•不管多大的设计团队设计结果必须由一人或两人完成确保决定一致
•明确定义体系结构与先前不同重新定义的详细程度与原先说明一致 •形式化的设计定义且记叙性定义以加深理解
•直接整合是强制推行软件的结构性标准
10
为什么巴比伦塔会失败
•缺乏交流及交流结果 •实时更新
•由于对其他人的假设 •非正式的进行简要技术陈述的常规会议共享正式项目工作手册
3
职业乐趣
•创建事物的乐趣
•帮助了别人 •创建过程的乐趣 •持续学习的乐趣
4
职业苦恼
•他人设定目标，供给资源，提供信息
•寻找琐碎BUG •产品完工但过时
5
人月神话
•时间进度不合理，最主要原因 •任务的分解导致额外的沟通工作量 •进度安排：1/3计划1/6编码1/4构建测试1/4系统测试
•时间 •所有的编程人员都是乐观主义者
•构建独立小型程序的数据不适用于编程系统项目 •程序开发呈程序规模的指数增长
•使用适当的高级语言程序编制的生产率可提高5倍
13
削足适履
•除运行时间外程序所占内存空间也是主要开销 •早期制定策略以决定可选项目粗细程度
•消除不必要的规模 •设立规模目标控制规模
•编程需要技术积累每个项目需要有自己的标注组件库 •库中分为运行速度快与短小精炼
•对于项目将体系结构的工作与具体实现分离是获得概念完整性的强力方法 •要得到系统概念上的完整性就需要有人去控制 •行业要有纪律与规则 •体系结构设计实现物理实现的许多工作可并发进行
8
画蛇添足
•尽早交流且持续沟通
•不要过分的倾向于设计 •为功能分配一个字节和微妙的优先权值是很有价值的规范化方法
9
贯彻执行
•慢性进度偏离易影响士气，要有进取心 •项目经理必须停止对估计日期的怀疑
21
另外一面
•对于软件编程来说程序向用户所呈现的文档与提供给机器识别的内容一样重要
•要养成写描述性文字的习惯 •文档对克服懒惰和进度的压力起促进与激励的作用
•失败不都是应为缺乏热情和说服力而是没正确展示如何有效和经济的编制文档 •发布的程序拷贝要包括一些测试用例 •必须修改程序的人而言要有程序内部文 档 •为使文档易于维护要将它们合并到源程序中
•大型编程程序不能一拥而上否者会高成本速度慢效率低 •构思缺陷导致BUG的出现 •团队的架构类似于外科手术队伍
7
贵族专制，民主政治与系统设计
•概念的完整性是最重要的考虑因素 •概念统一有利于更快开发测试
•功能与理解上的复杂程度的比值是最终测试目标 •概念完整性获得设计由一人或具有共识的小型团队完成
人月神话
[美]弗雷德里克·布鲁克斯 （Frederick P.Brooks.Jr）著 UMLChina翻译组 汪颖 译
焦油坑
编程产品
职业乐趣
职业苦恼
2
编程产品：更有用，成本更高
程序转变为编程产品：可被任何人运行，测试，修复和扩 展的程序。
程序转变为编程系统：功能上相互协作，具有给烦的格式， 可以进行交互的程序集合，可用来组装和搭建整个系统。
19
整体部分
•若想不至于出现过多BUG就要对产品有一个精确的定位
•编写代码前规格说明必须提交给外部测试小组详细检查说明完整性明确性 •相对于单元测试系统测试所化时间会比预料的更长
•系统调试应在所有部件能够运作后开始 •系统测试期间一次只添加一个构件
20
祸起萧墙
•项目的进度落后
•制定一个进度表，由里程碑与日期组成 •里程碑必须是具体的特定的可度量的事件
•项目经理的职责使每个人向着相同的方向前进 •项目经理的主要日常工作是沟通不是决定
15
未雨绸缪
•什Leabharlann Baidu事都有一个过程不可能一步到位
•凡是急于求成的项目都会面临慢大难以使用或三者兼而有之的现象 •开发人员交付的是用户满意程度而不仅仅是产品
•为了追求时间而放弃原有的设计代价是高昂的有了产品没了信誉 •用户需求及感觉会随程序构建测试使用变化 •软件产品易于掌握性及不可见性导致构建人员面临永恒的需求变更
•抱有过高期望 •构思缺陷导致BUG的出现
•数据估计的缺乏
•技术不确定在种种压力下缺乏坚持下去的勇气 •向进度落后的项目不能增加人手
•围绕成本核算的估计而混淆了工作量与项目进展 •重新分配培训新人额外沟通
6
外科手术队伍
•小型精干队伍最好避免思绪的增加
•两个人的团队有一个是领导者 •相对于大型系统小型精干队伍太慢
•目标与开发策略的正常变化是无可避免的要事先做好准备
•高级语言的使用，编译时操作，引用的声明整合与自文档技术可减少变更引发的错误
•要尽可能的为设计书写文档
•只要管理人员与技术人才天赋容许老板必须对他们能力培养给予极大关注使其具备互换性
•程序的维护由各种变更组成 •对于一个广泛使用的程序其维护成本是其开发成本的40%或更多 •维护成本受用户数目影响用户越多出现的错误越多 •每次修复后必须重新运行先前所有测试用例确保系统不被隐式破坏
22
谢谢观赏!
23
17
•实现设计的人员越少接口越少产生的错误就越少
•在修复缺陷时有20%~50%引进新BUG
18
干将莫邪
•项目经理要制定策略并为通用工具的开发分配资源
•开发操作系统队伍需要有自己的目标机器进行调试开发 •分配给某个小组的连续目标时间块是好的安排方法
•高级语言有利于生产率的提高BUG的减少 •系统软件开发中交互式编程生产率是原有的2倍
•项目工作手册对项目产生的文档进行组织的一种结构 •尽早且仔细设计工作手册结 构 •每一个团队人员应该能够看到所有材料
•每个人不需要看到每件事的目标只需了解接口
11
•团队组织是为了减少交流与协作量
•人力划分与限定职责范围
•不允许双重领导 •组织中的交流是网状的而不是树状结构
12
胸有成竹
•仅对编码部分时间估计后乘以任务其他部分相对系数无法得出对整项工作的精确估计
•规模预算不仅在占据内存方面是明确的且与分配的功能相关联 •不要过于倾向局部优化要考虑用户整体影响 •突破点在于新型算法 •培养开发人员从系统整体出发面向用户的态度是软件编程管理员最重要职责
14
提纲挈领
•不管文件有多少总是有少数文档是关键枢纽
•关键文档:目标用户手册内部文档进度预算组织机构图与空间分配 •不管多大的项目，项目经理都应在早期对上述文档进行规范化
•不管多大的设计团队设计结果必须由一人或两人完成确保决定一致
•明确定义体系结构与先前不同重新定义的详细程度与原先说明一致 •形式化的设计定义且记叙性定义以加深理解
•直接整合是强制推行软件的结构性标准
10
为什么巴比伦塔会失败
•缺乏交流及交流结果 •实时更新
•由于对其他人的假设 •非正式的进行简要技术陈述的常规会议共享正式项目工作手册
3
职业乐趣
•创建事物的乐趣
•帮助了别人 •创建过程的乐趣 •持续学习的乐趣
4
职业苦恼
•他人设定目标，供给资源，提供信息
•寻找琐碎BUG •产品完工但过时
5
人月神话
•时间进度不合理，最主要原因 •任务的分解导致额外的沟通工作量 •进度安排：1/3计划1/6编码1/4构建测试1/4系统测试
•时间 •所有的编程人员都是乐观主义者
•构建独立小型程序的数据不适用于编程系统项目 •程序开发呈程序规模的指数增长
•使用适当的高级语言程序编制的生产率可提高5倍
13
削足适履
•除运行时间外程序所占内存空间也是主要开销 •早期制定策略以决定可选项目粗细程度
•消除不必要的规模 •设立规模目标控制规模
•编程需要技术积累每个项目需要有自己的标注组件库 •库中分为运行速度快与短小精炼
•对于项目将体系结构的工作与具体实现分离是获得概念完整性的强力方法 •要得到系统概念上的完整性就需要有人去控制 •行业要有纪律与规则 •体系结构设计实现物理实现的许多工作可并发进行
8
画蛇添足
•尽早交流且持续沟通
•不要过分的倾向于设计 •为功能分配一个字节和微妙的优先权值是很有价值的规范化方法
9
贯彻执行
•慢性进度偏离易影响士气，要有进取心 •项目经理必须停止对估计日期的怀疑
21
另外一面
•对于软件编程来说程序向用户所呈现的文档与提供给机器识别的内容一样重要
•要养成写描述性文字的习惯 •文档对克服懒惰和进度的压力起促进与激励的作用
•失败不都是应为缺乏热情和说服力而是没正确展示如何有效和经济的编制文档 •发布的程序拷贝要包括一些测试用例 •必须修改程序的人而言要有程序内部文 档 •为使文档易于维护要将它们合并到源程序中
•大型编程程序不能一拥而上否者会高成本速度慢效率低 •构思缺陷导致BUG的出现 •团队的架构类似于外科手术队伍
7
贵族专制，民主政治与系统设计
•概念的完整性是最重要的考虑因素 •概念统一有利于更快开发测试
•功能与理解上的复杂程度的比值是最终测试目标 •概念完整性获得设计由一人或具有共识的小型团队完成
人月神话
[美]弗雷德里克·布鲁克斯 （Frederick P.Brooks.Jr）著 UMLChina翻译组 汪颖 译
焦油坑
编程产品
职业乐趣
职业苦恼
2
编程产品：更有用，成本更高
程序转变为编程产品：可被任何人运行，测试，修复和扩 展的程序。
程序转变为编程系统：功能上相互协作，具有给烦的格式， 可以进行交互的程序集合，可用来组装和搭建整个系统。
19
整体部分
•若想不至于出现过多BUG就要对产品有一个精确的定位
•编写代码前规格说明必须提交给外部测试小组详细检查说明完整性明确性 •相对于单元测试系统测试所化时间会比预料的更长
•系统调试应在所有部件能够运作后开始 •系统测试期间一次只添加一个构件
20
祸起萧墙
•项目的进度落后
•制定一个进度表，由里程碑与日期组成 •里程碑必须是具体的特定的可度量的事件
•项目经理的职责使每个人向着相同的方向前进 •项目经理的主要日常工作是沟通不是决定
15
未雨绸缪
•什Leabharlann Baidu事都有一个过程不可能一步到位
•凡是急于求成的项目都会面临慢大难以使用或三者兼而有之的现象 •开发人员交付的是用户满意程度而不仅仅是产品
•为了追求时间而放弃原有的设计代价是高昂的有了产品没了信誉 •用户需求及感觉会随程序构建测试使用变化 •软件产品易于掌握性及不可见性导致构建人员面临永恒的需求变更
•抱有过高期望 •构思缺陷导致BUG的出现
•数据估计的缺乏
•技术不确定在种种压力下缺乏坚持下去的勇气 •向进度落后的项目不能增加人手
•围绕成本核算的估计而混淆了工作量与项目进展 •重新分配培训新人额外沟通
6
外科手术队伍
•小型精干队伍最好避免思绪的增加
•两个人的团队有一个是领导者 •相对于大型系统小型精干队伍太慢