M.M神话 (人月神话) 写写'银'生

          为什么标题会以MM 来命名  ,取自书名  《THE MYTHICALMAN-MONTH 》Man-Month 人月的首字母

这本书是全球软工领域最畅销的项目管理经典！影响人力编程思想的最牛著作之一,在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。

       用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。(注:人月是用来衡量工作量的，规模是通过功能点或代码行等方式来衡量的，规模除以个体生产率后可以得到人月数据)。这里进一步来描述人月不能互换的原因，首先是任务能否拆解，及时能够分解任务间是否存在相互的依赖和约束，分解后是否增加会增加相应的沟通，以及由于分解任务而引入的分解和后期集成等额外的工作量。

                

书中第16章：没有银弹

人狼和其他恐怖传说
《没有银弹－软件工程中的根本和次要问题》（第 16 章）最初是在 IFIP’86 年都柏林

大会的约稿，接着在一系列的刊物上发表

《计算机》杂志上翻印了该文章，封面是一副类
似于《伦敦人狼》

影片的恐怖剧照。同时，还有一栏补充报道《杀死人狼》，描述了银弹将
要完成的（现代）神话。在出版以前，我并未注意到补充报道和文字，也没有料到一篇严肃
的技术性文字会被这样润色。
Computer 杂志的编辑们是取得他们想要的效果的专家，不过，似乎有很多人阅读了那
篇文章。因此，我为那一章选择了另一幅人狼插图，一幅对这种近乎滑稽物种的古老素描。
我希望这副并不刺眼的图案有相同的正面效果。

存在着银弹－就在这里！
《没有银弹》中声称和断定，在近十年内，没有任何单独的软件工程进展可以使软件
生产率有数量级的提高（引自 1986 年的版本）。现在已经是第九个年头，因此也该看看是否
这些预言得到了应验。
《人月神话》一文被大量地引用，很少存在异议；相比之下，《没有银弹》却引发了众
多的辩论，编辑收到了很多文章和信件，至今还在延续

他们中的大多数攻击其核心论点
和我的观点——没有神话般的解决方案，以及将来也不会有。他们大都同意《没有银弹》一
文中的多数观点，但接着断定实际存在着杀死软件怪兽的银弹——由他们所发明的银弹。今
天，当我重新阅读一些早期的反馈，我不禁发现在 1986 年～1987 年期间，曾被强烈推崇的
秘方并没有出现所声称的戏剧性效果。
在购买计算机软件和硬件时，我喜欢听取那些真正使用过产品并感到满意的用户的推
荐。类似的，我很乐意接受银弹已经出现的观点，例如，某个名副其实的中立客户走到面前，
并声称，“我使用了这种方法、工具或者产品，它使我的软件生产率提高了十倍。”
很多书信作者进行了若干正确的修订和澄清，其中一些还提供了很有针对性的分析和
辩驳，对此我非常感激。本章中，我将同大家分享这些改进，以及对反面意见进行讨论。

《没有银弹》无可争辩地指出，如果开发的次要部分少于整个工作的 9/10，那么即使
不占用任何时间（除非出现奇迹），也不会给生产率带来数量级的提高。因此，必须着手解
决开发的根本问题。
由于《没有银弹》，Bruce Blum 把我的注意力引向 Herzberg、Mausner 和 Sayderman
7
等人在 1959 年的研究。他们发现动机因素可以提高生产率。另一方面，环境和次要因素，
无论起到多么积极的作用，仍无法提高生产率。但是在产生负面影响时，它们会使生产率降
低。《没有银弹》认为很多软件开发过程已经消除了以下负面因素：十分笨拙的机器语言、
漫长的批处理周转时间以及无法忍受的内存限制。


“消极”主题。Harel 认识到《没有银弹》中的消极来自三个主题：
1根本和次要问题的清晰划分
2独立地评价每个候选银弹
3仅仅预言了十年，而不是足够长的时间“出现任何重大的进步。”


第一个主题，它是整篇文章的主要观点。我仍然认为上述划分对于理解为什么软件难
以开发是绝对关键的。对于应该做出哪些方面的改进，它也是十分明确的指南。
至于独立地考虑不同的候选银弹，《没有银弹》并非如此。各种各样的技术一个接一个
地被提出，每一种都过分宣扬自身的效果。因此，依次独立的评估它们是非常公平的。我持
反对态度的并不是这些技术，而是那种它们能起到魔术般作用的观点。Glass、Vessey 和
Conger 在他们 1992 年的论文中提供了充足的证据，指出对银弹的无谓研究仍未结束

关于选择 10 年还是 40 年作为预言的期限，选择较短的时间是承认我们并没有足够强
的能力可以预见到十年以后的事情。我们中间有谁可以在 1975 年预见到 80 年代的微型计算
机革命吗？
对于十年的期限，还有其他的一些原因：各种银弹都宣称它们能够立刻取得效果。我
回顾了一下，发现没有任何一种银弹声称“向我的秘方投资，在十年后你将获得成功”。另
外，硬件的性能/价格比可能每十年就会有成百倍的增长，尽管这种比较不很合适，但是直
觉上的确如此。我们确信会在下一个 40 年中取得稳步的发展。不过，以 40 年代价取得数量
级的进展，很难被认为是不可思议的进步。


想象的试验。Harel 建议了一种想象的试验，他假设《没有银弹》是发表在 1952 年，
而不是 1986 年，不过表达的论断相同。他使用反证法来证明将根本和次要问题分开是不恰
当的。
这种观点站不住脚。首先，《没有银弹》一开始就声称，50 年代的程序开发中曾占支配
地位的次要困难，如今已经不存在了，并且消除这些困难已经产生了提高若干数量级的效果


银弹就在这里。Harel 接着提出了他自己的银弹，一种称为“香草（Vanilla）框架”
的建模技术。文中并没有对方法提供足够评估的详细描述，不过给出了一些论文和参考资料
 
。建模所针对的确实是软件开发的根本困难，即概念性要素的设计和调试，因此 Vanilla
框架有可能是革命性的。我也希望如此。Ken Brooks 在报告中提到，在实际工作中应用时，
它的确是一种颇有帮助的方法学。
不可见性。Harel 强烈地主张软件的概念性要素本质上是拓扑的，这些关系可以用空间
/图形方式来自然地表达：
适当使用可视化图形可以给工程师和程序员带来可观的成效。而且，这种效果并不仅
仅局限于次要问题，开发人员思考和探索的质量也得到了改进。未来的成功系统的开发将围
绕在可视化图形表达方式的周围。首先，我们会使用“合适的”实体和关系来形成概念，然
后表达成一系列逐步完善的模型，不断地系统化阐明和精化设计概念。模型用若干可视化语
言的适当组合来描述，它必须是多种语言的组合，因为系统模型具有若干方面的内容，每方
面象变戏法般产生不同类型的思维图像。
……就使自己成为良好可视化表达方式而言，建模过程的某些方面并不会立刻出现改
观。例如，变量和数据结构上的算法操作可能还是会采用文字性描述。




将反馈限定在直接相邻的先前阶段，从而容纳它引起的成本增加和进度延迟

                    瀑布模型
计划     编码     单元测试     系统测试     现场支持

      作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。 作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。

其实项目中人和时间分配在于管理人的计算之中，虽然成品能否让用户(客户)认可，但是有了可用的程序出来,后续可能客户需求可能有所改动，都要逐步克服。

题外话：所为人生就是为银子工作生存。

‘//----------------------------------------------------------------------------------------------------------------------------------------//’

庆祝一下CSDN Android客户端发布