前言
3月公司进行CMMI5复评，本人非常荣幸地作为ATM成员之一全程参与其中，近距离的倾听评估专家丛斌博士对体系的完整解读，对问题的深刻剖析，还被科普了很多专业新名词，真是获益良多。
想当年向公司投递简历时，相中它其中很重要的一点是公司通过了CMMI5级，当时的我对CMMI其实是懵懂的，但作为一名QA，对能走近它是向往而笃定的。
这次评估结束后，我一边整理笔记，一边在想，这些天的所闻所学，仅局限在有限的几个人范围内似乎太过浪费了呢？这些思想和方法被真正使用体系、参与实际研发过程的团队和个人获悉、试用、最终被落地，一定会更具价值！于是就有了下文——
引入精益理念
精益像一个改进驱动器，从团队当前使用的过程开始，通过将工作流程可视化，控制软件规模，限制在制品个数（WIP），动态揭示出瓶颈点并一个一个去改进解决，最终冲破各种阻力，打造源源不断的价值流直达客户。
精益看板
端到端的思想
有些团队敏捷迭代做得很快，但是否很快让用户用起来，如何一脚踹到用户，就需要做更多思考了。今年计划研究和引入devops就是基于此。
需求拆分方法
MMF方法
Minimum Marketable Feature：将项目分解成最小有市场价值功能特性集，每个小的子集都能实现独立的客户价值，依据这些价值，我们可以找出性价比最好的针对MMF 的开发次序，最大限度地降低我们投入的风险。
MVP方法
Minimum Viable Product ：开发一个大的产品时，从小的开始做，并确保刚开始就是有价值的，不断加一点，不断加一点，并遵循 just enough的原则。了解更多：https://en.wikipedia.org/wiki/Minimum_viable_product
关于敏捷估算
建议建立story的颗粒划分标准，1个story不要超过迭代总长的1/3；
对工作量的估算不能只以开发量为参考线，有时一个迭代大半都是测试工作量都是可能的。
定期偿还技术债务
技术债务是修复已上线程序中结构质量问题的成本，如果这些问题不能解决，其带来的后果是后续升级开发失控或用户操作失灵。为加快开发速度产生些债务是可接受的，只要能及时优化和还债，在敏捷中应该考虑定期偿还这些债务，提高代码可读性、可维护性。
建议每隔几个迭代排一个代码优化任务
重视同行评审
需求分析、设计的投入应该要比实现占比大，这是业界准则，可以有效降低可规避的返工，CMMI2.0在删减一些域的同时将同行评审变成了一个独立的域，可见重视程度。
落实缺陷分析
客户报上来的缺陷，为什么我们的测试、评审过程没有发现，应该在哪里发现？每个缺陷的暴露都有潜伏期，一个缺陷暴露了，是否可以主动发现其他模块中类似的地雷？
度量响应时间
响应时间是指从客户提出来到交付的时间，衡量端到端的效率，否则即使生产力提高，交付给客户仍然慢，也没有实际意义。
度量响应时间更容易找到真正的瓶颈点，在已有人员和能力下想再大幅提高效率，除非引入非常多工具，否则很难，所以引入响应时间的度量，分析等待时间的耗费，一一去改进才是正道。
考虑延期成本
很多项目赶着上线，往往是在项目后期测试阶段加班较多，但这个阶段加班特别“贵”，因为项目已全面铺开、各角色都已经卷入，同时为赶进度而补充的新人学习成本也高，还容易犯错误，导致越赶越乱。时间应该在哪赶？在项目前期争取一个月时间的代价远比项目后期争取一个月的代价要低很多。
PM能力把关
明确关键项目项目经理能力标准，针对性的提升欠缺的能力，协助对关键接力棒点进行识别，避免简单错误。
明晰改进主体
改进中区分责任部门、支持部门，鞋穿在谁脚上谁才知道是否合脚。
评估0准备
今年3月刚刚发布了CMMI2.0，新标准强调用最小代价达成目标，只要理解评估的每个目标是要解决什么问题，被评估组织对照说明自己是如何做的即可，理想状态是：实际评估前不需要刻意准备。
因个人理解深度、篇幅等原因，很多观点和方法无法一一阐述透彻，但仍希望以此文为引子，后续大家一起多琢磨、多实践，也欢迎大家留言讨论。
丛博经典文章推荐
1、是敏捷还是精益？
2、如何管理好你的技术债务 - 好借好还，再借不难！
3、是老酒装新瓶还是重酿的新酒? – 我看CMMI2.0
