敏捷开发和高级别CMMI

关键字:高级别CMMI敏捷开发

　　我经常和别人一起讨论敏捷开发过程的知识，并且我们也会经常争论结合使用敏捷开发过程和CMMI高级别的话题。他们两个是否能够结合使用？或者他们两个只是向相反的方向发展？带着这个疑问，下面我们一起来探讨。

　　“这个问题可以说是老生常谈，但是我对第5级别中的那个基本差异有一个疑问，这个疑问会使人产生不安的情绪。CMMI1.2强调了想在组织中控制结果的变更，进而将其重心转移到了个人的身上。敏捷开发在意义上说不单单是为了让每个项目能在应对各种各样的环境中都拥有灵活的能力，并且可以让他们在这个环境中尽其所能表现的最好。我们并没有特别关注在所有项目中要规范行为以便可以预知结果是“可靠的”。

　　但是，我并不清楚我现在尽力想说明的这种区别，是否确实是敏捷开发和CMMI的基本概念中的一个基础的区别，还是只是组织如何解释和执行CMMI第5级别的一个结果。当然，敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比CMMI团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的，但是没有假设说明这就是组织要走的路。事实上，敏捷开发支持者偏向于这样的想法，在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果。是否这就是等同说敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍，以至在组织中试图建立预见性的模型是无用的？”

　　CMMI第4级别：

　　QPM（量化项目管理）：主要关注懂得过程行为变更的个别项目，他们认为这些变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目标。组织单位（EPG）必须要监控成果。

　　OPP（组织过程实践）：主要关注集成模型，项目可以使用模型来规范他们想要达到成功的方面，比如说质量，进度表，预算，维护以及其他任何事情。诀窍就是项目在过程执行中以这些模型为基础，控制QPM中的行为。比较典型的是，这些模型可能是基于相似的项目中的重复的结果不断建立起来的，虽然可能并没有这样的需求。在个别项目级别中模型应该先被改进以便使用，所以在CMMI模型中使用基于一个项目的历史数据（比如说，增量）或者20个项目的历史数据是没有区别的，虽然这可能对使用者来说是有区别的。

　　CMMI第5级别：

　　CAR（原因分析与解决方法）：主要关注引起问题的主要原因，过失，管理问题或者其他一切需要解决的问题。项目，EPG或者其他任何人是否可以应用，是作为解决问题的方法。EPG在OPP中监控结果，或者得到别的经验。（敏捷开发是否在增量开始点或者结束点不建议进行类似的行为？我不清楚我所知道的术语是否正确）

　　OID（组织创新与推展）：完全非项目特点。关注基于个体，CAR，模型使用，外界因素等的组织改进。你是否会收集并且使用所有这些学到的经验？你进入企业后是否会寻求新的或者更好的做生意的方法（其中敏捷开发可能只是一个例子）？在组织中又该如何处理证明，分析（职业），和使用（结构请参照第4级别中的模型和过程控制）这些改进。

　　我个人认为CMMI高级别和敏捷开发应该结合起来工作。敏捷可以帮助CMMI高级别更容易实现短期的转变，并且它在处理事情的发展上起了很重要的作用。我的经验基本是从第5级别得来的，有部分来自第4级别。许多组织怀着“每个人都必须如此做”的想法而通过了第3级别，但是他们却反对在第4，5级别中有着同样的想法。就像我曾经提到的，敏捷开发是使用CMMI第4，5级别来改进如何发展产品的完美例子。

　　CMMI是Capability Maturity Model Integration（能力成熟度模型集成）的缩写，是在CMM（Capability Maturity Model能力成熟度模型）的基础上发展而来

　　三、CMMI实施

　　现在很多企业因某种原因想做CMMI了，大体做法

　　1、决定实施CMMI

　　2、EPG接受培训，理解CMMI

　　3、EPG根据自己理解的CMMI和实际情况开发一大堆漂漂亮亮的过程文档、流程图、表格、模板、检查单、作业指南。

　　4、大家边听着EPG的解释(包括培训、答疑)，边执行这些过程标准，然后审计(内、外)

　　将目前的最佳实践记录下来、写下来、文档化下来。

　　很多新的EPG在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员、甚至文档管理员。自己工作大部分时间是面对文档，或者督促别人写文档。

　　我到觉得EPG最主要的工作应该深入到研发第一线，帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度，而不应是单个问题或个人)，甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点，并主动记录下来。

　　为什么这么说呢?CMMI实施的主要宗旨就是以每个项目为采集数据的源头，达到企业整体效益提升和资源重用。真正有价值的东西，是需要一线人员在实际工作中遇到问题，解决问题，并总结问题，不是一个一线工作的流水帐。就象一份研发人员的日报。写了上午做什么，下午做什么。这对企业的积累有什么用处呢?他工作过程中，遇到什么问题，他是怎么解决的，走过什么弯路，实验过几种方法，失败了，失败的原因是什么，最后选择了什么方法，可能不是最好的，但完成了任务，达到了效率和资源分配的平衡。这些东西才可能是未来类似项目中，遇到类似问题时，可能有参考价值的。通常也是EPG个人职业生涯的技术积累。只有公司里每个员工，把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积累。而决不是形式上写的上午下午每个小时的流水帐。

　　明白了上面的说的CMMI的目的，做为一个合格的EPG，就应该具备以下的素质：

　　1、明白什么是有价值的积累，先是对你个人，然后才是顺便帮公司做了积累。

　　2、深入一线，发现她们并忠实地记录她们。CMMI里的SP、GP，只是帮助你，提醒你在哪个环节，哪些东西可能是有价值了。你去收集一下，别视而不见了。因为还有一个企业和你个人的角度不同，立场不同的问题。例如，REQM里收集需求，对个人技术方面的积累虽然不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到客户那里去签字落实，可能就会给企业造成很大的损失。做为一个合格的EPG，是需要有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的一个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。

　　通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为一个提高效率的好办法。但过去一个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组，今天晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素，甚至是开发人员常说的"手气问题"，"人品问题"。但这些是需要控制的，也是通过经验可以控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。

　　那怎么解决这种两难的问题呢?逼着技术骨干写心水，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下：

　　公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JAVA组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和"顶"的人数来说明谁写的是心水，谁在写垃圾。大家都是一个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢?

　　EPG适时的评估大家的成果，并把他们分到项目里。帮助项目总结，甚至在平时遇到问题时，直接帮助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。

　　EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。

　　四、CMMI实施之核心

　　关键字：CMMI，SCAMPI，过程改进，能力成熟度，EPG，PA，过程域

　　前面我们谈到了关于过程改进团队的组建方法及在组建过程中需要注意的问题，在本节中我们将继续探讨EPG过程改进的另一个更为重要的一环——定义过程文档。

　　曾经有一位评估师开玩笑说，三级是写文档，四级是写文档的文档，五级是写文档的文档的文档。由此可见，文档贯穿于整个CMMI，在过程改进中起着举足轻重的作用。那么如何才能写出既符合CMMI又立足于企业本身实际情况的文档呢？这就是本文将要探讨的问题——定义过程文档。

　　在定义过程文档时，首先，应该进行企业的习惯表述与CMMI术语和语言间的映射。特别是组织结构中的一些术语、角色、组织内部之间关系以及过程活动的表述方式都需要映射到其组织的相应部分，以防止别人无法理解。

　　定义过程文档的一般步骤是：

　　（1）先确定并描述产品的生命周期。

　　一般来说，产品生命周期可以划分为6个阶段，即产品概念阶段、产品定义阶段、

　　产品开发阶段、

　　产品测试阶段、用户验收阶段、产品维护阶段。