Você está na página 1de 15

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

de software mais utilizados, possvel definir um


Integrando Agilidade com maturidade:
processo de desenvolvimento aderente aos padres
O processo de desenvolvimento de um software
consolidados de qualidade e que seja implementa-
uma sequncia lgica de atividades com o objetivo
do por mtodos geis de desenvolvimento, unindo
final de produzir ou evoluir um produto. Essas ativi-
os benefcios de ambos os paradigmas.
dades englobam a especificao de requisitos, an-
Este artigo apresenta caractersticas especficas dos
lise e design, implementao, testes e implantao.
principais mtodos geis e dos modelos de maturi-
Caracterizando-se pela interao de ferramentas,
dade CMMI e MPS.BR, para ento, desenhar um mo-
pessoas e mtodos.
delo que mostra, na prtica, como os dois diferentes
Um dos caminhos para se trabalhar com melhoria
paradigmas podem se integrar e conceber um pro-
de processos fazer uso de modelos de maturidade.
cesso de desenvolvimento de software de qualida-
Estes indicam um conjunto de boas prticas que
de moderno. Este artigo mostra que o preconceito
podem ser estabelecidas na organizao de forma
existente que separa os modelos de maturidade e
a propiciar que ela obtenha melhores resultados no
melhoria de software e as metodologias geis no
desenvolvimento de produtos de software. Tam-
justificado. Inclusive, apresentada uma proposta
bm estimulado pelo desafio de entregar software
prtica de integrao entre eles.
de qualidade, dentro do prazo e no custo planejado,
surgiram as metodologias geis.
Entretanto, por defenderem formas de desenvol- Em que situao o tema til:
vimento muitas vezes contrrias, os modelos de Diante do atual cenrio de mercado altamente
maturidade CMMI e MPS.BR e os mtodos geis competitivo, importante que as organizaes
geralmente caminham em vias diferentes. Porm, invistam na melhoria de processos para atender
a partir das caractersticas apresentadas pelas s suas perspectivas (satisfao dos clientes, lu-
Bruno Carreira Coutinho Silva principais prticas geis e modelos de maturidade cratividade, qualidade, entre outras).
brunocarreira@gmail.com
Possui graduao em Cincia da Compu-
tao e mestrado na rea de Qualidade de

A
Software pela UFES. Tem mais de 12 anos utilizao de metodologias competitivo. As prticas geis iniciaram
de experincia profissional na rea de en- geis em projetos de desenvol- sua aplicao em organizaes de pe-
genharia de software, atuando principal- vimento de software j uma queno porte, apesar de terem mostrado,
mente como arquiteto de software J2EE.
realidade, sendo motivada principal- ao longo dos ltimos anos, que tambm
Utiliza o framework Scrum h trs anos e
atualmente engenheiro de software no mente por sua caracterstica dinmica, podem ser utilizadas em corporaes de
servio pblico federal. exigncia de um mercado cada vez mais mdio e grande porte, onde comum a

6 Engenharia de Software Magazine - Integrando Agilidade com maturidade


AgiLidAdE

implementao de prticas formais de melhoria de processo Metfora: traduo das palavras do cliente para facilitar a
de software, dada a necessidade de se repetir e melhorar os comunicao com o desenvolvedor;
resultados obtidos em todos os projetos do portflio organi- Projeto Simples: preciso ter foco na funcionalidade mais
zacional. Os modelos de melhoria de processos de software importante para cada iterao;
mais utilizados no Brasil so o CMMI e MPS.BR, considerados Testes de Aceitao: testes construdos pelo cliente em
referncia para empresas que desejam elaborar processos conjunto com analistas e testadores para aceitao de deter-
otimizados e maduros. minados requisitos;
Muitos adeptos dessas metodologias defendem que mo- Programao em Pares: Desenvolvedor experiente e iniciante
delos de melhoria de software, como o CMMI e MPS.BR, e programando juntos buscando amadurecimento do iniciante e
metodologias geis divergem entre si em conceito e propsito, proporcionando a reviso do cdigo em busca de diminuio
impossibilitando que possam ser integrados. Talvez esse tipo de defeitos;
de reao se deva ao aparente antagonismo de princpios en- Refatorao: proporciona melhoria contnua da progra-
tre elas ou, at mesmo, por simples orgulho proveniente do mao, mantendo a compatibilidade com cdigo original,
comportamento humano. diminuio de erros e duplicaes de cdigo;
Na observao criteriosa dos processos e prticas do CMMI Propriedade Coletiva: onde o cdigo no tem dono, pro-
e MPS.BR e alguns mtodos propostos pelo manifesto gil, porcionando que todos alterem qualquer parte do programa
possvel perceber que ambos se complementam, ou seja, e conheam todas as suas partes;
perfeitamente vivel definir um processo de software Integrao Contnua: a cada nova funcionalidade produzida,
aderente a modelos de maturidade e utilizar mtodos geis feita a integrao ao cdigo existente para que se saiba a real
para sua implementao prtica. A tendncia que os be- situao da programao;
nefcios desses dois diferentes paradigmas sejam somados, Semana de 40 horas: horas extras s devem ser permitidas
possibilitando o desenvolvimento de software mais eficiente caso haja motivao suficiente para boa produtividade;
e maduro. Reunies em p: reunies rpidas e produtivas evitando a
perda de foco;
Metodologias geis Padronizao de Cdigo: o cdigo de todos os desenvolve-
Em 2001 foi criado o Manifesto gil, movimento cuja essncia dores deve ser padronizado, permitindo que todos possam
o desenvolvimento de software respeitando os seguintes manter qualquer parte do sistema.
conceitos:
Pessoas e interaes, ao contrrio de processos e Estas prticas so claras, objetivas e especficas e utilizadas
ferramentas; no dia a dia dos membros de uma equipe de XP.
Software executvel, ao contrrio de documentao
abrangente; TDD (Test-Driven Development)
Colaborao do cliente sobre negociao do contrato; O Test-Driven Development uma tcnica de desenvolvimento
Respostas s mudanas, ao invs de seguir planos. onde, primeiramente, so definidos testes para todos os cen-
rios dos requisitos levantados e, em seguida, escrito o cdigo,
Vrias metodologias e ferramentas geis foram originadas que deve respeitar as restries impostas por eles. Dessa forma,
desse movimento, tendo como base os conceitos previamente o engenheiro tem a tendncia de entender melhor o problema,
listados. Dentre as metodologias geis existentes, algumas antes de implementar a soluo.
delas mais utilizadas no mercado so XP (Extreme Program- Apesar de no ser considerada uma tcnica exclusivamente
ming), TDD (Test-Driven Development), FDD (Feature-Driven relacionada ao XP, o TDD tem suas origens nele, sendo comu-
Development), SCRUM e Kanban. mente utilizado em projetos geis.

