PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS



Documentos relacionados
Políticas de Qualidade em TI

Scrum e CMMI no C.E.S.A.R Relato de Experiência

Modelo de Referência para melhoria do processo de software (MR mps)

Unidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini

MODELO CMM MATURIDADE DE SOFTWARE

Géssica Talita. Márcia Verônica. Prof.: Edmilson

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL PEDROHOLI@GMAIL.COM CMM E CMMI

Gerenciamento de Riscos do Projeto Eventos Adversos

CAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi

Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

Tecnologia em Gestão Pública Desenvolvimento de Projetos - Aula 9 Prof. Rafael Roesler

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

ENGENHARIA DE SOFTWARE I

MASTER IN PROJECT MANAGEMENT

Melhorias de Processos de Engenharia de Software

Implantação de um Processo de Medições de Software

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

PLANEJAMENTO E PROJETOS. Lílian Simão Oliveira

Gerenciamento de Projetos Modulo III Grupo de Processos

Módulo de projetos ágeis Scrum Módulo de Projetos Ágeis Scrum

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Políticas de Qualidade em TI

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

CMMI: Capability Maturity Model Integration

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

Universidade Federal do Espírito Santo Centro de Ciências Agrárias CCA-UFES Departamento de Computação

Década de 80, o Instituto de Engenharia de Software (SEI) foi criado.

Princípios da Engenharia de Software aula 05 Gerenciamento de planejamento de projetos. Prof.: Franklin M. Correia

Introdução CMMI. Qualidade e Teste de Software CMMI 1

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

Agenda. Visão Revolução Ágil EduScrum Visão Geral do Método Benefícios Projeto Scrum for Education Sinergias

Governança de TI. ITIL v.2&3. parte 1

Introdução ao CMM (CapabilityMaturityModel) e CMMI (Capability Maturity Model Integration)

Metodologia de Gerenciamento de Projetos da Justiça Federal

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processos de gerenciamento de projetos em um projeto

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ - UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE

Manifesto Ágil - Princípios

APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2

Wesley Torres Galindo

F.1 Gerenciamento da integração do projeto

Disciplina: Gerenciamento de Projetos e Práticas de Integração. Gerenciamento de Projetos e Práticas de Integração AULA 3.

ATO Nº 91/2015/GP/TRT 19ª, DE 1º DE JUNHO DE 2015

A Disciplina Gerência de Projetos

Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura. O Modelo. Wesley Torres Galindo. wesleygalindo@gmail.

Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Engenharia de Software II: Definindo Projeto III. Prof. Msc Ricardo Britto DIE-UFPI

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini prof.andre.luis.belini@gmail.com /

SISTEMA. Tecnologia. Software. Hardware. Prazos. Pessoas. Qualidade. Custo GERENCIAMENTO DE RISCO: COMO GARANTIR O SUCESSO DOS PROJETOS DE TI?

Wesley Torres Galindo.

Implantação. Prof. Eduardo H. S. Oliveira

Modelos de Maturidade. Porque estudar um Modelo de Maturidade? Descrevem as características de processos efetivos;

QUALIDADE DE SOFTWARE AULA N.7

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

Objetivos. Histórico. Out/11 2. Out/11 3

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

Integração dos Modelos de Gestão de TI

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto

Qualidade de Software Aula 6 / luis@garcia.pro.br

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Project Builder: uma Ferramenta de Apoio a Implementação do Processo Gerência de Projetos do MPS.BR

C.M.M. Capability Maturity Model Modelo de Maturidade da Capacidade

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Qualidade de Processo de Software Normas ISO e 15504

Inovação na utilização de Método Ágil aderente ao CMMI. Palestrante: Anderson Donas, PMP, CFPS Consultor Sênior - DISYS

Aula Anterior. Capítulo 2

Gerenciamento de Projetos

Versão 7 TraceGP Ágil

APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR

GESTÃO E OTIMIZAÇÃO DE PROCESSOS. Vanice Ferreira

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel

Avaliação de Riscos Aplicada à Qualidade em Desenvolvimento de Software

Roteiro SENAC. Análise de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos. Monitoramento e Controle de Riscos

