hello，大家好，我是张张
1、关于人月神话
在软件开发领域，布鲁克斯博士的《人月神话》是一本关于大型项目管理的经典之作。它不仅对每一个软件行业的项目经理(PM)来说是一本必读读物，对每个软件行业的参与者，都是一本不可错过的经典。
Q：为什么被称为“人月神话”？
通常情况下，我们估算开发成本会说 xx 人/月。
这里人是程序员，月是时间。
我们这样的成本核算方式，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的，如果1人干10个月如果等同10人干1个月，那就成神话。
2、开发中的“坑”
为什么会出现“人月堪称神话”的情况呢？因为开发过程中存在很多的坑，会让我们避之不及。
2.1 遗留系统堪比焦油坑
过去几十年的大型系统开发就犹如一个焦油坑，很多研发团队曾在其中不断挣扎过，他们开发出了可运行的系统，不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。
各种团队，不管大型的还是小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢且很难看清问题的本质。
2.2 避免画蛇添足
这可能是我们经常见到的一种现象：
当在开发第一个系统时，程序员倾向于精炼和简洁。因为他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地进行工作。 在开发第一个项目时，他会面对不断产生的装饰和润色功能，这些功能当时都被搁置在了一边，作为“下一个”项目的内容。 第一个项目迟早会结束，而此时的程序员，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。 第二个系统是程序员所实践的最危险的系统。原因是 一种普遍倾向是过分地设计第二个系统，曾在第一个系统中被小心谨慎地推迟的修饰功能和想法终于得以用武之地了。
问题总结下，就是：过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。
面对估算过高的难题，架构师有两个选择：削减设计或者建议成本更低的实现方法。
那该如何解决呢？
实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
还可以让至少拥有两个系统以上开发经验的架构师指导，保持对过度设计诱惑的警觉，他们可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
2.3 吸取巴比伦塔失败的经验
巴比伦塔项目失败的主要原因是因为缺乏交流，交流的必然条件--组织。
因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。 随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定，而因此给其他部分引发了BUG。
那有什么解决方案呢？
- 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规的项目会议。
- 会上进行简要的技术陈述、共享的正式项目工作手册。
- 举行常规项目会议，会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
- 制定项目工作手册，并实时记录变更。
- 首先，必须在页面上标记发生改变的文本，例如，使用页面上的竖线标记每行变化的文字。
- 第二，分发的变更页附带独立的总结性文字，对变更的重要性以及批注进行记录
2.4 防止祸起萧墙
当人们听到某个项目的进度发生了灾难性偏离时，可能会认为项目一定是遭受了一系列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。
因为按照熵的理论，如果不加以控制，事物总是向无序的方向发展，所以如果没有防微杜渐，那么事情就会越来越糟。
破窗户理论讲的是，如果你想让一所房子破百那么很简单的方式，就是打破一扇窗户，只要这个窗户没有及时得到维修，那么很快就会有另一扇窗户被打破。接着就会有人开始乱扔垃圾，乱涂乱画，严重的结构损坏开始了。用不了多久，建筑就被损毁得不成样子。
软件开发也是这样。
如果发现软件有了一些小问题，但你没有去纠正，那么软件就可能会出现越来越多的问题，软件的味道会越来越差。
3、总结一下
通俗地说，软件是一个集合，是程序 数据 文档的集合。
并不是大部分普通人认为的软件仅仅是程序。
软件开发过程是复杂的，其本身是不可见的和无法可视化的，所有软件都是逐步发展成熟，而不是一次性搭建的。
软件开发是一件棘手的事情，并不会有魔术般的解决方案，现在有可能可以在软件生产率上取得逐步的进展，而不是等待不可能到来的大突破。