XP (Extreme Programming) FDD (Feature-Driven Development)


Mtodo ideal para pequenas e mdias equipes de desen- O Feature-Driven Development uma metodologia gil que
volvimento, que possuem requisitos vagos ou dinmicos de combina prticas de gerenciamento gil e a abordagem de
um produto a ser desenvolvido. Devido a essa caracterstica, engenharia de software orientada a objetos.
esta tcnica defende o desenvolvimento incremental e o A FDD descrita por cinco processos:
feedback constante entre as partes interessadas, encorajando Desenvolver um Modelo Abrangente que a construo
a comunicao entre elas. Alm disso, possui cinco valores de modelo de objetos (ou de dados) que servir de referncia
fundamentais: comunicao, simplicidade, feedback, coragem para a equipe de desenvolvimento;
e respeito. Tendo como principais prticas: Construir uma Lista de Funcionalidades onde se divide
Jogo de Planejamento: feito um planejamento semanal o domnio do problema em trs camadas (reas de negcio,
para priorizao de funcionalidades; atividades de negcio e funcionalidades), representando uma
Entregas Frequentes: entregas de pequenas verses funcio- hierarquia de funcionalidades que representa o produto a ser
nais para aceite do cliente; 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 AP 1.1 - O processo executado;
pequenos, so geralmente tratados em conjunto. Como AP 2.1 - O processo gerenciado;
consequncia, no comum encontrar empresas que alcan- AP 2.2 - Os produtos de trabalho do processo so gerenciados;
aram o CMMI nvel 4. Normalmente do nvel 3, elas passam AP 3.1 - O processo definido;
diretamente para o nvel 5. AP 3.2 - O processo est implementado;
AP 4.1 - O processo medido;
MPS.BR AP 4.2 - O processo controlado;
O MPS.BR (Melhoria de Processos de Software Brasileiro) AP 5.1 - O processo objeto de inovaes;
um modelo de qualidade de processo voltado para a realida- AP 5.2 - O processo otimizado continuamente.
de de pequenas e mdias empresas de desenvolvimento de
software do Brasil e est dividido em trs partes: Note que diferente do CMMI, no MPS.BR os primeiros nveis
MR-MPS (Modelo de referncia para melhoria do processo de maturidade possuem menos reas de processo. O objetivo
de software), que contm as reas de processos divididas em desta definio facilitar a insero da cultura de processos
nveis de maturidade; dentro das organizaes e permitir que mais organizaes
MA-MPS (Mtodo de avaliao para melhoria do processo considerem nveis de maturidade em seus processos, fazendo
de software), que orienta a realizao de avaliaes, conforme com que os custos de implementao sejam mais baixos e o im-
a ISO/IEC 15504; pacto sofrido pela organizao ao implantar os nveis iniciais
MN-MPS (Modelo de negcio para melhoria do processo de maturidade sejam mais facilmente absorvidos.
de software), que guia instituies que desejam implantar os
processos MPS.BR, como implementadoras. Mapeando prticas geis em modelos de maturidade
Apesar de abordarem princpios com focos diferentes, no h o
O MPS.BR est organizado em diversas reas de processo, que inviabilize a utilizao de mtodos geis na implementao
divididas em sete nveis de maturidade (Tabela 2). de modelos de qualidade e melhoria de processos de software.
Para cada nvel de maturidade, uma quantidade de capacida- A utilizao de prticas geis mais comum em equipes
des obrigatrias para cada processo definida, sendo elas: 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)

Verificao - VER
Validao - VAL
D Largamente Definido 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


AgiLidAdE

