Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Integrando Agilidade com maturidade
Conheça algumas formas de integração entre metodologias ágeis e os
modelos CMMI e MPS.BR
Bruno Carreira Coutinho Silva
brunocarreira@gmail.com
Possui graduação em Ciência da Compu-
tação e mestrado na área de Qualidade de
Software pela UFES. Tem mais de 12 anos
de experiência profissional na área de en-
genharia de software, atuando principal-
mente como arquiteto de software J2EE.
Utiliza o framework Scrum há três anos e
atualmente é engenheiro de software no
serviço público federal.
6 Engenharia de Software Magazine - Integrando Agilidade com maturidade
Integrando Agilidade com maturidade:
O processo de desenvolvimento de um software é
uma sequência lógica de atividades com o objetivo
final de produzir ou evoluir um produto. Essas ativi-
dades englobam a especificação de requisitos, aná-
lise e design, implementação, testes e implantação.
Caracterizando-se pela interação de ferramentas,
pessoas e métodos.
Um dos caminhos para se trabalhar com melhoria
de processos é fazer uso de modelos de maturidade.
Estes indicam um conjunto de boas práticas que
podem ser estabelecidas na organização de forma
a propiciar que ela obtenha melhores resultados no
desenvolvimento de produtos de software. Tam-
bém estimulado pelo desafio de entregar software
de qualidade, dentro do prazo e no custo planejado,
surgiram as metodologias ágeis.
Entretanto, por defenderem formas de desenvol-
vimento muitas vezes contrárias, os modelos de
maturidade CMMI e MPS.BR e os métodos ágeis
geralmente caminham em vias diferentes. Porém,
a partir das características apresentadas pelas
principais práticas ágeis e modelos de maturidade
A
utilização de metodologias
ágeis em projetos de desenvol-
vimento de software já é uma
realidade, sendo motivada principal-
mente por sua característica dinâmica,
exigência de um mercado cada vez mais
de software mais utilizados, é possível definir um
processo de desenvolvimento aderente aos padrões
consolidados de qualidade e que seja implementa-
do por métodos ágeis de desenvolvimento, unindo
os benefícios de ambos os paradigmas.
Este artigo apresenta características específicas dos
principais métodos ágeis e dos modelos de maturi-
dade CMMI e MPS.BR, para então, desenhar um mo-
delo que mostra, na prática, como os dois diferentes
paradigmas podem se integrar e conceber um pro-
cesso de desenvolvimento de software de qualida-
de moderno. Este artigo mostra que o preconceito
existente que separa os modelos de maturidade e
melhoria de software e as metodologias ágeis não é
justificado. Inclusive, é apresentada uma proposta
prática de integração entre eles.
Em que situação o tema é útil:
Diante do atual cenário de mercado altamente
competitivo, é importante que as organizações
invistam na melhoria de processos para atender
às suas perspectivas (satisfação dos clientes, lu-
cratividade, qualidade, entre outras).
competitivo. As práticas ágeis iniciaram
sua aplicação em organizações de pe-
queno porte, apesar de terem mostrado,
ao longo dos últimos anos, que também
podem ser utilizadas em corporações de
médio e grande porte, onde é comum a

