Conhecendo o CMMI

Conhecendo o CMMI (2º Edição) Alessandro Almeida

Agenda

Objetivos

Por que pensar nestas coisas?

Conhecendo o CMMI

Uma empresa que poderia ser a sua

Objetivos

Apresentar de uma forma prática e divertida o modelo CMMI, seus benefícios e alguns cases;

Questionar alguns “mitos”;

Compartilhar alguns “axiomas”.

Axioma - “premissa considerada necessariamente evidente e verdadeira(...)” Mito - “afirmação fantasiosa, inverídica, que é disseminada com fins de dominação, difamatórios, propagandísticos, como guerra psicológica ou ideológica” Fonte: Houaiss

Por que pensar nestas coisas * ? (a.k.a. * Motivação) * coisas: Termo a ser definido em um slide futuro. * a.k.a.: “Also known as” ou “Também conhecido como”

Sucesso em projetos

Somente 29% dos projetos verificados foram bem sucedidos, ou seja, saíram conforme o planejado.

Sucesso em projetos (a evolução)

Evolução de 13% em 10 anos!?!

Considerando as informações anteriores, podemos pensar:

Ahhhh... Mas estes dados são antigos (2004). Além disso, tratam de projetos do mundo inteiro.

Com certeza os projetos brasileiros são melhores!

Somente nós temos o “jeitinho brasileiro”.

Somente nós somos penta!

A fonte dos slides a seguir é o Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007 (Anexo 1 – Perspectiva por Setor)

Disponível para download no endereço www.pmi.org.br

Realizado pelos capítulos brasileiros do PMI (Project Management Institute)

184 empresas participaram (~60 da área de TI)

“ É importante ressaltar que as informações apresentadas são resultado da compilação e análise de dados fornecidos pelas Organizações participantes, não tendo sido realizada, portanto, nenhum tipo de auditoria em relação à veracidade ou adequação dos dados.”

Por que pensar nestas coisas? Somente 30% das organizações da área de TI dizem não apresentar desvio relevante no orçamento.

Problemas que ocorrem com mais frequência nos projetos da organização (1/2):

Não cumprimento dos prazos

Problemas de comunicação

Mudanças constantes no escopo

Escopo não definido adequadamente

Recursos humanos insuficientes

Riscos não avaliados corretamente

Não cumprimento do orçamento

Problemas que ocorrem com mais frequência nos projetos da organização (2/2):

Mudanças de prioridade constantes

Estimativas incorretas ou sem fundamento

Falta de definição de responsabilidades

Problemas com fornecedores

Retrabalho em função da falta de qualidade do produto

Falta de competência para gerenciar projetos

Falta de uma ferramenta de apoio

Falta de uma metodologia de apoio

Falta de apoio da alta administração

Falta de conhecimento técnico

Agora, o que deve ser a principal motivação:

E na minha empresa, como é?

Enfrentamos problemas com prazo, custo, qualidade, satisfação do cliente, etc.?

Quais são as “coisas” que devem nos preocupar?

Gerenciamento de projetos;

Riscos;

Comunicação;

Custos;

Etc...

Gerenciamento de requisitos;

Gerenciamento de configuração;

Qualidade;

Processos.

Etc...

1º Mito a ser “quebrado”

“CMMI é a solução!”

O CMMI não é (e nunca será) a solução dos seus problemas!

1º Axioma a ser compartilhado

O CMMI sozinho nunca será a solução, mas, sozinho, ele pode representar todo o problema

Por favor, não vão embora! Entenderemos esta afirmação antes do final do evento.

Então, onde o CMMI entra?

O que é o CMMI ® ?

Capability Maturity Model Integration ®

Fontes : Houaiss e Merriam-Webster 1 : the quality or state of being capable 2 : a feature or faculty capable of development : POTENTIALITY 3 : the facility or potential for an indicated use or deployment 4 : a usually miniature representation of something 1 : the quality or state of being mature 2 : estado, condição (de estrutura, forma, função ou organismo) num estágio adulto; condição de plenitude em arte, saber ou habilidade adquirida 3 : estado ou condição de pleno desenvolvimento

O que é o CMMI?