Gerência de Projetos CMMI & PMBOK

SIMPROS Experiência de implantação da norma ISO 9001:2000 a partir da utilização da ISO/IEC TR (SPICE) para Melhoria de Processos

O que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto

Gerenciamento de Projeto: Monitorando e Controlando o Projeto II. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

Porque estudar Gestão de Projetos?

Desenvolvimento Ágil de Software

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br


Engenharia de Software II: Desenvolvendo o Orçamento do Projeto. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Alessandro Almeida 23/04/ Semestre de 2013

Transcrição:

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e as melhores práticas do CMMI (Capability Maturity Model Integration) são frequentemente considerados como não conciliáveis.

CMMI E METODOLOGIAS ÁGEIS Esta discórdia não se justifica e os dois campos metodológicos poderão ser utilizados em conjunto, proporcionando vantagens e sinergias com o potencial para melhorar significativamente o desempenho.

CMMI E METODOLOGIAS ÁGEIS Cada uma das abordagens inclui princípios de bom desenvolvimento de software muitas vezes ignorados, mas que são necessários para a outra abordagem e para o sucesso dos projetos.

CMMI E METODOLOGIAS ÁGEIS Cada uma das abordagens inclui princípios de bom desenvolvimento de software muitas vezes ignorados, mas que são necessários para a outra abordagem e para o sucesso dos projetos.

CMMI E METODOLOGIAS ÁGEIS Porque a resistência? Duas grandes razões: 1. Pessoas que adaptaram inicialmente os métodos Ágeis ou o CMMI representarem exemplos extremos dos seus paradigmas de desenvolvimento de software. Os que adoptaram inicialmente o CMMI eram sobretudo especialistas no desenvolvimento de sistemas de grande escala, críticos e avessos ao risco. O desenvolvimento destes sistemas também envolvia frequentemente níveis elevados de supervisão em termos de gestão e governação hierárquica. Os promotores iniciais dos métodos Ágeis estavam normalmente envolvidos em projetos de desenvolvimento mais pequenos e com uma única equipe.

CMMI E METODOLOGIAS ÁGEIS 2. Informação incorreta sobre o CMMI e os métodos Ágeis, resultando em problemas de percepção em ambos os grupos. Fatores que contribuíram para os problemas de percepção e que colocaram erradamente o CMMI e os métodos Ágeis em campos opostos: A. Má utilização. Em cerca de duas décadas de experiências, primeiro com o Capability Maturity Model (CMM) e depois com o CMMI, ocorreram práticas de má utilização ou a aplicação a atividades de desenvolvimento que as equipes já consideravam produtivas sem o recurso ao CMM/CMMI. B. Falta de informação exata. Existe falta de informação exata sobre o CMMI na comunidade Ágil, assim como falta de informação exata sobre os métodos Ágeis na comunidade CMMI.

CMMI E METODOLOGIAS ÁGEIS C. Dificuldades de terminologia. São utilizadas terminologias no CMMI (por exemplo, disciplina, garantia de qualidade e previsibilidade) e nos métodos Ágeis (por exemplo, integração contínua, desenvolvimento orientado a testes, ou posse coletiva de código) que têm conotações específicas do contexto em que são utilizadas, pelo que são facilmente mal interpretadas e/ou utilizadas de forma abusiva. D. Abordagem top-down versus bottom-up. Assiste-se por vezes à introdução de uma abordagem que favorece um dos lados em detrimento do outro (por exemplo, gestão versus especialistas em desenvolvimento).

CMMI E METODOLOGIAS ÁGEIS Alguns dos mal entendidos do CMMI junto da comunidade Ágil têm a ver com aspectos do CMM que já não fazem parte do CMMI. Este último inclui muitas melhorias que o diferenciam do CMM. Algumas pessoas da comunidade Ágil utilizam conceitos do CMM para falarem injustamente do CMMI. Por exemplo, a referência incorreta ao objetivo do nível de maturidade dois como criador de processos repetíveis ainda persiste atualmente. Para complicar ainda mais esta questão, existem utilizadores do CMM que nunca se atualizaram para o CMMI, persistindo na utilização de um modelo que tem uma visão menos flexível do que os modelos CMMI quanto ao desenvolvimento de sistemas e de software

