TAG:
|
在公司顺利通过CMMI level 3的评估之后，我负责组织的稽核工作并帮助进行流程改善，但在公司推行实践的过程中，总感到有些压力和力不从心，不过毕竟，改变原有习惯，强调Process Control，CMMI究竟是轻量级还是重量级的使用等等，都是需要一个持续改进的过程的。我们既不能不论公司的实际情况，将CMMI仅当成了一种实施手册和准则，好像削足适履那样，也不能评估过后，连CMMI的思想概念精髓也随之抛弃脑后。CMMI并没有错，CMMI要求写一大堆文档的初衷很好目的也很明确，具体到项目中自然有执行上的限制和区别，但它的核心价值是不可抹煞的。我们不能提到CMM就只在文档上打转，而毫无利用其中的资源。我们所需要的正是CMM所提倡的Identify it, Control it的思想。或许1~2人的小项目根本没必要用CMMI,但如果我们没有将CMMI的概念刻在脑里，同样保证不了项目最后的成功。
CMMI的观点能保证项目在正确轨道上运行，更能保证一个软件公司持久地有条理地运作。我们有时候总是说，AXDC的项目类型太多，太杂，基本每个项目都不一样，所以我们做积累，做measurement好 像都毫无用处，但其实恰恰相反，每个项目都有它的特点，也有共性，在管理层次，它们的共性提供了跨项目的衡量标准的连续性。这些数据是珍贵的，是一个从来 没有执行过类似规范的小公司不可能拥有的。从文档上看，已有成功项目的模板确实很重要，因为很多后继项目很快就能上路了，一定程度上就得益于这些模板的帮 助。 今天偶尔看到了几篇关于CMMI与敏捷的几篇文章，感到有些共鸣，因而将其观点叙述等摘录如下，算是读书笔记吧。
CMMI与敏捷
最近在看bob大叔的敏捷软件开发，结合以前公司采用CMMI软件过程体系记录一下自己现在的认识：
CMMI相当于古代的对阵沙场，只需要有主将，其他的有几个辅佐的将军，剩下的就是各种军种，两军对垒的时候套路都是一样的，先出什么兵种（弓箭兵压住阵脚），除了主帅和将军，其他的并不需要英雄，只是遵守纪律的作战士兵，保持的是整体如一。
敏捷就像现在战争中的小分队，或者古代战争中的侦查兵，或者电影中的杀手，他们只有目的，没有具体的一个过程，因为过程是瞬息万变的，需要随机而变，他们每个单兵都需要有非常高的职业操守和职业技能，需要迅速的对当前的变化作出反应，改变自己的策略。
我理想的开放体系是裁减CMMI众多的过程，项目初期引入敏捷建立原型。
对于稍微上规模的国内公司来说，敏捷基本是不可取的，因为他太依靠极个别的牛人了，过内地开发环境如此的浮躁，人的流动如此的频繁，把公司的基础建立在几个人身上，是非常危险的，需要考虑到公司的资产能够文档化的保存，因此CMMI是很多公司的管理层推崇的。对于开发人员来说，CMMI太 过于沉重，需要大量的文档化，认为文档是没有技术含量的，就跟写报表一样。其实写出一份好的文档，才能见到真正的功力，首先要有清晰的逻辑，然后能够有好 的思路整理成文，能够让新加入到人一看就懂。报表也一样，报表是给用户中的领导看的，是非常重要的，毕竟每个公司的领导才是拍板的人。 敏捷对于人的要求太高，而国内更多的是一批又一批的新人进入项目做开发，稍微有点经验的都去管理了，所以敏捷至少在目前的环境下是不适合国内的国情的，真正的过程还是做了大量裁减后的CMMI开发体系。当国内的开发人员不再浮躁，敏捷才有可能在开发中伸展拳脚
CMMI和敏捷的一些对比
1. 组织关注焦点
CMMI - 关注组织级过程能力，所有的项目和团队的产品或服务的开发都将从组织过程能力提高后受益。
Agile - 焦点是项目和团队，即使组织不成熟，项目和团队仍然可以成功。
2.管理
CMMI - 系统化的管理思想和模型应用，特别是集成了各种计划的项目管理，包括风险管理。
Agile - 管理更多起的是教练作用以消除壁垒，敏捷的这种方法也可以延伸到大项目管理中。
3.信任
CMMI - 一些CMMI的实践和方法制定的目的是假设了一种低信任环境存在的可能性。
Agile - 敏捷团队中成员在组建新项目前已经合作的很好，敏捷团队是一种高信任的环境。
4.计划
CMMI - 计划在是组织标准定义上加上项目目标的自定义过程，强调完整详细计划，虽然不否认可以迭代。
Agile - 强调计划是分层次的，包括产品计划，项目计划和每次开发迭代计划，每次迭代版本的计划一般会在迭代前做的很细化，而且敏捷强调看板式进度可视化，弱化网络图和关键路径等方法。
5.市场和用户假设
CMMI - 在已经稳定和成熟的市场将发挥最大作用。如标准的软件外包等。
Agile - 在已经紧急临时或不成熟的市场和需求变化较频繁的情况下将发挥更大作用。
6.设计假设
CMMI － 强调产品架构已经确定和创建，处于一种稳定的状态以减少估算不确定性。
Agile - 架构往往会在敏捷开发过程中根据需要进行灵活的裁剪。
7.学习
CMMI - 学习无处不在，包括组织级和项目级，包括计划，需求，开发，评审，复盘等各种活动。
Agile - 发生在项目级，典型的是由底向上的问题驱动性学习，虽然有效但是并不系统。
8.愿景
CMMI - 期待的是组织和项目长期的过程改进和能力提升，而不是一个项目或版本的改进。
Agile - 更多关注的是当前项目的成功。
9.人力资源
CMMI - 关注重点是组织级和项目级，CMMI提倡非英雄主义，过程成熟的时候无英雄项目也应该成功。
Agile - 强调人的重要性，强调仅仅雇用优秀的人，强调工作和生活平衡的高效团队。
10.失败成本
CMMI - 系统工程学的方法，类似航天，飞机和医药等高失败成本的项目更加强调采用。
Agile - 即使项目失败，担负的失败成本会比较低。
敏捷与CMMI：双剑合璧，更具威力！
许多人认为敏捷与CMMI是极端对立的，彼此抵消对方的成效。在传统方式与敏捷框架之间一直持续的论战中，各自的支持者纷纷列举出与对方水火不容的观点。但是这种对抗的态度不但毫无道理，也会对我们的工作-在尽可能短的时间内开发出高质量的软件-产生妨碍。想要获得最好的投资收益，最好是创建一组混合模型和方法，选择合适的技术来应对特定的挑战。
CMMI回顾
能力成熟度模型集成（CMMI）是一个过程改进方法，它为组织提供了实现高效的过程所必需的基本元素。它可以用来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往各自为政的组织功能，建立过程改进的目标与优先级，指导我们进行质量改进，还提供了评价现有过程的参照点。
有趣的是，创建CMMI的初衷是为了应付一些软件开发相关的问题，而提出敏捷实践也是为了解决这些问题。
对新一代的敏捷实践者来说，CMMI似乎太臃肿、太枯燥、太缺乏创造性了。有人批评CMMI太官僚，过于关注过程而不是问题本身，削弱了应付日益严峻的需求变更的能力。同样，也有人批评敏捷对开发过程控制不力，导致隐性的变更和混乱。
CMMI提出，在组织中必须建立开发过程，必须采用同行评审来提高质量，必须有版本控制系统。如果我们发现一个跨国公司至今仍缺乏这些基本的“常识性”的控制手段， 肯定不只我一个人会感到震惊和失望。如果能合理地应用两种方法中的原则、方法及技术，我们不至于陷入两难的境地。然而，要在现有的成熟度级别上同时应用敏 捷，以及为敏捷团队找到最佳的成熟度级别都会是挑战。
实施敏捷的最佳时机
一项敏捷实践应该经过裁剪以适应组织实际的成熟度级别；特别是，如果组织的成熟度处于CMMI第3级，实施敏捷不但可以获得敏捷带来的重要好处，还可以减少返工，并全面提高推行CMMI的积极性。如果实施的软件开发过程既能遵循CMMI规范，又能符合敏捷原则，我们就可以真正获得CMMI提出的可重复性和可预测性的好处。敏捷特意设计得非常灵活，因此它可以在不违反敏捷宣言所规定的主要目标的前提下，裁剪为遵循CMMI规范的软件开发过程。
当成熟度处于CMMI第3级， 组织应该已经选定了适合团队及环境的过程，这些过程主要关注如何交付可正常运行的软件。此外，针对特定的项目，还要从组织的标准过程集中裁剪出相应的标 准、过程描述及流程。因此，实施敏捷的主要工作就是为集成敏捷实践而修改那些标准过程。实施敏捷的风险集中在管理开销上，因为组织的管理模式可能会限制团 队的自主决策权及灵活性。 在CMMI第3级上实施敏捷的挑战
如果成熟度未达CMMi第3级，说明组织缺乏稳定的项目管理、需求分析及配置管理相关的过程。正因为企业各个方面都缺乏训练，要实施敏捷还得提供缺失的软件开发过程。如果组织的成熟度未达CMMI第2级， 过程常常会因为人为原因或外来事件而被迫改变。在这样的环境中，敏捷项目可能会成功，但成功的经验不见得能重用。如果组织没有一种稳定的环境，可能是因为 组织还不清楚建立这样的环境需要哪些东西。这导致成功依赖于个人的专业知识、能力及英雄主义，而这些成效却可能被团队的其它因素抵消。
如果组织的成熟度高于第3级，流程已经基本可以在组织内通用了。这种情况下除非大幅改动那些在CMMI第4级中必需的成文的流程，否则敏捷所带来的灵活性将非常有限。其实，管理层希望能迅速找到合适的度量来控制项目的成本、进度与范围，而敏捷项目的进度已经是可视的，这与管理层的意图已经非常吻合了。此外，成熟度第3级与第4级之间的一个重大差别就是采用某组过程后的效果的可预测性：对于后者来说，过程的效果是通过统计及其它量化技术来控制的，可定量地预测。所以现在我还没兴趣在成熟度已达CMMI第4级的组织中推行敏捷。
结论
至此已经写了够多的内容来讲明CMM与敏捷实践之间的关系和协作效果。为了取得最好的效果，学习CMMI的各个过程域、各个成熟度级别并掌握如何在敏捷与CMMI之间过渡的能力非常重要。
Lydia (Lydia) |