敏捷和CMMI的另一种观点

Another View of Agile and CMMI

敏捷和CMMI的另一种观点

by Paul McMahon

作者 Paul McMahon

While in some cases I agree it is "easier to incorporate agile practices into an organization assessed at CMMI level 3 or higher than to move an agile project team into CMMI," my experiences indicate that this is not always true.

对于“在那些通过了CMMI 3级以上评估的组织中加入敏捷实践，要比将敏捷项目团队转为CMMI更简单”，尽管在某些情形中我同意这一观点，但我的经验表明：也并不总是这样。

I am helping a number of organizations with high CMMI maturity (levels 3, 4, 5) become more agile. But I am also helping small organizations that started out agile to use the CMMI model for process improvement. Last year I participated in a formal appraisal for a small company that is very Scrum-oriented, and they achieved a CMMI level 3 rating. If you use the CMMI model as it was intended, I don't believe you have to "move the team into CMMI."

我正在帮助很多具有CMMI高成熟度（3、4、5级）的组织变得更敏捷。但我也在帮助一些小型组织开始在敏捷之外使用CMMI过程改进模型。去年，我参加了一家非常面向Scrum的小公司的正式评审，最后他们取得了CMMI 3级的评分。如果你像CMMI模型所打算的那样使用CMMI模型，我不相信你必须“把团队转为CMMI”。

The CMMI model is a reference framework for process improvement. It isn't a set of required practices. In the case I mentioned, we didn't change the behavior inside the small company, except in isolated instances where change was clearly beneficial. For the most part, we demonstrated where what they do (largely Scrum) meets the intent of the level 2 and level 3 reference practices. To accomplish this requires a good understanding of the CMMI model, including the use of what is referred to as "alternate practices."

CMMI模型是过程改进的参考框架。它不是一组必须的实践。在我提到的这个例子中，除了那些修改的益处非常清楚的孤立情形之外，我们没有修改这家小公司内部的行为。对于大多数情况，我们都证明了他们所做的事情（大部分是Scrum）在哪些地方符合了2级和3级参考实践的意图。想要完成这一点，要求必须对CMMI模型有着很好的理解，其中包括使用：引用的“可选实践（alternate practice）是什么”。

As an example, the agile daily standup meetings can be viewed as an "alternate practice" within the CMMI model. These daily meetings along with the follow-up actions by the Scrum Master can achieve the intent of a number of the specific practices within the Project Monitoring and Control Process Area.

例如，敏捷的每日立会可以被看作是CMMI模型中的一个“可选实践”。这些每日的会议带有由Scrum Master负责的后续行为，这一点实现了项目监督和控制（Project Monitoring and Control）过程域（Process Area）中的很多特定实践（specific practice）的意图。

User viewings meet part of the need for stakeholder involvement, which is an important aspect of the Project Planning and Requirements Management Process Areas and the Generic Goals within the CMMI model.

用户观察（user viewing）符合了对涉众参与的部分需要，涉众参与是项目计划（Project Planning）和需求管理（Requirements Management）两个过程域的一个重要方面，也是CMMI模型的共性目标（Generic Goal）。

With respect to reflections workshops, the CMMI model actually recognizes that change is a good thing. It expects the team to capture lessons learned and improve the process. So reflection workshops provide lessons learned, feedback, and improvement, as required within the generic goals of the model. The one subtle difference is that if you are going for level 3, then improvement recommendations that come out of the team should not be limited to the team but should also be communicated to the organization level so that other teams in the organization can benefit from what you have learned.

在反思研讨会方面，CMMI模型实际上认可了变更是件好事。它期望团队能记录那些学到的经验从而改进过程。因此，反思研讨会提供了学到的经验、反馈和改进，这正是CMMI模型的共性目标所要求的。有一个微妙的差别，在于：如果要达到3级，那么团队所提出的改进建议不应只限制在这个团队上，而是应该告知组织级，这样，组织中的其他团队也能从你曾经学到的经验中获益。

Attaining CMMI level 3 doesn't have to mean more detailed process definitions. It means that the processes that work for an organization are shared across that organization and adhered to. Nothing says they can't be "agile processes." Institutionalization is an important part of the model, which means the processes don't break down in times of crisis and aren't ignored when new people are brought in. In my view it is often easier to institutionalize agile practices because agile teams usually believe strongly in how they do their job.

获得CMMI 3级并不一定意味着有更详细的过程定义。它意味着，对一个组织起作用的过程应当在这个组织中共享和支持。没规定说这些过程不能是“敏捷过程”。制度化（institutionalization）是这个模型的重要部分，这意味着过程不会在危机来临的时候瓦解，也不会在引入新人时被忽略。在我看来，让敏捷实践制度化往往更容易，因为敏捷团队通常强烈地相信自己完成工作的方式。

