人月神话-结合QX项目的总结

      前几天关于QX的中期总结，多是发发牢骚1,2。这里看了《人月神话-国内实战体验精华版》的内容，重新对项目中的问题进行思考和总结。
1. 无论是开发人员的人数上，还是工作量本身上的变化，都可能导致最终完成时间的非线性变化。进一步的研究表明，增加人手不一定会施工期进一步推迟，不过一定会是工程效率进一步降低。
2. 大型系统项目首要的就是保持概念完整性，不要强调功能。为了确保概念完整性，作出决定的必须是少数人，甚至是一个人。交给开发人员的是完全的需求，即使最细微的需求分析也不要交给开发人员。
3. 本质困难是软件开发固有的，无法用任何方式取消。软件工程本质上是一种缓慢的艺术，这中间，筹划、交流、冥想、迭代占很大比重，同样错位、反复甚至离题也应该占有一席之地。
4. 程序系统=3*程序产品=9*程序
5. CMM level2到达到的是：配置标识、版本控制、变更控制和度量。
6. 银弹的讨论：1.Brooks1975年提出由于难以达成概念一致性，将会导致大型软件系统进度落后、成本暴涨以及错误百出，这就是软件危机。（为了保证概念一致性，可行的方法就是主架构和实施细节分开来。）2.1986年他断言十年之内不会有解决危机的银弹。同时认为，OOP只是改进了设计的表示方法，除去了表达性复杂和困难，并没有除去根本性的复杂。3.1990年cox认为如晶体般高度内化的组件，使得软件可以像机器一样组装，软件危机可以解决。4.1995年brooks认为大型软件开发困难依旧存在，短期内不会有解决方案。Cox的晶体方案，只是解释了建造方法上的缺失，而brooks所指的根本性困难是概念性复杂导致的。5.1995年底，cox认为银弹存在，而且在于以人为核心进行思维转变，而不在于技术。
      另外，最近看了几本社会类书，观点也开始慢慢转变，逐步认识到之前的一些错误想法。所以这里，说一些题外的话。
      北京国家气象局Debug的反思
1.即使是技术发起方，也可能对技术并不精通。
2.领导说说就ok，具体技术细节一般都不太清楚，不要害怕，谁坚持、说得明白谁就是对的。
3.小兵干工作，力求一个无错。
4.各方利益相互斗争，只要默不作声就可以了。
5.要有一个好的态度，然后有一个好的工作的样子，至于结果，不可控。
6.三人行必有我师。
7.和有些人生活在一个城市中，都能提高我的杀心。
8.不一定要接受所有的踢过来的皮球，不是自己的问题要说清楚，当然要适当承认自己的错误。
      武汉湖北气象局Debug的反思
1.不着急，只尽力。
2.事业单位只强调一个工作完成和没有出错，大家都知道这个项目是怎么回事了，心态也就不再那么焦急了。
3.还是强调态度，你看工作没完成没问题，态度不好就不行。
4.不要大包大揽不是自己的问题。
      参考
1. QX项目实战-20.阶段性总结反思
2. 关于需求变更以及管理