Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Integrando Agilidade com maturidade
Conhea algumas formas de integrao entre metodologias geis e os
modelos CMMI e MPS.BR
Bruno Carreira Coutinho Silva
brunocarreira@gmail.com
Possui graduao em Cincia da Compu-
tao e mestrado na rea de Qualidade de
Software pela UFES. Tem mais de 12 anos
de experincia profissional na rea de en-
genharia de software, atuando principal-
mente como arquiteto de software J2EE.
Utiliza o framework Scrum h trs anos e
atualmente engenheiro de software no
servio pblico federal.
6 Engenharia de Software Magazine - Integrando Agilidade com maturidade
Integrando Agilidade com maturidade:
O processo de desenvolvimento de um software
uma sequncia lgica de atividades com o objetivo
final de produzir ou evoluir um produto. Essas ativi-
dades englobam a especificao de requisitos, an-
lise e design, implementao, testes e implantao.
Caracterizando-se pela interao de ferramentas,
pessoas e mtodos.
Um dos caminhos para se trabalhar com melhoria
de processos fazer uso de modelos de maturidade.
Estes indicam um conjunto de boas prticas que
podem ser estabelecidas na organizao de forma
a propiciar que ela obtenha melhores resultados no
desenvolvimento de produtos de software. Tam-
bm 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 contrrias, os modelos de
maturidade CMMI e MPS.BR e os mtodos geis
geralmente caminham em vias diferentes. Porm,
a partir das caractersticas apresentadas pelas
principais prticas geis e modelos de maturidade
A
utilizao de metodologias
geis em projetos de desenvol-
vimento de software j uma
realidade, sendo motivada principal-
mente por sua caracterstica dinmica,
exigncia de um mercado cada vez mais
de software mais utilizados, possvel definir um
processo de desenvolvimento aderente aos padres
consolidados de qualidade e que seja implementa-
do por mtodos geis de desenvolvimento, unindo
os benefcios de ambos os paradigmas.
Este artigo apresenta caractersticas especficas dos
principais mtodos geis e dos modelos de maturi-
dade CMMI e MPS.BR, para ento, desenhar um mo-
delo que mostra, na prtica, 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 no
justificado. Inclusive, apresentada uma proposta
prtica de integrao entre eles.
Em que situao o tema til:
Diante do atual cenrio de mercado altamente
competitivo, importante que as organizaes
invistam na melhoria de processos para atender
s suas perspectivas (satisfao dos clientes, lu-
cratividade, qualidade, entre outras).
competitivo. As prticas geis iniciaram
sua aplicao em organizaes de pe-
queno porte, apesar de terem mostrado,
ao longo dos ltimos anos, que tambm
podem ser utilizadas em corporaes de
mdio e grande porte, onde comum a

implementao de prticas formais de melhoria de processo
de software, dada a necessidade de se repetir e melhorar os
resultados obtidos em todos os projetos do portflio organi-
zacional. Os modelos de melhoria de processos de software
mais utilizados no Brasil so o CMMI e MPS.BR, considerados
referncia 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 propsito,
impossibilitando que possam ser integrados. Talvez esse tipo
de reao se deva ao aparente antagonismo de princpios en-
tre elas ou, at mesmo, por simples orgulho proveniente do
comportamento humano.
Na observao criteriosa dos processos e prticas do CMMI
e MPS.BR e alguns mtodos propostos pelo manifesto gil,
possvel perceber que ambos se complementam, ou seja,
perfeitamente vivel definir um processo de software
aderente a modelos de maturidade e utilizar mtodos geis
para sua implementao prtica. A tendncia que os be- situao da programao;
nefcios 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 essncia
o desenvolvimento de software respeitando os seguintes
conceitos:
Pessoas e interaes, ao contrrio de processos e
ferramentas;
Software executvel, ao contrrio de documentao
abrangente;
Colaborao do cliente sobre negociao do contrato;
Respostas s mudanas, ao invs de seguir planos.
Vrias 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 so XP (Extreme Program-
ming), TDD (Test-Driven Development), FDD (Feature-Driven
Development), SCRUM e Kanban.
XP (Extreme Programming)
Mtodo ideal para pequenas e mdias equipes de desen-
volvimento, que possuem requisitos vagos ou dinmicos de
um produto a ser desenvolvido. Devido a essa caracterstica,
esta tcnica defende o desenvolvimento incremental e o
feedback constante entre as partes interessadas, encorajando
a comunicao entre elas. Alm disso, possui cinco valores
fundamentais: comunicao, simplicidade, feedback, coragem
e respeito. Tendo como principais prticas:
Jogo de Planejamento: feito um planejamento semanal
para priorizao de funcionalidades;
Entregas Frequentes: entregas de pequenas verses funcio-
nais para aceite do cliente;
AgiLidAdE
Metfora: traduo das palavras do cliente para facilitar a
comunicao com o desenvolvedor;
Projeto Simples: preciso ter foco na funcionalidade mais
importante para cada iterao;
Testes de Aceitao: testes construdos pelo cliente em
conjunto com analistas e testadores para aceitao de deter-
minados requisitos;
Programao em Pares: Desenvolvedor experiente e iniciante
programando juntos buscando amadurecimento do iniciante e
proporcionando a reviso do cdigo em busca de diminuio
de defeitos;
Refatorao: proporciona melhoria contnua da progra-
mao, mantendo a compatibilidade com cdigo original,
diminuio de erros e duplicaes de cdigo;
Propriedade Coletiva: onde o cdigo no tem dono, pro-
porcionando que todos alterem qualquer parte do programa
e conheam todas as suas partes;
Integrao Contnua: a cada nova funcionalidade produzida,
feita a integrao ao cdigo existente para que se saiba a real
Semana de 40 horas: horas extras s devem ser permitidas
caso haja motivao suficiente para boa produtividade;
Reunies em p: reunies rpidas e produtivas evitando a
perda de foco;
Padronizao de Cdigo: o cdigo de todos os desenvolve-
dores deve ser padronizado, permitindo que todos possam
manter qualquer parte do sistema.
Estas prticas so claras, objetivas e especficas e utilizadas
no dia a dia dos membros de uma equipe de XP.
TDD (Test-Driven Development)
O Test-Driven Development uma tcnica de desenvolvimento
onde, primeiramente, so definidos testes para todos os cen-
rios dos requisitos levantados e, em seguida, escrito o cdigo,
que deve respeitar as restries impostas por eles. Dessa forma,
o engenheiro tem a tendncia de entender melhor o problema,
antes de implementar a soluo.
Apesar de no ser considerada uma tcnica 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 prticas 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 construo
de modelo de objetos (ou de dados) que servir de referncia
para a equipe de desenvolvimento;
Construir uma Lista de Funcionalidades onde se divide
o domnio do problema em trs camadas (reas de negcio,
atividades de negcio e funcionalidades), representando uma
hierarquia de funcionalidades que representa o produto a ser
construdo;
Edio 59 - Engenharia de Software Magazine 7
 Planejar por Funcionalidade construindo um plano com
pacotes de trabalho que leva em considerao as prioridades
e valores para o cliente;
Detalhar por Funcionalidade onde se produz um modelo
de domnio mais detalhado (esqueleto) considerando a cons-
truo de cdigo;
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

aplicao e para alcanar mais benefcios com o FDD.

Figura 1. Estrutura bsica do Scrum