As another example, the agile company I have been helping has an open communication culture where lead engineers aren't afraid to walk into a senior manager's office as soon as they know they have a risk or just need help. The team members are also encouraged to raise risks at the daily standup meetings, and they often do.

还有另一个例子，一家我帮助过的敏捷公司，它有着开放的沟通文化。在那里，主任工程师只要知道自己有某种风险或者只是需要帮助，就会毫不害怕地走进高级经理的办公室。公司还鼓励团队成员们在每天的立会上提出风险，而他们往往也会这么做。

At first, based on the Risk Management Process Area in the CMMI model, we created a form to capture risks more formally, but the form was not well received in the organization. So instead we defined a risk process that captured exactly what the team does and then trained new personnel in the organization's expected risk management behavior. We did require that they capture their risks in a periodic briefing to Senior Management, but we continued to encourage the informal and immediate communication that was already working well.

首先，根据CMMI模型中风险管理（Risk Management）过程域，我们创建了一种表格来较正式地记录风险，但组织对于这一表格接受得不太好。因此，我们另外定义了一个风险过程来真正地记录团队做了什么，然后对新人培训组织所期望的风险管理行为。我们确实要求：他们定期简要记录他们的风险，交给高级经理，但我们继续还鼓励那些已经很好地发挥了作用的非正式的及时沟通。

Our lead appraiser had no trouble at all with processes like Risk Management that clearly were institutionalized across the organization and met the intent of the process areas - as long as the "direct artifacts" and "affirmations" substantiated the effectiveness of the process (direct artifacts and affirmations are discussed later).

我们的主任评估师对于像风险管理之类的过程没有问题，因为情况很清楚：这些过程已经在组织级制度化了，并且符合了这些过程域的意图——只要有“直接工件（direct artifact）”和“访谈证实（affirmation）”证实了这个过程的有效性（关于直接工件和访谈证实将在以后讨论）就行了。

My experience has been that when we try to "formalize" effective processes, too often this results in negative side effects because we unintentionally change what works. As an example, if we required formal written meeting minutes on the agile daily standup meetings, people would be less likely to speak openly, based on my experience. I have observed this type of behavior change on numerous occasions.

我的经验是这样的：当我们试图“形式化”一些有效的过程时，往往这会引出消极的副作用，因为我们会无意中改变了一些起作用的东西。例如，如果我们要求在敏捷每日立会上正式做会议记录，根据我的经验，人们可能就不会开放地发言。我在很多情况下都看到过这种行为变化。

Another way to look at what we did was to capture what the successful people in the organization were already doing - in this case mostly Scrum - and then share it across the organization. This is an effective way to use the CMMI model and agile methods together. These examples demonstrate that agile practices can actually help achieve CMMI goals if the model is used correctly as a framework.

看待我们所做的事情的另一种方式是：记录组织中那些成功的人已经在做的事情（在这种情况下，主要是Scrum），然后在组织中共享它。这就是一种一起使用CMMI模型和敏捷方法的有效方式。这些例子都显示出：如果正确地把CMMI模型用作一个框架，敏捷实践能够真正地帮助实现CMMI目标。

Be aware that one of the keys to this working is to get a CMMI appraisal lead who understands how the CMMI model is suppose to be used and who understands agile methods. For example, you need to have a lead appraiser who isn't afraid to use "alternate practices" as they were intended by the model. Some lead appraisers discourage the use of alternate practices out of fear that it will be perceived as "trying to get out" of a required practice. This can be a legitimate concern, but it shouldn't be used as a reason to change what is already working in a successful agile organization.

要知道，这一工作的关键之一是：找到一个既理解如何灵活使用CMMI模型又理解敏捷方法的CMMI主任评估师。例如，你需要的是这样的一位主任评估师：他不害怕使用模型所提到的“替代实践”。有些主任评估师不鼓励使用那些替代实践，他们害怕这样做会被理解为“试图摆脱”一项要求的实践。这可能是一种合情合理的顾虑，但不应把它作为改变那些在一个成功的敏捷组织中已经发挥了作用的事情的借口。

Although it is true that some "organizations striving for CMMI assessment" are "unwilling" to employ agile practices, my experience indicates that many organizations involved with DoD work are actually very willing and interested.

虽然，真的有一些“争取CMMI评估的组织”“不愿意”使用敏捷实践，我的经验表明：很多与美国国防部（DoD）的工程有关的组织都真正愿意使用敏捷实践并且对此感兴趣。