que sejam efetivamente aplicadas em equipes maiores, muito os demais mdulos do sistema numa verso executvel, per-
comuns em organizaes que adotam modelos de maturida- mitindo a resposta a erros inseridos de forma mais rpida.
de. Para isso, treinamentos adequados so necessrios e, em-
bora a abordagem gil valorize mais as pessoas e interaes Garantia da Qualidade (CMMI nvel 2, MPS.BR nvel F)
mais do que processos e ferramentas, possvel contar com A qualidade do desenvolvimento gil est relacionada
processos corretamente dimensionados e ferramentas certas principalmente qualidade do cdigo fonte do produto de
para atingir sucesso. software, que pode ser feita atravs de revises e inspees.
Outro ajuste indicado para a utilizao de tcnicas geis para Entretanto, atravs de algumas prticas do mtodo gil XP,
a definio de processos maduros a adoo de planos mais como refatorao, padronizao de cdigo e programao em
detalhados, exigidos pelos modelos de maturidade, apesar pares, a qualidade do cdigo melhorada de forma dinmica,
do princpio gil defender que as respostas s mudanas tem reduzindo a necessidade desses controles.
prioridade mais alta sobre a adeso a um plano. A refatorao possibilita a reestruturao do cdigo, tor-
nando-o mais limpo e coeso, reduzindo a insero de erros e
Mapeamento Agile X CMMI X MPS.BR facilitando a remoo dos mesmos. Ter escrita de cdigo pa-
Dentro deste contexto de adaptaes para a integrao de dronizado tambm contribui para a garantia da qualidade por
prticas geis e modelos de maturidade, possvel mapear facilitar a manuteno do software. Por sua vez, a programao
mtodos geis s reas de processos do CMMI e aos processos em pares permite que o cdigo seja validado no momento de
do MPS.BR, agrupando as vantagens dos dois paradigmas e sua escrita, diminuindo a quantidade de erros.
definindo processos melhores.
A seguir sero apresentados os processos do CMMI e MPS. Medio (CMMI nvel 2, MPS.BR nvel F)
BR onde se torna vivel e compatvel a utilizao de prticas A medio em projetos geis pode ser feita em dois nveis,
geis para sua implementao. utilizando o Scrum. O Daily Scrum permite que a evoluo
das tarefas seja medida dia a dia, proporcionando respostas
Gerncia de Requisitos (CMMI nvel 2, MPS.BR nvel G) mais rpidas. As ferramentas geis Kanban e Burndown Chart
O mtodo gil XP pode proporcionar diversos benefcios podem auxiliar neste processo.
na implementao deste processo, por ter o cliente como ator O Sprint Review Meeting realizado ao final de um Sprint
fundamental do projeto. Algumas das prticas utilizadas so: acumula os resultados do ciclo, permitindo aprendizado para
comunicao contnua, feedback e integrao contnua. o ciclo seguinte e projetos posteriores.
O mtodo gil Scrum fornece elementos essenciais na gern-
cia de requisitos, so eles: backlog, contendo as user stories e o Verificao (CMMI nvel 3, MPS.BR nvel D)
Product Owner, responsvel por controlar as stories. Alm disso, Este processo pode ser implementado pelos mtodos XP e
possvel obter melhoria contnua com o auxlio das reunies Scrum atravs das frequentes interaes entre equipe e clien-
dirias (daily meeting). te. A presena diria do Product Owner ganha destaque nesta
O mtodo FDD pode contribuir com este processo atravs de disciplina, impedindo que o desenvolvimento fuja do escopo
lista de Features e relatrios de progresso do projeto atrelado requerido e permitindo que mudanas de requisitos sejam
aos requisitos. realizadas com o menor custo possvel.
O TDD tambm podem ser teis para a verificao, por criar
Gerncia de Projetos (CMMI nvel 2, MPS.BR nvel G) testes aderentes aos requisitos antes mesmo da construo,
O processo de gerenciamento de projetos est intimamente dificultando os desvios de escopo.
ligado ao Scrum como um todo, dado que esse tem esse pro-
cesso como principal objetivo. Validao (CMMI nvel 3, MPS.BR nvel D)
Apesar de no possurem funes idnticas, o Scrum Mas- Existem duas formas geis muito utilizadas para validar se
ter executa atividades similares a de um gerente de projetos, o produto est sendo desenvolvido corretamente:
como remoo de impedimentos e organizao de reunies Atravs da prtica XP de programao em pares, onde o
de integrao entre membros da equipe. cdigo validado durante sua construo;
Alm disso, as ferramentas geis Kanban e Burndown Chart Por meio do TDD, onde os testes antecipados diminuem os
podem ser utilizadas em conjunto para auxiliar o controle de riscos de desvios e erros.
atividades da equipe durante um Sprint.
Mais uma vez, a natureza interativa e cclica da prtica gil
gerncia de Configurao (CMMi nvel 2, MPS. permite que o produto seja frequentemente validado pelos
BR nvel F) membros da equipe e pelo cliente.
A caracterstica dinmica e interativa dos projetos geis di-
reciona este processo para a integrao contnua. Isso significa Integrao do Produto (CMMI nvel 3, MPS.BR nvel D)
que, a cada commit de cdigo no repositrio de desenvolvi- Atravs da prtica XP de integrao contnua o produto pode
mento do projeto, feita integrao entre o que foi inserido e 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- caractersticas e objetivos de cada organizao. Como exemplo,
mente detectado e corrigido. Existem algumas ferramentas de pode-se considerar uma pequena startup de tecnologia, que
software que automatizam este processo, como a ferramenta utilize mtodos geis e que, com o intuito de se adequar s
de integrao contnua Hudson. exigncias de um cliente, precise alcanar determinado nvel
de maturidade do MPS.BR.
Desenvolvimento de Requisitos (CMMI nvel 3, MPS.BR O dinamismo da tecnologia da informao no permite que
nvel D) normas e modelos de qualidade sejam inflexveis, mesmo que
Assim como ocorre no processo de Gerncia de Requisitos, sejam consolidados h anos. O direcionamento gil observado
em um projeto Scrum este processo executado pelo papel no desenvolvimento de solues de software sugere que adap-
de Product Owner. Este personagem responde pelo cliente, ou taes sejam feitas nos padres de qualidade j estabelecidos,
seja, os requisitos atualizados do cliente so traduzidos por permitindo que a qualidade j comprovada destes modelos
ele para o restante da equipe. possa se unir objetividade e produtividade, gerando um novo
modelo de qualidade para a produo de softwares.
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 Links
reunio, que est dividido em trs colunas (mitigar, aceitar Agile e MPS.BR - Viso gil
e evitar). A cada risco identificado nas tarefas selecionadas, http://www.visaoagil.com/static/downloads/edicoes/VA_03.pdf
o quadro atualizado para que estejam visveis pela equipe
Implementando CMMi utilizando uma combinao de Mtodos geis
durante todo Sprint de desenvolvimento.
http://www.cin.ufpe.br/~processos/TAES3/slides-2012.2/Implementing%20CMMi%20
using%20a%20Combination%20of%20agile%20methods.pdf
Concluso
O mapeamento entre prticas geis e reas de processos (ou Library | CMMI or Agile: Why Not Embrace Both!
processos) de modelos de maturidade, apresentado neste arti- http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm
go, apenas um exemplo prtico que possibilita a visualizao
da sinergia entre essas disciplinas de propsitos diferentes,
porm no divergentes. Existem outras metodologias geis Feedback
D seu feedback sobre esta edio! eu
no exploradas neste artigo que podem abranger ainda mais

s
D
os processos do CMMI e MPS.BR. A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
Assim, no preciso definir um processo de desenvolvi- Para isso, precisamos saber o que voc, leitor, acha da revista!

s
ta
edio
mento de software rgido que integre metodologias geis e D seu voto sobre este artigo, atravs do link:
modelos de maturidade. possvel flexibilizar a utilizao www.devmedia.com.br/esmag/feedback
de mtodos geis e modelos de maturidade de acordo com as

12 Engenharia de Software Magazine - Integrando Agilidade com maturidade


Agilidade

Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.

Como formar Times de alta performance