CMMI E METODOLOGIAS ÁGEIS Muitas pessoas falarem de CMMI e de Ágil nas suas atividades, mas na realidade não aplicarem adequadamente nenhuma das abordagens. Todas estas situações contribuem para a difusão de percepções negativas relativamente às duas abordagens. O CMMI e as metodologias Ágeis podem ser utilizados em conjunto de forma bem sucedida.

Tabela de todas as áreas de processo do CMMI e quais são satisfeitas por cada uma das metodologias ágeis. Nível de Maturidade Área de Processo Nível de Satisfação Scrum FDD XP Nível 2: Gerenciado Gerenciamento de Requisitos ++ ++ ++ ++ Amplamente satisfeito + Parcialmente satisfeito -- Não satisfeito Planejamento do Projeto ++ ++ ++ Monitoramento de Controle do Projeto + -- + Gestão de Contrato com Fornecedores -- -- -- Gestão de Análise e Medição de Contrato ++ + ++ Garantia da Qualidade do Processo e do Produto -- ++ + Gerencia de Configuração -- -- +

Tabela de todas as áreas de processo do CMMI e quais são satisfeitas por cada uma das metodologias ágeis. Nível de Maturidade Área de Processo Nível de Satisfação Scrum FDD XP Nível 3: Definido Requerimentos do Desenvolvimento ++ ++ ++ ++ Amplamente satisfeito + Parcialmente satisfeito -- Não satisfeito Solução Técnica -- ++ -- Integração do Produto -- + ++ Verificação -- ++ ++ Validação ++ + ++ Foco no Processo Organizacional + + + Definição do processo organizacional + + + Treinamento organizacional -- -- -- Gestão Integrada de Projetos -- -- -- Gerenciamento de Riscos -- -- -- Análise de Decisão e Resolução -- ++ --

Tabela de todas as áreas de processo do CMMI e quais são satisfeitas por cada uma das metodologias ágeis. Nível de Maturidade Área de Processo Nível de Satisfação Nível 4: Gerenciado Quantitativamente Scrum FDD XP Desempenho do Processo Organizacional -- -- -- Gestão de Processos Quantitativos -- -- -- Nível 5: Otimizado Inovação Organizacional e Implantação -- -- -- ++ Amplamente satisfeito + Parcialmente satisfeito -- Não satisfeito Análise Causal e Resolução -- -- --

O Scrum é compatível com o CMMI? Sim e não. A formalização requerida pelo modelo CMMI contrasta teoricamente com a agilidade no tempo de desenvolvimento de software. Abordagens ágeis são criticadas devido ao fato de apresentarem muito pouco design de arquitetura e pouca documentação e quase nenhuma formalização. Abordagens rigorosas são criticadas por serem burocráticas e serem de difícil adaptação à mudança.

O modelo CMMI descreve o que fazer. A metodologia ágil, como o Scrum, descreve o como fazer. As práticas estabelecidas pelo CMMI não interferem em como devemos executá-las (conforme proposto por métodos ágeis). O importante é entender o que o CMMI pode adaptar métodos ágeis a essa realidade sem perder o controle do CAOS, pois o CMMI é aberto a várias formas de interpretação e o modelo não descreve o como fazer.

Combinando Agilidade e CMMI Avaliação do Scrum nas práticas do modelo CMMI corresponde a: Planejamento do Projeto (PP) Monitoramento e Controle do Projeto (PMC) Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do Produto e do Processo (IPPD) e Gerenciamento de Riscos (RSKM). Estas áreas de processo compõem os níveis 2 e 3 de maturidade da representação por estágios do modelo.

Combinando Agilidade e CMMI Análise do Planejamento do Projeto Estabelecer e manter os planos que definem as atividades do projeto. Para tanto, PP possui três metas específicas: Estabelecer Estimativas, Desenvolver um Plano de Projeto e Obter Compromissos com o Plano Entre as quais se encontram distribuídas 14 práticas específicas.

Combinando Agilidade e CMMI Análise do Planejamento do Projeto