SCRUM
O Scrum um framework para gerncia de projetos geis,
considerando a existncia de equipes altamente colaborativas. Kanban e Grfico Burndown
uma forma de construir um produto em ciclos iterativos, onde Duas ferramentas geis bastante utilizadas para auxlio
diferentes equipes trabalham em paralelo para chegarem a uma nas atividades de um projeto Scrum so o quadro Kanban e o
verso do mesmo. A cada ciclo, o cliente avalia a verso do pro- grfico Burndown.
duto e sugere correes ou alteraes at a concluso final do O Kanban um quadro de acompanhamento de um Sprint,
produto. Isso permite respostas rpidas s mudanas 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 so as fases de
Os agentes responsveis pelas atividades em um projeto desenvolvimento por onde passam essas tarefas.
Scrum esto divididos em: Por sua vez, o grfico de Burndown representa, de forma
Product Owner o representante do cliente dentro da consolidada, a evoluo das tarefas no decorrer de um Sprint,
equipe. Responsvel por controlar o Product Backlog (lista de dando uma viso objetiva do andamento do Sprint a toda
requisitos que compem o produto final) e efetuar o aceite das equipe (Figura 2).
entregas de cada ciclo iterativo de desenvolvimento;
ScrumMaster o lder e facilitador da equipe. Responsvel
por remover impedimentos que possam atrapalhar a produ-
tividade da equipe, auxilia o Product Owner na elaborao do
Product Backlog e garante o respeito s prticas do Scrum;
Equipe Scrum so colaboradores multifuncionais e auto-
gerenciveis responsveis pela construo do produto.

Respeitando uma das caractersticas de metodologias geis,

os projetos Scrum so divididos em ciclos (geralmente quin-
zenais ou mensais) denominados Sprints, que so espaos de
tempo onde um conjunto determinado de atividades deve
ser realizado.
No incio de cada Sprint realiza-se o Sprint Planning Meeting,
reunio de planejamento em que o Product Owner prioriza
Figura 2. Kanban e Grfico 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 grfico de andamento do Sprint, relacionando
Product Backlog para o Sprint Backlog. Os itens das listas de horas e data em relao ao restante de tempo hbil para o tr-
backlog so sentenas 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 incio de cada dia do Sprint, toda a equipe faz uma
reunio 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 organizao, 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 duo de um ativo. Isso pode ser afirmado porque maturidade
construdas em uma reunio chamada Sprint Review Meeting, est diretamente relacionada formalizao de procedimentos,
onde a entrega parcial feita e um novo ciclo planejado. medio, controle e utilizao de boas prticas.

8 Engenharia de Software Magazine - Integrando Agilidade com maturidade

 AgiLidAdE

Nvel 2 Nvel 3 Nvel 4 Nvel 5

Gerncia de Requisitos Desenvolvimento de Requisitos Gerncia de Projeto Integrada Gerncia Quantitativa do Projeto Inovao e Implantao Organizacional
Gerncia Integrada de
Planejamento de Projeto Soluo Tcnica Desempenho do Processo Organizacional Anlise e Resoluo de Causas
Fornecedores
Monitorao e Controle do Projeto Verificao Gerncia de Riscos
Gerncia de Acordo com Fornecedores Validao Anlise de Deciso e Resoluo
Medio e Anlise Integrao do Produto Integrao da Equipe
Garantia da Qualidade do Processo e Ambiente Organizacional para
Foco no Processo Organizacional
do Produto Integrao
Gerncia de Configurao Definio do Processo Organizacional
Treinamento Organizacional

Tabela 1. reas de processos do CMMI.

A maturidade de um processo tambm est diretamente com outras empresas. Todos os processos de um nvel devem
associada qualidade do produto resultante do mesmo. Po- atingir um determinado patamar de maturidade para evoluir
rm, a formalizao advinda de modelos de maturidade pode a um prximo nvel.
significar maior volume de documentos e grande nmero de
atividades. Isso pode burocratizar demasiadamente o processo As reas de processos do CMMI, distribudas entre os nveis
e prejudicar a produtividade da equipe, caso seja utilizada de de maturidade da representao por estgios, so exibidas na
forma incorreta. Tabela 1.
A utilizao de modelos de maturidade tem sido realizada Como se pode observar, h uma concentrao maior de reas
principalmente por organizaes de grande porte, devido aos de processos nos dois primeiros nveis de maturidade. Como
custos envolvidos em sua implantao e tambm pelo objetivo consequncia, ao implantar estes dois primeiros nveis, o
de atingir um nvel de maturidade certificado, permitindo uma impacto causado na organizao tende a ser muito alto.
colocao reconhecida no mercado.
Dois dos modelos de maturidade e melhoria de processos
de software mais utilizados no Brasil so o CMMI e MPS.BR,
que podem ser utilizados tanto em organizaes 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
prticas especficas e genricas com o objetivo de obter um
nvel de maturidade (ou capacidade) em disciplinas especficas.
Est dividido em trs modelos:
CMMI para Desenvolvimento (CMMI-DEV), para o desen-
volvimento de servios e produtos;
CMMI para Aquisio (CMMI-ACQ), para aquisio e ter-
ceirizao de bens e servios;
CMMI para Servios (CMMI-SVC), para empresas presta-
doras de servios.

O modelo possui duas representaes:

Representao Contnua: indicada para empresas que dese-
jam melhorar somente alguns de seus processos. Os processos
so classificados separadamente em nveis de capacidade
(Nvel 0 - Incompleto, Nvel 1 - Executado, Nvel 2 - Gerenciado,
Nvel 3 - Definido, Nvel 4 - Gerenciado Quantitativamente,
Nvel 5 - Em Otimizao).
Representao por Estgios: indicada para empresas que de-
sejam obter um nvel de maturidade, permitindo a comparao

Edio 59 - Engenharia de Software Magazine 9

 Quanto aos dois ltimos nveis, por ser relativamente
pequenos, so geralmente tratados em conjunto. Como
consequncia, no comum encontrar empresas que alcan-
aram o CMMI nvel 4. Normalmente do nvel 3, elas passam
diretamente para o nvel 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 mdias empresas de desenvolvimento de
software do Brasil e est dividido em trs partes:
MR-MPS (Modelo de referncia para melhoria do processo
de software), que contm as reas de processos divididas em
nveis de maturidade;
MA-MPS (Mtodo de avaliao para melhoria do processo
de software), que orienta a realizao de avaliaes, conforme
a ISO/IEC 15504;
MN-MPS (Modelo de negcio para melhoria do processo
de software), que guia instituies que desejam implantar os
processos MPS.BR, como implementadoras.
O MPS.BR est organizado em diversas reas de processo,
divididas em sete nveis de maturidade (Tabela 2).
Para cada nvel de maturidade, uma quantidade de capacida-
des obrigatrias 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 so 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 inovaes;
AP 5.2 - O processo otimizado continuamente.
Note que diferente do CMMI, no MPS.BR os primeiros nveis
de maturidade possuem menos reas de processo. O objetivo
desta definio facilitar a insero da cultura de processos
dentro das organizaes e permitir que mais organizaes
considerem nveis de maturidade em seus processos, fazendo
com que os custos de implementao sejam mais baixos e o im-
pacto sofrido pela organizao ao implantar os nveis iniciais
de maturidade sejam mais facilmente absorvidos.
Mapeando prticas geis em modelos de maturidade
Apesar de abordarem princpios com focos diferentes, no h o
que inviabilize a utilizao de mtodos geis na implementao
de modelos de qualidade e melhoria de processos de software.
A utilizao de prticas geis mais comum em equipes
pequenas, porm possvel realizar um ajuste de escala para

Nvel Nome Processos Atributos de Processos

AP 1.1 AP 2.1 AP 2.2 AP 3.1 AP 3.2 AP 4.1

