一种融合CMMI和敏捷的策略的前进路线

本文的英文版为CMMI官方推荐文章《The Way Forward A Strategy for Harmonizing Agile and CMMI》，发表于2016年的CrossTalk。赵星汉学习兼翻译于2020年5月

摘要： 敏捷和CMMI就像是完全相反的两种范例——或许它们是否能互相融合或增强？敏捷和CMMI的临界点是什么？以及为什么是这样。在LinkedIn的博客里，敏捷或CMMI的支持者们都是如此的极力反对另一个学派的观点，以至于让两方理性的共存是一个不可能的任务，这种情形一直持续到如今。一种新的思维方式由Ivan Jacobson在Software Engineering Methods and Technology (SEMAT) and Essene Kernel提出，这种想法有助于解决这个难题。

准备这篇论文的目的是从实际出发说明发表于《软件工程方法与技术以及精华内核》的这种思考方式,并将CMMI架构和敏捷方法这两种截然不同的方法之间的问题在一个统一的架构应用内融合。

基础的机会价值主张，扩展和加速SEMAT and its Essence Kernel的传播和采用，将通过系统地将其应用到领先框架和方法的受众和用户群中来实现，从而影响和吸引新的支持者到SEMAT and Essene Kernel，以及它的思考方式，工作方式…最终转化他们。如今拥有数量最多支持者的方法架构是敏捷和CMMI,所以我们提出一种方法来调和这两者的紧张关系。现在的问题是，这两者的协调工作是否已经实现完成，或者正在艰难的推进中。

CMMI

CMMI是一个过程成熟度框架，而敏捷是一种软件开发方法。Watls Humphrey将软件过程看作制造软件产品的工具，方法和实践的集合，这里过程的质量大体的决定了软件产品的质量。而在敏捷中，敏捷和开发人员和用户将保持在一个相对封闭的环境，并专注于所分配的当前工程的必须的需求。任何其他的人和事件都被排除于环境之外。这一点与CMMI的从上至下的方式，全局范围联动，合规驱动和以组织为中心的文化形成对应。倘若与CMMI成熟度框架进行适当的融合共存，一个敏捷实施或许可以看成CMMI实施的一个实例。但是，大部分敏捷实践并不满足CMMI的过程要求，哪怕是最低的CMMI的2级过程要求。

软件的能力成熟度模型（CMM）为软件的过程改进提供了路线。而后能力成熟度模型集成(CMMI)将其扩展到系统和软件工程过程改进的获取、开发和维护方面。

在资本和垂直整合的倾向下，CMMI被全世界范围内的政府，军队和商业组织作为过程改进的标准采用。CMMI是一个通过过程绩效来聚焦保证产品质量的最佳实践框架。从最开始，CMM就避开基于实践的方法，而是采用整体框架。

从1980年代晚期的创新者和早期使用者开始，以及1990年代的逐渐作为主流，如今CMMI一直处在市场优势并蚕食落后者的市场份额，这时他们的主任评价员制度，如同工会的成员一样，试图通过与CMMI评估相一致而保持他们的市场份额，却忽视了更加重要的软件工程，软件产品工程，以及软件工程管理等以实际为基础的方法。

敏捷

而作为“新贵”的敏捷却并非如此，它的相对自由的市场，横向整合理论在市场中取得了如同“火山爆发”一般的巨大的颠覆性效果。敏捷在程序员中获得了更多的支持，它为从业者提供了一套可实施的方法，而不是简单的一个为企业中层设计的框架。不仅如此，敏捷还授权并赋予程序员对于他们工作路线的决策权，而这些以前在CMMI中是中层管理者的权限。总的来说，敏捷的价值在于选择的自由性,以及交付形式的改革，同时拒绝和贬斥合规性概念。简单来说，敏捷连接了做工作的程序员和用工作产品的用户，而CMMI连接了检查工作的中层管理者。

助推CMMI的价值主张