implementação de práticas formais de melhoria de processo
de software, dada a necessidade de se repetir e melhorar os
resultados obtidos em todos os projetos do portfólio organi-
zacional. Os modelos de melhoria de processos de software
mais utilizados no Brasil são o CMMI e MPS.BR, considerados
referência para empresas que desejam elaborar processos
otimizados e maduros.
Muitos adeptos dessas metodologias defendem que mo-
delos de melhoria de software, como o CMMI e MPS.BR, e
metodologias ágeis divergem entre si em conceito e propósito,
impossibilitando que possam ser integrados. Talvez esse tipo
de reação se deva ao aparente antagonismo de princípios en-
tre elas ou, até mesmo, por simples orgulho proveniente do
comportamento humano.
Na observação criteriosa dos processos e práticas do CMMI
e MPS.BR e alguns métodos propostos pelo manifesto ágil,
é possível perceber que ambos se complementam, ou seja,
é perfeitamente viável definir um processo de software
aderente a modelos de maturidade e utilizar métodos ágeis
para sua implementação prática. A tendência é que os be-
nefícios desses dois diferentes paradigmas sejam somados,
possibilitando o desenvolvimento de software mais eficiente
e maduro.
Metodologias Ágeis
Em 2001 foi criado o Manifesto Ágil, movimento cuja essência
é o desenvolvimento de software respeitando os seguintes
conceitos:
• Pessoas e interações, ao contrário de processos e
ferramentas;
• Software executável, ao contrário de documentação
abrangente;
• Colaboração do cliente sobre negociação do contrato;
• Respostas às mudanças, ao invés de seguir planos.
Várias metodologias e ferramentas ágeis foram originadas
desse movimento, tendo como base os conceitos previamente
listados. Dentre as metodologias ágeis existentes, algumas
delas mais utilizadas no mercado são XP (Extreme Program-
ming), TDD (Test-Driven Development), FDD (Feature-Driven
Development), SCRUM e Kanban.
XP (Extreme Programming)
Método ideal para pequenas e médias equipes de desen-
volvimento, que possuem requisitos vagos ou dinâmicos de
um produto a ser desenvolvido. Devido a essa característica,
esta técnica defende o desenvolvimento incremental e o
feedback constante entre as partes interessadas, encorajando
a comunicação entre elas. Além disso, possui cinco valores
fundamentais: comunicação, simplicidade, feedback, coragem
e respeito. Tendo como principais práticas:
• Jogo de Planejamento: é feito um planejamento semanal
para priorização de funcionalidades;
• Entregas Frequentes: entregas de pequenas versões funcio-
nais para aceite do cliente;
AG IL I DAD E
• Metáfora: tradução das palavras do cliente para facilitar a
comunicação com o desenvolvedor;
• Projeto Simples: é preciso ter foco na funcionalidade mais
importante para cada iteração;
• Testes de Aceitação: testes construídos pelo cliente em
conjunto com analistas e testadores para aceitação de deter-
minados requisitos;
• Programação em Pares: Desenvolvedor experiente e iniciante
programando juntos buscando amadurecimento do iniciante e
proporcionando a revisão do código em busca de diminuição
de defeitos;
• Refatoração: proporciona melhoria contínua da progra-
mação, mantendo a compatibilidade com código original,
diminuição de erros e duplicações de código;
• Propriedade Coletiva: onde o código não tem dono, pro-
porcionando que todos alterem qualquer parte do programa
e conheçam todas as suas partes;
• Integração Contínua: a cada nova funcionalidade produzida,
é feita a integração ao código existente para que se saiba a real
situação da programação;
• Semana de 40 horas: horas extras só devem ser permitidas
caso haja motivação suficiente para boa produtividade;
• Reuniões em pé: reuniões rápidas e produtivas evitando a
perda de foco;
• Padronização de Código: o código de todos os desenvolve-
dores deve ser padronizado, permitindo que todos possam
manter qualquer parte do sistema.
Estas práticas são claras, objetivas e específicas e utilizadas
no dia a dia dos membros de uma equipe de XP.
TDD (Test-Driven Development)
O Test-Driven Development é uma técnica de desenvolvimento
onde, primeiramente, são definidos testes para todos os cená-
rios dos requisitos levantados e, em seguida, é escrito o código,
que deve respeitar as restrições impostas por eles. Dessa forma,
o engenheiro tem a tendência de entender melhor o problema,
antes de implementar a solução.
Apesar de não ser considerada uma técnica exclusivamente
relacionada ao XP, o TDD tem suas origens nele, sendo comu-
mente utilizado em projetos ágeis.
FDD (Feature-Driven Development)
O Feature-Driven Development é uma metodologia ágil que
combina práticas de gerenciamento ágil e a abordagem de
engenharia de software orientada a objetos.
A FDD é descrita por cinco processos:
• Desenvolver um Modelo Abrangente – que é a construção
de modelo de objetos (ou de dados) que servirá de referência
para a equipe de desenvolvimento;
• Construir uma Lista de Funcionalidades – onde se divide
o domínio do problema em três camadas (áreas de negócio,
atividades de negócio e funcionalidades), representando uma
hierarquia de funcionalidades que representa o produto a ser
construído;
Edição 59 - Engenharia de Software Magazine 7
• Planejar por Funcionalidade – construindo um plano com
pacotes de trabalho que leva em consideração as prioridades
e valores para o cliente;
• Detalhar por Funcionalidade – onde se produz um modelo
de domínio mais detalhado (esqueleto) considerando a cons-
trução de código;
• Construir por Funcionalidade – onde pelo esqueleto pro-
duzido no processo anterior é incremento o produto, que pode
ser apresentado ao cliente.

