Princípios e valores CMMI

Por David J. Anderson. David J. Anderson é o autor de dois livros, “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results” [1] publicado em 2003 e “Kanban: Successful Evolutionary Change for your Technology Business” [2] publicado em 2010. Ele era um membro da equipe que criou o método de desenvolvimento de software Agile, Desenvolvimento orientado para recurso, em Cingapura entre 1997 e 1999. É um autor dos princípios de gerenciamento de projeto Ágeis definidos na Declaração de Interdependência, 2005. David criou MSF para Melhoria do Processo CMMI e co-criou a Nota Técnica do Software Engineering Institute, “CMMI ou Agile: Porque não os dois!” [3] É vice-presidente do Lean Software & Systems Consortium, http://www.leanssc.org, e lidera uma firma de consultoria e treinamento em gerenciamento internacional, David J. Anderson & Associates Inc., http://www.agilemanagement.net que ajudam negócios da tecnologia a melhorar seu desempenho com as melhores políticas de gerenciamento e tomada de decisão.

Janeiro de 2012

Anderson descreve como procurar por organizações através das lentes CMMI fornece ideias valiosas para gerentes, engenheiros de processo e todos os participantes externos incluindo clientes, investidores, corpo de administração e auditores.

Aplica-se a

Gerenciamento do Ciclo de Vida do Aplicativo; CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

O Capability Maturity Model (CMM) original foi publicado pela primeira vez em 1991. Ele evoluiu para a Integração do Modelo de Maturidade da Capacidade (CMMI) uma década depois. CMMI é agora uma família de três constelações (que são conhecidas) e este artigo se refere especificamente à constelação CMMI para Desenvolvimento (CMMI-DEV). O CMM foi desenvolvidos para ajudar a melhor compreensão do Departamento de Defesa dos Estados Unidos das falhas caras em projetos de software dentro dos programas de obtenção em grande de escala do governo. Uma avaliação com base em CMM foi usada para determinar a “aptidão” para contratos do governo. Mais tarde, este evoluiu para um esquema de avaliação definido com base no CMMI.

O conceito de maturidade de organização permanece controverso. Como, por exemplo, a maturidade de uma organização pode ser avaliada? E uma organização realmente tem o comportamento diferente do comportamento e das ações de seus indivíduos? O conceito que uma organização pode ser avaliada no nível de maturidade específico e que este é um indicador da capacidade para fornecer trabalho confiável para o governo é uma questão de debate contínuo. No entanto, eu permaneço um crente e apoiador do CMMI e acredito que procurar por organizações através de lentes CMMI fornece ideias valiosas para gerentes, engenheiros de processo e todos os participantes externos incluindo clientes, investidores, corpo de administração e auditores.

O significado de maturidade organizacional

A maturidade em CMMI destina-se a implicar uma abordagem e uma habilidade para avaliar e gerenciar riscos e o julgamento usado para tomar decisões. O termo “maturidade” está, na verdade, sendo usado no sentido de seu uso comum em relação a pessoas. Por exemplo, os seguradores podem nos dizer que os homens de 18 anos são mais prováveis ter um acidente de carro do que mulheres de 55 anos. O homem de 18 anos é mais provável ter um mau julgamento quando tomar decisões em relação ao tratamento de um veículo e é provável ter experiência insuficiente para avaliar adequadamente os riscos envolvidos em um curso de ação específico. Isso pode levar a acidentes que uma mulher de 55 anos de idade deve evitar. As empresas de seguros são particularmente boas em avaliar os riscos, porque coletam os dados estatísticos e as evidências de correlação.

Um problema com o CMMI é a possível natureza pejorativa do termo “maturidade”. Normalmente, ter mais maturidade é melhor do que ter menos maturidade. E a maior maturidade deve sempre ser buscada. Se fôssemos pensar nisso em termos individuais, nem sempre faz sentido. Uma empresa de seguros pode colocar o custo do seguro de carro mais barato para os mais velhos no entanto, uma equipe de corrida abertas provavelmente irá valorizar a exuberância jovem e o risco. Para a equipe de corrida, os acidentes de carro fazem parte do negócio. Na verdade, os motoristas que nunca bateram um veículo seriam demitidos.