CMMI并不是没有价值，尽管美国防御部门（US Department of Defence)和一些原先的资助放弃了CMMI，但它拥有自己的支持者，并应得到更多的支持。缺乏稳定的资金支持，CMMI就像一艘满载珍贵货物的大船却找不到港口靠岸一样，直到重新修正它的机会价值主张。

这就是CMMI面临的窘境，在一方面被低估，一方面却被充分重视之间维持着平衡。透过这些挣扎，一些人致力于扩展CMMI的价值范围，并通过新的思维方式来重申CMMI的机会价值主张。现在正是时候来超越这个日益萎缩的市场，超越敏捷的分裂以及过度的主任评价员制度来践行Ivan Jacobson推出的对解锁CMMI更大的价值的可行易行的主张，并击破基于实践的方法和总体框架之间的限制。很少有组织发现他们现行的管理策略在敏捷小组中能正常适用的情况。进一步说，CMMI对于授权开发团队解决日常工作中遇到的问题几乎没有帮助。

协调的路径

一个敏捷的实例是不可能在非特定设计的情况下符合CMMI的规定的。一个敏捷的组织需要在目的和资源上做出详尽的规定来满足CMMI的规定。必须通过人员提供基于过程的证据,基于过程实施的验证，以及通过测量结果进行基于产出物的确认。这时一个艰巨的任务，而敏捷在开始时就是缺乏承诺的。

类似的，CMMI也不能在非特定设计的情况下就借用敏捷。相反，CMMI架构应该对敏捷的导向、内部观察、从下往上，本地化，需求牵引，小组集中文化和它的敏感性和自我管理进行准确的协调。此外，敏捷也应该对CMMI以及它的从上至下，全面研发，合规驱动，组织集中文化进行协调。所有这些也是一个艰巨的任务，而它成功的可能性取决于目前不具备的领导力。

回避一下现在宗教一般的狂热，或许我们需要一个立竿见影的方法来对敏捷和CMMI进行评估。例如，那种方法对处理目前面对的赛博安全的挑战更有效果？同样的，那种方法能处理更加严酷的其他挑战？如果不是简单的在敏捷和CMMI中保持绝对的的中立，那么这个问题的答案可能会围绕实践中赛博安全挑战所需要的各种专业知识来界定,比如软件保证（Software Assurance）、可信性和严格性等方面。敏捷和CMMI如何面对紧缩的挑战？敏捷依靠它的内部观察、自底向上、本地需求牵引，小组集中文化来解决那些紧缩。他们如何积累可信度和软件保证？

不论公司或者政府，现在的经济气候就是一种紧缩。这种紧缩和可负担的挑战开始于21世纪，对公司和组织起到了相当大的约束作用。与当下的时代保持一致，下一代软件工程的短期目标是驱动系统和软件工程能够利用智能和可信技术达到“做的更多，花费更少，时间更短”的效果。非常明显的紧缩目标是敏捷的长期手段。
软件保证只有在可信的前提下才有意义，也就是说，覆盖关键需求的可信软件部分需要特殊的软件部件、子系统和系统。软件保证在可信方面有两方面能力的要求，即生产可信软件的能力以及确认可信软件的能力。每一方面都对工程和技术层面有着严格的要求。软件保证的分层防御方法的核心是构建内安全性（Build Security In）以及严谨并可验证的正确运用（0，1）断言，沿构成主程序的多个主要子程序进行查验，这些子程序都应只有一个入口和出口。

架构 vs 方法

原始的CMM集中于软件过程，它的原型在1988年公布，目前已经废弃。CMMI公布于2000年，致力于软件开发，并将范围扩展到系统工程、产品采购（product acquisition)，综合团队(integrated team)以及需求开发方面。CMMI现在划分成了三个组成部分，成为了保证一个组织在软件开发（CMMI-DEV 2006），采购（CMMI-ACQ 2007）和服务（CMMI-SVC 2009）三方面能力的基础。现在CMMI的现行版本是1.3，它公布于2010年12月。（目前已经是2.0版本）