Combinando Agilidade e CMMI Análise do Monitoramento e Controle do Projeto Tem como objetivo fornecer um entendimento do progresso do projeto de forma que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. Composta por 10 práticas específicas agrupadas em 2 metas específicas: Monitorar o Projeto Contra o Plano e Gerenciar Ações Corretivas até o Encerramento.

Combinando Agilidade e CMMI Análise do Monitoramento e Controle do Projeto

Combinando Agilidade e CMMI Análise do Gerenciamento Integrado do Projeto + IPPD Têm como objetivo estabelecer e gerenciar o projeto e o envolvimento dos stakeholders relevantes, de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Esta área de processo também faz cobertura da definição de uma visão compartilhada do projeto bem como do estabelecimento de times integrados que devem cuidar dos objetivos do projeto. IPM +IPPD é composto por 3 metas específicas: Utilizar o Processo Definido do Projeto; Coordenar e Colaborar com os Stakeholders Relevantes; e Aplicar

Combinando Agilidade e CMMI Análise do Gerenciamento Integrado do Projeto + IPPD

Combinando Agilidade e CMMI Análise do Gerenciamento de Riscos A identificação de riscos no Scrum é realizada como impedimentos durante as reuniões diárias Não existem práticas explícitas para definir fontes, parâmetros e categorias de riscos que devem ser usados para analisar, categorizar bem como para controlar o esforço do gerenciamento dos riscos. Não há uma estratégia para o gerenciamento dos riscos, nem mesmo um plano de mitigação para os riscos mais importantes e uso de bases históricas.

Combinando Agilidade e CMMI Análise do Gerenciamento de Riscos

Práticas do CMMI e como Scrum pode implementar cada prática: Para avaliar o nível 2, é assumido que a aplicação Scrum é robusto e mostra a evidência da prática do CMMI a ser realizada. Gerenciamento de Requisitos (GR): Gerenciar os requisitos dos produtos do projeto e componentes do produto e identificar inconsistências entre esses requisitos e os planos do projeto e produtos de trabalho.

GR Prática CMMI Prática Scrum 1.1 Desenvolver uma compreensão com os provedores de requisitos sobre o significado dos requisitos 1.2 Obter compromisso com os requisitos dos participantes do projeto. 1.3 Gerenciar as mudanças dos requisitos à medida que o projeto evolue. 1.5 Identificar inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos. Revisão do Product Backlog (requisitos) com o proprietário do produto e a equipe. Planejamento da Entrega e do Sprint buscando a compreensão dos membros da equipe Adicione as mudanças de requisitos para o Product Backlog. Gerenciar mudanças na próxima reunião de planejamento do sprint. Reunião diária (rápidas) para identificar problemas. Planejamento das Entregas e do Sprint para resolver inconsistências. O gráfico de Sprint Burndown para o rastreio do esforço restante. Entrega do gráfico Burndown que rastreia pontos da história que foram concluída. Mostra o quanto a funcionalidade do produto foi deixado para completar.

Práticas do CMMI e como Scrum pode implementar cada prática: Planejamento do Projeto (PP): Estabelecer e manter planos que definem as atividades do projeto. PP Prática CMMI Prática Scrum 1.1 Estabelecer um trabalho de nível alto (Estrutura Analítica de Projetos - EAP) para estimar o escopo do projeto 1.2 Estabelecer e manter as estimativas dos atributos e dos produtos de trabalho e das tarefas. 1.3 Definir o projeto de ciclo de vida em fases definidas pelo esforço de planejamento do escopo. 1.4 Estimar o esforço do projeto e o custo para os produtos de trabalho e tarefas com base na lógica de estimação. As tarefas padrões usadas no processo Scrum combinadas com tarefas específicas (Scrum Backlog) Pontos das estórias, usada para estimar a dificuldade (ou tamanho relativo) de uma estoria (requisito). O processo de Scrum Estimativa Tempo Ideal (semelhante a horas trabalhadas ou a tempo inteiro Equivalentes).