A mensagem aqui é a de que os níveis de maturidade necessários devem corresponder às circunstâncias e ao contexto. Mais não significa necessariamente melhor, porém poder identificar e avaliar corretamente a maturidade da organização ajuda a avaliar se a empresa é capaz de gerenciar riscos e exercer um julgamento adequado ao tomar decisões sobre projetos e produtos.

Deve haver uma correlação forte entre o nível de maturidade e a probabilidade de alcançar ou de obter um resultado desejado. Uma organização de alta maturidade deve ter uma chance muito forte de fornecer um resultado próximo ao resultado desejado. Isso inclui ter a maturidade e o recurso para classificar resultados possíveis, prováveis e realizáveis, e definir metas de acordo. Uma organização de baixa maturidade é menos provável definir metas realizáveis e é menos provável fornecer um resultado desejado em relação a uma expectativa. O outro lado da moeda é que uma organização de alta maturidade pode se tornar avessa a riscos, e somente definir metas facilmente realizáveis, enquanto uma organização exuberante de baixa maturidade pode obter um desempenho excepcional com uma combinação de sorte e de trabalho duro.

Inspiração para o modelo CMMI

O CMM original foi desenvolvido por Watts Humphrey e apareceu pela primeira vez (sem o nome CMM) em seu livro Managing the Software Process[4]. Ele foi inspirado pelo movimento de garantia de qualidade de fabricação do Século XX e o trabalho de Joseph Juran, W. Edwards Deming e Philip Crosby. O termo “modelo de maturidade” e seus cinco níveis foram inspirados pelo modelo de maturidade de fabricação de Crosby. No entanto, o CMM devem ser visto como uma verdadeira síntese de ideias. o termo “recurso” é quase certamente inspirado pelo Deming.

A demanda usou o termo “capacidade” com um significado muito específico que executa muito mais profundamente do que talvez a compreensão da linguagem comum de palavras. Mais precisamente, um “recurso” pode ser considerado a “filosofia natural” de um sistema ou de uma operação dentro de um sistema. A demanda incentivou os gerentes a “estudar a capacidade” e analisá-la estatisticamente. Desenvolveu seu sistema de conhecimento profundo [5] que é destinado para uso como uma estrutura de decisão para ajudar os gerentes a realizarem as intervenções apropriadas ao design do sistema. A demanda era um verdadeiro pensador de sistemas. Neste caso, a palavra "sistema" implica um processo, realizado por pessoas. Não há nenhuma intenção em implicar uma tecnologia ou alguma automação.

A demanda acreditou e compilou a evidência, que sugeriu que tanto quanto 95% de desempenho de um sistema veio de um design do sistema e não das capacidades dos indivíduos de trabalharem dentro do sistema. Em outras palavras, para criar melhoria, deve haver um foco na mudança do processo, o sistema dentro do qual as pessoas trabalham, em vez de um foco na melhoria do desempenho individual. Como resultado disso, não acreditamos nos destinos, no gerenciamento por objetivos, em cartazes motivacionais ou em punir pessoas por mau desempenho.

Portanto Deming forneceu um Modelo de Capacidade com seu Sistema de Conhecimento Profundo, e Crosby forneceu um Modelo de Maturidade. Humphrey procurou sintetizar estes conceitos e aplicá-los ao campo da engenharia de software, e o resultado foi o Modelo de Maturidade de Recurso.

Dado o foco na avaliação e a perseguição de níveis de maturidade para qualificar para contratos governamentais, a Modelagem de Capacidade e a influência do Deming desapareciam muito de grande parte da literatura sobre CMM e CMMI. No entanto, a influência de Deming pode ser claramente vista em áreas de processo definidas nos níveis superiores de maturidade.

