概述
公司近期进行CMMI3, 公司目标很明确:招投标用的，过程中准备了一些材料，对于我们外包工作来说,还是有一定指导作用的。
CMMI
概述
集成的能力成熟度模型（CMMI）是成熟度模型和相关产品的集成框架，其中集成了系统开发活动中不可分割的两个关键学科：软件工程和系统工程。
流程管理和质量改进概念在产品开发，维护和采购中的常识性应用
一组最佳做法
公共开发指南
组织改进的模型
CMMI涉及三个感兴趣的领域：
产品和服务开发-CMMI for Development（CMMI-DEV）， 服务的建立，管理，—服务的CMMI（CMMI-SVC），以及 产品和服务获取— CMMI for Acquisition（CMMI-ACQ）。
在2.0版中，这三个区域（以前每个区域都有一个单独的模型）被合并为一个模型。
CMMI由行业，政府和CMU的软件工程学院(SEI)组成的小组开发。 CMMI模型为开发或改进满足组织业务目标的流程提供了指导。 CMMI模型也可以用作评估组织流程成熟度的框架。 到2013年1月，整个CMMI产品套件已从SEI转移到卡耐基梅隆大学新成立的组织CMMI研究所。
核心过程
版本1.3中CMMI领域共有的17个CMMI核心过程领域。
| 缩写 | 名称 | 领域 | 成熟度 |
|---|---|---|---|
| OT | Organizational Training | Process Management | 3 |
| OPP | Organizational Process Performance | Process Management | 4 |
| OPM | Organizational Performance Management | Process Management | 5 |
| OPF | Organizational Process Focus | Process Management | 3 |
| OPD | Organizational Process Definition | Process Management | 3 |
| RSKM | Risk Management | Project Management | 3 |
| REQM | Requirements Management | Project Management | 2 |
| QPM | Quantitative Project Management | Project Management | 4 |
| PP | Project Planning | Project Management | 2 |
| PMC | Project Monitoring and Control | Project Management | 2 |
| IPM | Integrated Project Management | Project Management | 3 |
| SAM | Supplier Agreement Management | Support | 2 |
| PPQA | Process and Product Quality Assurance | Support | 2 |
| MA | Measurement and Analysis | Support | 2 |
| DAR | Decision Analysis and Resolution | Support | 3 |
| CM | Configuration Management | Support | 2 |
| CAR | Causal Analysis and Resolution | Support | 5 |
访谈
我们访谈主要涵盖 PP, RSKM, IPM, PMC, 我们是驻场实施,实施流程也是符合甲方要求的，甲方是通过CMMI4的，所以我们的项目实施过程还是蛮符合标准的 :)
存在的问题
- 风险跟踪：对于风险跟踪不足，未对相关风险标识状态。
- 需求分析：建议使用原型分析法。
- 项目经理工作监督：QA对项目经理工作的检查不是很完善。
- 资产库中工具需定时更新。
影响比较深的就是项目中出现的问题，首先要做到能够合理的定级，判断问题的轻重缓急，之后的处理过程中要，一定要定期的跟踪，跟踪状态,更新状态，直到问题解决。
项目中度量部分，包括人力成本估算， 工作量估算等 我们目前的状态就是根据历史项目结合当前项目进行估算, 缺乏历史项目数据的积累。
小结
毕业到现在一直在一家外包公司，前期一个人出差做一些技术支持的工作，基本上是单枪匹马，主要工作就是安装培训, Dos, linux , Windows各种客户端，给收银员培训，后来由于负责开发的同事心梗住院了， 客户端没人改， 只好拿来改改，还行，后续陆续开始修改后台相关服务模块。
这个时期犯了一个我现在还不能原谅的错误，修改windows客户端，开始使用标准版本修改， 后来负责该区域的人，说该客户端最好使用客户化代码修改。由于之前修改测试花了很长时间， 我把相关修改代码合并到了那个客户化代码上，没有再仔细进行回归测似乎, 导致客户当天的资金出现入账重复，还是公司大拿帮我解决了这个问题。但是后来他们很少让我碰过windows客户端。 当然也有令人振作的消息, 由于经常出差,接触客户女生居多，顺便把自己也给嫁了。 :P
接触后台部分改造后，有了新同事一起出差，2,3人出差感觉好多了,没有那么多孤独感， 在客户方开发，和客户关系基本都不错, 沟通需求，需求确认都很方便。
经常大吃大喝的，这个阶段吃出了脂肪肝。
再后来我们有了甲方总部的项目，家里也填了新丁 ,项目规模也越来越大，由开始的10来个人的后续知道现在50多人的规模, 这个阶段的最大变化是：总想自己去主导项目到帮助大家一起完成项目。还记得由于一个技术实现方案和开发的同事争得满红耳赤，总想着自己去拍板让大家都听我的。后来有了宝宝，感觉团队就像养孩子一样，得让他们有成就感，只要在关键部分做好把控，应该接受团队犯错。但事后及时的复盘和总结. 因为我也是在不停的犯错中成长的。
项目组由多个小组组成，各自负责业务不同，技术栈不同，有一部分历史项目需求较少，实施周期相对合理， 有些创新类型的项目时间要求很紧张，恨不得明天就上线。实施过程中对这些项目项目管理是根据不同小组，不同任务进行了裁剪进行了裁剪。我们此次认证还是找了两个比较典型的项目进行准备。CMMI还是比较适合指导和改进外包项目的过程的， 毕竟CMM模型本身就是DOD拿来评估分析软件厂商开发能力，以及评选合格软件承包商的工具.