Demonstre performance para seus clientes

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
Danilo Cereda simplicidade, software funcional no incio das indiquem que o seu time est na direo certa, de
danilo.cereda@gmail.com iteraes, flexibilidade e intensa comunicao, modo que a avaliao do time no fique somente
Graduado na rea de TI, com 7 anos de tanto internamente quanto com clientes. Alm na percepo superficial do cliente e sim em uma
experincia em desenvolvimento de disso, aplicam o desenvolvimento iterativo e in- percepo formada por fatos concretos.
Software e 11 anos de experincia profissio- Este artigo retrata tcnicas e experincias em pro-
cremental, planejamento adaptativo, flexibilidade
nal atuando na rea de desenvolvimento de
sistemas WEB, sendo os ltimos 3 dedicados e rpida resposta a mudanas. jetos Scrum relacionadas formao de times de
liderana de equipes e coordenao de O Scrum uma metodologia gil para gerncia alta performance e demonstrao de ganho para o
projetos utilizando metodologia gil e o de projetos, baseado em inspeo e adaptao, cliente atravs de mtricas de projeto.
framework Scrum. Atualmente atua como iterativo e incremental, e pode ser aplicado a
Lder / Scrum Master em Campinas na Ci&T
qualquer produto ou no gerenciamento de qual- Em que situao o tema til:
(multinacional brasileira especializada em
consultoria e outsourcing de aplicaes vol- quer atividade complexa. Assim, o Scrum um Este artigo fornece uma viso geral de formao
tadas para agilidade nos negcios). 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-
Fabio Pallini trinta dias, sendo conhecida como Sprint. Ao final das tcnicas que podem ser aplicadas a projetos
fmpallini@gmail.com de cada Sprint deve ser entregue ao cliente parte geis para dar viso objetiva ao time de desenvol-
Graduado na rea de TI possui 3 anos de do produto concludo e funcional. vimento e ao cliente, sobre a qualidade e produti-
experincia em desenvolvimento gil. Times de Alta Performance um conceito dentro vidade das equipes.
Certificado como Professional Scrum Mas-
do desenvolvimento das organizaes referente a
ter pela Scrum.org, atualmente trabalha na
Ci&T Campinas.

Edio 59 - Engenharia de Software Magazine 13


U
m dos principais assuntos em destaque nas mdias e qualidade das entregas melhorem a cada Sprint, mantendo
especializadas em gesto e TI (Tecnologia de Infor- a produtividade. Muitas vezes esta melhoria negociada no
mao) a construo de times de alta performance momento de fechar um contrato, propondo uma velocidade de
(HPT High Performance Teams), como pode ser observado em incio abaixo da expectativa do cliente e projetando um ganho
fontes virtuais, quando o termo procurado em algum bus- de velocidade Sprint a Sprint at chegar a um valor que oscila,
cador qualquer, sendo surpreendente o nmero de resultados pouco conhecido como velocidade de cruzeiro. Portanto, uma
relativamente retornados. Outra linha que tambm se destaca o empresa de TI que vende times Scrum, na verdade vende times
assunto a acadmica, pelo nmero de trabalhos relacionados de desenvolvimento que conhecem e utilizam Scrum, mas no
ao assunto atualmente. tem como garantir que eles sejam Times de Alta Performance
Um exemplo de time de alta performance a seleo brasi- por mais que conheam estes times e por mais que eles tenham
leira de vlei, conforme discurso do tcnico Bernardinho, tido sucesso em projetos anteriores.
sobre a formao do time onde, como em qualquer time de
alta performance, h garra, treino, conhecimento dos pontos O que so Times de Alta Performance?
fortes de cada um, evoluo contnua e conhecimento do jogo A performance, no contexto de clulas ou times de desenvol-
(negcio e metodologia). vimento, est intimamente relacionada com a maturidade do
O que poucas pessoas conseguem lembrar quando veem um time como um todo. Uma definio de maturidade estado
time vencedor o caminho que foi trilhado para chegar ao sta- das pessoas ou das coisas que atingiram completo desenvol-
tus de campeo. Pensando nesse caminho, pode-se fazer uma vimento. Para um time de desenvolvimento, maturidade
comparao direta com um time de desenvolvimento. Embora pode ser considerada como o conjunto de caractersticas que
se tenha experincia individual dos componentes da equipe, de mostram um alto grau de desenvolvimento tcnico e compor-
incio ainda no formam um time. Em conjunto possvel de- tamental. Entretanto, ter um time reconhecido como maduro
senvolver diversas competncias tcnicas e comportamentais, no garante um incio com alta performance.
para ento se tornarem um time e atravs de ciclos de melhoria A definio de HPT, ou High Performance Teams, segundo
gradual formarem um time de alta performance. O que ser o livro The Wisdom of Teams, traduzido para o portugus,
apresentado neste artigo justamente este caminho. Times de Alta Performance, um conceito dentro do desen-
Iniciar um projeto sempre um desafio, preciso lidar com volvimento das organizaes referente a times, organizaes
um novo produto, novas expectativas, novas percepes e, ou grupos virtuais que so altamente focados nas suas metas
muitas vezes novos clientes. Este entendimento, anterior ao e alcanam resultados de negcio superiores, superando todos
incio do projeto, conhecido como fase de concepo. Nesta os outros times similares e tambm as expectativas dadas a
fase, antes de pensar em desenvolver os times necessrio sua composio.
encontrar pessoas adequadas ao novo desafio, dimensionar e Analisando a definio acima, pode ser observado que
montar um ou mais times de desenvolvimento. comparativa.Ou seja, para identificar um time como de alta
Dificilmente um projeto ser entregue a um time de desen- performance utiliza-se comparao com outros times em
volvimento j existente, que j trabalha junto h muito tempo, situao semelhante.
sem mudanas de papel ou de pessoas. No mundo real, no A definio de HPT tambm subjetiva, considerando as ex-
existe o conceito de times fixos, com pessoas que no mudam pectativas do cliente. No existe um modo de aplicar um ques-
de emprego, nem de rea de atuao. A carreira de TI sujeita tionrio e dizer com certeza que um time um HPT. O cliente
a mudanas e constantemente nos deparamos com situaes deve perceber a evoluo dos times e reconhec-los. Para isso,
imprevisveis no que diz respeito s alocaes internas e importante extrair informaes e mtricas que indiquem que
externas de pessoas, assim como no existe garantia nas con- o seu time est na direo certa, de modo que a avaliao do
trataes de desenvolvedores de que os mesmos vo atender time no fique somente na percepo superficial do cliente e
s expectativas e atingir o resultado previsto. sim em uma percepo formada por fatos concretos.
Mesmo que no framework Scrum no exista escopo de projeto Para ser um time de alta performance necessrio superar as
fixo, definido na concepo, muitas vezes existe um prazo para expectativas, entregar cada vez mais e cada vez melhor, sobre
entrega definido pela rea de negcio, para um conjunto de uma meta possvel, evitando situaes comuns, onde o cliente
funcionalidades bsicas, viabilizando que o produto retorne considera alta performance a entrega de tudo o que gostaria de
valor (por exemplo, uma data de estreia de campanha comer- ter, simplesmente guiado pelo desejo e gerando uma avaliao
cial, uma data fixada pelo governo para funcionamento de baseada em emoo e no em resultados.
uma alterao fiscal, entre outras).
Existem tcnicas para garantir que o cliente receba este pro- Custo X Adequao
duto mnimo entregvel, atravs da realizao de engenharia Para viabilizar um projeto existem diversas combinaes
de valor, redimensionamento de times, entre outras. possveis de montar times de desenvolvimento. Fatores como
No entanto, independente de problemas de cronograma distribuio, experincia tcnica e maturidade das pessoas
de projeto, os times devem ser trabalhados para a evoluo devem ser levados em conta antes de garantir que determinado
constante. Pois a expectativa do cliente que a quantidade conjunto de pessoas atende a necessidade do negcio.

