“人月神话”和CMMI (下篇)
2018-11-15
来源：老丛讲桌 丛斌博士
本来也想一气呵成下，但以我这啰啰嗦嗦的劲儿估计得写上几页纸，这种无趣的文章过长，别说你们了，我自己都看不下去，索性拦腰一斩。得咧！又多混篇文章！闲篇放下，接着谈六七八九十！
人月神话结论六：尽早交流并持续沟通产品需求，能让架构师有较好的成本意识，也会让开发人员对自己的设计更有信心，并且会明确各自的责任分工。画蛇添足是软件开发的一个常见问题（需求蔓延）。而产品总是在完成前总面临过时的威胁，因为软件产品的易于掌握的特性和不可视性，导致开发人员面临常态化的需求变更。软件开发必须考虑它带来的各种风险，软件维护也主要有各种变更组成。
CMMI对应策略六：在整个开发过程中，强调需求双向追溯管理在一定程度上可以缓解Brooks提出的问题，模型对质量属性等非功能需求的关注，也对产品整体规划有很大帮助，减少了维护变更成本。
人月神话结论七：自律、规范对软件开发是有益的，体系结构的规范是加强而不是限制了实现团队的创造性。精确性的要求意味着开发团队需要形式化的设计定义，同时需要用记叙性定义来加深理解。有必要强制推动软件结构性标准（如接口标准）。
CMMI对应策略七：CMMI对过程的执行力及改进力的关注，让自律及规范的遵守成为习惯。其中的通用目标及实践，加上过程QA为过程的执行及改进提供了必要的组织支持。
人月神话结论八：项目经理最好的朋友是独立的产品测试团队，如果能每天面对测试的挑战，那就更好了。变更后全量的回归测试，能确保系统不会以更隐蔽的方式被破坏。软件管理者应为测试自动化工具及其它开发工具投入必要的资源，让测试环境能接近实际操作环境，非常重要！
CMMI对应策略八：模型中的V&V以及PI的统一规划执行，是Humphrey和SEI对软件工程中质量控制的重要贡献，它的内容已经超出了人月神话的范围。
人月神话结论九：团队组织结构应该包括人力划分和明确的职责范围。组织中的交流是网状的而不是树性结构，软件项目需要两个领导角色：产品负责人和技术负责人，这两个角色的职能有很大区别，需要不同的技能。
CMMI对应策略九：CMMI中团队管理的内容和通用实践，使得团队建设及管理成为项目开展的前提，明确干系人的职责并加以监督检查，也是CMMI组织的一个基本要求。
人月神话结论十：项目管理围绕一些关键文档运行，在形成这些文档时应该将注意力集中在思索和讨论的提炼上，这些文档应该让大家从乱象中得到清晰、明确的策略。对关键文档应提供及时维护，并形成一定的规范。必须向团队灌输对待文档的积极态度 – 好的文档能在项目整个生命周期对克服懒惰和进度压力起促进和激励作用，同时要注意如何有效和经济地编制文档。
CMMI对应策略十：模型的IDEAL方法，特别是过程体系文档的建立、裁剪使用、度量、稽核、经验积累、反馈改进等实践，形成了一套让Brooks提出的关键文档在项目中有效落地的套路。
1975年版的“人月神话”
Humphrey软件过程经典著作
Brooks指出软件系统产品可能是人类创造的最错综复杂的事务，软件工程的焦油坑让我们举步艰难。Humphrey用模型的形式为我们展示了一套可以在这个焦油坑生存、成长的方法。迷信大师不可取，但大师能撑起大师的牌子，过人之处的总结必须敬重！
推荐阅读
1. 那些年，我们不能忘记的IBM360
2. 软件质量之父——Watts Humphrey
3.论CMMI的核心价值
4. “人月神话”和CMMI (上篇)
5. 软件度量三定律
6. 过程改进十大问题
7. CMMI模型高成熟度的硬伤
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