I have worked with multiple large U.S. Defense contractors who came to me, already having achieved a CMMI level 3, 4, or 5 rating, but wanting to infuse more agile practices into their work processes. Their motivation has come from multiple sources including customer interest, developer interest, and a belief that to continue to be successful - and maybe to survive - increased agility will be required.

我曾经为多家大型美国国防项目的承包商工作过，他们已经获得了CMMI3级、4级或5级的评分，但他们想要注入更多的敏捷实践到他们的工作过程中。他们的动机来自多个来源，其中包括客户的兴趣、开发人员的兴趣和这样一个信仰：想要继续成功（也可能是继续生存下去），增加敏捷性是必须的。

A question I am hearing frequently from large DoD contractors is, "How can we infuse more agile operations into our existing processes?" In one case, we created an agile developer's guide to help his projects tailor their traditional company process assets employing agile practices.

在一家大型的DoD承包商那里，我经常听到的问题是：“我们怎样能够将更多的敏捷操作诸如到我们现有的过程中？”。在一种情况下，我们创建了一个敏捷开发者指南，来帮助那些项目使用敏捷实践来剪裁他们传统的公司过程资产。

The DoD acquisition community has also expressed interest through questions like, "How can we get our people trained in agile methods so that we can be more effective at evaluating the agile implementations of our contractors?" In this case, we are training acquisition community personnel and providing evaluations and recommendations on DoD projects that are already moving toward increased agility.

DoD的采购界也曾通过这样的问题表达出了兴趣：“我们如何能让自己的人接受敏捷方法的培训，这样我们就能更有效地评估我们的承包商的敏捷实现？”。在这种情况下，我们应该培训采购界的人，并且向那些已经向着增加敏捷度转变的DoD的项目提供评估和建议。

It is certainly true that many "Organizations operating in a high-flux, competitive environment and needing the agile approach for organizational survival, can't afford to (or don't see the value to) spend the money or time to create the process superstructure."

很多“组织在一种高度变动的竞争性环境下运作，他们需要敏捷方法来维持组织的生存，他们承担不起花费这样的金钱和时间爱创建过程的超结构，他们也看不到这么做的价值”，这种情况当然是真的。

But, at the same time, my experience indicates that you don't necessarily need a "process superstructure" to achieve a high CMMI Process Maturity Rating. Let me explain why I believe this and why so many organizations still go the "process superstructure" route.

但是，与此同时，我的经验表明：想要得到CMMI过程成熟度的高级别评分，你并非必须需要一个“过程超结构”。让我解释一下，为什么我相信这一点，为什么很多组织仍然在走“过程超结构”的路子。

To attain a staged CMMI level 3 involves 18 process areas and 140 expected specific practices. Today, many CMMI-based process improvement initiatives focus on the stepwise procedural definitions, which can be implied (although erroneously in my view) from the specific practices. This approach often leads organizations to produce explicit objective evidence for each expected practice. These efforts frequently lead to team frustration and reduced performance. Comments such as "Our processes don't reflect what our people really do" and "Our processes force us to do non-value-added work" are not uncommon.

想要获得阶梯式的CMMI 3级评分，涉及18个过程域和140个预期的特定实践。今天，很多基于CMMI的过程改进活动都关注于那些逐步的程序上的定义，这从特定实践中有所暗示（尽管在我看来，这是不正确的）。这种方式往往会导致组织为每个预期的实践制定出显式的客观证据（objective evidence）。这些努力往往会引起团队受挫和性能降低。“我们的过程没有反映我们真正做的事情”，“我们的过程强制我们做一些没有附加值的工作”，诸如此类的评论已司空见惯了。

I believe this approach goes wrong based on the way objective evidence is handled. Objective evidence (OE) is critical to the appraisal method, but more than one type of OE is allowed. To achieve an expected practice, an organization's adherence to the practice must be verified by an appraisal team through what is referred to as direct and indirect artifacts.

我相信，根据处理客观证据的方式来看，这种方式走错了路。客观证据（OE）是评估方法的关键，但允许的OE类型不止一种。为了完成一项预期实践，评估组通过“引用的直接工件和间接工件是什么”来验证组织是否贯彻了这一实践。

