跟胖子一起学裁缝

我不想给大家造成一个我是cmm死敌的印象，因为我从cmm中吸取了很多有益的思想。可以说我对cmm这个标准的态度是全盘否定的，但是对于其背后的很多思想和思维方法是非常支持的。今天我就用一些cmm所使用的思想来对RUP做个手术，让大家同我一起分享我的过程。同时我也做个预报，下次我将使用Alistair Cockburn和Highsmith的方式从头建立一个新开发流程。
任何的过程要素，不管你是要改进也好，还是要新建也好，在cmmi模型中都用术语“required”，“expected”，“informative”加以区分。使用台湾的翻译，required为必要的，expected为期望的，informative为助益的。我手头的一本由周伯生等翻译的《cmmi精粹》，则将informtive翻译为用于提供信息的。我认为这两种翻译都陈述了informtive的重要内容，其核心内涵是一致的。从我的观点来看，required当然是最重要的部分，也就是任何的方法都必须具有的那些核心要素。比如针对敏捷，则就是四个原则思想；针对xp则是单元测试，和代码公有；而对FDD来说则是使用feature。而expected则是希望能具有的（既然是希望，当然也就是可选择的，或者说也是可不选择的）。针对敏捷来说，就是那16条；对xp则就是tdd，重构，持续集成，pp等等；而对FDD则就是领域建模，主程序员机制等等。而informtive则是为你现在做的和下一步做的提供基础信息的部分。这些部分在agile方法系统下都是比较少的，这大概是因为agile都信奉KISS的缘故。例如在FDD，彩色建模就是属于informtive，同时crc卡也可以看作一种面向xp和fdd等方法的informtive。
而关于过程改进，在cmmi这里提供了两种表示方法，一种是阶段性的——也就是原来cmm的分级的方法，一种是连续方式的。为什么sei会在cmmi中提出一个连续方式的表示法呢？实际上过程改进中很多部分，比如需求工程，scm都是一个连续性的，持久存在的需要解决的问题，也是一个经常性的双方向的可条件的部分。比如一个scm系统，今天可能面对的是一个9k行代码的系统，通过一段时间可能会膨胀到200k行，而随后由于使用了某些新技术（比如ror了）一下子又降低到了5k行，其使用人员也是随着进展而不断动态的调整的。因此我们针对一个区段制定的scm制度就不能满足所有的时段的需要，而同时我们也不能说scm总是会从能力低级到高级单项前进，而应该认为以满足当前情况的能力水平为最好。当然我这个分析，和cmm分级的方法所认同的思想是有所抵触的。而在实际的操作中，我们也会发现开发流程中的某些部分是存在这样的持续性的情况的，特别是那些required元素往往都是持续性的。
而阶段性的提法实际上我也很认同，毕竟针对一个相对稳定的组织来说，任何的方法改进都是阶段性的。当然我认为cmm提出的阶段性是值得我们探讨的，或者干脆的说cmm所说的12345的做法是有问题的。cmm的一级是表示公司依靠有能力的精英；而二级则是可重复的或者说具备了基本的项目管理；三级则是已经定义的，也就是说过程已经被组织内部标准化了的；四级则是已经被管理的了，也就是定量了的；五级则为优化了的，也就是支持持续性改进的了。在我看来这提法都具有相当的价值，都是值得我们去追求的。但是以这个顺序出现，是我所不同意的。实际上周芝英教授早就提出了cmm太极的看法，我认为这个说法是很合适的。不过我也认为，实际上这些要素也是存在一个优先实现的级别的，从而使得我们可以按照其一般的顺序继续进行工作。我认为首先要做到的就是优化的，也就是说必须在早期就建立一个指导过程改进的思想体系，制定出基本的原则，确定基本的组织层面的统一的世界观。比如我们可以在早期就确定我们将使用agile的思想建立一个开发流程，遵守KISS原则。而第二级则是被管理的，也就是建立一套测量企业过程的参数系统。这是因为任何的方法改进，都必须经过检验才能确定其实施的效果，从而得到反馈，从而进行总结并制定下一步的计划。如果将这个工作推后，则你就往往只能是摸着石头过河，而且也往往不能对与过程中的争论做出一个比较客观的评价。第三级则是被定义的，也就是企业内部已经达成共识，或者说具有了统一的方言系统。这个阶段显然会造成企业内部的人员的分化，也就是说有些人会适合这个系统，有些人会不适合这个系统，而这也就是方法的一个重要作用。而第四级则是可重复的，也就是组织按照上面的系统持续性的保证在一定范围内重复操作，同时又不会阻碍新的过程改进工作。这个阶段，那些适合的人和不适合的人将被明显的区别开来。第五级则是精英化的团队，或者说外科手术的团队。由于有了从第三级开始的区分，从而将那些真正的精英人员沉淀下来，并且促使那些非精英向精英转变，并且剔除那些不思进取不能适应的人员。在这个阶段，管理成本将大幅度的降低，人的效率将最大限度的提高，并且新的员工将能够有一套完整的培养的过程。

