经典传颂人月神话The Mythical Man-Month
Posted 如何在3年拿到50K
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了经典传颂人月神话The Mythical Man-Month相关的知识,希望对你有一定的参考价值。
书籍是一种凝固的时间,穿过明月清辉与万里河山来看你。
这本书写成十余载后我才出生,半个世纪后我才阅读。可怕之处在于,书中的观点仍然广泛受到认同。软件工程领域与其他工程行业相比大多程序员所认为的还要相似。有些方面右又比我们人所认为的差异还要大。这个领域的知识重在积累,终身学习是很多程序员的觉悟。
0、引言
人月神话是危险性和欺骗性的神话,因为他暗示了人员数量和时间可以互相替换的。进一步说,及时人力(Man)和时间(Month)不是线性关系,使用人月作为衡量标准实际上就是Mythical.
一、程序员不为人知的乐趣与烦恼
YES
1. 创建事务的纯粹快乐。
纯粹指的是处于人类本能的快乐,我们喜欢音乐与美食一样,我们喜欢沙滩城堡与建造房子。这种快乐是上帝兴趣的折射,六角雪花与独特树叶的呈现。
2. 创造帮助他人的的东西。
从内心深处,我们希望我们的劳作能够被他人认可和使用。
3. 操控世界的魔力
软件可以操作硬盘存储,显示器显示图片,我们通过代码级别的咒语操作一些物件产生变化和效果。甚至代替人的思考获取更高层次的答案。这个过程经过百年的积累已经成为一种魔法改变世界。人天生变有控制世界的欲望。
4. 持续学习的快乐。
软件工程综合了科学和工程实践,算法和设计模式能够帮助我们更加本质和透彻的角度看待世界,把复杂的问题简单化。诞生了无数大师的思想,解决了无数问题。程序员可以自我升华到架构师。每个架构师都会具备一定哲学思想
NO
1. 不得不完美的苦恼
我们不得不追求完美,即使懒惰的程序员也不得不按照语法和标点符号完成每一行代码,并完成拼装。经过无数bug才能获取到运行成功。这个过程代表了大量的琐碎时间,以及产出缓慢的苦恼。
2. 他人设定目标
很多时候我们的进展有业务方和需求方决定。自身的发挥收到很大限制。
3. 不断的被淘汰
我们今天的项目可能明天就被淘汰,今天的技术明天就不在流程。这中间的过程并不连贯,花大量时间积累的经验很可能无用
过去十年软件行业犹如一个焦油坑,无数动物在里面挣扎,最终只有程序猿站立执行。
二、人月神话
- 每个软件项目进度安排最大的错误假设:一切都将运行良好,每一项任务仅花费‘应该’花费的时间。
- 理论上缺陷的数量应该为0.
- 只有一个人的项目我们才能较为准确地估计出人月。在一个大规模项目人月是一个乐观主义神话。
- 根据经验法则,编码只占整个软件工程中的20%时间,甚至更少。这部分是最容易估计人月的。其他的都不容易。
- 向落后的项目添加人手通常导致更严重的落后。
三、 系统设计
- 系统设计中,概念的完整性是最重要的考虑因素。为了概念完整和连贯,可以舍弃一部分精美但是无法整合的设计。
- 最差的设计往往是那些投入远超预计工时的项目。长时间的投入并不会产生更多创造性。
- 创造性活动纷呈三个独立阶段:架构设计、详细设计、物理实现。这三种是可以并行的。
- 自律是系统设计的首要原则。我们会不自觉地把很多想法认为是可以直接落地的,这些想法会耗费大量精力在无用的模块上。
- 准确地表达复杂结构是必要的困难活动。这些创造性活动并不会影响太多生产效率。
- == 卓越的设计人员是无法估量价值的== 和莫扎特、周杰伦一样,伟大的软件系统都是有少数人设计的。
- 重用需要良好的设计和卓越的文档。
四、贯彻落地
- 看似琐碎问题上统一原则是一件至关重要的事情
- 光说不做是不会发生任何事情的
- 重视文档的设计。必须清晰完整准确,重复说明必须要素,所有文字要相互一致,精确比有趣更重要。
- 会议室必要的。周例会和年度大会是有必要的方式。敏捷管理中的晨会也有其独特的价值。会议目标:交流沟通、解决冲突、达成一致、发现风险、解决问题,跟进进度。
- 巴比伦塔为什么失败?上帝为每个国家创造了独特语言,他们之间无法沟通。·交流· ·组织·
- 程序猿仅需要了解自己负责的部分,而不需要关注整个系统细节时,效率最高。
- 团队组织目标就是较少交叉沟通的渠道,减少沟通的数量。通过职责划分和任务分配是减少沟通数量的重要手段。避免跨团队的直接沟通,每个团队最好有接口人。
- 里程碑必须是具体的、特定的、可以度量的事件、必须清晰明确定义达成基准。
- 大型设计团队,设计结果也必须由一个或者两个完成,以确保决定是一致的。
五、 团队建设
- 产品负责人和技术负责人如果是同一个人,可以有更好的推进效果。在大型项目中,推荐产品经理作为整个团队负责人。
- 确保团队成员经验技巧能够不断被培训,而不是依赖于自身经验积累。
- 创造性的想法和技能可以最大程度保证项目空间。
- 技术需要积累,需要开发更多的公共单元。
- 文档能够作为其他人沟通的渠道,只有记录下来分歧才会明确
- 进取意味着团队成员比要求跑的更快,从而使开发团队能够处理常规的风险,为项目工期提供了缓冲地带。
- 负责人和老板是存在冲突的。真是的汇报可能让老板采取行动取代负责人。虚假的回报可能导致整个项目陷入巨大风险。 (减少角色冲突:老板必须规范自己,不在检查进度时发号施令,仅在必要时做出决策。猛地拉开地毯:里程碑评审,对于项目彻底拉开评审真实进度)
六、系统维护
- 系统在最开始是最好的
- 熵曾宇宙也是系统最基本的定律。每次版本号的增加都代表系统的混乱程度更高,所有的修改都倾向于破坏现有的设计。
- a goog man is konwn by his tools。工具很重要
- 架构师会对整个系统做出一些假设。这些假设和真是情况不匹配是大多数致命和难以察觉bug的来源。
5.开发人员不会说自己不懂。他们会自己创造一条解决问题(生产bug)的方法。
七、没有银弹
- No Silver Bullet.成为行业著名口头禅,没有任何工具可以解决所有问题。
- 复杂想是软件行业的属性,也是我们的主要限制。 导致技术问题和管理苦难那,让沟通困难,导致产品瑕疵,方案概念完整性,离散出口难以控制,学习负担、让开发变成灾难。
- 常常看似简单明了的东西,却有可能变成一个落后进度,超出预算,存在大量缺陷的怪物。
- 软禁工程师无法从科学法则上获取一致性、我们必须掌握壕无人性,毫无规律的软件复杂度法则。
- 可变性。软件工程遭受着持续变更的压力,可以无限修改可扩展。没有人修改建筑,应该成本太高昂,没人傻子提出这种需求。而软件工程的傻子大有存在。
- 不可变性:软件是不可见的,没有空间几何特性。这些如同巴比伦成一样,阻碍了工程师的交流和组织。
以上是关于经典传颂人月神话The Mythical Man-Month的主要内容,如果未能解决你的问题,请参考以下文章
《人月神话(The Mythical Man-Month)》2人和月可以互换吗?人月神话存在吗?
悼念《人月神话》(The Mythical Man-Month)作者 Fred Brooks
《人月神话》(The Mythical Man-Month)6贯彻执行(Passing the Word)
《人月神话》(The Mythical Man-Month)3 外科手术队伍(The Surgical Team)
《人月神话》8 胸有成竹(Chaptor 8.Calling the Shot -The Mythical Man-Month)