因为其起源，CMMI缺乏对业务调整与战略规划的明确关联，缺乏对企业重要价值的来源。另外，利用其从上之下的命令和控制决策制定，CMMI可以在一个封闭系统中运行的很棒。而在一个开放的组织环境中，有更多的自下而上的基于全体赞同的决策，其他选择或许更合适。当在CMMI的价值上附加上外部压力时，敏捷和迭代开发的优势在20世纪70年代起被认知，并在“六西格玛”中被广泛采用.CMMI的资源和价值区间被广泛质疑和测试。甚至Watts Humphrey也表示了关注。

被问及CMMI前进的方向时，Watts Humphrey赞同在高成熟度组织的效率方面存在问题，特别是在流程效率基线的使用和主任评价员模型方面。他为“程序上的（the what）”和“可操作的（the how）”的过程做了仔细的区分。但是，程序上的过程需要职能机构去贯彻；而可操作的过程需要教导一个自我管理的可信赖的劳动力去应用它的方法。

与培育革新的需求相一致，官僚性质的从上至下的评价驱动的合规可能让位给自下而上的多元化自我指导团队，赋予他们权力和自主权。正如CMMI聚焦于在过程执行中确保产品质量，敏捷处理如何在定义好的方法下构建软件，这个方法的重心在于提升顾客的满意度。相似的，六西格玛后来也提供了如何着重于在数据驱动决策和减少浪费的方面使用加工品模板，测量方法和控制图。

CMMI 价值

卡内基梅隆大学软件工程过程成熟度框架由五个级别组成。初始级别的特征是没有有序的过程和缺少期望。第二级是定义了管理软件支出、日程和变更的过程，维持项目承诺过程所需要的一切。第三级定义了技术过程，比如，系统设计和在组织中辅助其应用的技术转变机制，比如，软件工程过程组。第四级有初始过程和产品测量方法。第五级利用系统的过程测量来持续改进过程和产品。

CMMI的价值能在系统的角度得到更全面的认知，并最终取决于对一个企业的软件价值增长。软件价值更大的视角需要考虑系统工程和与其密不可分的软件工程中的必要的角色。总的来说，CMMI的价值是起到对于战略软件管理的促进作用。战略软件管理主要是围绕什么是顾客最需要的，调整最好的能力去提供它，理解正确的实践，测量它的关键参量，挑选最重要的承诺变化，计划持续改进，提升改进的能力，以及坚持到底。

(注：文章这里使用的是strategic software management，strategic可以翻译成“关键”，我觉得翻译成关键软件管理也不太对，所以这里我都翻译成了“战略软件管理”，欢迎讨论)

围绕战略意图、手段和测量结果，CMMI的价值能够被战略软件管理所撬动。战略意图声明可以直接在组织及其行业部门的业务管理，流程，工程和运营文化驱动因素的背景下进行阐述。CMMI与它的本地软件工程过程组（SEPG）及它的全球范围的主任评价员促进了一种组织文化，专业性的环境，和为维持世界范围内的使用和培养专业使用所设计的过程框架。Ivan Jacobson提出的思考方式提供了一种在全局范围内解锁CMMI隐含价值的手段。

SEMAT and the Essence Kernel

SEMAT formulation and its kernel是软件工程的本质和共同点。七个维度的共同点用Alpha（含义在后文有解释，这里的alpha快搞死我了）表示，连接到每一个Alpha的前进的序列状态是其基础。这些Alpha和状态独立于特定的方法、实践和工具，并因此具有不依赖任何方法和实践选择而引导前进和评估任何软件工程状态的能力。这个结果对于管理人员是友好且易于理解的。