CMMI sempre pretendeu ser uma estrutura para incentivar a emergência de uma cultura de melhoria contínua em uma organização e pretendeu sempre ser uma destinadas para uma abordagem de pensamento do sistema. Há muitos paralelos evidentes com o software magro nas raízes do CMMI.

CMMI é um modelo

O CMMI é um modelo para entender a maturidade e a capacidade organizacional. Não é um padrão, nem é um desenvolvimento de software ou definição do processo de gerenciamento do projeto. As práticas genéricas descritas neste artigo se referem ao recurso do processo, e não a algum projeto ou produto em desenvolvimento. Por exemplo, onde planejar é mostrado na tabela a seguir, refere-se a planejar a implementação do processo e não para qualquer projeto ou entrega de produto.

O modelo CMMI consiste em 22 áreas de processo, mais três metas genéricas que todas as organizações são esperadas obter.

As 3 metas genéricas são as seguintes:

Metas genéricas

Prática genérica

Objetivo

GG 1 - O processo suporta e permite a realização de metas específicas da área de processo transformando produtos de trabalho de entrada identificável para gerar produtos de trabalho de saída identificável.

GP 1.1 - Executar as práticas específicas do processo para desenvolver produtos de trabalho e fornecer serviços para obter as metas específicas da área de processo.

A suposição subjacente é a de que os resultados previstos vêm após um processo.

GG 2 - O processo é institucionalizado como um processo gerenciado.

GP 2.1 - Estabelecer e manter uma política organizacional para planejar e executar o processo.

O gerenciamento deve suportar GP 2.1 incentivando a criação, a manutenção, e o uso de um processo. Há um memorando/política de gerenciamento identificável indicando que deve-se seguir um processo para garantir resultados previsíveis.

GP 2.2 - Estabelecer e manter o plano para executar o processo.

Há um plano para garantir que as novas atividades adotem o processo e o sigam.

GP 2.3 - Fornecer recursos suficientes para executar o processo, desenvolver os produtos de trabalho e fornecer serviços do processo.

O gerenciamento realmente suporta o seguinte exemplo de um processo e define projetos acima para o sucesso para pesquisá-los adequadamente.

GP 2.4 - Atribuir a responsabilidade e autoridade para executar o processo, desenvolver os produtos de trabalho e fornecer serviços do processo.

A gerência sênior delega autoridade e definir funções e responsabilidades no projeto para garantir que o processo seja seguido e o produto do trabalho esperado seja gerado.

GP 2.5 - Treinar pessoas que executam ou suportam o processo quando necessário.

Um programa de treinamento está pronto para garantir que a equipe de projeto seja adequadamente especializada executar as tarefas solicitadas e fornecer a capacidade da área de processo desejada.

GP 2.6 - Colocar os produtos de trabalho selecionados do processo em níveis de controle apropriados.

Há um gerenciamento de configuração e um gerenciamento de documentos para todos os artefatos essenciais na criação do produto de trabalho, por exemplo, gerenciamento e acompanhamento de requisitos, controle de versão do código-fonte e controle de configuração ambiental.

GP 2.7 - Identificar e envolver os participantes relevantes como esperado.

Todos os participantes necessários estão envolvidos. Os riscos previsíveis são identificados como um resultado.

GP 2.8 - Controlar e monitorar o processo no plano para executar o processo e tomar a ação corretiva apropriada.

Isso está relacionado ao GP 2.2 e pede que o plano para seguir o processo seja monitorado para mostrar que o plano foi realizado. Por exemplo, se o plano exige um engenheiro de processo encontrar com o gerenciador de projeto para personalizar a definição, essa reunião ocorreu?

GP 2.9 - Avaliar objetivamente a adesão do processo com suas descrição do processo, padrões e procedimentos e abordar incompatibilidades.

Monitore o processo para saber se ele está sendo seguido, e não contornado ou ignorado. Considere a modificação do processo definido se não corresponde às realidades operacionais.

