敏捷PK CMMI：软件工程的关公战秦琼

打小儿爱听相声，特别偏好侯宝林大师的段子，尤其是很多和京戏相关的。大师扎实的科班功底，把老北京的雅俗两大艺术完美的结合在一起，其代表作《关公战秦琼》更是以极高的艺术技巧，强烈的幽默感，给听众留下极为美好的印象。话说韩复榘给他爸爸做寿，堂会点了‘千里走单骑’，可是这位“寿星老”不愿意听红净戏，非说关羽关云长是山西阎锡山的队伍；想知道是关公的本事大？是山东好汉秦琼秦叔宝的本事大？也不论关公是汉朝的，秦琼是唐朝的，就点了一出‘关公战秦琼’。

引起我儿时记忆的，是11月21日参与的一次非常有趣的过程改进研讨活动，CSSPI2009第八届中国系统与软件过程改进年会中的一个精彩环节——CMMI &敏捷PK赛——金融危机之后，在危与机并存的背景下，软件工程理论体系的两大流派CMMI和敏捷急需得以反思；CMMI在引入中国之后，在软件过程领域产生了深远而长久的影响，改变了整整一代致力于IT行业发展的有识之士的思维，同时也得到了政府的大力推进；敏捷在CMMI引入中国之后，逐渐地走入人们，尤其是开发人员的视野。为了厘清CMMI以及敏捷之后的林林总总，CSSPI2009特地邀请了在两方面颇有建树的专家进行一次面对面的碰撞。

当天的活动气氛热烈，主持人妙语连珠，激辩双方唇枪舌剑，甚至是台上辩手、亲友团与台下观众“群殴”。既有郑人杰老师这样的老专家的认真点评，也有初出茅庐的程序员的热情参与，包括Moto公司内部CMMI执行部门与敏捷实践者之间的内部PK。不过，透过热闹的表象，抛开精彩的主持表现，“敏捷PK CMMI：软件工程的关公战秦琼”，这个命题却越来越清晰的浮现在脑海。

作为候补的SCAMPI主任评估师，自2002年接触CMM模型以来，逐步积累对CMM/CMMI体系的深入认识，尤其是今年来参与的多次SEI主持的培训和考试，让我对CMMI模型有了更深刻的理解。作为美国DoD资助的科研机构，SEI推出CMMI模型的本意就是提高美国军方采购供应商的软件研发能力和成熟度，其立意就是要“集成”全球软件工程领域的最佳实践，这一点在CMMI模型的序言中，开篇第一句就进行了描述： CMMI (Capability Maturity Model Integration) is a process improvement maturity model for the development of products and services. It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance. 所以，对待二十世纪九十年代逐步萌芽的敏捷方法，SEI一向是采取“拥抱变化”的开放心态给与关注。

在SEI的官方网站上，自2006年以来，每年都有相关敏捷方法的研究成果：

• 2006：Agile/Lean Development and CMMI
• 2007：My Agile Life with CMMI
• 2008：CMMI with Agile, Lean, Six Sigma, and Everything Else
  • CMMI-Agile
  • CMMI or Agile: Why Not Embrace Both!
• 2009：Love and Marriage: Why CMMI and Agile Need Each Other

其中，SEI08年发布的报告——“CMMI或Agile：为何不能彼此相拥！”，提出了在软件开发项目中如何将CMMI和Agile的理念及实践相结合的课题。

让我们重温一下《敏捷宣言》

• 个体与交互 重于 过程和工具
  
• 可用的软件 重于 完备的文档
  
• 客户协作 重于 合同谈判
  
• 响应变化 重于 遵循计划
  

《敏捷宣言》背后的12条准则：

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4. 项目过程中，业务人员与开发人员必须在一起工作。

5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7. 可用的软件是衡量进度的主要指标。

8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。

10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11. 最佳的架构、需求和设计出自于自组织的团队。

12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

一个简单的比喻，《敏捷宣言》中无处不散发着程序员“反抗”既有软件工程体系对他们的“管理”或“压迫”。即使在软件工程已有的方法论、工具和人的三角理论中，既有的方法论似乎更多的是将程序员“臆想”为懒惰、自由散漫和没有责任心的角色，却没有想到真的该探索焕发程序员积极进取的无比创作力会给组织带来多么光明的前景。最简单的道理，作为软件企业的老总，想想手下有几个合格的PM或QA？他们的觉醒和企业里全体程序员、测试员的觉醒，哪个将决定公司的命运？只有质量意识和服务意识真的深入员工的每天的工作中，才有可能保证企业的持续改进。因此，敏捷方法的引入，绝对不是培养几个ScrumMaster或者引入个开源工具这么简单是事情。敏捷的生命力就在于它广阔的“群众”基础和无限的“群众”智慧。

起来，饥寒交迫的程序员；

起来，全世界受苦的IT人！

满腔的热血已经沸腾，要为敏捷而斗争，

旧世界打个落花流水，程序员起来起来，

不要说我们一无所有，我们要做天下的主人！

这是最后的斗争，团结起来到明天——A-G-I-L-E，就一定要实现！

---

止于至善的博客 http://tyou1215.csai.cn/