客户(customer)空间由利益相关者的共同愿景构架，以构想出具有令人信服和相应结果的机会的合理价值主张。
解决方案(solution)由利益相关者绑定，这里的利益相关者同意了需求和用户故事，以及有利于操作和使用的软件系统结构。
工作(endeavor’s work)是由一支精挑细选，准备就绪的团队执行的，并且是一种基于既定原则和基础的工作方式

这些Alpha状态检查点是导向性指标，这些指标为这些Alpha状态建议令人信服和满意的结果。产品工作上的检查点被加上，是为了集成可信的软件工程期望。为了更好的结果，请遵循以下期望，取得基于实践的方法与总体框架之间的更好的平衡，全面的思考并实施本地化：

利益相关者之间达成一致并共享同一愿景。
建立一个机会价值主张，该主张由利益相关者的愿景来实现。
需求和用户故事是相关和被接受。它们都是为了实现愿景。
软件系统结构已经确定，该结构由一个用于指导软件实现领域特定的架构组成，并且该软件实现是准备就绪的且实施起来没有技术债。
团队成员间通力合作，共享工程愿景，准备执行共同的愿景，软件工程过程，软件项目管理，软件产品工程，操作支持，和领域特定结构过程，方法和工具。
团队的工作方式已经建立了软件工程过程、软件项目管理、软件产品工程和操作支持的坚实基础。
工作开始前，所有的准备工作应该完成，准备工作包括一致的用户需求，被认可的用户故事，意见统一的利益相关者，坚实的工作方式基础。
所有工作产品依据已定义的标准进行检查和准备，这个标准在完整性、正确性和一致性方面应是最佳的。

Alpha是Abstract Level Progress Health Attributes的缩写。简单但是高效，这些明确的alpha和它们前进的自然状态在引导一个工程实施和引导目前已经失去前进方向的软件工业时非常有用。更加特别的是，alpha和它们的状态序列（表1）包括：

利益相关者 - 被认可的，已代表的，已参与，一致同意的，已被满意部署的，已被满意使用的（这里翻译的不好）。
机遇 - 已经识别的，软件需要的，价值确定的，有活力的，已确认的，已形成好处的。
需求 - 已构思的，已绑定的，一致的，已接受的，已确认的，以满足的。
软件系统 - 结构已选择的，已证明的，可使用的，已就绪的，可操作的，已废弃的。
团队 - 以选择的，形成的，合作的，执行的，中止的。
工作方式 - 已建立的理论，已建立的基础，在用的，已保留的，工作完好的，废弃的。
工作 - 初始化，准备，开始，在控，总结，关闭

这些选定的里程碑是项目成功的指标。当这些状态的完成被忽视或推迟，工程的产品就会有很大的风险。表1展示了选定的对项目成败有关键意义的里程碑。

CMMI和精华内核

随着CMMI连接了监控项目的中层管理者，一个挑战是提供一个更好的方式来监控项目工作。SEMAT和它的精华内核以及alpha状态和他们的alpha检查点提供了这样的一个在CMMI和敏捷都可以使用的思考方式，它是一个工业界可以大范围应用的方法。使用人可以考虑如下的alpha状态检查点：

CMMI的利益相关方可以在卡内基梅隆大学和它的CMMI研究所的等级，主任评价员社区，Telecommunications的应用中的工业部门，金融服务，制造商、运输、医疗、公共工程和能源，电子商务，防务和那些在商务、管理、过程、工程和操作中的间接企业中被发现。因为如此多样，利益相关方的一致满意非常难以实现。

利益相关方 —— 识别，表示，涵盖，达成一致，满足部署，满足使用

不同利益相关者，机会价值主张也不同，而驱动他们的力量，如名望、经济、任务、竞争、外部资源、和优质保证也不同。因此，每一个利益相关者都有自己的机会价值主张，而他们的利益价值主张不可能一致。

机会 —— 识别，软件需要，价值基础，可行性，地址，应累算利益