14 Engenharia de Software Magazine - Como formar Times de alta performance


AgiLidAdE

O Scrum prega que quanto mais multidisciplinar for um Mas e a qualidade? Por que a qualidade no negocivel?
time, melhor ser para o projeto. Se possvel, o time todo deve O pilar qualidade fica entre os trs vrtices, o que impossibili-
ser capaz de planejar, executar e testar estrias, assim como ta que seja negociado. Qualquer problema com qualidade gera
executar tarefas de Front-end e Back-end, com praticamente impacto direto em custo, prazo e/ou escopo. No existe motivo
o mesmo esforo. Porm, sempre haver pessoas com mais para diminuir a qualidade, mesmo que a falta de cuidado com a
facilidade para um tipo de atividade e menos para outro tipo, qualidade parea atraente por diminuir o custo, como nos casos
mas deve haver o incentivo a multidisciplinaridade e o trabalho que h diminuio no time de testes ou no escopo de testes, por
conjunto sempre que possvel, o que auxilia ter um time menos exemplo. O problema que se no h garantia de qualidade,
sujeito a situaes imprevisveis. dificilmente haver como dizer que entregaremos no prazo ou
Qualquer empresa gostaria de ter em seus times somente que respeitaremos o custo. Ento o ganho aparente ser posto
pessoas com muitos anos de experincia comprovada, um em prova quando defeitos em desenvolvimento, homologao
time inteiro snior. Na maioria das vezes, isso no possvel, ou produo comearem a impactar negativamente no prazo
seja por motivo de falta de colaboradores com esse perfil no e no custo, um risco que no vale a pena correr.
mercado, seja pelo alto custo. O que deve estar claro que a Diante disso, existe um cuidado com times de desenvolvi-
no ser que o cenrio exija e possibilite um time de sniores, mento que no deve ser negligenciado, o de produzir com
o aconselhvel a fazer montar um time balanceado. Onde qualidade, acima de velocidade ou previsibilidade.
desenvolvedores menos experientes tenham apoio tcnico de
um desenvolvedor mais experiente, assim como um testador Desenvolvimento contnuo
jnior possa ser responsvel por executar os testes, enquanto Para atingir as metas de velocidade sem perder qualidade, o
um testador mais experiente possa ser responsabilizado pela ideal seria iniciar o projeto com um time de tcnicos especialis-
criao dos cenrios e validao dos requisitos, de modo a focar tas nas tecnologias do projeto, com profundo conhecimento no
em planejamento e no na execuo de testes. negcio, no cliente e comprometido com a entrega do produto.
Na maioria das vezes, o sucesso de um projeto tem uma rela- Esta realidade possvel para equipes que desenvolvem pro-
o direta entre o equilbrio de qualidade, custo e prazo. dutos diretamente para a empresa onde atuam, trabalhando
em conjunto com a rea de negcio e com conhecimento prvio
Pilares: Escopo x Custo x Prazo do sistema que ser criado ou evoludo.
As trs primeiras reas a serem estudadas pelo PMI (Project Esta no a realidade das consultorias e fbricas de softwa-
Management Institute), Escopo, Custo e Prazo, ajudaram re, pelo fato de que tanto na contratao dos profissionais,
a formar um diagrama, chamado de Trinmio Sagrado do quanto na formao da equipe, no existe garantia de que
Gerenciamento de Projetos. Este diagrama mostra resultados os colaboradores tenham conhecimento tcnico necessrio.
das variaes sobre o escopo, custo e prazo do projeto e seu Dificilmente os colaboradores conhecero o negcio do cliente
impacto na qualidade. antes de iniciar o projeto e muito menos haver garantia de que
Para o sucesso de um projeto necessrio equilibrar esses todos estejam comprometidos com a entrega. Por este motivo
trs pilares, que so relacionados como vrtices de um trin- importante entender que times diferentes, compostos por
gulo (veja a Figura 1). Se a opo for um custo menor, deve-se pessoas com nvel tcnico e de maturidade diversificados, tero
aumentar o prazo ou reduzir o escopo. Se a busca for pela incio de projeto com resultados diferentes. Por isso, quando
entrega em menor prazo, provavelmente haver um custo no existe garantia de iniciar um projeto com alto rendimen-
maior ou ser necessria reduo do escopo. 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-
Figura 1. Trinmio Sagrado do gerenciamento de projetos 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 Demo Meeting /Sprint Review Meeting: Chegou o momento
mais prximo da metodologia um time executa os Sprints, me- da entrega do Sprint e o time todo se rene com o PO para de-
lhor o resultado. Este cuidado com a fidelidade ao processo monstrar o produto, sendo notvel a reao do PO quando se
conhecido como execuo do Scrum by the book. alcana o resultado esperado, assim como quando a expectativa
Existem sugestes de aes para aperfeioar a execuo dos era maior que o produto entregue. A apresentao do Review
ritos Scrum durante os projetos, so elas: meeting no altera a qualidade da entrega, mas contribui para
Planning Meeting: As planning meetings so reunies de que na prxima Planning meeting estes feedbacks sejam incor-
planejamento das funcionalidades do produto, que sero porados ao produto;
compromisso da prxima entrega e devem estar focadas em Retrospective Meeting: Reunio realizada no final de todo
um produto simples e que resolva o problema proposto pelo Sprint, onde realizada toda a retrospectiva do Sprint com um
PO (Product Owner). Geralmente o time pensa em entregar um olhar crtico. Nesta reunio todos so convidados a apontar clara-
produto completo de funcionalidades e esteticamente agrad- mente o que deu certo e o que no deu certo no Sprint e chegar
vel, mas as funcionalidades bsicas e a facilidade de uso devem a um consenso sobre quais itens devem ser melhorados.
ser prioridades para a maioria dos casos. Pode at ser que a
esttica seja o foco do desenvolvimento como, por exemplo, o momento oficial para apontar aes de sucesso e discutir
no caso de desenvolvimento de sites, mas este requisito deve melhorias. Os feedbacks devem ser focados em aes possveis
ser alinhado e no tomado como meta do Sprint, devido ao de serem implantadas, por exemplo, no adianta apontar que
interesse do time. O importante que o PO atue ativamente se tivessem um supercomputador se ganharia tempo com a
no planejamento, ficando com a deciso do que prioritrio gerao de builds, se no possvel conseguir esse supercom-
para a entrega e que todos saiam da reunio alinhados com o putador. Tambm deve se eleger poucas aes para melhorar
consenso de aceite do Sprint. o prximo Sprint, no adiantando eleger quinze pontos de
O time deve pensar no compromisso da entrega e focar em melhoria e no final do Sprint conseguir atuar em apenas
conseguir entregar as estrias das quais houve o comprome- trs. Neste caso, a melhor estratgia seria trabalhar em trs a
timento. esperado que o time tenha capacidade de negociar, cinco aes possveis por Sprint e realmente resolv-las, alm
caso o escopo no seja coerente com a velocidade prevista pelo de refletir sobre a soluo do problema para que no volte a
time. s vezes, uma soluo mais simples que a proposta, ou ocorrer. Outra atitude que contribui para a efetividade das
uma funcionalidade (no essencial) que seja retirada de uma retrospectivas no deixar para lembrar os problemas na l-
estria, permite que o produto entregue traga maior valor. tima hora. Assim, necessrio procurara estimular os times a
O questionamento do que prioridade na maioria das vezes anotar os problemas conforme eles acontecem durante o Sprint,
fica sobre responsabilidade do Scrum Master, mas quando h a para diminuir o risco de esquecer algo importante e melhorar
responsabilidade do time com o produto que est desenvolven- a dinmica da prpria reunio de retrospectiva.
do, negociando diretamente com o Product Owner, se tem um
compromisso maior de ambos os lados e maior flexibilidade Exercitar o Feedback sempre
na resoluo dos desafios, conforme forem surgindo; Uma grande vantagem de um framework com iterao a pos-
Daily Meeting: A daily meeting uma reunio diria que sibilidade de trabalhar com melhoria contnua. Para fornecer a
permite um alinhamento do time com as atividades do Sprint, retroalimentao necessria anlise dos pontos de melhoria
geralmente realizada com o time em p e seus membros res- existe a prtica da Retrospective Meeting.
pondendo questes, como, O que voc fez ontem? O que voc Realizar feedback apenas uma vez por Sprint no suficien-
est fazendo hoje? O que est te impedindo de realizar o seu te, esse deve ser exercitado sempre que possvel, fornecendo
trabalho? De forma resumida; ao time uma rgua para medir o quanto alinhados esto
Acompanhando a daily meeting, o Scrum Master deve inter- com a necessidade do projeto. No existe uma regra, nem
romper quando o time est fazendo uma apresentao para interessante utilizar tempo do time se no existir nenhum
cada membro ao invs de para o time todo. A importncia da acontecimento pertinente, mas se possvel deve-se exercitar
daily meeting passar, alm do status, a percepo do desenvol- o feedback dirio.
vedor sobre a meta do Sprint e as dificuldades encontradas no O modo mais fcil de no cometer o mesmo erro mais de uma
desenvolvimento de sua atividade, de modo que todos possam vez tomar conhecimento do problema o quanto antes. Deste
entender e participar das atividades de todos. Portanto, deve-se modo, aumenta a chance de que uma ao de resultado positivo
utilizar esse tempo para refletir sobre as atividades do time, seja aplicada novamente, antecipando um novo problema, e
um exemplo seria um desenvolvedor dar uma ideia que resolva expondo a todos o resultado para que sejam estimulados a
o problema de outro, um testador perceber um risco em deter- aplicar iniciativas de sucesso.
minado cenrio e planejar testes mais especficos para este ce-
nrio, o Scrum Master detectar um impedimento antes mesmo Capacitao e treinamentos direcionados
dele se concretizar, ou seja, o momento do time esquecer as A evoluo de um time compreende enfrentar desafios, mas
dificuldades individuais e trabalhar na construo do produto muitas vezes se deparam com situaes tcnicas e compor-
como um todo e no como um conjunto de atividades; tamentais para as quais no esto preparados. importante