A Em Otimizao Anlise de Causas de Problemas e Resoluo - 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

B Gerenciado Quantitativamente Gerncia de Projetos - GPR (evoluo)
e AP 4.2

Gerncia de Riscos - GRI

Desenvolvimento para Reutilizao - DRU
C Definido AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Anlise de Deciso e Resoluo - ADR
Gerncia de Reutilizao - GRU (evoluo)

D Largamente Definido
Verificao - VER
Validao - VAL
Projeto e Construo de Produto - PCP AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Integrao de Produto - ITP
Desenvolvimento de Requisitos - DRE

Gerncia de Projetos - GPR (evoluo)

Gerncia de Reutilizao - GRU
E Parcialmente Definido Gerncia de Recursos Humanos - GRH AP 1.1 AP 2.1 AP 2.2 AP 3.1 e AP 3.2
Definio do Processo Organizacional - DFP
Avaliao e Melhoria do Processo Organizacional - AMP

Medio - MED
Garantia de Qualidade - GQA
F Gerenciado AP 1.1 AP 2.1 e AP 2.2
Gerncia de Configurao - GCO
Aquisio - AQU

Gerncia de Requisitos - GRE

G Parcialmente Gerenciado AP 1.1 AP 2.1
Gerncia de Projetos - GPR

Tabela 2. Nveis de maturidade do MPS.BR

10 Engenharia de Software Magazine - Integrando Agilidade com maturidade