用户故事围绕着策略目的，含义，和各类利益相关方的结果，包括主要指标包括能力控制，容量控制，变更控制，复杂度控制，缺陷归0，优化，预测性控制，质量控制，发布频率，可重复性，弹性、计划控制、跨度和响应，市场时机，可追溯性。因此，用户故事在持续的探寻结果上可能会缺乏一致性。

需求 —— 构思，有界限的，前后一致，可接受的，能溯源（这里的addressed我觉得应该是这个意思），令人满意的

CMMI的结构基于五个成熟度等级和每个成熟度的过程域要求。正是在过程域中，用户故事和利益相关者能被扩展来包含敏捷和赛博安全的条件。

软件系统 —— 架构以选定的，可论证的，可使用的，准备好的，可操作性的，报废的

CMMI是其采纳者的一种工作方式，横跨管理，过程，和工程。软件工程管理（SPM）是基于承诺管理范例：计划、控制、和测量。计划包含行为和产品，任务和反馈，以及支出和计划估计，挣值管理系统。软件产品工程（SPE）基于生命周期行为、方法和工具，这些内容在不论瀑布、增量和迭代的开发中都会使用。操作支持（OPS）是基于创造软件产品，该产品每次都能得到正确的响应，其使用的过程和其支出和计划有关，并确保软件产品和过程。领域特定结构（DSA）的成熟度由在应用领域中所记录的模型、方法和范例的广度和深度决定。

工作方式 —— 已建立的理论，已建立的基础，在用的，在布设的，工作良好的，废弃的

团队在一起工作，共享同一工程愿景，并准备好履行共同愿景、软件工程过程、软件工程管理，软件产品工程，操作支持和领域特定架构处理，方法和工具。

团队 —— 主任评价员，目标组织评价团队，评价团队已形成，评价团队训练，评价实施，评价报告完成，评价延期

工作集中于获取重要的产出，这些产出和用户故事和工作方式有关，该工作方式高于未来CMMI评价的预期。

工作 —— 初始化，准备，开始，控制，总结，关闭

工作产品聚焦于对完整性、正确性和一致性的完善和期望，具体有以下内容：

工作产品已作为工作方式的一部分定义。
工作产品已经被生产，共享于团队，已检查
工作产品是完整的，其部件可通过先前产品追溯
工作产品是正确的，它的部件已经被确认，且被证明是正确的。
工作产品在风格，记录表格，系统结构和构建规则上一致。
工作产品是有价值的，可追溯到用户故事和工作方式中的“完成”标准。

总结

融合敏捷和CMMI需要防范不可调和的矛盾点，将敏捷看成是一种方法来构建某一个工程的工作方式的基础，将CMMI看成是一个有用的架构，该架构的内容涉及软件工程的高层管理者承诺和组织管理能力，以及采用SEMAT和其精华内核的新的思考方式来评定工程进展状态和选择下面的步骤。

这样来说，在一个工程中需要作什么和预定的顺序和依赖关系模式分离。通过alpha状态转换解释项目进展和相似的选择下一步骤被留给项目组，并仅通过对实现机会价值的贡献来告知。

结合alpha状态期望，进行全局化思考和本地化实施，是非常有用的。在解决瀑布式生命周期的背景下，敏捷与CMMI之间的紧张根源与过早地满足需求相关联时，这就是最好的例证，所有这些因素都被认为是CMMI思维方式所固有的。通过本地化视角来看问题，以及通过工程团队选定的工作方式，团队可以选择没有需求就开始工作，部分需求就开始工作，或者在开始时拥有所有需求。

尽管如此，不论团队选择什么方法解决需求，alpha状态对于评估当前完成度和通过当前状态（包含构思，绑定，前后一致，受理，处理，满足等）来提炼下一步状态的期望很有用。总之，alpha状态的追踪透漏出工程的混乱边缘有多近，甚至是否无条件信任团队是明智的。

关于作者

这篇文章对于我有点难，里边很多词语和用法和常见的英语文法不一样，请大家对照着原文来看