16 Engenharia de Software Magazine - Como formar Times de alta performance


AgiLidAdE

reconhecer os momentos onde o time precisa de ajuda para se e o cliente, todos devem ter ferramentas para acompanhar os
desenvolver, podendo ser atravs de um treinamento, que pode resultados dos Sprints de modo claro e intuitivo.
ser realizado no dia a dia do Sprint, direcionado para a soluo Com todas estas diretivas se cria um ambiente com condies
do problema ou de um treinamento mais formal. O que importa para o time se desenvolver, afinal, o prprio time deve ser
que o time entenda que tem um problema a resolver e seja capaz de visualizar sua condio atual e o caminho para se
encorajado a se desenvolver, tendo apoio para isso. No caso tornar melhor. Aes de melhoria e corretivas podem ser pla-
de ter um colaborador do time com dificuldades, sugerido nejadas e executadas, mas se o time no estiver comprometido
treinamento especfico de forma a equalizar o conhecimento a evoluir, no se tornar um HPT.
em que ele esteja defasado dos demais.
O cliente enxerga a alta performance do seu time?
Exibir claramente os resultados sobre as metas aceitas No momento da entrega, pouco vale o fornecedor estar
O PO uma das chaves para o sucesso do projeto. Ele deve orgulhoso do seu time HPT e do produto construdo, se o
acreditar no Scrum e defender seu uso perante os stackeholders cliente no enxerga o mesmo. Mas, como medir e demonstrar
e sponsors do projeto. O sucesso ou a falha da entrega do time performance para seu cliente?
o sucesso ou a falha da entrega do PO, que sabe o valor de cada O cliente muitas vezes quer saber quantas horas/minutos/
entrega, o compromisso firmado com o time e tem condies segundos o time levou para desenvolver cada estria, se con-
de justificar o desempenho do time se for questionado. sidera este dado o mais importante para seu planejamento.
De nada adianta o time estar orgulhoso em cumprir o acordo Dentro de um cenrio complexo de gesto de projeto muitas
do Sprint se ao apresentar o produto ao PO ele estiver com uma variveis interferem nas estimativas de entrega. Ento, porque
expectativa maior. Por isso importante que o acordo firmado no planejamento do Sprint se usa Story Points, em vez de estimar
na planning esteja alinhado com a expectativa do cliente, tam- o prazo de desenvolvimento em horas? Porque cada estria
bm importante ao PO conhecer e acreditar na metodologia, diferente da outra. Mesmo tendo levado trs dias para entregar
ou seja, entender as regras do jogo, de modo que participe ati- uma estria de treze Story Points, no existe garantia de que
vamente dos resultados, j que ele est construindo o produto uma estria, aparentemente parecida com os mesmo treze Story
junto ao time. Para que exista o comprometimento entre o time 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- observado o atraso foi compensado a partir do Sprint cinco.
cala de Fibonacci para medir o esforo, porque ela possui valores No oitavo Sprint o time entrega todos os pontos restantes e ain-
com intervalos crescentes e no sequenciais. Por isso pode-se da sobraram seis, de modo que poder ser aceita uma (ou mais)
concluir que uma estria de treze Story Points leva mais esforo estria, somando seis SP e manter a previso de entrega.
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 Figura 2. Acompanhamento das entregas previstas e realizadas para
de entrega efetivas. Para o cliente, a capacidade de prever o Sprints de um release ou projeto
que ser entregue e quando. Para garantir uma medida correta
de previsibilidade importante manter o controle de Baseline Produtividade
do projeto, atualizando qualquer desvio ocorrido. Para medir A produtividade a capacidade de entrega de um time, sen-
o desvio aps a entrega de um Sprint necessrio realizar o do a quantidade de funcionalidades que um time consegue
grooming do backlog, ou seja, a anlise do backlog restante, com entregar em um perodo de tempo. Essa pode ser medida
foco em rever qual o esforo necessrio para entregar as demais utilizando a velocidade do time (velocity) em Story Points, essa
estrias e avaliar se essas foram alteradas para mais complexas velocidade calculada pela quantidade de pontos que o time
ou menos complexas, com base na pontuao das estrias j consegue entregar por Sprint, considerando a quantidade de
entregues. Atravs de um backlog inicial pode ser gerado um desenvolvedores fixa ou a taxa resultante da quantidade total
release e um grfico de burndown que mostra na linha do tem- de Story Points dividida pela quantidade de desenvolvedores,
po a concluso dos Sprints de um release, para medir o quo caso o time sofra alteraes.
prximo do planejado se esta aps o trmino de cada sprint Deve ser considerado ganho positivo quando o time entrega
e deste modo demonstrar desvios por aumento de escopo de uma quantidade maior de Story Points do que no ltimo Sprint,
produto, consequente aumento do backlog. projetando velocidade crescente. Mas para este ganho ser real,
Com a percepo de desvios nas entregas dos Sprints, pode- o time deve mostrar que entrega realmente mais, pois, apenas
se replanejar datas do projeto ou cortar escopo, de modo a subir a pontuao das estrias gera uma viso errada de ganho
concretizar a entrega na data inicial proposta. Lembrando que de produtividade. importante fazer uma anlise comparativa
quando entra uma estria (funcionalidade) nova ou aumenta do tamanho das estrias Sprint a Sprint.
a complexidade de alguma existente no backlog, automatica- No final do Sprint podem ser comparadas as estrias e
mente necessita se despriorizar outra estria, de preferncia verificar se elas so do tamanho proposto inicialmente.
que entregue menor valor ao negcio. O escopo do projeto, que O importante manter as comparaes atualizadas, para que
forma o backlog, deve ser visto como um espao limitado, onde na prxima planning meetings as estimativas sejam baseadas
no cabem mais estrias e para que entre uma, outra de mesmo em valores atualizados.
tamanho deva sair. O importante que as trocas sejam feitas Acompanhando os valores da velocidade do time nos Sprints,
pelo PO, junto ao Scrum Master e/ou o time e devidamente o esperado que o time, ao adquirir maturidade, aumente sua
alinhadas com as reas de negcios. produtividade nos primeiros Sprints, mas em algum momento
No exemplo da Figura 2 pode ser acompanhado o total pre- ele deve estabilizar, pois atinge sua produtividade mxima.
visto de pontos que deveriam ser entregues em nove Sprints. O maior desafio, deste ponto em diante, manter estes valores
O grfico mostra atravs da linha verde (entrega executada) constantes, pois uma diferena negativa pode aparecer de um
que houve um atraso nos quatro primeiros Sprints, atravs Sprint para outro, por motivos que no podem ser controlados.
dos Story Points (SP) restantes acumulados. Acompanhando a O esperado que uma vez que o time atingiu um patamar m-
linha vermelha (entrega planejada), que mostra os Story Points ximo de produtividade, a mdia de Story Points dos ltimos se
restantes planejados para o final de cada Sprint, como pode ser mantenha estvel, com pouca variao em torno deste valor.