Compilação de boas práticas no processo de diversas empresas de software

Mostra “O QUÊ” fazer, e não “COMO” fazer

Práticas distribuídas em 22 “áreas de processo”

Área de Processo = PA (Process Area)

O que é o CMMI?

Mantido pelo SEI (Software Engineering Institute)

Universidade Carnegie Mellon

http://www.sei.cmu.edu/cmmi

Sponsors:

DoD (U.S. Department of Defense)

NDIA (National Defense Industrial Association)

Foco da apresentação: CMMI for Development (CMMI-DEV)

O que é o CMMI? Um pouco de história... 1987 1991 1995 1997 2000 2002 First CMM Published Model Refined and Published as SW-CMM v1.0 SW-CMM v1.1 Published 1993 Software Acquisition (SA-CMM), Systems Engineering (SE-CMM), Integrated Product Development (IPD-CMM), Organizational Workforce Capability Development (People CMM) Developed CMMI Initiative Launched CMMI-SE/SW Version 1.02 Published CMMI-SE/SW/IPPD Version 1.1 Published 2006 2007 CMMI for Development v1.2 CMMI for Acquisition v1.2 Fontes: -CMMI Second Edition -http://www.rtpspin.org/Information/IntroCMMIv5.ppt 2008 CMMI for Services v1.2

O que é o CMMI? CMMI Model Foundation CMMI-DEV CMMI-ACQ CMMI-SVC Fonte: -http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html

Estrutura do modelo

22 áreas de processo distribuídas em:

4 categorias

5 níveis de maturidade

Mas o que é “área de processo”?

Estrutura do modelo

Área de processo (Process Area)

É o agrupamento de práticas comuns de uma determinada “disciplina”.

É onde fica o “O que fazer”.

Estrutura do modelo

Demonstração 01 Detalhando uma área de processo

Detalhando uma área de processo Nome da PA Categoria Nível de Maturidade Propósito da PA Notas Introdutórias

Detalhando uma área de processo Áreas de Processo Relacionadas

Detalhando uma área de processo Sumário dos objetivos e práticas específicas

Detalhando uma área de processo Prática específica Produtos de trabalho típicos Subpráticas

Detalhando uma área de processo Prática genérica

Detalhando uma área de processo

Os “Objetivos Específicos” ( Specific Goals)

Apresenta características únicas que devem ser seguidas para satisfazer a área de processo;

É utilizada nas avaliações para verificar se a área de processo está sendo seguida.

Os “Objetivos Genéricos” ( Generic Goals)

Todas as PAs devem seguir os objetivos genéricos correspondentes ao “capability ou maturity level” que se almeja;

Apóiam a institucionalização do processo.

Áreas de processo distribuídas por categorias

Áreas de processo distribuídas por níveis de maturidade Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Mas... Pra que tudo isto?

Representações (a.k.a. “formas de implementação do modelo”)

Representações

Contínua

Representações

Contínua

Especialização em áreas de processos específicas

Permite o foco em determinada(s) necessidade(s)

Capability levels.

Grande vantagem!

Fornece flexibilidade

Custo de implementação menor (considerando a representação por estágio)

Permite atuação em categorias:

Engineering;

Process Management;

Project Management;

Support.

Áreas de processo distribuídas por categorias

Capability Levels 1 2 3 4 5 Objetivos específicos da área de processo são atendidos Processo gerenciado (monitorado, controlado, etc.) Processo definido para toda a organização Processo controlado utilizando estatística e técnicas quantitativas Melhoria contínua do processo... Optimizing Quantitatively Managed Performed Managed Defined Incomplete 0 Onde as coisas simplesmente acontecem

Capability Levels

Exemplo:

Representações

Por estágio

Representações

Por estágio

Foco em um conjunto de áreas de processo

Demonstra a “experiência” da organização de uma forma simples: Nível de Maturidade

É mais fácil de “vender”

Mais “simples”

Mais utilizada

Pode ser um caminho interessante para organizações que estão iniciando o plano de melhoria do processo de software (SPI Plan)

Áreas de processo distribuídas por níveis de maturidade Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Representações

Por estágio

Níveis de Maturidade:

1 [Initial]

Semelhante ao “capability level 0”;