O uso em conjunto desses processos é essencial para a correta

aplicação e para alcançar mais benefícios com o FDD.

Figura 1. Estrutura básica do Scrum

SCRUM
O Scrum é um framework para gerência de projetos ágeis,
considerando a existência de equipes altamente colaborativas. Kanban e Gráfico Burndown
É uma forma de construir um produto em ciclos iterativos, onde Duas ferramentas ágeis bastante utilizadas para auxílio
diferentes equipes trabalham em paralelo para chegarem a uma nas atividades de um projeto Scrum são o quadro Kanban e o
versão do mesmo. A cada ciclo, o cliente avalia a versão do pro- gráfico Burndown.
duto e sugere correções ou alterações até a conclusão final do O Kanban é um quadro de acompanhamento de um Sprint,
produto. Isso permite respostas rápidas às mudanças propostas em que a primeira coluna apresenta as tarefas definidas para
e diminui a possibilidade de erros no produto final. um determinado Sprint e as demais colunas são as fases de
Os agentes responsáveis pelas atividades em um projeto desenvolvimento por onde passam essas tarefas.
Scrum estão divididos em: Por sua vez, o gráfico de Burndown representa, de forma
฀ ฀ – é o representante do cliente dentro da consolidada, a evolução das tarefas no decorrer de um Sprint,
equipe. Responsável por controlar o Product Backlog (lista de dando uma visão objetiva do andamento do Sprint a toda
requisitos que compõem o produto final) e efetuar o aceite das equipe (Figura 2).
entregas de cada ciclo iterativo de desenvolvimento;
฀ – é o líder e facilitador da equipe. Responsável
por remover impedimentos que possam atrapalhar a produ-
tividade da equipe, auxilia o Product Owner na elaboração do
Product Backlog e garante o respeito às práticas do Scrum;
• Equipe Scrum – são colaboradores multifuncionais e auto-
gerenciáveis responsáveis pela construção do produto.

Respeitando uma das características de metodologias ágeis,

os projetos Scrum são divididos em ciclos (geralmente quin-
zenais ou mensais) denominados Sprints, que são espaços de
tempo onde um conjunto determinado de atividades deve
ser realizado.
No início de cada Sprint realiza-se o Sprint Planning Meeting,
reunião de planejamento em que o Product Owner prioriza
Figura 2. Kanban e Gráfico Burndown integrados
os itens do Product Backlog (Figura 1). Durante este encontro,
a Equipe Scrum seleciona as atividades que será capaz de
implementar durante o Sprint, transferindo as tarefas do O Burndown é o gráfico de andamento do Sprint, relacionando
Product Backlog para o Sprint Backlog. Os itens das listas de horas e data em relação ao restante de tempo hábil para o tér-
backlog são sentenças representando requisitos do produto mino do ciclo. Com ele podemos notar o andamento do projeto
chamadas Stories. ao longo do seu ciclo de desenvolvimento (Sprint).
No início de cada dia do Sprint, toda a equipe faz uma
reunião denominada Daily Scrum, cujo objetivo é disseminar Modelos de Maturidade
conhecimento sobre o que foi feito no dia anterior, identificar Quanto maior a maturidade de uma organização, maior a
impedimentos e priorizar as tarefas do dia. probabilidade de se repetir o resultado bem sucedido de pro-
Ao final do Sprint, a equipe apresenta as funcionalidades dução de um ativo. Isso pode ser afirmado porque maturidade
construídas em uma reunião chamada Sprint Review Meeting, está diretamente relacionada à formalização de procedimentos,
onde a entrega parcial é feita e um novo ciclo é planejado. medição, controle e utilização de boas práticas.