18 Engenharia de Software Magazine - Como formar Times de alta performance


AgiLidAdE

Qualidade definio de DONE o acordo para garantir que o que est


Qualidade prioridade em qualquer projeto. Em qualquer sendo entregue tenha qualidade. definir com o PO o que
momento deve ser possvel negociar prazo, custo, mas quali- uma estria pronta para o projeto. Chamamos estas regras de
dade no se negocia. De nada adianta entregar um projeto no Definio de Pronto (Definition of Done ou DoD).
prazo, quando se gera inmeros problemas em produo. O Estas regras variam de projeto para projeto e por isso devem
custo de corrigir problemas em produo alto, quem alm ser combinadas no incio para serem utilizadas durante todo
de causar problemas para o negcio, tambm pode consumir o projeto.
margem de um projeto atravs do cumprimento de um contrato Critrios de Aceite: Para a Definio de Pronto das est-
de garantia, por exemplo. rias uma das regras que todos os critrios de aceite foram
Se um time apresenta erros de desenvolvimento pode se entregues. Isso porque a viso de qualidade do PO intima-
considerar algumas hipteses, como estrias com requisitos fa- mente ligada aos critrios que foram pedidos para o produto
lhos, falta de maturidade tcnica do time de desenvolvimento, em cada estria, sendo de responsabilidade dele cobrar do
falta de entendimento entre desenvolvedores e testadores, um time os critrios que foram definidos nas estrias. Qualquer
PO ausente. Atravs do levantamento de pontos falhos, ainda funcionalidade ou caracterstica que no foi definida como
durante o desenvolvimento, possvel fixar planos de ao que critrio, no pode ser exigida na Review meeting e dever ser
acompanhados podem reverter o cenrio negativo. mapeada em uma nova estria que entrar no backlog, gerando
Para ter alta performance necessrio que o time conhea a necessidade de negociao do escopo para que no impacte
e entenda a qualidade do projeto, assim como os meios de no prazo de entrega do projeto;
monitorar/melhorar a qualidade Sprint a Sprint.
Para definir o que esperado da qualidade em um projeto e Com todas estas definies alinhadas deve se garantir que os
o que ser cobrado no momento das entregas, existem compro- acordos sejam cumpridos. Para isso h mtricas que devem ser
missos, que firmados em documentos, descrevem definies acompanhadas para gerar aes corretivas, caso o resultado
e critrios que devero ser atendidos, a saber: no esteja de acordo.
Definio de READY: O ponto de partida no Scrum para
garantir que o que est sendo produzido ter qualidade, Mtricas de qualidade em desenvolvimento,
definir as regras para o time de desenvolvimento, com o homologao e produo
que produzir e como produzir. Chamamos estas regras A principal mtrica que indica se o time est desenvolven-
de Definio de READY (ou DoR). Este acordo define as do uma aplicao com qualidade o nmero de defeitos. Se
caractersticas mnimas que uma estria deve ter para ir ao h muitos defeitos em desenvolvimento, existe uma chance
Planning meeting. enorme de ter defeitos em homologao e, consequentemente,
Um exemplo levar para a reunio de planning uma estria muitos defeitos em produo.
que contemple criar uma pgina principal de um site sem um Uma meta comum maioria dos contratos buscar executar
wireframe (desenho bsico dos componentes da tela) ou sem um projetos sem defeitos. Mas este resultado no alcanado na
guia de estilo. Como os desenvolvedores podem saber o que maioria das entregas. Portanto, deve ser determinada uma
fazer, como fazer, ou at mesmo definir quanto esforo tero meta possvel, iniciando pelo nmero de defeitos que seja
que fazer para entregar uma tela que nem imagina como ? aceitvel em desenvolvimento, e garantir que a homologao
Para sanar este problema podemos exemplificar que no projeto seja bem feita, mirando uma produo sem defeitos. no mun-
Site Institucional da Empresa X, todas as estrias que des- do real que a qualidade do projeto posta a prova, portanto
crevem uma pgina qualquer do site podem ter as seguintes no adianta fazer um projeto com poucos defeitos na fase de
regras na sua DoR: desenvolvimento, se tiver vrias ocorrncias de defeitos em
- As telas devem possuir um guia de estilo (tipo/tamanho produo.
de letra, cores, etc); Para ter uma medida da qualidade geral do projeto, a quan-
- As telas devem possuir wireframes que expliquem quais tidade de defeitos deve ser considerada como a principal evi-
componentes devem ser exibidos, sua localizao, tamanho, dncia, mas sem esquecer de avaliar a gravidade de cada um
tipo de contedo, etc; individualmente. Em alguns casos pode ser melhor, do ponto
- As telas devem ter sido aprovadas pela rea responsvel de vista do negcio, ter mais de um defeito simples a um ni-
pela usabilidade. co crtico. Apesar disso, necessrio ter critrio na avaliao
da qualidade, pois dificilmente haver muitos erros sem que
Assim como a definio geral de Ready, que mostra quando parte deles seja crtico.
uma estria est pronta para ser discutida na planning meeting, Um modo interessante para o time acompanhar e atuar so-
preciso criar regras (critrios), que expliquem claramente para bre o nmero de defeitos construir um Burnup de Defeitos
o time durante a reunio de planning qual resultado esperado (Figura 3), uma ferramenta visual para acompanhar a curva
na entrega de cada estria do backlog; de crescimento de defeitos diariamente, de modo que no final
Definio de DONE: Assim como a definio de READY de cada Sprint o nmero total de defeitos seja comparado a um
o ponto de partida, para saber o que se deve produzir, a nvel mximo aceitvel em desenvolvimento. Este limite, ou