GP 2.10 - Examinar as atividades, o status e os resultados do processo com o gerenciamento de alto nível e resolver problemas.

Mantém a participação de gerenciamento sênior e suporte. Conduza um formulário de revisão de operações com alta administração e compare a capacidade com as expectativas e os requisitos. Considere se o recurso e o treinamento são adequados e tome ações para resolver problemas de definição do processo ou de capacidade da área de processo, conforme necessário.

GG 3 - O processo é institucionalizado como um processo definido

GP 3.1 - Estabelecer e manter uma descrição de um processo definido.

Para que o processo seja repetido e seguido como esperado, é necessário que haja uma descrição escrita.

GP 3.2 - Coletar produtos de trabalho, medidas, resultados de medição e informações de melhoria derivadas do planejamento e executar o processo para oferecer suporte ao uso futuro e a melhoria dos recursos dos processos e do processo da organização.

Gerenciar a conveniência do processo através dos meios quantitativos, e evolua-a conforme necessário para satisfazer as necessidades conforme elas se desdobram.

As 22 áreas de processo são organizadas em 4 categorias: Engenharia, Gerenciamento de projeto, Gerenciamento de processo e Suporte. Cada área de processo consiste em uma das três metas específica e todas as três metas genéricas. Para cada meta, um número de práticas são geralmente esperadas para que o objetivo seja realizado. Dentro de uma prática, pode haver subpráticas sugeridas. O CMMI somente exige ou prescreve metas. As práticas definidas dentro de metas de modelo CMMI são obrigatórias, mas não esperadas. Se não estiver presente, eles devem ser substituídos por uma prática de substituição equivalente. A tabela a seguir mostra o agrupamento de áreas de processo:

Foco da organização

Área de processo

Engenharia

Desenvolvimento dos requisitos

Solução técnica

Integração do Produto

Verificação

Validação

Gerenciamento de Projetos

Planejamento de Projetos

Monitoramento e Controle de Projetos

Gerenciamento de Projeto Integrado

Gerenciamento de acordo de fornecedor

Gerenciamento dos requisitos

Gerenciamento de riscos

Gerenciamento de Projeto Quantitativo

Gerenciamento de Processo

Foco do processo da organização

Definição do processo da organização

Treinamento na organização

Desempenho do Processo da Organização

Inovação e implantação da organização

Suporte

Gerenciamento de configuração

Controle de Qualidade do Processo e do Produto

Medição e análise

Análise e resolução de decisão

Análise casual e resolução

O princípio é simples: se uma organização pode exibir o recurso para obter as metas em cada área de processo, então pode-se dizer que têm um recurso nessa área de processo específica.

As áreas de processo também são agrupadas em níveis de maturidade, o que fornece um método abreviado para descrever a maturidade. Embora o agrupamento de áreas de processo nos níveis permaneça controverso em vários níveis, minha observação das organizações por duas décadas é que a versão atual do modelo 1.3 (considerando o CMMI como efetivamente a versão 2 do CMM) é amplamente correta. Maturidade baixa, organizações caóticas tendem a desenvolver capacidades nas áreas de processo definidas no nível 2 de maturidade antes de desenvolver capacidades nas áreas de processo definidas em níveis mais elevados.

A tabela a seguir mostra o agrupamento de áreas de processo em níveis.

Nível de maturidade

Áreas de processo

5

CAR - Análise causal e resolução

OPM – Gerenciamento do Desempenho da Organização

4

OPP – Desempenho do Processo da Organização

QPM - Gerenciamento de Projeto Quantitativo

3

RD - Desenvolvimento dos Requisitos

TS – Solução Técnica

PI – Integração do Produto

VER – verificação

VAL – Validação

IPM - Gerenciamento do Projeto Integrado

RSKM – Gerenciamento de riscos

OPF – Foco do Processo da Organização

OPD – Definição do Processo da Organização

OT – Treinamento na Organização

DAR – Análise e resolução de decisão