实际上上面提到的仅仅是cmmi这个系统中最基础的部分，其价值可见是很重要的。如果我们使用上面三个思想方法就可以对面前任何一个方法进行裁剪，例如RUP。
例如业务建模这个过程，在RUP中我们就可以确定其为expected的。而业务建模出品的工件——业务词汇表，业务用例模型，业务分析模型则都可以认为是informtive的。而我们则就可以根据具体的情况有选择的进行取舍。比如很多时候业务用例就可以作为需求工程中的用例，而业务词汇表如果不是需要持续性长时间的在一个领域内工作则就可以在用例中作为注解出现。而业务分析模型则在大多数非复杂性的业务面向的项目中进行省略。
而如果你是面向一个领域进行产品的开发，则上面三个工件无疑其重要程度就会大大提高，并且其工作往往也就成为持续性的工作。而持续性也就带来了阶段性的问题，也就是说你的业务词汇表不必一开始就建立的那么完整，而也不必最终建立得那么完善，而是要将其由简单到复杂再精简这样一个阶段性的过程进行制作。
实际上在第二级的很多工作就是进行informtive基本的元素进行选择的过程，而这个过程可说是一个过程改进的基础。而第三级别则是一个选择expected方法的过程。第四级是一个实现expected并将其集成起来的过程。而最出的一级则是进行思想同意，建立共同的信仰基础，并且确定required的过程。

我想大家如果有兴趣可以使用我上面提到的方法对RUP做一次裁剪，这也算是我对RUP裁剪争论的一点自己的贡献。

呵呵,只差我这一票就是精华贴。

字数不多，内容不少，理解中...

按照“required”，“expected”，“informative” 或者一二三四五级 裁剪确实很有必要，不然最重要的原则没有遵守到，反而只做了一些细枝末节。
问题是裁缝们还没开始开裁，这帖子就变成了精华是不是快了点...

我其实是希望拿RUP来做样品进行一个演示的，但是这样一个工程就太大了，而且需要结合具体大实际项目，我做这么一个演示就付出太多了。

如果裁剪完就不仅仅是演示了，所以您可以慢慢裁，慢慢剪。
每一步我觉得都可以产生启发的，未必要全部完成。

其实上面我就已经对业务建模做了一个小演示了。只不过RUP系统的产品和工作流太多了，我真的没有办法做太多的演示。

要不是TW的同学缩头缩脚，不肯出头，哪里需要oz6来顶这个缸啊，呵呵。

还是TW出头发起敏捷与CMM的论战更好些。不过TW的同学好像更喜欢在小圈子里面的交流。

CMM对开发人员侵入性也是一个问题，这不符合好的面向对象原则。开发人员并不理解为何CMM每天要求他们做的一些事情是有价值的，貌似这些事情纯粹是做给管理者看的，并不会对于为用户交付更多的商业价值带来任何好处，甚至还会影响开发效率，损害为用户交付更多的商业价值。

敏捷方法的最佳实践，至少是开发人员很容易理解和愿意予以配合的。TDD有何价值，重构有何价值、持续集成有何价值，很容易理解，看的很清楚。对于我来说，我完全无法理解的事情，很多时候都会采取非暴力不合作的态度。

最好将一些管理过程对于开发人员的影响降低到最小的程度。内用黄老，外释儒术。对于开发人员的管理完全采用敏捷的套路，外面再设置一些人（专门的PIG）专门加以包装以符合CMM的标准。但是这些PIG人员与开发团队并非是管理者与被管理者的关系，而是平等的伙伴关系，他们并没有至高无上的权力对开发团队任意指手画脚。

这样以来，开发人员也愉快，那些对过程改进极其热衷的PIG成员们也愉快了。

有一个前提两方面必须达成共识，那就是市场需求和为用户交付商业价值永远高于过程改进。

实际上现在大多数公司过CMM都是因为市场需求（可以将这个东西拿来作为一个开拓市场的工具），而不是这个东西真正能带来的价值。包括做CMM认证的公司在内，大家都是骗。像oz6这样认真思考这些问题的人是极其罕见的。