敏捷与CMMI

        20世纪90年代末产生了以Scrum与XP为代表的敏捷方法。敏捷方法吸收了历史上各种软件开发方法中的最佳实践，如迭代、原型、用户驱动、时间箱管理等，并提出了轻量化过程的思想，以简化开发过程中的管理负担，达到简洁高效的目的。

        敏捷方法与以CMMI为代表的规范方法都是为了按时、保质地实现需求，殊途同归，目的相同，实现的方法不同。

        两种方法都认为每个人都会犯错。

        规范方法的管理假设是：通过遵循规范的过程可以降低犯错的概率。如何确保按过程执行了呢？需要QA进行检查。QA怎么检查呢？通过检查执行时留下的证据来验证是否遵循了过程。这些证据是否是最终用户所关注的呢？是否对最终用户有直接作用呢？未必！遵循过程的人员可能做了一些无用功，这些投入不是客户所关注的。

        敏捷方法的管理假设是：开发人员是有经验的、有智商的，不需要详细地告诉项目成员如何做一件事情，只要告诉项目成员做事的原则与目标，他们就可以自己根据经验判断应该如何做，应该如何实现目标，即使在过程中发生了错误，也能够及时发现并纠正。在这种场景下，不需要保留做事的中间证据，只要检查半成品或成品的质量即可。胜任工作与互相协同的人是敏捷方法的核心基础。敏捷方法强调好的结果胜过好的过程，因而敏捷方法更注重过程的速效性。敏捷方法强调在产品本身投入更大的质量成本，而非在过程的监督与执行上。敏捷方法期望客户实时参与、开发人员实时面对面的沟通，以便于进行验证与确认。规范的方法强调文字沟通、强调记录。敏捷的方法强调口头的、面对面沟通。流行的敏捷方法大都回避了对于质量保证活动的描述，而是强调了测试，强调了实时地对文档进行评审。

        如果说规范方法的管理假设是“人之初，性本恶”，敏捷方法的管理假设则是“人之初，性本善”。如果说规范方法是“中药”，敏捷方法则是“西药”。中药长于治本，重在预防，见效慢，效果持久。西药长于治标，见效快，立竿见影。

        很多软件项目的管理者、开发者倾向于采用敏捷开发方法，但是不能误解敏捷方法。敏捷方法不意味着没有管理，也不意味着不写文档，不要打着敏捷的旗号行“不作为”之实，从而玷污了敏捷的名声，正如以机械的行为玷污CMMI的名声一样。

        CMMI在实施初期往往编写了大量的文档，随着对CMMI的理解越来越深刻，与实际的结合越来越紧密，文档会越来越精简。

        敏捷方法在初期时，往往感受很简单，但是越做就会感觉越复杂，一个很简单的活动如果想做到位，有很多注意事项。

        CMMI的实践如同白开水，没滋没味。敏捷的实践如同陈年老酒，需要慢慢品，越品越有味。

        中药与西药都能治病，关键是看你得的什么病！只要对症下药，中西医结合可能更好！