8 Engenharia de Software Magazine - Integrando Agilidade com maturidade

 AG IL I DAD E

Nível 2 Nível 3 Nível 4 Nível 5

Gerência de Requisitos
Planejamento de Projeto
Monitoração e Controle do Projeto
Gerência de Acordo com Fornecedores Validação
Medição e Análise
Garantia da Qualidade do Processo e
do Produto
Gerência de Configuração
Desenvolvimento de Requisitos
Solução Técnica
Verificação
Integração do Produto
Foco no Processo Organizacional
Definição do Processo Organizacional
Treinamento Organizacional
Gerência de Projeto Integrada Gerência Quantitativa do Projeto Inovação e Implantação Organizacional
Gerência Integrada de
Desempenho do Processo Organizacional Análise e Resolução de Causas
Fornecedores
Gerência de Riscos
Análise de Decisão e Resolução
Integração da Equipe
Ambiente Organizacional para
Integração

Tabela 1. Áreas de processos do CMMI.

A maturidade de um processo também está diretamente com outras empresas. Todos os processos de um nível devem
associada à qualidade do produto resultante do mesmo. Po- atingir um determinado patamar de maturidade para evoluir
rém, a formalização advinda de modelos de maturidade pode a um próximo nível.
significar maior volume de documentos e grande número de
atividades. Isso pode burocratizar demasiadamente o processo As áreas de processos do CMMI, distribuídas entre os níveis
e prejudicar a produtividade da equipe, caso seja utilizada de de maturidade da representação por estágios, são exibidas na
forma incorreta. Tabela 1.
A utilização de modelos de maturidade tem sido realizada Como se pode observar, há uma concentração maior de áreas
principalmente por organizações de grande porte, devido aos de processos nos dois primeiros níveis de maturidade. Como
custos envolvidos em sua implantação e também pelo objetivo consequência, ao implantar estes dois primeiros níveis, o
de atingir um nível de maturidade certificado, permitindo uma impacto causado na organização tende a ser muito alto.
colocação reconhecida no mercado.
Dois dos modelos de maturidade e melhoria de processos
de software mais utilizados no Brasil são o CMMI e MPS.BR,
que podem ser utilizados tanto em organizações sem processo
de software definido, quanto naquelas que já possuem um
processo, mas desejam melhorá-lo.

CMMI
O CMMI (Capability Maturity Model Integration) é um modelo
desenvolvido pelo SEI (Software Engineering Institute) que indica
práticas específicas e genéricas com o objetivo de obter um
nível de maturidade (ou capacidade) em disciplinas específicas.
Está dividido em três modelos:
• CMMI para Desenvolvimento (CMMI-DEV), para o desen-
volvimento de serviços e produtos;
• CMMI para Aquisição (CMMI-ACQ), para aquisição e ter-
ceirização de bens e serviços;
• CMMI para Serviços (CMMI-SVC), para empresas presta-
doras de serviços.

O modelo possui duas representações:

• Representação Contínua: indicada para empresas que dese-
jam melhorar somente alguns de seus processos. Os processos
são classificados separadamente em níveis de capacidade
(Nível 0 - Incompleto, Nível 1 - Executado, Nível 2 - Gerenciado,
Nível 3 - Definido, Nível 4 - Gerenciado Quantitativamente,
Nível 5 - Em Otimização).
• Representação por Estágios: indicada para empresas que de-
sejam obter um nível de maturidade, permitindo a comparação

Edição 59 - Engenharia de Software Magazine 9

 Quanto aos dois últimos níveis, por ser relativamente