Onde as coisas simplesmente acontecem;

O “sucesso” nos projetos acontece “por acaso”;

“ Por acaso, temos alguns heróis...”

“ Por acaso, o cliente era mais desorganizado...”

É normal estouro de prazo e custos (entre outros problemas);

Ambiente sem controle (caos);

Grande dependência dos heróis (mas não é qualquer herói...)

Jack Bauer – O herói das empresas nível 1

Está sempre sob pressão;

Nunca tira férias;

Anda sempre estressado;

Nunca tem tempo para os amigos;

Nunca se diverte;

Sempre tem que trabalhar 24 horas direto;

Até consegue terminar o projeto, mas...

Representações

Por estágio

2 [Managed]

Recursos são definidos;

Projetos são planejados e monitorados;

Medições são coletadas;

Requisitos são gerenciados;

As coisas deixam de “simplesmente acontecer”...

Representações

Por estágio

3 [Defined]

Processo definido para a organização;

“ Portal de Processos”, “Processo de Desenvolvimento de Software”, etc.

Customização do processo para projetos (a partir do processo padrão);

Evolução do nível 2.

Representações

Por estágio

4 [Quantitatively Managed]

Controle estatístico;

Previsibilidade;

Base de medições utilizada para tomada de decisão;

É fundamental que os níveis 2 e 3 estejam “rodando perfeitamente”;

High Level Maturity.

Representações

Por estágio

5 [Optimizing]

Inovação;

Revisões buscando refletir alterações nos objetivos de negócio;

Melhoria contínua utilizando dados estatísticos;

Estado da arte;

High Level Maturity;

2º Mito a ser “quebrado”

“ CMMI acaba com os heróis.”

A partir do nível 2 temos um novo herói...

James Bond – O herói das empresas nível 2 a 5

Herói potencializado;

Consegue planejar seus projetos;

Tem os recursos definidos, de acordo com o projeto;

Tem tempo para estudar e utilizar novas tecnologias;

Tem tempo para os amigos;

Consegue se divertir e até namorar...

Conhecendo as PAs

PAs do Nível 2 Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Processos ad hoc Œ Initial

Requirements Management (REQM)

ML 2

Categoria: Engineering

Sugere práticas para:

Gestão dos requisitos;

Identificação de inconsistências entre requisitos e produtos do projeto.

Project Monitoring and Control (PMC)

ML 2

Categoria: Project Management

Acompanhamento do projeto;

Ações corretivas a serem tomadas em desvios significativos do plano .

Project Planning (PP)

ML 2

Criação do plano de projeto;

Revisão e aprovação do plano.

Supplier Agreement Management (SAM)

ML 2

Estabelecer acordos com os fornecedores;

Gerenciar os acordos com os fornecedores.

Configuration Management (CM)

ML 2

Categoria: Support Process

Estabelecer e manter a integridade dos produtos de trabalho do projeto;

Gerenciar mudanças.

Measurement and Analysis (MA)

ML 2

Criação de medições ( úteis );

Coleta, análise, divulgação e armazenagem das medições coletadas.

Process and Product Quality Assurance (PPQA)

ML 2

Verificar aderência dos projetos aos processos;

Acompanhar inconsistências e “garantir” que serão resolvidas.

Fiscal?

Depende…

PAs do Nível 3 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined

Product Integration (PI)

ML 3

Planejar a integração do produto;

Garantir a compatibilidade;

Realizar a “montagem”.

Requirements Development (RD)

ML 3

Levantar requisitos do cliente;

Levantar requisitos do produto;

Analisar e validar requisitos.

Technical Solution (TS)

ML 3

Projetar, desenvolver e implementar soluções para os requisitos levantados.

Validation (VAL)

ML 3

Validar se você fez a coisa certa.

Verification (VER)

ML 3

Validar se você fez a coisa da forma correta.

Organizational Process Definition +IPPD (OPD)

ML 3

Categoria: Process Management

Estabelecer e manter ativos do processo organizacional.

Processo Padrão;

Ciclo de Vida;

Critérios de customização;

Repositório de medições;

Ambiente de trabalho;

Biblioteca de ativos do processo.