Controle de Qualidade do Processo e do Produto

2

CM – Gerenciamento de configuração

MA – medida & análise

SAM – Gerenciamento de acordo de fornecedor

PP – Planejamento de Projetos

PMC – Monitoramento e Controle de Projetos

RM - Gerenciamento dos requisitos

1

Não há nenhuma área de processo dentro do modelo de nível 1. O nível 1 representa um procedimento indefinido sem introspecção ou capacidade para definir um processo ou repetir um resultado através da compreensão do processo que o produziu. Tecnicamente, em uma avaliação CMMI, uma organização que não cumpre as metas das áreas de processo no nível 2 de modelo ainda está no nível 1 de modelo. As organizações com processos emergentes serão tecnicamente ainda exibidas como modelo nível 1, embora tenham amadurecido por um longo caminho desde o caos indefinido.

A tabela a seguir apresenta uma visão geral em termos leigos sobre o assunto ou a finalidade de cada área de processo:

Área de processo

Objetivo

CAR - Análise causal e resolução

Investigar a causa raiz de problemas do processo excepcional (variações da causa especial, para usar o W. O termo de Edwards Deming e sugere e implementa as alterações do processo para impedir uma recorrência. A atenção é direcionada para o comportamento incomum dos processos estáveis compreendidos quantitativamente. As surpresas diárias provavelmente devem ser considerados parte do Gerenciamento de Risco (RSKM) em vez de um CAR.

CM - Gerenciamento de configuração

Mais do que apenas controle de versão do código-fonte, essa área de processo cobre todo tipo de administração relacionado a ambientes de sistema, configurações de componentes, plataformas, middleware, aplicativos e documentação. A capacidade de compilar e implantar com êxito o código de trabalho está dentro desta área de processo.

DAR - Análise e resolução de decisão

Para todas as principais decisões em um projeto ou um desenvolvimento de produtos, mostre que um conjunto de alternativas ou opções foram considerados e que os elementos contextuais foram usados para avaliar a compatibilidade de opções diferentes. Registre a decisão e as razões para a escolha.

IPM - Gerenciamento do Projeto Integrado

Este segundo nível de gerenciamento de projeto dentro do modelo CMMI significa que uma organização é capaz de gerenciar vários projetos potencialmente dependentes simultaneamente. Isso geralmente é alcançado com o uso de um escritório de gerenciamento de portfólio ou de programa.

MA - medição e análise

Coletar dados no processo, no projeto e no desempenho do produto. Produz métricas e indicadores na forma de relatórios baseados nos dados.

OPD - Definição do Processo da Organização

A organização deve ter uma ou mais definições de processo que são definidas em um contexto. Um contexto descreverá um risco de perfil. Cada projeto pode ser avaliado para os riscos e uma definição de processo selecionada do catálogo organizacional e personalizada adequadamente.

OPF – Foco do Processo da Organização

A organização deve acreditar que a definição de processo define e afeta o recurso, e que melhorar o recurso é sobretudo orientar com os processos aprimorados. Consequentemente, a organização gerencia proativamente suas definições de processo e monitora (usando a área de processo PPQA) para garantir que essas definições sejam seguidas.

OPM – Gerenciamento do Desempenho da Organização

Essa área de processo encapsula o conceito de uma compreensão estatística do quão bem um processo entrega em relação a seu recurso esperado. As alterações para o processo pretendido deve aumentar a capacidade que pode ser avaliada e o modelo subjacente para o processo considerado se os observados não refletem estas precisões pelo modelo de processo subjacente quando uma alteração na definição de processo for realizada. A organização gerencia o desempenho através dos processos para satisfazer suas necessidades comerciais.

OPP – Desempenho do Processo da Organização

Essa área de processo encapsula o conceito de comparação de desempenho, geralmente conhecida como “benchmarking”. O OPP cria modelos de processo a partir de dados da linha de base para ativar a comparação. Isso oferece a uma organização a capacidade de responder a perguntas como “Qual de nossas três equipes de produtos nós devemos escolher para [esse projeto específico]?”

Treinamento na organização

A capacidade individual em práticas específicas é importante para o desempenho do processo e a capacidade do sistema. Um sistema bem comportado com forte desempenho terá uma capacidade de treinamento forte para reduzir a variabilidade na capacidade no nível de prática local.

Integração do Produto

A capacidade de integrar vários componentes para formar um produto completo e gerenciar os elementos necessários para torná-lo possível.

Monitoramento e Controle de Projetos

Coletar dados sobre projetos em andamento, compare com planos, projeções e simulações e faça as ações apropriadas com base nos dados.

Planejamento de Projetos

Planeje projetos com base em avaliações, simulações e análises de requisitos.

Controle de Qualidade do Processo e do Produto

Basicamente, uma função de auditoria de conformidade com o processo. Destina-se a demonstrar que o sistema está operando como projetado. Ajuda a evitar que potenciais erros de gerenciamento alterarem o processo para corrigir um problema quando realmente o processo atual não está sendo seguido como esperado.

Gerenciamento de Projeto Quantitativo

Esse é o terceiro e mais alto nível de gerenciamento de projetos dentro do modelo CMMI. Ele implica que, estatisticamente, os métodos de som e quantitativos são usados para planejar, monitorar e gerenciar projetos.

Desenvolvimento dos requisitos

Há um processo definido e reproduzível para solicitar, negociar, analisar, e documentar requisitos.

Gerenciamento dos requisitos

Os requisitos são rastreados pelo ciclo de vida do projeto e há, idealmente, uma rastreabilidade de ponta a ponta entre uma configuração entregue e a solicitação original do requisito.

Gerenciamento de riscos

Embora todo o modelo CMMI possa ser considerado como uma estrutura para gerenciamento de risco, esta área de processo aborda especificamente, “risco orientado por evento” ou a probabilidade e o impacto das variações de causa especial e surpresas diárias. Essa área de processo requer a redução de risco, atenuação, planejamento de contingência, gerenciamento de problemas e resolução.

Gerenciamento de acordo de fornecedor

A capacidade de gerenciar fornecedores externos, definir acordos, gerenciar o contrato e realizar a entrega do produto ou serviço desejado.

Solução técnica

Todas as habilidades necessárias em relação à arquitetura de software, o design e a codificação.

Validação

Aceitação do teste em requisitos do cliente.

Verificação

Testa um design (de Solução Técnica). Procura garantir que o produto que está sendo criado seja conforme a visão e o design e seja montado de modo a atender às necessidades dos usuários e trabalhar no seu ambiente.

Para cada área de processo, um nível de capacidade pode ser avaliado. Quatro níveis de capacidades são definidos no v1.3 do CMMI:

0. Incompleto

1. Executado

2. Managed

3. Definido

Se cada meta específica é satisfeita e algumas das metas genéricas são atendidas, a capacidade para uma área do processo específico será avaliada como pelo menos o nível 1 – executado. A capacidade nível 1 significa que os membros da equipe sabem o que fazer e o que estão fazendo. No entanto, a prática específica é improvável mostrar a estabilidade se analisada estatisticamente. As práticas estão sendo seguidas, mas ainda há uma falta de consistência. A capacidade nível 2 implica que a equipe entende como algo funciona e tem um nível de habilidade que torna o desempenho uma prática previsível e provavelmente exiba o controle estatístico. É provável que o treinamento ou as práticas de trabalho colaborativas estão no local para produzir uma maior consistência entre os membros da equipe. A capacidade nível 3 implica um domínio da habilidade e uma capacidade de desenvolver as novas técnicas e melhoradas que irão atingir o objetivo. A capacidade de nível 3 significa que qualquer análise estatística exigiria a recriação da linha de base após cada alteração explícita na técnica ou na prática subjacente.

Entendendo o CMMI simplificado

O modelo CMMI basicamente afirma que as novas e imaturas organizações, a princípio, desenvolverão recursos em práticas para gerenciar configurações e controle de origem, coletando informações sobre projetos e trabalho que estão empreendendo, planejando projetos, acompanhando requisitos, monitorando o progresso do projeto e tomando ações com base em comparar dados reais com um plano. Essa é a essência do nível 2 de maturidade.

Conforme as capacidades do nível 2 de maturidade se enquadram no local, a organização e suas pessoas encaminham sua atenção para outros interesses, portanto, a capacidade de definir requisitos, teste, arquitetura e design, integração e processos de definição para que eles possam ser repetidos começa a emergir. Conforme as coisas se estabilizam, uma compreensão de como a cultura e o estilo de gerenciamento afetam o desempenho surge e, esperamos, uma compreensão de que uma abordagem de pensamento do sistema é necessária para fornecer melhorias de desempenho ainda maiores. Com as coisas se tornando mais estáveis e os problemas do dia-a-dia como o planejamento e monitoramento de projeto se tornando a rotina propriamente, há um tempo para considerar o gerenciamento dos riscos e alternativas e opções analisar antes de tomar decisões. A coordenação de vários projetos dependentes e a administração aprimorada de recursos compartilhados pode surgir. Talvez um programa de treinamento, um esquema de tutoria, um esquema de aprendizado professor-aluno ou formas simples de trabalho colaborativo surjam para melhorar as habilidades e aumentar o nível geral de desempenho. Se necessário, alguma auditoria interna ou função de garantia de qualidade do processo podem emergir. Tudo isto é a essência da maturidade nível 3.

Quando uma organização executa uma maturidade contínua nível 3, as coisas são executadas como relógio. A organização cumpre suas promessas e é considerada muito confiável e seguro. Um alto nível de confiança emerge nas relações com clientes. Os gerentes seniores começam a fazer perguntas como “Onde devo investir para obter mais melhorias?” e “Qual equipe tem o melhor desempenho econômico?” Os gerentes começam a desenvolver idéias avançadas em capacidades e desempenho e percebe que eles podem usar a simulação e a análise estatística para melhorar a qualidade do produto, entrega ao cliente e a satisfação. As decisões de gerenciamento agora são totalmente objetivas e defensáveis com dados estatísticos. Essa é a essência de uma organização de nível 4 de maturidade. Para a maioria de diretores principais, o nível 4 de maturidade representa seu estado ideal. Tudo funciona como um relógio e eles possuem dados de desempenho comparativos e podem enviar contra promessas com um alto grau de precisão. O desempenho econômico é muito melhorado e o desempenho da organização é altamente previsível.

Os comportamentos de nível 5 de maturidade emergem geralmente muito antes de uma organização realmente alcançar o nível 5. A análise de raiz causa é geralmente vista em organizações com maturidade de nível 3. O que a torna um recurso do nível 5 é se a análise da causa raiz é feita usando dados quantitativos e é defensável estatisticamente. A emergência de um processo formalizado para a inovação de processo e implantação de melhorias também pode ocorrer antes que a organização pudesse realmente ser considerada para o nível 5 de maturidade. No nível 5, a melhoria do processo foi institucionalizada e inserida na cultura de organização. A cultura é a de sempre desafiar o status de quo e procurar melhores recursos, melhor qualidade de produto e melhor desempenho econômico.

Avaliações CMMI

Uma classificação de maturidade CMMI é estabelecida por uma avaliação. Há um processo padrão para executar avaliações, SCAMPI – método de avaliação de CMMI padrão para a melhoria de processos. Isso foi introduzido para colocar qualquer repetibilidade ao processo e certa confiança no resultado. Os três níveis de rigor na classificação são conhecidos como classe e A, B e C, no qual a classe A é a mais rigorosa. As avaliações de classe A são necessárias para uma avaliação de nível de modelo aceitável para o registro público ou requisitos do Departamento de Defesa dos Estados Unidos.

Todas as avaliações de Classe A e a maioria das avaliações de Classes B e C são conduzidas pelos Avaliadores Chefes CMMI, que são autorizados pelo Instituto de Engenharia de Software a conduzir avaliações. Esses consultantes passaram por um programa de treinamento completo antes de serem licenciados para praticar. Alguns avaliadores passaram por treinamento extra e são designados como Avaliadores Líderes com Alto Grau de Maturidade do CMMI. As organizações que buscam uma avaliação de modelo de nível 4 ou 5 devem trabalhar com um HMLA (High Maturity Lead Appraiser).

Evidência de pesquisa de classificações de que as práticas foram conduzidas para obter as metas dentro das áreas de processo do CMMI. Em uma organização que executa um portfólio de projetos e talvez com várias divisões de negócios, uma fórmula complexa é usada para determinar quantos projetos de qual escopo devem ser avaliados. O objetivo é garantir uma cobertura justa de um conjunto de exemplos de projetos que demonstram que a organização teve um recurso institucionalizado dentro de cada área de processo necessária. O Lead Appraiser irá determinar os projetos a serem avaliados com base nessa fórmula.

Em cada projeto que está sendo avaliado, devem ser obtidas evidências que demonstram as práticas, necessárias para mostrar que o recurso suficiente dentro da área de processo, foi concluído. Para cada prática, o avaliador procura pela evidência sólida e real conhecida como artefatos e geralmente encontrada em evidências documentáveis como planos, código-fonte, projetos e documentos de arquitetura. Além disso, eles procuram por afirmações. Uma afirmação é geralmente evidência de boato, como os membros da equipe falando sobre a conduta de uma prática, como as anedotas que descrevem a participação de uma reunião de planejamento. As afirmações são coletadas entrevistando a equipe envolvida em projetos que estão sendo avaliados. As afirmações podem reforçar a evidência documentável ou refutá-la, resultando ao avaliador questionar a validade da documentação.

As avaliações CMMI não são necessárias para o modelo CMMI ser útil. O CMMI ajuda as organizações de desenvolvimento de software a entender suas capacidades e maturidade e comparam com as expectativas de seus clientes e de outros participantes externos. Ter uma ideia geral de onde a organização mapeia contra o modelo CMMI fornecer uma maneira de avaliar como pode reagir sob esforço e sua capacidade atender as expectativas. As organizações que executam atividades de alto nível de maturidade sem ter uma base sólida de comportamentos de baixo nível de maturidade podem ser imprevisíveis. Isso acontece quando os comportamentos de altura maturidade estão presentes e isso é recomendável, essas práticas de alta maturidade não são tão confiáveis porque não estão compiladas em um alicerce sólido.

As avaliações CMMI são frequentemente usadas como uma maneira de validar uma iniciativa de melhoria do processo em toda a organização. Isso cria uma pressão para “passar no teste.” O foco se torna o de demonstrar que cada prática dentro de cada área de processo é seguida, e o de evidenciar isso. Pode haver uma perda de foco do que é realmente importante – mostrando recurso diferentes das expectativas de cliente – e aprimorando esse recurso com ações explícitas de gerenciamento. Esse foco em “passar no teste” tem geralmente resultado em deficiência e efeitos colaterais significativos nas organizações. Como resultado, o CMMI desenvolveu um corpo forte de detratores na indústria. É uma pena, pois eu acredito que o modelo CMMI é válido, e que ele fornece compreensões valiosas para os gerentes em uma organização – compreensões que devem levar a um recurso aprimorado, melhor desempenho e maior satisfação do cliente.

[1] Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

[2] Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

[3] Glazer, Hillel e Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI ou Agile: Porque não abraçar todos!, Instituto de Engenharia de Software, Novembro de 2008

[4] Humphrey, Watts S., Managing the Software Process, Addison Wesley Professional, 1989

[5] Deming, W. Edwards, The New Economics for Industry, Government, Education, 2ª Edição, The MIT Press, 2000