pequenos, são geralmente tratados em conjunto. Como
consequência, não é comum encontrar empresas que alcan-
çaram o CMMI nível 4. Normalmente do nível 3, elas passam
diretamente para o nível 5.
MPS.BR
O MPS.BR (Melhoria de Processos de Software Brasileiro) é
um modelo de qualidade de processo voltado para a realida-
de de pequenas e médias empresas de desenvolvimento de
software do Brasil e está dividido em três partes:
• MR-MPS (Modelo de referência para melhoria do processo
de software), que contém as áreas de processos divididas em
níveis de maturidade;
• MA-MPS (Método de avaliação para melhoria do processo
de software), que orienta a realização de avaliações, conforme
a ISO/IEC 15504;
• MN-MPS (Modelo de negócio para melhoria do processo
de software), que guia instituições que desejam implantar os
processos MPS.BR, como implementadoras.
O MPS.BR está organizado em diversas áreas de processo,
divididas em sete níveis de maturidade (Tabela 2).
Para cada nível de maturidade, uma quantidade de capacida-
des obrigatórias para cada processo é definida, sendo elas:
• AP 1.1 - O processo é executado;
• AP 2.1 - O processo é gerenciado;
• AP 2.2 - Os produtos de trabalho do processo são gerenciados;
• AP 3.1 - O processo é definido;
• AP 3.2 - O processo está implementado;
• AP 4.1 - O processo é medido;
• AP 4.2 - O processo é controlado;
• AP 5.1 - O processo é objeto de inovações;
• AP 5.2 - O processo é otimizado continuamente.
Note que diferente do CMMI, no MPS.BR os primeiros níveis
de maturidade possuem menos áreas de processo. O objetivo
desta definição é facilitar a inserção da cultura de processos
dentro das organizações e permitir que mais organizações
considerem níveis de maturidade em seus processos, fazendo
com que os custos de implementação sejam mais baixos e o im-
pacto sofrido pela organização ao implantar os níveis iniciais
de maturidade sejam mais facilmente absorvidos.
Mapeando práticas ágeis em modelos de maturidade
Apesar de abordarem princípios com focos diferentes, não há o
que inviabilize a utilização de métodos ágeis na implementação
de modelos de qualidade e melhoria de processos de software.
A utilização de práticas ágeis é mais comum em equipes
pequenas, porém é possível realizar um ajuste de escala para

Nível Nome Processos Atributos de Processos

A Em Otimização
B Gerenciado Quantitativamente
C Definido
AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1
Análise de Causas de Problemas e Resolução - ACP
AP 4.2 AP 5.1 e AP 5.2
AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1
Gerência de Projetos - GPR (evolução)
e AP 4.2
Gerência de Riscos - GRI
Desenvolvimento para Reutilização - DRU
AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Análise de Decisão e Resolução - ADR
Gerência de Reutilização - GRU (evolução)

D Largamente Definido
E Parcialmente Definido
Verificação - VER
Validação - VAL
Projeto e Construção de Produto - PCP AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Integração de Produto - ITP
Desenvolvimento de Requisitos - DRE
Gerência de Projetos - GPR (evolução)
Gerência de Reutilização - GRU
Gerência de Recursos Humanos - GRH AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Definição do Processo Organizacional - DFP
Avaliação e Melhoria do Processo Organizacional - AMP

Medição - MED
Garantia de Qualidade - GQA
F Gerenciado AP 1.1 AP 2.1 e AP 2.2
Gerência de Configuração - GCO
Aquisição - AQU

Gerência de Requisitos - GRE

G Parcialmente Gerenciado AP 1.1 AP 2.1
Gerência de Projetos - GPR

Tabela 2. Níveis de maturidade do MPS.BR

10 Engenharia de Software Magazine - Integrando Agilidade com maturidade