Organizational Process Focus (OPF)

ML 3

Identificar oportunidades de melhoria do processo;

Planejar, implementar e disponibilizar melhorias no processo;

Avaliação do processo;

Comitê responsável pelo processo: EPG (Engineering Process Group).

Organizational Training (OT)

ML 3

Levantar necessidades de treinamento;

Planejar e realizar treinamentos necessários.

Integrated Project Management +IPPD (IPM)

ML 3

Customizar o processo para o projeto;

Garantir o envolvimento dos stakeholders.

Risk Management (RSKM)

ML 3

Identificar, analisar e mitigar riscos.

Decision Analysis and Resolution (DAR)

ML 3

Categoria: Support

Analisar as possíveis decisões utilizando um processo de avaliação formal;

Avaliar as alternativas e selecionar a solução.

PAs do Nível 4 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed

Organizational Process Performance (OPP)

ML 4

Verificar performance dos processos no atendimento dos objetivos.

Quantitative Project Management (QPM)

ML 4

Verificar quantitativamente o desempenho do projeto.

PAs do Nível 5 Processos ad hoc Œ Initial Configuration Management (CM) Measurement and Analysis (MA) Project Monitoring and Control (PMC) Project Planning (PP) Process and Product Quality Assurance (PPQA) Requirements Management (REQM) Supplier Agreement Management (SAM)  Managed Decision Analysis and Resolution (DAR) Integrated Project Management +IPPD (IPM) Organizational Process Definition +IPPD (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Product Integration (PI) Requirements Development (RD) Risk Management (RSKM) Technical Solution (TS) Validation (VAL) Verification (VER) Ž Defined  Organizational Process Performance (OPP) Quantitative Project Management (QPM) Quantitatively Managed  Causal Analysis and Resolution (CAR) Organizational Innovation and Deployment (OID) Optimizing

Organizational Innovation and Deployment (OID)

ML 5

A partir dos objetivos de negócio, selecionar e implementar melhorias no processo.

Causal Analysis and Resolution (CAR)

ML 5

Categoria: Support

Identificar e analisar causas de defeitos;

Tomar ações de prevenção.

Avaliando o trabalho (a.k.a. “buscando o ‘certificado’”)

SCAMPI

Standard CMMI® Appraisal Method for Process Improvement

Método utilizado para avaliar aderência do processo da empresa ao CMMI

Deve ser realizado por um lead appraiser

Deve ser realizado a cada 3 anos (SCAMPI 1.2)

Classes A, B ou C

Complicado? Depende do ângulo...

Demonstração 02 Uma empresa que poderia ser a sua...

Cenário

Nome da empresa: UCT

Nº de funcionários: ~120

Tipo: Fábrica de software e projetos

Situação: Jack Bauer é gerente de projetos na UCT, ele anda um pouco estressado, pois nenhum dos projetos possui um cronograma confiável. Além disso, o cliente muda de idéia toda hora, solicitando alterações direto para os desenvolvedores. Sem contar outros problemas que não cabem aqui...

Nosso objetivo

O diagnóstico Alô... Bill? Tem um minuto? Prossiga, Jack. Fiz um levantamento em nossos projetos e percebi que 95% são concluídos fora do prazo e custo... Além disso, 80% dos projetos teve desvio de pelo menos 70% do prazo e 55% do custo. Por isso, acredito que devemos fazer algo. Posso coordenar este trabalho? Vá em frente, Jack.

O diagnóstico

Não temos uma forma de estimar o tamanho, esforço e nem o custo dos projetos;

O cliente não se compromete com o planejado, pois nada é planejado, simplesmente realizamos uma reunião entre desenvolvedor e cliente e “saímos fazendo”;

Os riscos não são levantados, consequentemente não temos gestão de riscos;

O diagnóstico

O monitoramento é feito em conversas de corredor, o humor do cliente conta muito nas ações que serão tomadas;

Os desenvolvedores trocam muitas idéias entre si, mas as lições aprendidas não são registradas.

Vamos ajudar o Jack?

O que fazer? Alô... Chefe? Tem um minuto? Fala, aspirante! Precisamos da sua ajuda... Diagnosticamos sérios problemas na gestão dos projetos, mas não sabemos “O QUE” fazer... Então, aspira, por que vocês não dão uma olhada no CMMI-DEV? Lá vocês podem verificar pelo menos as práticas das PAs “PP” e “PMC”, que focam o planejamento e o monitoramento dos projetos. É mesmo... Valeu! E não me chama de aspira! Ok! Boa sorte, aspira!

Como fazer?

O resultado Jack, parabéns! Pode ir em frente com a sua idéia. Bill, nossa iniciativa foi um sucesso! O processo que definimos já está em uso e ajudando na redução dos desvios de custo e prazo. Inclusive percebi que nosso processo está aderente a algumas práticas do modelo CMMI. Com o CMMI nível 2 ou 3 poderíamos atender novos clientes. O que acha de realizarmos um diagnóstico de aderência e aproveitarmos a oportunidade de negócio?

Compartilhando experiências (a.k.a. “alguns axiomas”)

Compartilhando experiências

O diagnóstico deve ser muito bem feito

Foto da situação atual

Saiba onde você deseja chegar

Quais são as metas?

“ Por que estamos iniciando esta empreitada?”

A iniciativa deve estar alinhada com a estratégia da empresa

Alguém “forte” na organização deve ser o padrinho do projeto

Normalmente envolve mudança cultural

Traga o pessoal de RH para o projeto

Conte com os “integradores”

TODOS devem participar (desde analistas até diretores)

Alguém deve gerenciar a iniciativa

Seja “subversivo”

Sempre questionem!

“ Por que fazer assim se podemos fazer diferente?”

Seja um “herege”

Cuidado com os “religiosos”!

“ Misture” práticas, metodologias, ferramentas e etc.

Comunique!

O CMMI deve ser um dos resultados da mudança

Cuidado com àqueles que só estão preocupados com o “diploma” na parede

Aproveite a oportunidade

Mude de “Meu cliente exige que eu tenha CMMI.” para “O que posso oferecer de diferente utilizando o processo que criamos?”

Os últimos mitos a serem quebrados

“CMMI é coisa de ‘indiano’.”

“CMMI é sinônimo de burocracia.”

“CMMI bloqueia a criatividade.”

“CMMI só funciona em empresas grandes.”

Case

Empresa “S”

Resultados em 24 meses (CMMI 3)

Produtividade: aumento de 67%

Todos os projetos entregues no prazo;

Previsibilidade:

Custo - 83%

Esforço - 87%

Tamanho - 82%

Satisfação:

Interna – 150 melhores empresas para se trabalhar (2005 e 2006)

Adoção Process Maturity Profile – Setembro de 2007 www.sei.cmu.edu/appraisal-program/profile/profile.html

Adoção

mps.Br

Melhoria de processo do software brasileiro

www.softex.br/mpsbr

Foco em micro, pequenas e médias empresas

Custo de implementação e avaliação menor

Foi definido em conformidade ao CMMI for Development

Níveis:

G (Parcialmente Gerenciado) até A (Em otimização)

Vamos fazer uma revisão?

O que é o CMMI?

Compilação de boas práticas no processo de diversas empresas de software

Mostra “O QUÊ” fazer, e não “COMO” fazer

Práticas distribuídas em 22 “áreas de processo”

Área de Processo = PA (Process Area)

Representações

Forma de implementar o modelo

Maturity Levels 2 a 5 = Capability Levels 2 a 5

Diferença...

Maturity Levels: Refere-se a um conjunto de áreas de processo

Capability Levels: Refere-se a uma área de processo

Aguardo sua visita!

www.AlessandroAlmeida.com

Bate-Papo de Buteco

Blog do Alessandro

Células de Estudo

Quality|Process

Muito obrigado! [email_address]

APÊNDICE

Como tudo se integra?

Process Management

Basic Process Management Process Areas

Process Management

Advanced Process Management Process Areas

Project Management

Basic Project Management Process Areas

Project Management

Advanced Project Management Process Areas

Engineering

Engineering Process Areas

Support

Basic Support Process Areas

Support

Advanced Support Process Areas

Conhecendo o CMMI

2 comments

Notes on slide 1

5 Favorites