que sejam efetivamente aplicadas em equipes maiores, muito
comuns em organizaes que adotam modelos de maturida-
de. Para isso, treinamentos adequados so necessrios e, em-
bora a abordagem gil valorize mais as pessoas e interaes
mais do que processos e ferramentas, possvel contar com
processos corretamente dimensionados e ferramentas certas
para atingir sucesso.
Outro ajuste indicado para a utilizao de tcnicas geis para
a definio de processos maduros a adoo de planos mais
detalhados, exigidos pelos modelos de maturidade, apesar
do princpio gil defender que as respostas s mudanas tem
prioridade mais alta sobre a adeso a um plano.
Mapeamento Agile X CMMI X MPS.BR
Dentro deste contexto de adaptaes para a integrao de
prticas geis e modelos de maturidade, possvel mapear
mtodos 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 sero apresentados os processos do CMMI e MPS.
BR onde se torna vivel e compatvel a utilizao de prticas
geis para sua implementao.
Gerncia de Requisitos (CMMI nvel 2, MPS.BR nvel G)
O mtodo gil XP pode proporcionar diversos benefcios
na implementao deste processo, por ter o cliente como ator
fundamental do projeto. Algumas das prticas utilizadas so:
comunicao contnua, feedback e integrao contnua.
O mtodo gil Scrum fornece elementos essenciais na gern-
cia de requisitos, so eles: backlog, contendo as user stories e o
Product Owner, responsvel por controlar as stories. Alm disso,
possvel obter melhoria contnua com o auxlio das reunies
dirias (daily meeting).
O mtodo FDD pode contribuir com este processo atravs de
lista de Features e relatrios de progresso do projeto atrelado
aos requisitos.
Gerncia de Projetos (CMMI nvel 2, MPS.BR nvel 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 no possurem funes idnticas, o Scrum Mas-
ter executa atividades similares a de um gerente de projetos,
como remoo de impedimentos e organizao de reunies
de integrao entre membros da equipe.
Alm disso, as ferramentas geis Kanban e Burndown Chart
podem ser utilizadas em conjunto para auxiliar o controle de
atividades da equipe durante um Sprint.
gerncia de Configurao (CMMi nvel 2, MPS.
BR nvel F)
A caracterstica dinmica e interativa dos projetos geis di-
reciona este processo para a integrao contnua. Isso significa
que, a cada commit de cdigo no repositrio de desenvolvi-
mento do projeto, feita integrao entre o que foi inserido e
AgiLidAdE
os demais mdulos do sistema numa verso executvel, per-
mitindo a resposta a erros inseridos de forma mais rpida.
Garantia da Qualidade (CMMI nvel 2, MPS.BR nvel F)
A qualidade do desenvolvimento gil est relacionada
principalmente qualidade do cdigo fonte do produto de
software, que pode ser feita atravs de revises e inspees.
Entretanto, atravs de algumas prticas do mtodo gil XP,
como refatorao, padronizao de cdigo e programao em
pares, a qualidade do cdigo melhorada de forma dinmica,
reduzindo a necessidade desses controles.
A refatorao possibilita a reestruturao do cdigo, tor-
nando-o mais limpo e coeso, reduzindo a insero de erros e
facilitando a remoo dos mesmos. Ter escrita de cdigo pa-
dronizado tambm contribui para a garantia da qualidade por
facilitar a manuteno do software. Por sua vez, a programao
em pares permite que o cdigo seja validado no momento de
sua escrita, diminuindo a quantidade de erros.
Medio (CMMI nvel 2, MPS.BR nvel F)
A medio em projetos geis pode ser feita em dois nveis,
utilizando o Scrum. O Daily Scrum permite que a evoluo
das tarefas seja medida dia a dia, proporcionando respostas
mais rpidas. 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.
Verificao (CMMI nvel 3, MPS.BR nvel D)
Este processo pode ser implementado pelos mtodos XP e
Scrum atravs das frequentes interaes entre equipe e clien-
te. A presena diria do Product Owner ganha destaque nesta
disciplina, impedindo que o desenvolvimento fuja do escopo
requerido e permitindo que mudanas de requisitos sejam
realizadas com o menor custo possvel.
O TDD tambm podem ser teis para a verificao, por criar
testes aderentes aos requisitos antes mesmo da construo,
dificultando os desvios de escopo.
Validao (CMMI nvel 3, MPS.BR nvel D)
Existem duas formas geis muito utilizadas para validar se
o produto est sendo desenvolvido corretamente:
Atravs da prtica XP de programao em pares, onde o
cdigo validado durante sua construo;
Por meio do TDD, onde os testes antecipados diminuem os
riscos de desvios e erros.
Mais uma vez, a natureza interativa e cclica da prtica gil
permite que o produto seja frequentemente validado pelos
membros da equipe e pelo cliente.
Integrao do Produto (CMMI nvel 3, MPS.BR nvel D)
Atravs da prtica XP de integrao contnua o produto pode
ser integrado a cada alterao de cdigo. Isso permite que
Edio 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 integrao contnua Hudson.
Desenvolvimento de Requisitos (CMMI nvel 3, MPS.BR
nvel D)
Assim como ocorre no processo de Gerncia 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 so traduzidos por
ele para o restante da equipe.
Gerncia de Riscos (CMMI nvel 3, MPS.BR nvel C)
Para implementar o processo de gerencia de riscos, pode-se
lanar mo do quadro de riscos, ferramenta comum em proje-
tos Scrum. Trata-se de um quadro, construdo e mantido a cada
reunio, que est dividido em trs colunas (mitigar, aceitar
e evitar). A cada risco identificado nas tarefas selecionadas,
o quadro atualizado para que estejam visveis pela equipe
durante todo Sprint de desenvolvimento.
Concluso
O mapeamento entre prticas geis e reas de processos (ou
processos) de modelos de maturidade, apresentado neste arti-
go, apenas um exemplo prtico que possibilita a visualizao
da sinergia entre essas disciplinas de propsitos diferentes,
porm no divergentes. Existem outras metodologias geis
no exploradas neste artigo que podem abranger ainda mais
os processos do CMMI e MPS.BR.
Assim, no preciso definir um processo de desenvolvi-
mento de software rgido que integre metodologias geis e
modelos de maturidade. possvel flexibilizar a utilizao
de mtodos geis e modelos de maturidade de acordo com as
12 Engenharia de Software Magazine - Integrando Agilidade com maturidade
caractersticas e objetivos de cada organizao. Como exemplo,
pode-se considerar uma pequena startup de tecnologia, que
utilize mtodos geis e que, com o intuito de se adequar s
exigncias de um cliente, precise alcanar determinado nvel
de maturidade do MPS.BR.
O dinamismo da tecnologia da informao no permite que
normas e modelos de qualidade sejam inflexveis, mesmo que
sejam consolidados h anos. O direcionamento gil observado
no desenvolvimento de solues de software sugere que adap-
taes sejam feitas nos padres 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 produo de softwares.
Links
Agile e MPS.BR - Viso gil
http://www.visaoagil.com/static/downloads/edicoes/VA_03.pdf
Implementando CMMi utilizando uma combinao de Mtodos 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 edio! 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
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
Como formar Times de alta performance
Demonstre performance para seus clientes
Danilo Cereda
danilo.cereda@gmail.com
Graduado na rea de TI, com 7 anos de
experincia em desenvolvimento de
Software e 11 anos de experincia profissio-
nal atuando na rea de desenvolvimento de
sistemas WEB, sendo os ltimos 3 dedicados
liderana de equipes e coordenao de O Scrum uma metodologia gil para gerncia
projetos utilizando metodologia gil e o
framework Scrum. Atualmente atua como
Lder / Scrum Master em Campinas na Ci&T
(multinacional brasileira especializada em
consultoria e outsourcing de aplicaes vol-
tadas para agilidade nos negcios).
Fabio Pallini
fmpallini@gmail.com
Graduado na rea de TI possui 3 anos de
experincia em desenvolvimento gil.
Certificado como Professional Scrum Mas-
ter pela Scrum.org, atualmente trabalha na
Ci&T Campinas.
Como formar Times de alta performance: equipes, organizaes ou grupos virtuais, que so
Diversas metodologias foram criadas para siste- altamente focados nas suas metas e alcanam re-
matizar o desenvolvimento de software. Tais me- sultados de negcio surpreendentes.
todologias podem ser divididas em tradicionais, No existe um modo de aplicar um questionrio
que enfatizam a documentao de cada processo e dizer com certeza que um time de alta per-
do desenvolvimento de software, ou geis, que formance. O cliente deve perceber a evoluo
consideram um novo paradigma de desenvolvi- dos times e reconhec-los como tal. Para isso,
mento de software. Os mtodos geis focam em importante extrair informaes e mtricas que
simplicidade, software funcional no incio das indiquem que o seu time est na direo certa, de
iteraes, flexibilidade e intensa comunicao, modo que a avaliao do time no fique somente
tanto internamente quanto com clientes. Alm na percepo superficial do cliente e sim em uma
disso, aplicam o desenvolvimento iterativo e in- percepo formada por fatos concretos.
Este artigo retrata tcnicas e experincias em pro-
cremental, planejamento adaptativo, flexibilidade
e rpida resposta a mudanas. jetos Scrum relacionadas formao de times de
alta performance e demonstrao de ganho para o
de projetos, baseado em inspeo e adaptao, cliente atravs de mtricas de projeto.
iterativo e incremental, e pode ser aplicado a
qualquer produto ou no gerenciamento de qual- Em que situao o tema til:
quer atividade complexa. Assim, o Scrum um Este artigo fornece uma viso geral de formao
processo leve para gerenciar e controlar projetos de times geis e como desenvolve-los de modo a
de desenvolvimento de software e para criao de ganhar performance, at que possa ser chamado
produtos. Cada iterao dura aproximadamente de um Time de Alta Performance. So apresenta-
trinta dias, sendo conhecida como Sprint. Ao final das tcnicas que podem ser aplicadas a projetos
de cada Sprint deve ser entregue ao cliente parte geis para dar viso objetiva ao time de desenvol-
do produto concludo e funcional. vimento e ao cliente, sobre a qualidade e produti-
Times de Alta Performance um conceito dentro vidade das equipes.
do desenvolvimento das organizaes referente a
Edio 59 - Engenharia de Software Magazine 13
U
m dos principais assuntos em destaque nas mdias
especializadas em gesto e TI (Tecnologia de Infor-
mao) a construo de times de alta performance
(HPT High Performance Teams), como pode ser observado em
fontes virtuais, quando o termo procurado em algum bus-
cador qualquer, sendo surpreendente o nmero de resultados
relativamente retornados. Outra linha que tambm se destaca o
assunto a acadmica, pelo nmero de trabalhos relacionados
ao assunto atualmente.
Um exemplo de time de alta performance a seleo brasi-
leira de vlei, conforme discurso do tcnico Bernardinho,
sobre a formao do time onde, como em qualquer time de
alta performance, h garra, treino, conhecimento dos pontos
fortes de cada um, evoluo contnua e conhecimento do jogo
(negcio e metodologia).
O que poucas pessoas conseguem lembrar quando veem um
time vencedor o caminho que foi trilhado para chegar ao sta-
tus de campeo. Pensando nesse caminho, pode-se fazer uma
comparao direta com um time de desenvolvimento. Embora
se tenha experincia individual dos componentes da equipe, de
incio ainda no formam um time. Em conjunto possvel de-
senvolver diversas competncias tcnicas e comportamentais,
para ento se tornarem um time e atravs de ciclos de melhoria
gradual formarem um time de alta performance. O que ser
apresentado neste artigo justamente este caminho.
Iniciar um projeto sempre um desafio, preciso lidar com
um novo produto, novas expectativas, novas percepes e,
muitas vezes novos clientes. Este entendimento, anterior ao
incio do projeto, conhecido como fase de concepo. Nesta
fase, antes de pensar em desenvolver os times necessrio
encontrar pessoas adequadas ao novo desafio, dimensionar e
montar um ou mais times de desenvolvimento.
Dificilmente um projeto ser entregue a um time de desen-
volvimento j existente, que j trabalha junto h muito tempo,
sem mudanas de papel ou de pessoas. No mundo real, no
existe o conceito de times fixos, com pessoas que no mudam
de emprego, nem de rea de atuao. A carreira de TI sujeita
a mudanas e constantemente nos deparamos com situaes
imprevisveis no que diz respeito s alocaes internas e
externas de pessoas, assim como no existe garantia nas con-
trataes de desenvolvedores de que os mesmos vo atender
s expectativas e atingir o resultado previsto.
Mesmo que no framework Scrum no exista escopo de projeto
fixo, definido na concepo, muitas vezes existe um prazo para
entrega definido pela rea de negcio, para um conjunto de
funcionalidades bsicas, viabilizando que o produto retorne
valor (por exemplo, uma data de estreia de campanha comer-
cial, uma data fixada pelo governo para funcionamento de
uma alterao fiscal, entre outras).
Existem tcnicas para garantir que o cliente receba este pro-
duto mnimo entregvel, atravs da realizao de engenharia
de valor, redimensionamento de times, entre outras.
No entanto, independente de problemas de cronograma
de projeto, os times devem ser trabalhados para a evoluo
constante. Pois a expectativa do cliente que a quantidade
14 Engenharia de Software Magazine - Como formar Times de alta performance
e qualidade das entregas melhorem a cada Sprint, mantendo
a produtividade. Muitas vezes esta melhoria negociada no
momento de fechar um contrato, propondo uma velocidade de
incio abaixo da expectativa do cliente e projetando um ganho
de velocidade Sprint a Sprint at chegar a um valor que oscila,
pouco conhecido como velocidade de cruzeiro. Portanto, uma
empresa de TI que vende times Scrum, na verdade vende times
de desenvolvimento que conhecem e utilizam Scrum, mas no
tem como garantir que eles sejam Times de Alta Performance
por mais que conheam estes times e por mais que eles tenham
tido sucesso em projetos anteriores.
O que so Times de Alta Performance?
A performance, no contexto de clulas ou times de desenvol-
vimento, est intimamente relacionada com a maturidade do
time como um todo. Uma definio de maturidade estado
das pessoas ou das coisas que atingiram completo desenvol-
vimento. Para um time de desenvolvimento, maturidade
pode ser considerada como o conjunto de caractersticas que
mostram um alto grau de desenvolvimento tcnico e compor-
tamental. Entretanto, ter um time reconhecido como maduro
no garante um incio com alta performance.
A definio de HPT, ou High Performance Teams, segundo
o livro The Wisdom of Teams, traduzido para o portugus,
Times de Alta Performance, um conceito dentro do desen-
volvimento das organizaes referente a times, organizaes
ou grupos virtuais que so altamente focados nas suas metas
e alcanam resultados de negcio superiores, superando todos
os outros times similares e tambm as expectativas dadas a
sua composio.
Analisando a definio acima, pode ser observado que
comparativa.Ou seja, para identificar um time como de alta
performance utiliza-se comparao com outros times em
situao semelhante.
A definio de HPT tambm subjetiva, considerando as ex-
pectativas do cliente. No existe um modo de aplicar um ques-
tionrio e dizer com certeza que um time um HPT. O cliente
deve perceber a evoluo dos times e reconhec-los. Para isso,
importante extrair informaes e mtricas que indiquem que
o seu time est na direo certa, de modo que a avaliao do
time no fique somente na percepo superficial do cliente e
sim em uma percepo formada por fatos concretos.
Para ser um time de alta performance necessrio superar as
expectativas, entregar cada vez mais e cada vez melhor, sobre
uma meta possvel, evitando situaes comuns, onde o cliente
considera alta performance a entrega de tudo o que gostaria de
ter, simplesmente guiado pelo desejo e gerando uma avaliao
baseada em emoo e no em resultados.
Custo X Adequao
Para viabilizar um projeto existem diversas combinaes
possveis de montar times de desenvolvimento. Fatores como
distribuio, experincia tcnica e maturidade das pessoas
devem ser levados em conta antes de garantir que determinado
conjunto de pessoas atende a necessidade do negcio.

O Scrum prega que quanto mais multidisciplinar for um
time, melhor ser para o projeto. Se possvel, o time todo deve
ser capaz de planejar, executar e testar estrias, assim como
executar tarefas de Front-end e Back-end, com praticamente
o mesmo esforo. Porm, sempre haver pessoas com mais
facilidade para um tipo de atividade e menos para outro tipo,
mas deve haver o incentivo a multidisciplinaridade e o trabalho
conjunto sempre que possvel, o que auxilia ter um time menos
sujeito a situaes imprevisveis.
Qualquer empresa gostaria de ter em seus times somente
pessoas com muitos anos de experincia comprovada, um
time inteiro snior. Na maioria das vezes, isso no possvel,
seja por motivo de falta de colaboradores com esse perfil no
mercado, seja pelo alto custo. O que deve estar claro que a
no ser que o cenrio exija e possibilite um time de sniores,
o aconselhvel a fazer montar um time balanceado. Onde
desenvolvedores menos experientes tenham apoio tcnico de
um desenvolvedor mais experiente, assim como um testador
jnior possa ser responsvel por executar os testes, enquanto
um testador mais experiente possa ser responsabilizado pela
criao dos cenrios e validao dos requisitos, de modo a focar
em planejamento e no na execuo de testes.
Na maioria das vezes, o sucesso de um projeto tem uma rela-
o direta entre o equilbrio de qualidade, custo e prazo.
Pilares: Escopo x Custo x Prazo
As trs primeiras reas a serem estudadas pelo PMI (Project
Management Institute), Escopo, Custo e Prazo, ajudaram
a formar um diagrama, chamado de Trinmio Sagrado do
Gerenciamento de Projetos. Este diagrama mostra resultados
das variaes sobre o escopo, custo e prazo do projeto e seu
impacto na qualidade.
Para o sucesso de um projeto necessrio equilibrar esses
trs pilares, que so relacionados como vrtices de um trin-
gulo (veja a Figura 1). Se a opo for um custo menor, deve-se
aumentar o prazo ou reduzir o escopo. Se a busca for pela
entrega em menor prazo, provavelmente haver um custo
maior ou ser necessria reduo do escopo.
Figura 1. Trinmio Sagrado do gerenciamento de projetos
AgiLidAdE
Mas e a qualidade? Por que a qualidade no negocivel?
O pilar qualidade fica entre os trs vrtices, o que impossibili-
ta que seja negociado. Qualquer problema com qualidade gera
impacto direto em custo, prazo e/ou escopo. No existe motivo
para diminuir a qualidade, mesmo que a falta de cuidado com a
qualidade parea atraente por diminuir o custo, como nos casos
que h diminuio no time de testes ou no escopo de testes, por
exemplo. O problema que se no h garantia de qualidade,
dificilmente haver como dizer que entregaremos no prazo ou
que respeitaremos o custo. Ento o ganho aparente ser posto
em prova quando defeitos em desenvolvimento, homologao
ou produo comearem a impactar negativamente no prazo
e no custo, um risco que no vale a pena correr.
Diante disso, existe um cuidado com times de desenvolvi-
mento que no deve ser negligenciado, o de produzir com
qualidade, acima de velocidade ou previsibilidade.
Desenvolvimento contnuo
Para atingir as metas de velocidade sem perder qualidade, o
ideal seria iniciar o projeto com um time de tcnicos especialis-
tas nas tecnologias do projeto, com profundo conhecimento no
negcio, no cliente e comprometido com a entrega do produto.
Esta realidade possvel para equipes que desenvolvem pro-
dutos diretamente para a empresa onde atuam, trabalhando
em conjunto com a rea de negcio e com conhecimento prvio
do sistema que ser criado ou evoludo.
Esta no a realidade das consultorias e fbricas de softwa-
re, pelo fato de que tanto na contratao dos profissionais,
quanto na formao da equipe, no existe garantia de que
os colaboradores tenham conhecimento tcnico necessrio.
Dificilmente os colaboradores conhecero o negcio do cliente
antes de iniciar o projeto e muito menos haver garantia de que
todos estejam comprometidos com a entrega. Por este motivo
importante entender que times diferentes, compostos por
pessoas com nvel tcnico e de maturidade diversificados, tero
incio de projeto com resultados diferentes. Por isso, quando
no existe garantia de iniciar um projeto com alto rendimen-
to, os colaboradores devem ser conduzidos pelo processo de
melhoria contnua, de forma a serem capazes de alcanar o
desenvolvimento tcnico e pessoal necessrio para atender a
necessidades identificadas.
O Scrum um framework iterativo, baseado em ciclos de PDCA;
sigla em ingls que significa Planejar, Executar, Validar e Atuar
(Plan, Do, Check, Act). Deste modo, as fases que compem uma
iterao (ou ciclo) devem ser analisadas para dar aos times
insumos para o desenvolvimento, aumentando a percepo
do prprio time sobre seus pontos fortes e de melhoria.
Com o foco na melhoria contnua e considerando o aprovei-
tamento mximo e feedback das iteraes, alguns pontos de
ateno devem ser levados em considerao, os quais sero
analisados na sequncia.
Levar a srio os ritos do Scrum
O Scrum utiliza ritos formais para marcar as diferentes fa-
ses dentro da iterao, sendo o resultado da aplicao correta
Edio 59 - Engenharia de Software Magazine 15
refletido diretamente na eficincia de cada rito. Por isso, quanto
mais prximo da metodologia um time executa os Sprints, me-
lhor o resultado. Este cuidado com a fidelidade ao processo
conhecido como execuo do Scrum by the book.
Existem sugestes de aes para aperfeioar a execuo dos
ritos Scrum durante os projetos, so elas:
Planning Meeting: As planning meetings so reunies de
planejamento das funcionalidades do produto, que sero
compromisso da prxima entrega e devem estar focadas em
um produto simples e que resolva o problema proposto pelo
PO (Product Owner). Geralmente o time pensa em entregar um
produto completo de funcionalidades e esteticamente agrad-
vel, mas as funcionalidades bsicas e a facilidade de uso devem
ser prioridades para a maioria dos casos. Pode at ser que a
esttica seja o foco do desenvolvimento como, por exemplo,
no caso de desenvolvimento de sites, mas este requisito deve
ser alinhado e no tomado como meta do Sprint, devido ao
interesse do time. O importante que o PO atue ativamente
no planejamento, ficando com a deciso do que prioritrio
para a entrega e que todos saiam da reunio alinhados com o
consenso de aceite do Sprint.
O time deve pensar no compromisso da entrega e focar em
conseguir entregar as estrias das quais houve o comprome-
timento. esperado que o time tenha capacidade de negociar,
caso o escopo no seja coerente com a velocidade prevista pelo
time. s vezes, uma soluo mais simples que a proposta, ou
uma funcionalidade (no essencial) que seja retirada de uma
estria, permite que o produto entregue traga maior valor.
O questionamento do que prioridade na maioria das vezes
fica sobre responsabilidade do Scrum Master, mas quando h a
responsabilidade do time com o produto que est desenvolven-
do, negociando diretamente com o Product Owner, se tem um
compromisso maior de ambos os lados e maior flexibilidade
na resoluo dos desafios, conforme forem surgindo;
Daily Meeting: A daily meeting uma reunio diria que
permite um alinhamento do time com as atividades do Sprint,
geralmente realizada com o time em p e seus membros res-
pondendo questes, como, O que voc fez ontem? O que voc
est fazendo hoje? O que est te impedindo de realizar o seu
trabalho? De forma resumida;
Acompanhando a daily meeting, o Scrum Master deve inter-
romper quando o time est fazendo uma apresentao para
cada membro ao invs de para o time todo. A importncia da
daily meeting passar, alm do status, a percepo do desenvol-
vedor sobre a meta do Sprint e as dificuldades encontradas no
desenvolvimento de sua atividade, de modo que todos possam
entender e participar das atividades de todos. Portanto, deve-se
utilizar esse tempo para refletir sobre as atividades do time,
um exemplo seria um desenvolvedor dar uma ideia que resolva
o problema de outro, um testador perceber um risco em deter-
minado cenrio e planejar testes mais especficos para este ce-
nrio, o Scrum Master detectar um impedimento antes mesmo
dele se concretizar, ou seja, o momento do time esquecer as
dificuldades individuais e trabalhar na construo do produto
como um todo e no como um conjunto de atividades;
16 Engenharia de Software Magazine - Como formar Times de alta performance
Demo Meeting /Sprint Review Meeting: Chegou o momento
da entrega do Sprint e o time todo se rene com o PO para de-
monstrar o produto, sendo notvel a reao do PO quando se
alcana o resultado esperado, assim como quando a expectativa
era maior que o produto entregue. A apresentao do Review
meeting no altera a qualidade da entrega, mas contribui para
que na prxima Planning meeting estes feedbacks sejam incor-
porados ao produto;
Retrospective Meeting: Reunio realizada no final de todo
Sprint, onde realizada toda a retrospectiva do Sprint com um
olhar crtico. Nesta reunio todos so convidados a apontar clara-
mente o que deu certo e o que no deu certo no Sprint e chegar
a um consenso sobre quais itens devem ser melhorados.
o momento oficial para apontar aes de sucesso e discutir
melhorias. Os feedbacks devem ser focados em aes possveis
de serem implantadas, por exemplo, no adianta apontar que
se tivessem um supercomputador se ganharia tempo com a
gerao de builds, se no possvel conseguir esse supercom-
putador. Tambm deve se eleger poucas aes para melhorar
o prximo Sprint, no adiantando eleger quinze pontos de
melhoria e no final do Sprint conseguir atuar em apenas
trs. Neste caso, a melhor estratgia seria trabalhar em trs a
cinco aes possveis por Sprint e realmente resolv-las, alm
de refletir sobre a soluo do problema para que no volte a
ocorrer. Outra atitude que contribui para a efetividade das
retrospectivas no deixar para lembrar os problemas na l-
tima hora. Assim, necessrio procurara estimular os times a
anotar os problemas conforme eles acontecem durante o Sprint,
para diminuir o risco de esquecer algo importante e melhorar
a dinmica da prpria reunio de retrospectiva.
Exercitar o Feedback sempre
Uma grande vantagem de um framework com iterao a pos-
sibilidade de trabalhar com melhoria contnua. Para fornecer a
retroalimentao necessria anlise dos pontos de melhoria
existe a prtica da Retrospective Meeting.
Realizar feedback apenas uma vez por Sprint no suficien-
te, esse deve ser exercitado sempre que possvel, fornecendo
ao time uma rgua para medir o quanto alinhados esto
com a necessidade do projeto. No existe uma regra, nem
interessante utilizar tempo do time se no existir nenhum
acontecimento pertinente, mas se possvel deve-se exercitar
o feedback dirio.
O modo mais fcil de no cometer o mesmo erro mais de uma
vez tomar conhecimento do problema o quanto antes. Deste
modo, aumenta a chance de que uma ao de resultado positivo
seja aplicada novamente, antecipando um novo problema, e
expondo a todos o resultado para que sejam estimulados a
aplicar iniciativas de sucesso.
Capacitao e treinamentos direcionados
A evoluo de um time compreende enfrentar desafios, mas
muitas vezes se deparam com situaes tcnicas e compor-
tamentais para as quais no esto preparados. importante

reconhecer os momentos onde o time precisa de ajuda para se
desenvolver, podendo ser atravs de um treinamento, que pode
ser realizado no dia a dia do Sprint, direcionado para a soluo
do problema ou de um treinamento mais formal. O que importa
que o time entenda que tem um problema a resolver e seja
encorajado a se desenvolver, tendo apoio para isso. No caso
de ter um colaborador do time com dificuldades, sugerido
treinamento especfico de forma a equalizar o conhecimento
em que ele esteja defasado dos demais.
Exibir claramente os resultados sobre as metas aceitas
O PO uma das chaves para o sucesso do projeto. Ele deve
acreditar no Scrum e defender seu uso perante os stackeholders
e sponsors do projeto. O sucesso ou a falha da entrega do time
o sucesso ou a falha da entrega do PO, que sabe o valor de cada
entrega, o compromisso firmado com o time e tem condies
de justificar o desempenho do time se for questionado.
De nada adianta o time estar orgulhoso em cumprir o acordo
do Sprint se ao apresentar o produto ao PO ele estiver com uma
expectativa maior. Por isso importante que o acordo firmado
na planning esteja alinhado com a expectativa do cliente, tam-
bm importante ao PO conhecer e acreditar na metodologia,
ou seja, entender as regras do jogo, de modo que participe ati-
vamente dos resultados, j que ele est construindo o produto
junto ao time. Para que exista o comprometimento entre o time
AgiLidAdE
e o cliente, todos devem ter ferramentas para acompanhar os
resultados dos Sprints de modo claro e intuitivo.
Com todas estas diretivas se cria um ambiente com condies
para o time se desenvolver, afinal, o prprio time deve ser
capaz de visualizar sua condio atual e o caminho para se
tornar melhor. Aes de melhoria e corretivas podem ser pla-
nejadas e executadas, mas se o time no estiver comprometido
a evoluir, no se tornar um HPT.
O cliente enxerga a alta performance do seu time?
No momento da entrega, pouco vale o fornecedor estar
orgulhoso do seu time HPT e do produto construdo, se o
cliente no enxerga o mesmo. Mas, como medir e demonstrar
performance para seu cliente?
O cliente muitas vezes quer saber quantas horas/minutos/
segundos o time levou para desenvolver cada estria, se con-
sidera este dado o mais importante para seu planejamento.
Dentro de um cenrio complexo de gesto de projeto muitas
variveis interferem nas estimativas de entrega. Ento, porque
no planejamento do Sprint se usa Story Points, em vez de estimar
o prazo de desenvolvimento em horas? Porque cada estria
diferente da outra. Mesmo tendo levado trs dias para entregar
uma estria de treze Story Points, no existe garantia de que
uma estria, aparentemente parecida com os mesmo treze Story
Points, ser entregue em trs dias tambm.
Edio 59 - Engenharia de Software Magazine 17
 Nenhuma estimativa to precisa e por isso que se usa a es-
cala de Fibonacci para medir o esforo, porque ela possui valores
com intervalos crescentes e no sequenciais. Por isso pode-se
concluir que uma estria de treze Story Points leva mais esforo
para entregar do que uma de oito Story Points, mas menos que
uma estria de vinte e um Story Points. Existe um intervalo entre
os valores que cresce conforme a pontuao aumenta, mostran-
do que quanto maior o esforo total para entregar uma estria
maior o erro de estimativa, ou desvio, possvel de ocorrer.
O planejamento do projeto sempre fica sujeito a desvios de
prazo, mas no Scrum este desvio j previsto, de modo que
pode ser gerenciado alterando o escopo de entrega, mas man-
tendo o foco no desenvolvimento das funcionalidades que
possuem mais valor.
Para medir desvios positivos ou negativos sobre custo, prazo
e qualidade de um projeto, podem ser usados trs pilares:
Produtividade, Previsibilidade e Qualidade.
Previsibilidade
A mtrica de previsibilidade mede o desvio das datas de en-
trega, no momento do planejamento do roadmap sobre as datas
de entrega efetivas. Para o cliente, a capacidade de prever o
que ser entregue e quando. Para garantir uma medida correta
de previsibilidade importante manter o controle de Baseline
do projeto, atualizando qualquer desvio ocorrido. Para medir
o desvio aps a entrega de um Sprint necessrio realizar o
grooming do backlog, ou seja, a anlise do backlog restante, com
foco em rever qual o esforo necessrio para entregar as demais
estrias e avaliar se essas foram alteradas para mais complexas
ou menos complexas, com base na pontuao das estrias j
entregues. Atravs de um backlog inicial pode ser gerado um
release e um grfico de burndown que mostra na linha do tem-
po a concluso dos Sprints de um release, para medir o quo
prximo do planejado se esta aps o trmino de cada sprint
e deste modo demonstrar desvios por aumento de escopo de
produto, consequente aumento do backlog.
Com a percepo de desvios nas entregas dos Sprints, pode-
se replanejar datas do projeto ou cortar escopo, de modo a
concretizar a entrega na data inicial proposta. Lembrando que
quando entra uma estria (funcionalidade) nova ou aumenta
a complexidade de alguma existente no backlog, automatica-
mente necessita se despriorizar outra estria, de preferncia
que entregue menor valor ao negcio. O escopo do projeto, que
forma o backlog, deve ser visto como um espao limitado, onde
no cabem mais estrias e para que entre uma, outra de mesmo
tamanho deva sair. O importante que as trocas sejam feitas
pelo PO, junto ao Scrum Master e/ou o time e devidamente
alinhadas com as reas de negcios.
No exemplo da Figura 2 pode ser acompanhado o total pre-
visto de pontos que deveriam ser entregues em nove Sprints.
O grfico mostra atravs da linha verde (entrega executada)
que houve um atraso nos quatro primeiros Sprints, atravs
dos Story Points (SP) restantes acumulados. Acompanhando a
linha vermelha (entrega planejada), que mostra os Story Points
restantes planejados para o final de cada Sprint, como pode ser
18 Engenharia de Software Magazine - Como formar Times de alta performance
observado o atraso foi compensado a partir do Sprint cinco.
No oitavo Sprint o time entrega todos os pontos restantes e ain-
da sobraram seis, de modo que poder ser aceita uma (ou mais)
estria, somando seis SP e manter a previso de entrega.
Figura 2. Acompanhamento das entregas previstas e realizadas para
Sprints de um release ou projeto
Produtividade
A produtividade a capacidade de entrega de um time, sen-
do a quantidade de funcionalidades que um time consegue
entregar em um perodo de tempo. Essa pode ser medida
utilizando a velocidade do time (velocity) em Story Points, essa
velocidade calculada pela quantidade de pontos que o time
consegue entregar por Sprint, considerando a quantidade de
desenvolvedores fixa ou a taxa resultante da quantidade total
de Story Points dividida pela quantidade de desenvolvedores,
caso o time sofra alteraes.
Deve ser considerado ganho positivo quando o time entrega
uma quantidade maior de Story Points do que no ltimo Sprint,
projetando velocidade crescente. Mas para este ganho ser real,
o time deve mostrar que entrega realmente mais, pois, apenas
subir a pontuao das estrias gera uma viso errada de ganho
de produtividade. importante fazer uma anlise comparativa
do tamanho das estrias Sprint a Sprint.
No final do Sprint podem ser comparadas as estrias e
verificar se elas so do tamanho proposto inicialmente.
O importante manter as comparaes atualizadas, para que
na prxima planning meetings as estimativas sejam baseadas
em valores atualizados.
Acompanhando os valores da velocidade do time nos Sprints,
o esperado que o time, ao adquirir maturidade, aumente sua
produtividade nos primeiros Sprints, mas em algum momento
ele deve estabilizar, pois atinge sua produtividade mxima.
O maior desafio, deste ponto em diante, manter estes valores
constantes, pois uma diferena negativa pode aparecer de um
Sprint para outro, por motivos que no podem ser controlados.
O esperado que uma vez que o time atingiu um patamar m-
ximo de produtividade, a mdia de Story Points dos ltimos se
mantenha estvel, com pouca variao em torno deste valor.

Qualidade
Qualidade prioridade em qualquer projeto. Em qualquer
momento deve ser possvel negociar prazo, custo, mas quali-
dade no se negocia. De nada adianta entregar um projeto no
prazo, quando se gera inmeros problemas em produo. O
custo de corrigir problemas em produo alto, quem alm
de causar problemas para o negcio, tambm pode consumir
margem de um projeto atravs do cumprimento de um contrato
de garantia, por exemplo.
Se um time apresenta erros de desenvolvimento pode se
considerar algumas hipteses, como estrias com requisitos fa-
lhos, falta de maturidade tcnica do time de desenvolvimento,
falta de entendimento entre desenvolvedores e testadores, um
PO ausente. Atravs do levantamento de pontos falhos, ainda
durante o desenvolvimento, possvel fixar planos de ao que
acompanhados podem reverter o cenrio negativo.
Para ter alta performance necessrio que o time conhea
e entenda a qualidade do projeto, assim como os meios de
monitorar/melhorar a qualidade Sprint a Sprint.
Para definir o que esperado da qualidade em um projeto e
o que ser cobrado no momento das entregas, existem compro-
missos, que firmados em documentos, descrevem definies
e critrios que devero ser atendidos, a saber:
Definio de READY: O ponto de partida no Scrum para
garantir que o que est sendo produzido ter qualidade,
definir as regras para o time de desenvolvimento, com o
que produzir e como produzir. Chamamos estas regras
de Definio de READY (ou DoR). Este acordo define as
caractersticas mnimas que uma estria deve ter para ir ao
Planning meeting.
Um exemplo levar para a reunio de planning uma estria
que contemple criar uma pgina principal de um site sem um
wireframe (desenho bsico dos componentes da tela) ou sem um
guia de estilo. Como os desenvolvedores podem saber o que
fazer, como fazer, ou at mesmo definir quanto esforo tero
que fazer para entregar uma tela que nem imagina como ?
Para sanar este problema podemos exemplificar que no projeto
Site Institucional da Empresa X, todas as estrias que des-
crevem uma pgina qualquer do site podem ter as seguintes
regras na sua DoR:
- As telas devem possuir um guia de estilo (tipo/tamanho
de letra, cores, etc);
- As telas devem possuir wireframes que expliquem quais
componentes devem ser exibidos, sua localizao, tamanho,
tipo de contedo, etc;
- As telas devem ter sido aprovadas pela rea responsvel
pela usabilidade.
Assim como a definio geral de Ready, que mostra quando
uma estria est pronta para ser discutida na planning meeting,
preciso criar regras (critrios), que expliquem claramente para
o time durante a reunio de planning qual resultado esperado
na entrega de cada estria do backlog;
Definio de DONE: Assim como a definio de READY
o ponto de partida, para saber o que se deve produzir, a
AgiLidAdE
definio de DONE o acordo para garantir que o que est
sendo entregue tenha qualidade. definir com o PO o que
uma estria pronta para o projeto. Chamamos estas regras de
Definio de Pronto (Definition of Done ou DoD).
Estas regras variam de projeto para projeto e por isso devem
ser combinadas no incio para serem utilizadas durante todo
o projeto.
Critrios de Aceite: Para a Definio de Pronto das est-
rias uma das regras que todos os critrios de aceite foram
entregues. Isso porque a viso de qualidade do PO intima-
mente ligada aos critrios que foram pedidos para o produto
em cada estria, sendo de responsabilidade dele cobrar do
time os critrios que foram definidos nas estrias. Qualquer
funcionalidade ou caracterstica que no foi definida como
critrio, no pode ser exigida na Review meeting e dever ser
mapeada em uma nova estria que entrar no backlog, gerando
a necessidade de negociao do escopo para que no impacte
no prazo de entrega do projeto;
Com todas estas definies alinhadas deve se garantir que os
acordos sejam cumpridos. Para isso h mtricas que devem ser
acompanhadas para gerar aes corretivas, caso o resultado
no esteja de acordo.
Mtricas de qualidade em desenvolvimento,
homologao e produo
A principal mtrica que indica se o time est desenvolven-
do uma aplicao com qualidade o nmero de defeitos. Se
h muitos defeitos em desenvolvimento, existe uma chance
enorme de ter defeitos em homologao e, consequentemente,
muitos defeitos em produo.
Uma meta comum maioria dos contratos buscar executar
projetos sem defeitos. Mas este resultado no alcanado na
maioria das entregas. Portanto, deve ser determinada uma
meta possvel, iniciando pelo nmero de defeitos que seja
aceitvel em desenvolvimento, e garantir que a homologao
seja bem feita, mirando uma produo sem defeitos. no mun-
do real que a qualidade do projeto posta a prova, portanto
no adianta fazer um projeto com poucos defeitos na fase de
desenvolvimento, se tiver vrias ocorrncias de defeitos em
produo.
Para ter uma medida da qualidade geral do projeto, a quan-
tidade de defeitos deve ser considerada como a principal evi-
dncia, mas sem esquecer de avaliar a gravidade de cada um
individualmente. Em alguns casos pode ser melhor, do ponto
de vista do negcio, ter mais de um defeito simples a um ni-
co crtico. Apesar disso, necessrio ter critrio na avaliao
da qualidade, pois dificilmente haver muitos erros sem que
parte deles seja crtico.
Um modo interessante para o time acompanhar e atuar so-
bre o nmero de defeitos construir um Burnup de Defeitos
(Figura 3), uma ferramenta visual para acompanhar a curva
de crescimento de defeitos diariamente, de modo que no final
de cada Sprint o nmero total de defeitos seja comparado a um
nvel mximo aceitvel em desenvolvimento. Este limite, ou
Edio 59 - Engenharia de Software Magazine 19
meta, deve ser negociado por projeto e geralmente calculado
levando em conta o nmero de desenvolvedores que geram
cdigo, a tecnologia em que o projeto est sendo desenvolvido
e outras particularidades do projeto. Uma vez que o limite
foi definido e o Sprint estiver em andamento, a atualizao
do grfico deve ser feita sempre que o testador encontrar um
novo defeito.
Figura 3. Acompanhamento da qualidade de implementao na fase de
desenvolvimento atravs de um Burnup de defeitos
Atravs da viso crtica sobre estes dados, o time deve atu-
ar para que o total no passe do limite estabelecido e caso
ultrapasse, deve-se tomar aes corretivas para se ter uma
diminuio progressiva nos prximos Sprints.
Concluso
Quem no gostaria de trabalhar sempre em times de alta per-
formance? Times que entregam muito, rpido e com qualidade.
20 Engenharia de Software Magazine - Como formar Times de alta performance
Times que surpreendem o cliente com solues inovadoras e
que entregam mais do que o cliente espera. Esta excelncia
pode e deve ser um objetivo comum aos times, mas no existe
como prever objetivamente que um time entregar com Alta
Performance. A meta que deve ser perseguida a evoluo do
time para que ele alcance o desempenho desejado, porque HPT
conquistada diariamente, com conhecimento do negcio,
domnio da tcnica, comprometimento, atitude colaborativa
e muita mobilizao para resolver problemas.
Para um fornecedor que pretende vender um time de alta
performance importante mostrar que o time tem potencial
de se tornar um HPT, mas para isso existe um caminho, mui-
tas vezes longo, a percorrer para alcanar este objetivo. Times
no nascem com alta performance, mas seguindo a meta de
melhora continua nas iteraes, permitindo conquistar este
objetivo em alguns Sprints.
Links
Scrum Guide 2011, escrito por Ken Schwaber e Jeff Sutherland
www.scrum.org/scrumguides
[1] The Wisdom of Teams, escrito por Katzenbach, editora HarperBusiness, 2003
[2] JALOTE, Pankaj. CMM in practice: processes for executing software projects at
Infosys. USA: Addison Wesley Longman, 1999.
Feedback
D seu feedback sobre esta edio! 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
edio
D seu voto sobre este artigo, atravs do link:
www.devmedia.com.br/esmag/feedback