PP Prática CMMI Prática Scrum 2.1 Estabelecer e manter o projeto de orçamento e cronograma. 2.4 Plano de recursos necessários para execução do projeto. 2.6 Planejar a identificação do envolvimento das partes interessadas 2.7 Estabelecer e manter o conteúdo global do plano de projeto. 3.1 Rever todos os planos que afetam o projetar para compreender os compromissos do projeto. As estimativas do Scrum (em tempo ideal). Estimativas de que o trabalho será em cada lançamento. Sprint Backlog. Taskboard Projeto. As estimativas do Scrum em Tempo Ideal Plano de entregas, Sprint Backlog e atribuições. Os papéis do processo Scrum (incluindo equipe, Scrum Master, Product Owner). [Nota: Os interessados enumerados no Scrum não precisa ser a lista completa das partes interessadas pelo projeto, por exemplo, clientes, outras equipes afetadas.] Plano de liberação do Scrum. Sprint Backlog. Projeto de Taskboard. [Nota: O termo "plano" em CMMI refere-se a plano adicional de componentes (tais como riscos e gerenciamento de dados) que não são realizados especificamente no Scrum.] Reunião de planejamento do Sprint Reunião diária do Scrum

PP Prática CMMI Prática Scrum 3.2 Reconciliar o plano do projeto para refletir os recursos disponíveis e estimados. 3.3 Obter o compromisso das partes interessadas, responsáveis pela realização e apoio a execução do plano. Reunião de planejamento do Sprint Reunião diária do Scrum Reunião de planejamento do Sprint Reunião diária do Scrum

Práticas do CMMI e como Scrum pode implementar cada prática: Monitoramento e Controle do Projeto (MCP) Fornecer uma compreensão do andamento do projeto para que as ações corretivas apropriadas podem ser tomadas quando o desempenho do projeto desvia significativamente do plano. MCP Prática CMMI Prática Scrum 1.1 Monitorar os valores reais dos parâmetros de planejamento do projeto com o plano do projeto. 1.2 Monitorar os compromissos com aqueles identificados no plano de projeto. O gráfico de Sprint Burndown que rastreia esforço restante. Lançamento do gráfico burndown que rastreia pontos da história concluídas. Este mostra a quantidade de a funcionalidade do produto que foi deixada para completar. Projeto do Task Board usado para rastrear estórias (requisitos) que são feitas, as em andamento, ou aquelas que necessitam de verificação. Discussões sobre os compromissos da equipe: Na reunião diária do Scrum Na reunião de revisão do Sprint O gráfico de Sprint Burndown que rastreia esforço restante. Lançamento gráfico burndown que rastreia pontos das estórias que foram concluída.

MCP Prática CMMI Prática Scrum 1.5 Monitorar o envolvimento dos stakeholders com o plano do projeto 1.6 Revisar periodicamente o progresso, o desempenho e as questões do projeto 1.7 Rever as realizações e os resultados do projeto selecionado em marcos do projeto. 2.1 Coletar e analisar os problemas e determinar as ações corretivas necessárias para resolver as questões. 2.2 Realizar as ações corretivas identificadas na questões. 2.3 Gerenciar ações corretivas para o encerramento. Discussões nas: Reuniões diárias do Scrum Reuniões de revisão do Sprint Reuniões diárias do Scrum Reuniões de revisão do Sprint Retrospectivas Reuniões de revisão do Sprint Notas da: Reunião diária do Scrum Reunião de revisão do Sprint. Ações da: Reunião diária do Scrum Reunião de revisão do Sprint. Acompanhamento das ações das: Reuniões diárias do Scrum Reuniões de revisão do Sprint

Conclusão As metodologias ágeis não cobrem diretamente todas as práticas específicas de gerenciamento de projeto do CMMI. Pode ser um ótimo ponto de partida para empresas que não possuem processos definidos e têm times pequenos Consegue criar grande parte dos fundamentos necessários para que estas empresas institucionalizem as Áreas de Processo de Gestão de Projetos do nível 2 do CMMI, sem comprometer a agilidade de que necessitam. Empresas que buscam níveis de maturidade maiores, o Scrum pode ser uma excelente largada Necessidade da adição de práticas complementares, como o CMMI.