Direct artifacts relate to the real intent of the practice. Examples are requirements, design, code, and test artifacts. (Note here that the model doesn't dictate the form these direct artifacts must take nor the order in which they must be produced.) Indirect artifacts are a consequence of performing the practice, but they are not the reason for the practice, nor are they required by the practice. Examples are meeting minutes and status reports.

直接工件涉及某一实践的真正意图。例如需求、设计、编码和测试的工件（请注意，模型没有指定这些直接工件所必须采取的形式，也没有指定制作这些工件的顺序）。间接工件是进行某一实践的结果，但它们既不是这一实践的原因，也不是这一实践所必须的。例如会议记录和状态报告。

But this is where I have seen many process improvement initiatives go off track. Too often I have found organizations being driven to perform unnatural and non-value-added behaviors to produce unnecessary indirect OE, rather than maintaining focus on the real target: quality products produced for their customers (direct OE).

但是，这正是我看到很多过程改进活动脱离轨道的地方。我总是看到：一些组织为了制作那些非必须的间接OE，而被驱使着进行那些不自然的没有附加值的行为，却没有维护对于真正目标的关注：为他们的客户生产高质量的产品（直接OE）。

My point is that indirect artifacts (e.g., meeting minutes, status reports, and so on) are not required by the model. I am not saying that meeting minutes and status reports are not important, but I am saying that you can use what are called "affirmations" during an appraisal instead. This means you interview people, and they tell you what they do.

我的观点是：间接工件（例如会议记录、状态报告等等）不是模型所必须的。我并不是说会议记录和状态报告不重要，我要说的是：在评估期间，你可以使用那些被成为“访谈证实”的东西来替代它。这就意味着，你对人们进行访谈，他们告诉你他们都做了什么。

For example, the appraisal team can interview an agile team, and the project team members tell the appraisal team what they do. As an example, a response from a team member might be, "We hold daily standup meetings where the team members report status and the team lead listens and then removes obstacles."

例如，评估团队可以访谈一个敏捷团队，让这个项目组的成员告诉评估团队他们做了些什么。例如，从团队成员那得到的回答可能是：“我们举行每天的立会。在会上，团队成员报告各自的状态，团队负责人听取这些状态并且削除那些阻碍”。

The appraisal team takes notes on what they hear (affirmations). These notes are then used as evidence that the organization is meeting the intent of many specific practices in the model. We don't have to force unnatural and non-value-added behavior and extra time-consuming work to create unnecessary artifacts to get ready for a CMMI appraisal. The direct artifacts and the affirmations are sufficient.

评估团队把他们所听到的记录下来（访谈证实）。然后使用这些笔记作为证明这个组织达到了模型中的很多特定实践的意图的证据。我们没有必要强制执行那些不自然的没有附加值的行为和额外的消耗时间的工作来创建那些不需要的证据，为CMMI评估做准备。直接工件和访谈证实就足够了。

So why then do many large DoD contractors spend huge amounts of money to get ready for a CMMI appraisal? One reason I have observed is that many contractors don't trust what their people will say in those interviews. They therefore force the creation of huge amounts of indirect evidence (e.g., meeting minutes, status reports, etc.) to "reduce the risk" that someone might say the wrong thing, which might lead to an unsuccessful appraisal.

那么，为什么很多大型的DoD承包商还要花费巨额的资金来为CMMI评估做准备呢？我观察到的ige原因是：很多承包商不能确信他们的人员在那些访谈中会说出什么样的话。因此，他们强制创建大量的间接工件（比如，会议记录、状态报告等），从而“降低风险”：有些人可能会说错话，这就可能导致评估不成功。

There is a lot of negative talk today concerning the effectiveness of the CMMI model. One of my government clients told me that he doesn't care anymore about the CMMI rating because he can't see the difference in the performance of an organization that says it is level 5 from one that says it is level 2. My view is that the problem isn't with the model but with the way companies apply it, focusing on the rating rather than its real intent. In my opinion, agile methods can actually help us use the CMMI model as it was intended - for real process improvement.

今天，关于CMMI模型的有效性，有很多负面的谈论。我的一个政府客户告诉我，他不再关心CMMI评分了，因为他看不出在说自己是5级的组织和说自己是2级的组织之间在性能上有什么差别。我的观点是，这个问题与模型无关，而与公司应用模型的方式有关，公司更多关注的是评分而不是模型的真正意图。在我看来，敏捷方法能够真正帮助我们按照CMMI模型的真正意图来使用这一模型——进行真正的过程改进。

Our philosophy, with the small agile company that had a business goal to achieve CMMI level 3, was not to drive the team to perform any unnatural or non-value-added acts in preparation for the appraisal. The team's affirmations and the direct artifacts became the real proof - the products they produced, their satisfied customers, and their business success: the business is currently growing 30% a year.

在那家以获得CMMI 3级为业务目标的小型敏捷公司中，我们的哲学不是驱使团队为了准备评估而进行任何不自然的或者没有附加值的活动。团队的访谈证实和直接工件成为了真正的证据——他们开发出的产品、对他们满意的客户以及他们在业务上的成功：业务正在以每年30%的速度增长。