que sejam efetivamente aplicadas em equipes maiores, muito
comuns em organizações que adotam modelos de maturida-
de. Para isso, treinamentos adequados são necessários e, em-
bora a abordagem ágil valorize mais as pessoas e interações
mais do que processos e ferramentas, é possível contar com
processos corretamente dimensionados e ferramentas certas
para atingir sucesso.
Outro ajuste indicado para a utilização de técnicas ágeis para
a definição de processos maduros é a adoção de planos mais
detalhados, exigidos pelos modelos de maturidade, apesar
do princípio ágil defender que as respostas às mudanças tem
prioridade mais alta sobre a adesão a um plano.
Mapeamento Agile X CMMI X MPS.BR
Dentro deste contexto de adaptações para a integração de
práticas ágeis e modelos de maturidade, é possível mapear
métodos ágeis às áreas de processos do CMMI e aos processos
do MPS.BR, agrupando as vantagens dos dois paradigmas e
definindo processos melhores.
A seguir serão apresentados os processos do CMMI e MPS.
BR onde se torna viável e compatível a utilização de práticas
ágeis para sua implementação.
Gerência de Requisitos (CMMI nível 2, MPS.BR nível G)
O método ágil XP pode proporcionar diversos benefícios
na implementação deste processo, por ter o cliente como ator
fundamental do projeto. Algumas das práticas utilizadas são:
comunicação contínua, feedback e integração contínua.
O método ágil Scrum fornece elementos essenciais na gerên-
cia de requisitos, são eles: backlog, contendo as user stories e o
Product Owner, responsável por controlar as stories. Além disso,
é possível obter melhoria contínua com o auxílio das reuniões
diárias (daily meeting).
O método FDD pode contribuir com este processo através de
lista de Features e relatórios de progresso do projeto atrelado
aos requisitos.
Gerência de Projetos (CMMI nível 2, MPS.BR nível G)
O processo de gerenciamento de projetos está intimamente
ligado ao Scrum como um todo, dado que esse tem esse pro-
cesso como principal objetivo.
Apesar de não possuírem funções idênticas, o Scrum Mas-
ter executa atividades similares a de um gerente de projetos,
como remoção de impedimentos e organização de reuniões
de integração entre membros da equipe.
Além disso, as ferramentas ágeis Kanban e Burndown Chart
podem ser utilizadas em conjunto para auxiliar o controle de
atividades da equipe durante um Sprint.
Gerência de Configuração (CMMI nível 2, MPS.
BR nível F)
A característica dinâmica e interativa dos projetos ágeis di-
reciona este processo para a integração contínua. Isso significa
que, a cada “commit” de código no repositório de desenvolvi-
mento do projeto, é feita integração entre o que foi inserido e
AG IL I DAD E
os demais módulos do sistema numa versão executável, per-
mitindo a resposta a erros inseridos de forma mais rápida.
Garantia da Qualidade (CMMI nível 2, MPS.BR nível F)
A qualidade do desenvolvimento ágil está relacionada
principalmente à qualidade do código fonte do produto de
software, que pode ser feita através de revisões e inspeções.
Entretanto, através de algumas práticas do método ágil XP,
como refatoração, padronização de código e programação em
pares, a qualidade do código é melhorada de forma dinâmica,
reduzindo a necessidade desses controles.
A refatoração possibilita a reestruturação do código, tor-
nando-o mais limpo e coeso, reduzindo a inserção de erros e
facilitando a remoção dos mesmos. Ter escrita de código pa-
dronizado também contribui para a garantia da qualidade por
facilitar a manutenção do software. Por sua vez, a programação
em pares permite que o código seja validado no momento de
sua escrita, diminuindo a quantidade de erros.
Medição (CMMI nível 2, MPS.BR nível F)
A medição em projetos ágeis pode ser feita em dois níveis,
utilizando o Scrum. O Daily Scrum permite que a evolução
das tarefas seja medida dia a dia, proporcionando respostas
mais rápidas. As ferramentas ágeis Kanban e Burndown Chart
podem auxiliar neste processo.
O Sprint Review Meeting realizado ao final de um Sprint
acumula os resultados do ciclo, permitindo aprendizado para
o ciclo seguinte e projetos posteriores.
Verificação (CMMI nível 3, MPS.BR nível D)
Este processo pode ser implementado pelos métodos XP e
Scrum através das frequentes interações entre equipe e clien-
te. A presença diária do Product Owner ganha destaque nesta
disciplina, impedindo que o desenvolvimento fuja do escopo
requerido e permitindo que mudanças de requisitos sejam
realizadas com o menor custo possível.
O TDD também podem ser úteis para a verificação, por criar
testes aderentes aos requisitos antes mesmo da construção,
dificultando os desvios de escopo.
Validação (CMMI nível 3, MPS.BR nível D)
Existem duas formas ágeis muito utilizadas para validar se
o produto está sendo desenvolvido corretamente:
• Através da prática XP de programação em pares, onde o
código é validado durante sua construção;
• Por meio do TDD, onde os testes antecipados diminuem os
riscos de desvios e erros.
Mais uma vez, a natureza interativa e cíclica da prática ágil
permite que o produto seja frequentemente validado pelos
membros da equipe e pelo cliente.
Integração do Produto (CMMI nível 3, MPS.BR nível D)
Através da prática XP de integração contínua o produto pode
ser integrado a cada alteração de código. Isso permite que
Edição 59 - Engenharia de Software Magazine 11
algum erro que venha a ser inserido no produto seja rapida-
mente detectado e corrigido. Existem algumas ferramentas de
software que automatizam este processo, como a ferramenta
de integração contínua Hudson.
Desenvolvimento de Requisitos (CMMI nível 3, MPS.BR
nível D)
Assim como ocorre no processo de Gerência de Requisitos,
em um projeto Scrum este processo é executado pelo papel
de Product Owner. Este personagem responde pelo cliente, ou
seja, os requisitos atualizados do cliente são traduzidos por
ele para o restante da equipe.
Gerência de Riscos (CMMI nível 3, MPS.BR nível C)
Para implementar o processo de gerencia de riscos, pode-se
lançar mão do quadro de riscos, ferramenta comum em proje-
tos Scrum. Trata-se de um quadro, construído e mantido a cada
reunião, que está dividido em três colunas (mitigar, aceitar
e evitar). A cada risco identificado nas tarefas selecionadas,
o quadro é atualizado para que estejam visíveis pela equipe
durante todo Sprint de desenvolvimento.
Conclusão
O mapeamento entre práticas ágeis e áreas de processos (ou
processos) de modelos de maturidade, apresentado neste arti-
go, é apenas um exemplo prático que possibilita a visualização
da sinergia entre essas disciplinas de propósitos diferentes,
porém não divergentes. Existem outras metodologias ágeis
não exploradas neste artigo que podem abranger ainda mais
os processos do CMMI e MPS.BR.
Assim, não é preciso definir um processo de desenvolvi-
mento de software rígido que integre metodologias ágeis e
modelos de maturidade. É possível flexibilizar a utilização
de métodos ágeis e modelos de maturidade de acordo com as
12 Engenharia de Software Magazine - Integrando Agilidade com maturidade
características e objetivos de cada organização. Como exemplo,
pode-se considerar uma pequena “startup” de tecnologia, que
utilize métodos ágeis e que, com o intuito de se adequar às
exigências de um cliente, precise alcançar determinado nível
de maturidade do MPS.BR.
O dinamismo da tecnologia da informação não permite que
normas e modelos de qualidade sejam inflexíveis, mesmo que
sejam consolidados há anos. O direcionamento ágil observado
no desenvolvimento de soluções de software sugere que adap-
tações sejam feitas nos padrões de qualidade já estabelecidos,
permitindo que a qualidade já comprovada destes modelos
possa se unir à objetividade e produtividade, gerando um novo
modelo de qualidade para a produção de softwares.
Links
Agile e MPS.BR - Visão Ágil
http://www.visaoagil.com/static/downloads/edicoes/VA_03.pdf
Implementando CMMi utilizando uma combinação de Métodos Ágeis
http://www.cin.ufpe.br/~processos/TAES3/slides-2012.2/Implementing%20CMMi%20
using%20a%20Combination%20of%20agile%20methods.pdf
Library | CMMI or Agile: Why Not Embrace Both!
http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm
Feedback
Dê seu feedback sobre esta edição! eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback