1.小弟最近一直在看CMMI Tailoring方面的文章
对裁剪方面也很有兴趣，但是缺乏实践，很想知道各位所在公司是如何积累CMMI裁剪实践的
举例说代码评审
1.如果是新手，他的代码就要重点评审，首次代码重点评审，同时有评审checklist，可能还要侧重代码规范的评审。
2.如果是编码2年以上的，他的代码评审频率就可以降低，就可以执行非正式评审，主要侧重的就是业务逻辑方面的评审
我很希望了解各个公司是如何实现裁剪实践的积累的，通过积累裁剪实践不断量化指标，持续改进裁剪指南。
希望各位给些具体的实践方案，有价值的给分方面我不会吝啬
------解决方案--------------------------------------------------------
裁剪是很有意义的行为
无论是裁剪CMM/CMMI，还是对RUP，甚至XP的裁剪
------解决方案--------------------------------------------------------
裁剪分很多类型(HCMM\CMM\……)：
项目管理、开发过程（设计＆开发）、测试过程、质量管理、配置管理、项目维护等等。
针对每个过程都会有相应的裁剪指南，具体的项目裁剪程度不一样，都应记录在PHB中。
如：
①根据客户意愿进行裁剪
②根据项目类型、规模进行适当的裁剪，如小项目（NBNC 1-3K、总进度在2周～2月 且 总工作量小于6人），可以将概设与详设合并为设计阶段，裁剪掉集成测试阶段等。
③测试过程中，根据不同描述的BUG单也会有不同的流程裁剪。
这些裁剪指南都应体现在过程、工程模板中。
------解决方案--------------------------------------------------------
PHB->Process Handbook 过程手册
主要是为了说明项目采用的生命周期模型、遵循的流程，各阶段的出入准则、例行公事、意外处理，以及相关的裁剪说明、依据等。
每个项目都需要有PHB，是项目的基础文档，项目的运转根据此文档中的描述为依据。
裁剪经验肯定是要总结的，整理成一系统的裁剪准则（裁剪ID，裁剪标题，应用阶段，应用标准等），不过是在已有的标准基础之上，进行总结优化，不同行业不同系统的肯定是不一样的，具体应用环境、侧重点不同。
------解决方案--------------------------------------------------------
在公司没有积累的情况下只能凭项目经理的个人经验了
关键是慢慢要把项目经理的经验积累起来
这个积累的框架就显得相对重要了
------解决方案--------------------------------------------------------
这是个很好的课题，怎么把裁剪形成行之有效的指南甚而方法轮，的确有很多需要关注和考虑的
裁剪的目的不外乎面向业务目的基于现有资源（尤其是人力资源），进行管理上的优化配置，以期高效的完成任务。
对于项目目标和对团队能力的准确认识是首要的，然后才是现有的管理手段是否匹配、匹配程度如何、何处可以裁剪、怎样裁剪的问题。适合是核心，有些理论上非常好的方法运作起来就知道行不通，而有些似乎有悖工程原理的手段，项目团队循之实施却有很好的效果，不能一概而论。
在缺乏稳定的管理方法和适应该方法的工程师的情况下，裁剪模式（可参考的资料很多）上僵化一点可以接受，然后PDCA一点一点积累，重要的是不断反省和评估，人员自身和管理方法都要不断调整。
如果条件具备，可以着手进行“裁剪”本身的改善，包括工具、评价、量化。
从组织层面来讲，面向业务单元要比面向项目单元制定裁剪指南要更好一些，当然项目实践也需要进行进一步细微变化。
裁剪指南的变更周期要看公司的业务方向变化情况，一般一年进行一次是可以的。业务部门和项目要更频繁一些。
------解决方案--------------------------------------------------------
框架是重要，但框架的积累只能接近和达到规范，并不能够使流程达到最优。
这就是软件过程中，人的重要性。
------解决方案--------------------------------------------------------
Mark P.Ginsberg的图