Edio 59 - Engenharia de Software Magazine 19


meta, deve ser negociado por projeto e geralmente calculado Times que surpreendem o cliente com solues inovadoras e
levando em conta o nmero de desenvolvedores que geram que entregam mais do que o cliente espera. Esta excelncia
cdigo, a tecnologia em que o projeto est sendo desenvolvido pode e deve ser um objetivo comum aos times, mas no existe
e outras particularidades do projeto. Uma vez que o limite como prever objetivamente que um time entregar com Alta
foi definido e o Sprint estiver em andamento, a atualizao Performance. A meta que deve ser perseguida a evoluo do
do grfico deve ser feita sempre que o testador encontrar um time para que ele alcance o desempenho desejado, porque HPT
novo defeito. 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

Figura 3. Acompanhamento da qualidade de implementao na fase de [2] JALOTE, Pankaj. CMM in practice: processes for executing software projects at
desenvolvimento atravs de um Burnup de defeitos Infosys. USA: Addison Wesley Longman, 1999.

Atravs da viso crtica sobre estes dados, o time deve atu-


ar para que o total no passe do limite estabelecido e caso Feedback
D seu feedback sobre esta edio! eu
ultrapasse, deve-se tomar aes corretivas para se ter uma

s
D
diminuio progressiva nos prximos Sprints. 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

Concluso
edio
D seu voto sobre este artigo, atravs do link:
Quem no gostaria de trabalhar sempre em times de alta per- www.devmedia.com.br/esmag/feedback
formance? Times que entregam muito, rpido e com qualidade.

20 Engenharia de Software Magazine - Como formar Times de alta performance