Você está na página 1de 62

ISSN 1983127-7

9 771983 127008

00085

Rodrigo Oliveira Spnola


rodrigo.devmedia@gmail.com
Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Ps-Doutorado na
University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente
Professor Titular do Programa de Ps-Graduao em Sistemas e Computao da Universidade
Salvador - UNIFACS.

Marco Antnio Pereira Arajo


maraujo@devmedia.com.br

85 Edio - 2016

Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ, Especialista em


Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF.

Corpo Editorial
Editor
Rodrigo Oliveira Spnola

Eduardo Oliveira Spnola


eduspinola@gmail.com

Colaboradores
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Nicolli Souza Rios Alves

Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.
bacharel em Cincia da Computao pela Universidade Salvador (UNIFACS).

Consultora Tcnica
Daniella Costa

Nicolli Souza Rios Alves


nicolli.devmedia@gmail.com
Bacharel em Cincia da Computao na Universidade Salvador (UNIFACS), Mestranda em Sistemas
e Computao no Programa de Ps-Graduao em Sistemas e Computao da UNIFACS na linha de
Engenharia de Software. editora da Engenharia de Software Magazine.

Jornalista Responsvel
Kaline Dolabella - JP24185
Na Web
http://www.devmedia.com.br/revista-engenharia-de-software-magazine

Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.
Se voc tiver algum problema no recebimento do seu exemplar ou precisar de algum
esclarecimento sobre assinaturas, exemplares anteriores, endereo de bancas de
jornal, entre outros, entre em contato com:
www.devmedia.com.br/central
(21) 3382-5038

Publicidade
Para informaes sobre veiculao de anncio na revista ou no site entre em
contato com:
publicidade@devmedia.com.br

Fale com o Editor!


muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo voc
gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a vontade para
entrar em contato com os editores e dar a sua sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site ES Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc gostaria
de publicar.

Sumrio
Contedo sobre Agilidade

06 Lean IT Alm dos mtodos geis


[ Rodrigo S. Prudente de Aquino ]

Destaque - Reflexo

Contedo sobre Agilidade, Artigo no estilo Mentoring

12 Conselhos para Product Owners em formao


[ Diana Corra ]

Contedo sobre Agilidade

18 Product Owner ou Product Manager? Eis a questo!


[ Romeu Ivolela Neto ]

Contedo sobre Agilidade

25 Modelo hbrido de gesto


[ Srgio Salles Galvo Neto ]

Artigo no estilo Prtico

[ lex Leocdio Jlio ]

D
s

36 Gerncia de mudanas utilizando Git

Feedback
eu

[ Priscila Martins Oliveira ]


Contedo sobre Arquitetura e Desenvolvimento, Contedo sobre Boas Prticas

49 Boas prticas para testes de performance


[ Fernando Oliveira ]

Contedo sobre Arquitetura e Desenvolvimento, Artigo no estilo Prtico

55 Teste de performance com JMeter


[ Dieny Oliveira ]

edio
ta

43 Utilizando as ferramentas Mantis, Subversion e Google Code

sobre e
s

Artigo no estilo Prtico

D seu feedback sobre esta edio!


A Engenharia de Software Magazine tem que ser
feita ao seu gosto.
Para isso, precisamos saber o que voc, leitor, acha
da revista!
www.devmedia.com.br/esmag/feedback

Programador Java:
Por onde comear?
Descubra nesse vdeo como entrar
na carreira Java com o p direito!

DEVMEDIA
Edio 05 - Engenharia de Software Magazine

http://www.devmedia.com.br/programador-java-por-onde-comecar/33638

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

Lean IT Alm dos mtodos geis


A entrega de valor ao cliente envolvendo todas as reas da empresa

Fique por dentro:

H
Rodrigo S. Prudente de Aquino
rodrigo.aquino@gmail.com

Atua h 18 anos na rea de TI. MBA em Engenharia de Software pela USP e Bacharel em Cincia da Computao pela PUC-SP. Atualmente Coordenador de Tecnologia da Informao
no Lean Institute Brasil, o qual trabalha por 5
anos. Trabalhou na ICEC (Coordenador Web),
Totvs (Lder de Projeto), Wunderman (Gerente
de Tecnologia Web) e Petrobras (Analista de
Sistema). Responsvel pela reviso tcnica do
primeiro livro de Lean IT lanado no Brasil (TI
Lean - Capacitando e Sustentando sua Transformao Lean), revisor dos termos tcnicos
do livro Liderar com Respeito e autor do livro:
WPage - Padronizando o desenvolvimento de
Web Sites.

anos, equipes de desenvolvimento de software buscam


melhorar seu trabalho no dia a
dia utilizando abordagens tradicionais
da engenharia de software como o modelo cascata, espiral, etc. No geral, essas
abordagens dividiam o desenvolvimento
de software em vrias etapas antes de
um projeto ser entregue ao cliente. Nesses modelos, quanto maior o projeto,
maiores os riscos de atraso, mudana
de escopo, aumento de custo, alto ndice
de erros, etc.
Os profissionais de TI perceberam
que nem sempre os clientes sabiam o
que queriam (notava-se isso devido s
frequentes mudanas de escopo aps o
projeto ser entregue), porm, quando recebiam o sistema, conseguiam entender
melhor o problema e consequentemente
vislumbrar uma melhor soluo.
A entrega de software em pequenos
lotes comeava a fazer sentido, pois era

O conjunto de prticas e conceitos Lean aplicados em TI vo muito alm dos mtodos geis
utilizados no desenvolvimento de software.
Nesse artigo, voc entender que a filosofia
Lean sugere no apenas entregar valor rapidamente ao cliente por meio desses mtodos, mas
estabelecer uma mudana na cultura da organizao levando em considerao os princpios
utilizados, o estilo da liderana, o comportamento entre os colaboradores, a maneira como
as pessoas entendem e resolvem problemas,
etc. Entregar valor mais rpido prxima etapa
do processo e, como consequncia, perceber a
motivao e satisfao da equipe de programadores, um dos grandes benefcios que esse
mtodo pode gerar ao negcio.

uma forma do programador assumir


que os problemas dos clientes seriam
resolvidos com entregas frequentes e
mais rpidas. Essa tcnica gerava timos
resultados e clientes satisfeitos nasciam
os mtodos geis.
Em 2001, um grupo de programadores
assinaram um manifesto que formalizou
o movimento para desenvolvimento gil
de software.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

Com essa formalizao, vrios mtodos passaram a ser


mais conhecidos pela comunidade de TI como o Kanban, XP,
Scrum, etc.
O manifesto contm 12 princpios que realam principalmente: as pessoas e interaes mais do que processos e ferramentas,
software funcionando mais do que documentao abrangente,
colaborao com o cliente mais do que negociao de contratos
e respostas s mudanas mais do que seguir um plano.
Embora ainda haja programadores que no aceitem totalmente o uso de mtodos geis em seu ambiente de trabalho
(podemos notar pelos debates nacionais e internacionais em
grupos no LinkedIn), no seria difcil negar a grande popularidade e benefcios que esses mtodos trouxeram para vrias
empresas, principalmente aquelas ligadas ao desenvolvimento
de software.
Entregar valor mais rpido prxima etapa do processo
e, como consequncia, perceber a motivao e satisfao da
equipe de programadores, um dos grandes benefcios que
esses mtodos podem gerar ao negcio.

O problema
Na maioria das vezes, o uso desses mtodos uma iniciativa
dos desenvolvedores, coordenadores e, no mximo, gerentes
de TI que buscam melhorar seu trabalho no dia a dia sem o
apoio da alta administrao. Sem esse apoio, no h garantia
de que o desenvolvimento ter integrao com as demais reas
da empresa e, com isso, as pequenas entregas nem sempre
chegaro rapidamente ao cliente.
Desenvolver um produto sem que a empresa toda (psvendas, suporte, helpdesk, infra, etc.) esteja alinhada com a
maneira em que as entregas so feitas aos clientes pode acarretar alguns problemas como: organizaes que possuem vrios
tipos de clientes e, por alguma razo, realizam deployment
semanais ou at quinzenais, ou seja, uma feature no produto
que leva apenas uma hora para ser feita, pode realmente ser
entregue ao cliente vrios dias depois de pronta. Outro problema que ocorre devido falta de integrao entre as equipes
a velocidade com que chega a especificao da tarefa para a
rea de desenvolvimento. Diversas vezes, os programadores
at conseguem finalizar rapidamente a produo de alguma
tarefa, porm ela sempre ser entregue atrasada caso a especificao chegue tarde demais.
Antes de aderir a algum mtodo gil, necessrio que todos
os envolvidos na cadeia de valor (fluxo por onde a informao passar) consigam responder as seguintes perguntas: a
estratgia est clara para todos da TI sobre o que representa
determinado cliente para a organizao? As outras reas da
empresa esto preparadas para responder to rapidamente ao
cliente quanto sua rea consegue entregar? O seu cliente est
preparado para receber nessa velocidade?
Nem sempre as respostas esto claras e bem definidas para
todos os colaboradores da organizao e qualquer problema
de comunicao, dependendo do tamanho da companhia,
poder significar atrasos e modificaes nos pedidos dos
clientes. Talvez seja por isso que muitas empresas fornecedoras

de produtos ou servios relacionados a TI comearam a se


interessar por algumas das possveis origens dos mtodos
geis: o Lean.

A filosofia Lean
O termo Lean surgiu no final da dcada de 80 devido a
um estudo organizado pelo MIT (Massachusetts Institute of
Technology) sobre a indstria automobilstica mundial. Esse
estudo resultou em um livro chamado A mquina que mudou o mundo. O livro destaca, alm de outras montadoras,
a maneira como a Toyota fabricava seus veculos algo totalmente inovador. O Sistema Toyota de Produo (STP), como
era conhecido, apresentava caractersticas muito diferentes
do sistema de produo em massa. Os autores entenderam
que o STP poderia ser adaptado e utilizado por qualquer
empresa de qualquer segmento e ento descreveram, no
livro, a mentalidade enxuta nas empresas (1996), cinco
princpios bsicos para que o pblico pudesse entender
melhor a funcionalidade desse sistema revolucionrio. Os
princpios so:
1 Valor ao cliente: Identificar o que realmente d valor
ao cliente, ou seja, o que o cliente realmente est disposto a
pagar pelo seu produto ou servio. Ao identificar o que no
agrega valor, voc identificar os desperdcios e, com isso,
conseguir eliminar processos, materiais, custos diretos,
indiretos e utilizar melhor o tempo das pessoas para se
esforarem em outras tarefas nas quais realmente agregam
valor ao produto sob o ponto de vista do cliente;
2 Fluxo de valor: Identificar quais etapas no agregam
valor na concepo do produto e, posteriormente, eliminlas. Em 2003, John Shook e Mike Rother apresentaram no
livro Aprendendo a Enxergar, uma ferramenta chamada
Mapeamento do Fluxo de Valor (MFV), que auxilia as empresas a identificarem onde est o desperdcio;
3 Fluxo Contnuo: Aps identificar e eliminar o desperdcio seguindo o princpio anterior, nesse momento, a empresa
deve criar fluxo contnuo na produo, ou seja, realizar
tarefas sem interrupes. Em outras palavras, atender as
necessidades dos clientes quase que instantaneamente;
4 Sistema Puxado: Ao invs da empresa produzir baseado em estudos ou histrico das demandas, segundo esse
princpio, a organizao passa a produzir somente quando
o cliente realmente compra o produto. Dessa maneira,
diminui-se a quantidade de itens em estoques e consequentemente o dinheiro investido pela empresa para fabricar
esses produtos;
5 Perfeio: Pode ser entendido tambm como melhoria
contnua. a busca incessante para melhorar o produto,
os processos, as pessoas, o fluxo de valor, os fornecedores,
etc. Para seguir esse princpio, os colaboradores da empresa
devem reconsiderar a maneira como entendem os problemas
e passar a utiliz-los como oportunidades de melhoria.
Alm dos princpios, a filosofia Lean tambm aborda
modelos mentais de forma a sustentar uma transformao

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

nas empresas. Diferentemente das prticas tradicionais, no


decorrer do artigo destacaremos como o comportamento
das pessoas importante para estabelecer um crescimento
organizacional consistente.
No modelo Lean, a opinio do colaborador valorizada
fazendo com que ele amadurea profissionalmente cada
vez mais. As pessoas so os elementos mais valiosos de
uma empresa e lderes motivadores so o que ela precisa para manter e aumentar cada vez mais seu valor no
mercado.
Toda pessoa deve adotar a prtica do Genchi Genbutsu
v e veja com os prprios olhos. O termo Gemba est
relacionado a essa prtica e significa local real ou lugar
verdadeiro. Ele resume a expresso de ir at o local para
viver a situao real com o intuito de entender o problema
que est acontecendo naquele momento profundamente.
Esse conceito usado, por exemplo, quando: pessoas experientes de diversas reas da empresa, que desenvolvem
algum produto, participam de reunies na fase inicial de
um projeto junto ao cliente, fazem pessoalmente ajustes
de sistemas, prottipos, etc.
Estar no local exatamente no instante em que o erro ocorreu te ajudar a ter sua prpria viso do problema e com
ela, informaes adicionais importantes para entender o
fato por completo e identificar a melhor soluo para que
ele no volte mais a acontecer.
Uma maneira de entender mais claramente como o trabalho dever ser feito criar padres simples e visuais
para coisas importantes. Esses padres ajudaro a garantir
a qualidade dos produtos e/ou servios oferecidos pela
organizao.
Parar a produo uma maneira de levar a empresa
falncia no entendimento de lderes convencionais. Na
Toyota, a linha de produo deve ser parada sempre que
ocorrer qualquer tipo de problema que prejudique a qualidade do produto final. Um procedimento chamado cadeia
de ajuda faz com que o operador chame o supervisor depois
de alguns segundos caso no consiga resolver o problema
o escalonamento feito at que o problema seja resolvido
ou contido. Aps alguns escalonamentos, ocorre a parada
na linha de produo (no em primeira instncia).
Esconder problemas uma forma direta ou indireta de
contribuir para a diminuio da qualidade no produto
ou servio prestado ao cliente final. Deixar os problemas
visveis uma forma de fazer com que todos saibam o que
est acontecendo para que possam ajudar uns aos outros e
dar sugestes de melhoria. Com isso, as pessoas podero
aprender tambm com as falhas cometidas em outros departamentos, se prevenindo e melhorando seu trabalho.
Faa uma anlise profunda antes de resolver qualquer
problema. Veja se o problema possui conexo com outro e
tente visualizar a situao como um todo, principalmente
sob o ponto de vista do cliente. Tente tornar o problema
atual descomplicado. Considere as seguintes perguntas
para fazer a si mesmo:

Sem gastar horas de trabalho, como eu poderia resolver


esse problema?
O problema do cliente resolvido definitivamente com
essa atitude?
Essa soluo ir aumentar o trabalho outros colaboradores?
J possuo algo pronto de forma que possa me ajudar a
resolver essa pendncia?
A filosofia Lean est sendo difundida cada vez mais por
meio de diversas empresas que oferecem consultoria, treinamentos, eventos e at publicaes sobre o tema. Essa nova
forma de trabalho vem sendo aplicada h pelo menos 25 anos
em organizaes de diversos pases, e o mais importante: vem
trazendo resultados surpreendentes em relao qualidade
e rapidez de entrega de produtos e/ou servios prestados aos
clientes, alm de gerar alta lucratividade para companhia.
No h setores empresariais que essa filosofia no possa
ser aplicada e, talvez por isso, ela esteja se expandindo
para as demais reas das organizaes chegando ao setor
de TI.

Lean IT
Lean IT a adaptao dos conceitos do Sistema Toyota de
Produo e da filosofia Lean para a rea de TI. Alm dos conceitos, existem vrias ferramentas que devem ser entendidas
com plenitude antes de serem adaptadas para TI. Algumas
delas sero apresentadas a seguir.

MFV
O mapeamento do fluxo de valor ou mapa do fluxo de
valor (MFV) uma poderosa ferramenta de comunicao e
planejamento e serve para que os colaboradores conheam
seus processos de fabricao/produo detalhadamente.
Com ela, cria-se uma linguagem entre os colaboradores iniciando, posteriormente, um processo de melhoria. A partir
de um produto ou servio que a empresa oferece, inicia-se o
desenho do estado atual coletando informaes como: etapas, nmero de envolvidos em cada processo, tempos, etc.
O prximo passo o desenho do estado futuro acompanhado
do plano de trabalho e implementao. O objetivo do plano
fazer com que o estado futuro se torne realidade. A Figura 1
ilustra um exemplo de um MFV do estado atual de uma
estamparia (caso real).

A3
um mtodo para resoluo de problemas representado
por uma folha de papel de tamanho padro 297x420 mm. Por
meio dela feita a comunicao entre o subordinado (autor) e
o supervisor (orientador) em relao ao problema em que se
deseja resolver.
Seu preenchimento se d da esquerda para direita e algumas
de suas caractersticas so: fazer com que as pessoas cheguem
causa raiz do problema, utilizao do modelo PDCA (Plan, Do,
Check, Act) como base para o desenvolvimento do contedo,
fazer com que o mentor e subordinado obtenham consenso
sobre o que deve ser feito, etc.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

Figura 1. MFV - estado atual (estamparia)

No A3 comum a utilizao de alguns mtodos para encontrar a causa raiz dos problemas como cinco porqus, espinha
de peixe, etc. Veja um exemplo na Figura 2 e tente identificar
o problema.
Vejamos agora um exemplo de como utilizar os cinco porqus
para identificar o problema indicado na figura:
Por que o computador no est funcionando?
Resposta: Porque no est ligado tomada.
Por que no est ligado?
Resposta: Porque o cabo foi puxado para fora da tomada.
Por que o cabo foi puxado para fora da tomada?
Resposta: Porque algo prendeu no cabo e o puxou.
Por que as coisas prendem no cabo?
Resposta: Porque o cabo est no cho e fica no caminho.
Por que o cabo est no cho e fica no caminho?
Resposta: Porque muito longo.
Por que o cabo muito longo?
Resposta: ... No sei.
Soluo 1: Diminua o comprimento do cabo.
Soluo 2: Prenda-o com fita na parede.
Soluo 3: Etc.
Com esse exemplo, percebe-se a dificuldade que as pessoas
possuem em realmente identificar os problemas.

Figura 2. Porque no devemos ligar o computador na tomada?

Muitas vezes elas querem chegar rapidamente na soluo e


nem sempre so eficazes, fazendo com que o problema ocorra
novamente. vlido lembrar que podemos utilizar somente
um ou mais de cinco porqus para chegar soluo de um
problema.

Por que devemos utilizar Lean em TI?


Os profissionais da rea de TI buscam incessantemente
mtodos, bibliotecas, processos e quaisquer boas prticas que

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

possam ajud-los no dia a dia a resolver problemas. Porm, nem


todas elas possuem grande nmero de adeptos atualmente.
O uso dos processos de desenvolvimento como RUP, espiral,
cascata e modelos como CMMI so exemplos dos que tiveram
uma grande perda de profissionais de TI quanto sua utilizao. Talvez, uma das possveis causas dessa perda foi no ter
apresentado os benefcios que as empresas e/ou os clientes
esperavam.
Diferentemente de um processo, o Lean uma filosofia de
trabalho. Sua aplicao deve ser usada no apenas em uma
rea, mas na empresa toda, por todos os colaboradores. Com
ela se pretende:
Entender e entregar o que realmente de valor ao cliente;
I nova r e mel hora r a gesto, a lm dos processos
empresariais;
Auxiliar a organizao a alcanar excelncia operacional;
Desenvolver as pessoas, melhorando-as cada vez mais sob
o ponto de vista do trabalho em equipe, da liderana e na
maneira como resolvem os problemas;
Alcanar melhoria dos servios e desenvolvimento de
software.

O framework Lean IT
O framework Lean IT, representado na Figura 3, apresenta
um conjunto de conceitos, prticas e mtodos a serem utilizados por empresas que desejam passar por uma transformao
em TI.
O significado de cada item e algumas relaes entre eles so:
Valor ao Cliente: serve como uma premissa bsica para o
incio da transformao. A todo momento, deveramos pensar
como a atividade que desenvolvemos no dia a dia gera valor
ao cliente. O que no agrega valor precisa ser entendido como
um desperdcio e deve ser eliminado. A definio de valor,
segundo James Womack no livro Solues Enxutas, pode ser
entendida como:
- Solucione meu problema completamente;
- No desperdice o meu tempo;
- Fornea exatamente aquilo que eu quero;
- Entregue valor exatamente onde eu quiser;
- Fornea valor exatamente quando eu quiser;
- Reduza o nmero de decises que eu devo tomar para
solucionar meus problemas.
Hoshin Kanri: o Hoshin deve ter uma relao direta com a
gerao de valor da empresa (norte verdadeiro, plano estratgico). Ele serve como um direcionador para as atividades
desenvolvidas com objetivo de gerar valor mais rapidamente
ao cliente. Por meio do gerenciamento dirio, a empresa atualiza os dados de seus indicadores informando se est ou no
dentro da meta;
Fluxo Contnuo: as atividades da organizao devem ser
desenvolvidas em fluxo contnuo (sem intervenes);
Sistema Puxado e Nivelamento da Produo: sistema
puxado significa fazer algo quando houver uma demanda
real do mercado e no uma suposio baseada em estimativas que podem falhar. Nivelar a produo significa variar o

10

Figura 3. Framework Lean TI

desenvolvimento das atividades no gastando esforos em


apenas um item ou produto. O propsito liberar pequenos
lotes de diferentes produtos a vrios clientes;
Jidoka: esse termo possui vrios significados nos quais alguns deles so: autonomao (automao com toque humano),
parar sempre que ocorrer uma falha (no passar o problema
adiante), etc.;
Kaizen: a ideia de melhoria contnua deve ser incorporada
aos colaboradores da empresa. As pessoas devem dedicar
tempo no somente a resolver pendncias, mas melhorar seus
processos de trabalho constantemente, alm de seus produtos
e servios;
Padronizao: preciso ter padres, seja na manuteno, na
construo de um novo software, no suporte, no treinamento
de colaboradores, na maneira como um problema resolvido,
etc. O Kaizen deve ser aplicado em todos esses casos. As boas
prticas de ITIL e COBIT no devem ser descartadas, o importante utilizar apenas o necessrio para suportar o fluxo de
valor ao cliente e no o interromper;
Estabilizao: necessrio ter estabilidade bsica nas operaes dirias da empresa. A estabilidade far com que todos
os termos explicados anteriormente possam ser utilizados
sem interrupo.
A aplicao da filosofia Lean em qualquer tipo de empresa
no se faz em poucos dias. Ela pode levar meses para iniciar
consistentemente e at anos para estabelecer uma mudana
cultural na organizao. Os modelos mentais descritos anteriormente apoiaro essa mudana, porm h outro fator
importante que cada colaborador deve ser treinado: identificar
os desperdcios.
Kiichiro Toyoda, em 1945, disse a Taiichi Ohno (gerente de
produo da Toyota): Alcancemos os Estados Unidos em trs
anos. Caso contrrio, a indstria automobilstica do Japo no
sobreviver. Naquela poca, a produo de um trabalhador
americano era nove vezes maior que de um japons. Estava
claro que os japoneses estavam desperdiando algo. Foi ento
que Ohno percebeu que se a maior parte dos desperdcios
fosse eliminada, a Toyota teria uma chance de se manter no
mercado.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

Estoque

Produo em excesso

Espera
Transporte

Superprocessamento

Movimentao

Defeitos

Excesso de especificaes (Backlog);


Funes no cdigo fonte com as mesmas funcionalidades de outras que j so utilizadas no software;
O nmero de licenas de software maior do que a quantidade de usurios;
Informaes duplicadas desnecessariamente no banco de dados;
Muitos e-mails no lidos na caixa de entrada dos colaboradores;
Links no acessados no menu de um sistema.
Produzir alguma coisa que o cliente no usar;
Reescrever funes que j esto prontas para um projeto;
Relatrios com informaes sem utilidade.
Desenvolvimento aguardando especificao;
Usurio espera vrios segundos o sistema passar de uma tela para outra.
Um programador especificar novamente o que est desenvolvendo e enviar ao responsvel (Product Owner);
Integraes desnecessrias com outras aplicaes.
Super processamento da mquina causado por cdigo de baixa qualidade;
Reunies improdutivas;
Muitas funcionalidades acumuladas em poucas telas da aplicao.
Deixar o ambiente de desenvolvimento para esclarecer dvidas simples de programao (Help);
Necessidade de o usurio buscar informaes em outras telas da aplicao e voltar para onde estava.
Inconsistncia entre a especificao, o resultado esperado e a real necessidade do cliente (este ltimo tambm pode ser entendido como produo em excesso);
Erro de programao quando usurio est utilizando;
Usurio no consegue encontrar o que deseja devido a um problema de usabilidade do sistema.

Tabela 1. Exemplos de desperdcios sob o ponto de vista Lean IT

Ele categorizou os desperdcios em: superproduo, espera, transporte, processamento, estoque, movimentao e
defeitos. Essa categorizao era uma maneira de facilitar a
identificao.
Mesmo naquela poca, identificar claramente um desperdcio no era uma tarefa nada fcil. Quando comentamos
sobre desperdcios em TI, a dificuldade ainda maior em
identific-los, pois a informao nem sempre entendida da
mesma maneira por todos da companhia, alm de muitas
vezes estar mal representada visualmente. Para entendermos
melhor sobre o que devemos eliminar em nossas organizaes,
elaboramos na Tabela 1 alguns tipos de desperdcios em TI e
os categorizamos.
O pior tipo de desperdcio seja em TI, manufatura ou escritrio a produo em excesso, pois com ele encontramos todos
os outros. Entender os desperdcios e focar em sua reduo
um dos passos para a conscientizao das pessoas e a evoluo
da organizao.
Ter a viso de todos os fluxos de valor da empresa importante para conseguirmos identificar onde h maiores desperdcios.
Ao elimin-los, a organizao estar indiretamente contribuindo para a diminuio do tempo em relao entrega de valor
ao cliente. Em outras palavras, no adianta apenas uma etapa
do processo ser gil (e isso no uma crtica aos mtodos geis),
necessrio que o cliente perceba o valor nas entregas, e para
essa situao ocorrer precisamos de uma empresa enxuta, ou
seja, uma empresa Lean.

Referncias:
Soares, H. F.; Alves, N.S.R.; Mendes, T.S.; Mendona, M.G.; Spnola, R.O..
Investigating the Link between User Stories and Documentation Debt on
Software Projects. In: International Conference on Information Technology New Generations, 2015, Las Vegas. International Conference on Information
Technology - New Generations, 2015.
Fowler, M.; Highsmith, J. The Agile Manifesto, Software Development,
Vol. 9, 2001
Henrajani, Anil.Desenvolvimento gil em Java com Spring, Hibernate e
Eclipse. So Paulo: Pearson Prentice Hall, 2007.
Kniberg, H. 10 ways to screw up whith Scrum and XP in Agile Conference.
Toronto, Canad, 2008.
Schwaber, K. The scrum development process. Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages,
and Applications, Austin, Texas, USA, 1995.

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

11

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

Conselhos para Product Owners em formao


Como se tornar um Product Champion

Fique por dentro:

Este artigo do tipo mentoring


saiba mais: www.devmedia.com.br/
mentoring-saibamais

O
Diana Corra
llldianalll@gmail.com
https://es.linkedin.com/in/dianacorrea

Publicitria por formao, agilista de corao


e gestora de produto por diverso. H mais
de 10 anos atuando na rea de tecnologia,
metade deles praticando a gesto de produtos gil para criar e desenvolver os produtos
certos para o pblico certo. Possui experincia
tanto em produtos para audincias de massa
quanto em sistemas que servem para resolver grandes problemas das corporaes. Atua
hoje na Espanha como Product Owner de um
e-commerce de viagens e lazer.

12

Product Owner um papel que


j se tornou imprescindvel na
maior parte das empresas atuais. Empresas de mdia e comunicao,
comrcio eletrnico, fbricas de software, instituies financeiras, fbricas de
tratores... Sistemas internos, aplicativos
nativos, portais de massa, software as a
service... Independentemente do produto
ou da indstria, o Product Owner est
presente cumprindo uma funo fundamental para o sucesso do negcio. Mas
qual o caminho a seguir para se tornar
um grande profissional da rea?
O trajeto bvio o analista de requisitos, de sistemas ou de negcios que, ao
ingressar no mundo gil, faz um curso
de um final de semana, tira uma certificao e pronto: nasce mais um Scrum
Product Owner no mercado. Na verdade,
esses cursos so um excelente pontap

O Product Owner um papel em crescente


valorizao no s no mercado brasileiro, mas
tambm no global. As opes de trabalho para
essa funo em diferentes indstrias de todos
os portes so inmeras, mesmo em tempos
de crise. Mas o que faz de um profissional um
grande Product Owner? Este artigo traz 10 pontos para que os profissionais ainda em formao
possam desempenhar um papel cada dia mais
estratgico e menos operacional tornando-se,
como alguns chamam, verdadeiros Product
Champions.

inicial, mas esto longe de ser suficientes


como formao. um primeiro passo e
no o ltimo passo. De modo geral, nessa
etapa, o profissional ainda no tem bagagem o suficiente para ter uma atuao
mais estratgica e menos operacional.
capaz de interagir com a rea de negcio,
mas de forma muito subordinada. No
possui, ainda, conhecimento suficiente
para realmente construir uma viso
e uma estratgia de produto slida.
Envolve-se muito mais com o sucesso
do desenvolvimento do que com o xito

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

do produto em si. Pouco investe nas fases de concepo e


otimizao. E, provavelmente, ainda no consegue realmente
colocar prova suas habilidades de comunicao.
Ao ingressar na carreira de Product Owner, o profissional
tem duas possibilidades de caminho a seguir. Ou para no
bsico, faz o arroz e feijo e, com tempo e experincia, pode
vir a cumprir o papel de forma adequada ou mesmo boa; ou
vence o comodismo e vai alm, buscando se tornar um Product
Champion.
Mas qual seria ento o prximo passo de formao para quem
est comeando sua carreira e quer ir alm do curso do CSPO?
H algum MBA, mestrado ou treinamento adicional? Infelizmente no. E tambm no h receita de bolo. Os caminhos que
levam um profissional a se tornar um grande Product Owner
so tortuosos e exigem tempo, esforo e dedicao. Mas, para
aqueles que possuem a vontade ingressar nessa jornada, a
compensao gigantesca. Na realidade, ser um Product Owner um trabalho que pode ser muito gratificante e divertido.
uma funo extremamente criativa, mas tambm analtica.
business, mas tambm tecnologia. buscar resultado
econmico, mas tambm a melhor experincia para o usurio
final. A vida de um Product Owner esta eterna dicotomia e
aqueles que seguem essa carreira certamente no tero dias
montonos pela frente.
Alm disso, o Product Owner um papel em crescente valorizao no s no mercado brasileiro, mas tambm globalmente.
As opes de trabalho em diferentes indstrias de todos os
portes so inmeras, mesmo em tempos de crise.

Entenda a carreira que voc est escolhendo


Um dos motivos pelos quais alguns profissionais nunca conseguem sair do operacional a falta de conscincia a respeito
do universo em que est inserido. simples, determinante,
mas por incrvel que parea no to bvio: a escola de estudo
de um Product Owner a escola da gesto de produto. Muitos
iniciantes buscam muita informao sobre Scrum, Kanban,
metodologias geis, desenvolvimento gil, priorizao do
backlog ou como escrever boas user stories. Tudo isso faz parte
e fundamental, mas no suficiente. s o bsico. Quando
olhamos o ciclo de gesto de um produto de forma mais ampla,
entendemos que existem as fases de concepo, desenvolvimento e otimizao, e o Product Owner precisa entender e
aperfeioar-se em cada uma delas.
Uma boa expresso chave de busca gerenciamento de produto gil e no apenas desenvolvimento gil. A gesto de
produto engloba mais do que coletar requisitos, definir o que
o produto tem ou no tem. mais do que uma lista priorizada
de itens a fazer, histrias de usurios e critrios de aceite. um
pouco de modelagem de negcios, de mercado, de experincia
de usurio, de marketing digital e de anlise de dados. Um
excelente Product Owner entende o negcio que est atuando,
a funo do seu produto dentro desse negcio, quem seu
pblico alvo, quais os indicadores de performance e como
medi-los, e, especialmente, como desenhar, executar e ajustar
a estratgia para atingir aquilo que chamamos de sucesso.

O Product Owner algum que quer se tornar um grande


gerente de produto. Definido isto, h diversos sites, blogs,
comunidades de prtica e livros que comeam a preencher as
lacunas que o curso do CSPO deixou em aberto.

A grande responsabilidade de ser o Owner


O nome diz tudo: o owner o dono. Esta palavra indica
empoderamento, autonomia, mas traz consigo tambm uma
grande responsabilidade. Embora seja verdade que o Product
Owner apenas um e o sucesso de um produto se gera a partir
do trabalho coletivo de um time, a responsabilidade maior est
sim nos ombros do P.O. Isso significa que ele precisa liderar,
agir e influenciar desenvolvedores, marqueteiros, produtores
de contedo, parceiros de mercado, investidores, reas de negcio, operao e diversas outras reas. Ele precisa trazer todos
esses diferentes interlocutores colaborao e ao engajamento,
sempre buscando um objetivo final: o sucesso do produto.
Se qualquer ponto da cadeia falha e esse ponto prejudicial ao
xito do produto, esse profissional deve ser o grande advogado
que buscar intermediar e instigar a soluo. Assim como um
Scrum Master remove os impedimentos que atrapalham o dia
a dia do time e do desenvolvimento, o Product Owner tem que
resolver os pontos e riscos que esto impedindo o produto
de atingir seus objetivos. Ou, ento, adaptar sua estratgia
quando necessrio.
A verdade que, estando no papel de Product Owner,
reclamar e encontrar desculpas no uma atitude que gera
resultados: O problema que o Business Owner no tem
tempo para falar de negcio, O problema a rea usuria,
que se recusa a usar o produto, A rea de marketing no se
interessa pelo produto e no estamos conseguindo uma boa
divulgao. Todas essas so frases possveis para o contexto
de atuao desse papel. Porm, ao se deparar com esse tipo de
situao, a melhor atitude a ser tomada em prol do produto :
O que eu, dono desse produto, posso e vou fazer para mudar
este cenrio?, Qual ser a minha estratgia para mudar essa
situao?. Um grande Product Owner tem a conscincia de
que, mesmo quando a responsabilidade no sua, de certa
forma a responsabilidade sua. Ou, em linguagem mais moderna, menos mimimi e mais go go go.

Todo heri tem um mentor


Todo aprendiz tem um mentor. Algum mais experiente para
se observar, obter conhecimento, tirar dvidas e anseios. No
Vale do Silcio ou em aceleradoras, o processo de mentoria
bem estabelecido e altamente valorizado. Startups promissoras
so mentoradas por gestores de produto e de negcio bemsucedidos e com mais bagagem de mercado. uma boa ideia,
portanto, repetir esse modelo em um mbito mais pessoal e
de carreira, identificando possveis mentores que possam ser
uma referncia, fonte de conhecimento e inspirao para o
Product Owner em formao.
O mentor no necessariamente o gestor direto do profissional. Pode ser um colega. Um consultor. Algum de outra
rea. O importante que seja algum que possua o conjunto

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

13

de conhecimentos e habilidades que se deseja desenvolver.


importante dizer que o mentor no um professor. Seu
papel e obrigao principal dentro da empresa provavelmente no ensinar. possvel, portanto, que essa pessoa no
possua muita disponibilidade de tempo. Sempre utilizando o
bom senso, o Product Owner deve buscar criar esses espaos
para aprendizagem, troca de conhecimento e, principalmente,
obteno de feedback e orientao. Posso participar do seu
workshop como observador? Gostaria de aprender mais sobre
como conduzir um momento como este, Excelente o trabalho que voc realizou. Poderia me explicar a lgica que voc
usou?, Voc teria 30 minutos para fornecer feedback sobre
roadmap do meu produto? Seria interessante eu obter a viso
de algum mais experiente, Voc gostaria de um assistente
para seu prximo workshop com clientes? Seria uma grande
experincia para mim so apenas alguns cenrios possveis
para aprender mais rpido a partir do conhecimento alheio.
Posto que as habilidades que um Product Owner deseja
obter so vastas e de campos diferenciados, bem possvel
que esse mentor na realidade sejam mentores. Ao longo de
sua carreira, o P.O. provavelmente vai se deparar com muitos
mentores, vai trocar de mentor ao longo do tempo, e, quando
menos espera, perceber que est comeando a ter seus prprios mentorados.

importante aprender a falar negcio


Muitos Product Owners reclamam que no se sentem realmente donos do produto. Que no possuem espao para
tomada de deciso. Embora, infelizmente, isso de fato ocorra
mesmo em empresas ditas geis, a verdade que autonomia
no se ganha, se conquista. E bem mais difcil conquistar
autonomia sem falar a lngua dos negcios.
Um profissional s ganha liberdade para trabalhar quando
conquista a confiana das pessoas que o circundam: gestores,
investidores, reas de negcio, colegas, entre outros. Essa confiana muitas vezes se constri com base no nvel de segurana
e conhecimento que o Product Owner demonstra a respeito
do trabalho que est desenvolvendo. Mas, como determinar
uma boa estratgia de produto desconhecendo as particularidades do negcio? Como ter bons argumentos para provar
seus pontos de vista quando no se conhece os dados? Um
Product Owner que no entende do seu negcio de atuao
provavelmente no conseguir agir em um mbito estratgico
e se estagnar em uma atuao meramente operacional. No
conseguir de fato colaborar ativamente com a rea de negcio,
pois no possui conhecimento suficiente para isto. O risco,
aqui, de se tornar um tirador de pedidos muito grande.
Ao longo da carreira, um P.O. tem a oportunidade de trabalhar em diversos negcios e contextos diferentes mesmo
dentro de uma mesma rea ou empresa. A tarefa nmero um
para esse profissional quando inicia em um produto qualquer
entender tudo o que puder no s sobre o produto, mas
tambm sobre o negcio que est inserido: qual o mercado,
como ele funciona, quem so os players e as referncias, qual
o modelo de negcio, quais os objetivos de negcio, o que est

14

indo bem e o que est indo mal, quais as oportunidades de


atuao, quem so as pessoas, como funcionam ou no funcionam os processos, etc. Ao longo do caminho ele ver que
algumas dessas respostas podem inclusive ser inexistentes.
Nesse caso, ao invs de se conformar e trabalhar no escuro,
o profissional deve buscar construir e trazer a luz esse conhecimento junto com as pessoas pertinentes. O produto no
tem modelo de negcios bem definido? Pois bem, o Product
Owner deve trazer as pessoas competentes para clarificar ou
criar conjuntamente essa viso.
Leva um tempo, mas o quanto antes o P.O. entender tudo
isso, o quanto antes ele vai ganhar a confiana daqueles que
o rodeiam. E certamente poder executar um trabalho mais
slido e bem embasado. Nesse nvel, Product Owner e Business
Owner de fato podero trabalhar como um par. Obviamente,
esperado que o Business Owner tenha um conhecimento um
pouco maior do negcio que o Product Owner. Mas este ter
um conhecimento maior de gesto de produtos. Conseguindo
conversar de igual para igual, essa dupla tem condies de
chegar mais longe e obter melhores resultados.
Mas como obter este conhecimento? Conversando com
pessoas de diversas reas, acessando relatrios e nmeros
que a empresa j tenha disponvel, acessando as ferramentas corporativas (QlikView, Google Analytics, etc.), fazendo
pesquisas, lendo matrias sobre o mercado ou pesquisando
os concorrentes. Enfim, os meios so inmeros, mas o importante , aos poucos, planejar como ir preenchendo os gaps de
conhecimento que todo Product Owner que est ingressando
em um novo negcio, independentemente do nvel de senioridade, possui.

Cultura data driven


Um dos aspectos mais valorizados atualmente pelo mercado
em um Product Owner a sua capacidade de tomar decises
com base em dados. No campo da gesto de produto, h cada
vez menos espao para achismos, palpites e estratgias pouco
embasadas. Quando um P.O. toma uma deciso a respeito do
seu produto, ele deve ser capaz de explicar seus motivos. Ele
precisa saber mostrar qual o racional utilizado para chegar
quela concluso. E isso provavelmente s ser possvel atravs
de nmeros.
Independente se este possui uma rea de mtricas como apoio
ou no, o bom Product Owner define quais so os indicadores
que precisa acompanhar para entender se o seu produto est
cumprindo seus objetivos. Ele monitora esses nmeros com
frequncia. Mais importante ainda: ele compartilha essa informao com seu time, ajudando a fortalecer essa cultura em toda
a empresa. Frente aos resultados, ele planeja aes para mudar
aquilo que vai mal e comemora com todos os aspectos que vo
bem. E, principalmente, questiona o tempo inteiro as suas prprias decises: Eu realmente possuo argumentos, fatos e dados
suficientes para seguir este caminho?. Um bom P.O. antecipa e
est preparado para responder as perguntas difceis.
A cultura analtica, na verdade, auxilia muito nas discusses
e negociaes a respeito do roadmap e do futuro do produto.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

No toa que a frase contra fatos no h argumentos se


torna cada vez mais clebre no mundo corporativo. A verdade
que aqueles que esto fora de contexto no so obrigados a
entender imediatamente a lgica que um Product Owner utilizou depois de muito raciocnio e trabalho - para traar a sua
estratgia de produto. de responsabilidade deste, portanto,
torna-la mais visvel, clara e facilmente compreensvel para todos os interlocutores. O fato que, com um bom embasamento,
orientado dados, o P.O. tende a conquistar cada vez mais a
confiana daqueles que o circundam, pois torna-se bvio que
o seu plano de fato faz sentido.
Outro aspecto muito importante da cultura data driven a
experimentao. Na gesto de produto, os profissionais devem
ter a humildade de entender que, at que se comprovem, suas
expectativas de resultado so meras hipteses. Hoje existem
diversas ferramentas e meios para realizao de teste A/B, por
exemplo. Uma boa prtica testar se as hipteses so vlidas
antes de tornar-se aparentes as novas funcionalidades do produto para todo o universo de utilizao. Quem trabalha com
e-commerce sabe: uma mera mudana de texto pode impactar
a converso e gerar um prejuzo financeiro considervel. Se o
impacto de uma funcionalidade zero ou negativo, o Product
Owner provavelmente vai tomar a deciso de no lan-la. E
tudo bem. Uma vez que a gesto de produtos baseada em
hipteses, muitas vezes os palpites esto mesmo errados. Faz
parte do jogo. No tem problema falhar desde que se falhe
rpido e o erro gere aprendizagem e mudana de estratgia.
Mais importante que isto, no deixar o ego insistir no erro.
Se o feeling in my guts aponta para um lado, mas os resultados apontam claramente para outro, o bom profissional tende
a ser pragmtico e, pelo menos para esta rodada, admite a
derrota.
H muita literatura disponvel hoje em dia a respeito de teste
e validao de hipteses mesmo quando o produto no est em
uma etapa de otimizao. Lean Startup, Customer Development,
Lean Metrics e Javelin Board so boas fontes de informao para
aqueles Product Owners em formao que querem aprender
mais sobre isto. E se no existem no Brasil muitos cursos disponveis sobre a gesto de produto propriamente dita, h diversos
workshops e eventos focados em empreendedorismo e startups
que contribuem imensamente para a formao dos profissionais da rea. O P.O. no deixa de ser um empresrio, um
empreendedor, e o quanto mais envolver-se com este campo
de estudo, mais desenvolver as habilidades e conhecimentos
necessrios para realizar uma boa gesto de produto.
Outro ponto importante que a cultura data driven no exclui
a realizao de testes com uma abordagem mais qualitativa. O
Product Owner e os nmeros devem ser os melhores amigos,
mas, ainda assim, clientes so pessoas. O fator humano no
deve ser esquecido. sempre uma boa estratgia, para aqueles
que possuem esta oportunidade, ouvir e trazer o usurio para
perto, observar como este interage com o produto e entender
melhor seu perfil e expectativas. Sendo assim, durante qualquer fase do produto, o P.O. pode contar com seus colegas de
UX para desenvolver pesquisas com clientes, testar navegao

e fluxos, coletar impresses sobre concorrentes e responder


diversas outras perguntas e indagaes.

O Product Owner tambm um comunicador


Uma das habilidades fundamentais de um bom Product
Owner a sua capacidade de comunicao. Ele deve falar
vrias lnguas. No, no estamos falando aqui de lnguas
estrangeiras embora certamente a aprendizagem de uma
segunda lngua sempre um diferencial, especialmente em
empresas multinacionais. O P.O. deve saber falar business,
como j mencionado. Mas, mesmo no tendo perfil tcnico,
tambm tem que conhecer um pouco de tequiniqus para
conseguir entender e interagir com o time de desenvolvimento.
Em muitos cenrios, ter que aprender, ainda, a falar a lngua
das pessoas da operao. Quase todo o profissional da rea
possui diversos interlocutores, de diversos perfis, e diferentes
estilos de comunicao. Cabe ao Product Owner saber circular
naturalmente em todos estes meios e falar a lngua de todas
estas pessoas. Comunicar-se com as partes interessadas, ganhar engajamento e empatia. Ser e fazer parte.
Adicionalmente, todo o Product Owner deve usar sua capacidade de interagir para comunicar tambm o seu produto.
Vende-lo internamente. Ser seu maior advogado. E gerar nos
outros a vontade de advogar em prol do produto tambm.
Um produto bem comunicado aquele que, quando o P.O no
est na sala, uma parte interessada qualquer desenvolvedor,
Business Owner, operao saiba responder pelo menos as
questes bsicas a respeito do mesmo. A sua viso de futuro.
Os prximos passos. Onde estamos agora. incrvel como um
Product Owner que tambm um bom comunicador encontra
aliados para a sua estratgia.
Por fim, faz parte ainda do trabalho estar sempre pensando
em como comunicar o produto para o pblico final. Como o
produto vai interagir com o usurio? Qual a linguagem de
comunicao? Um bom P.O. sabe que no precisa depender
apenas do marketing para divulgao. A melhor promoo
a espontnea. aquela feita dentro do prprio produto.
Quando o LinkedIn mostra uma lista de amigos que j esto
cadastrados no site e no final instiga o usurio a convidar
os conhecidos ainda no registrados, ele est fazendo nada
mais do que comunicao. Este o tipo de promoo que um
Product Owner deve estar sempre pensando. Como utilizar o
prprio produto e a prpria base de usurios para conquistar
ainda mais clientes?

A prtica leva perfeio


Assim como o gil prega a aprendizagem prtica, a formao
de um P.O. tambm iterativa incremental. Muitos iniciantes
sentem-se inseguros em atuar com tcnicas antes nunca utilizadas. No se sentem capazes por no terem experincia.
Mas a verdade que a nica forma de aprender realmente
expondo-se prtica. Um bom exemplo disto so os workshops.
Este tipo de tcnica auxilia muito um P.O. no momento de
conceber o seu produto. Workshops de Personas, de Business
Model Canvas ou Lean Canvas, User Story Mapping, Product Vision

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

15

so s algumas opes que podem vir a calhar para quem


est dando os primeiros passos na construo de uma nova
iniciativa. A ideia pegar um time de pessoas multidisciplinar,
que tenha as habilidades e conhecimentos necessrios para
que seja atingido o objetivo final do workshop. Neste caso, o
papel do P.O. o de facilitador da criao colaborativa. Este
outro ponto importante a ser considerado: as decises e
criaes compartilhadas tendem a ser mais assertivas. fato
que vrias mentes pensam melhor do que uma. Um Product
Owner sbio aquele que sabe aproveitar o conhecimento e
potencial das pessoas ao seu redor.
Para quem nunca conduziu um workshop, ou mesmo deseja utilizar qualquer outra tcnica nova, a melhor maneira
de aprender justamente tentando. O importante estudar
como funciona, ter um bom planejamento e, claro, pilotar. A
primeira tentativa, obviamente, pode ser feita com um qurum
menor e com pessoas que o Product Owner se sente mais
vontade. Quando possvel, pode-se buscar ainda o auxlio
de um profissional com mais senioridade para servir de coaching nesta primeira experincia. O importante sempre pedir
feedback ao final. Entender o que os participantes gostaram
e o que mudariam. A partir das opinies coletadas, ajusta-se
o planejamento para uma prxima vez. Certamente, tcnica e
performance vo melhorando progressivamente a cada nova
facilitao. O fato que no existe possibilidade de melhoria
na falta de tentativa. Ento, o melhor que um Product Owner
em formao pode fazer comear a testar as tcnicas que lhe
interessam, e j.

Gesto de tempo e trabalho colaborativo


Provavelmente aqui o Product Owner em formao j chegou concluso de que precisar ser um verdadeiro heri.
Vai ter que jogar no gol, no ataque, na defesa e ser o tcnico,
tudo simultaneamente. Alm de se qualificar em seu foco de
atuao, precisar aprender tambm sobre negcio, tecnologia,
comunicao, marketing e responsabilizar-se sobre o produto
em um mbito global. Sim, muito a fazer e so poucas as
horas em um dia. Bom, ningum disse que ia ser fcil e, como
j mencionado, os caminhos que levam um Product Owner a
tornar-se um Product Champion so mesmo tortuosos.
Como, ento, organizar o tempo para cumprir todos os aspectos do trabalho de um Product Owner e ainda conseguir
ter vida?
Primeiramente, uma das habilidades mais bsicas deste papel
a capacidade de fazer uma boa priorizao. Da mesma forma
que este profissional prioriza seu backlog, ele deve tambm
fazer escolhas a respeito do seu prprio tempo. Um P.O.
no precisa lidar com todos os assuntos relacionados ao seu
produto ao mesmo tempo. Ele tem que ser capaz de entender
qual o seu prximo passo: aquilo que, se no for feito agora,
prejudicar o produto. O Lean prega que as coisas sejam feitas
no ltimo momento responsvel para que, em caso de mudana, no tenhamos desperdcios relativos a trabalhos que
nunca sero aproveitados. E esta provavelmente uma boa
diretriz para qualquer Product Owner: o foco apenas naquilo

16

que importante neste momento. Os conceitos do gil tambm


so muito teis aqui. Melhor iniciar uma s tarefa e finaliza-la
do que abrir vrias frentes ao mesmo tempo e no conseguir
direcionar nenhuma adequadamente.
H algumas atividades, claro, que so on going. interessante reservar alguns momentos do dia e da semana para
estudar os nmeros do produto, pensar no futuro, ou fazer
benchmark de mercado, por exemplo. fundamental entender
este tempo como algo to fixo como uma reunio recorrente,
por exemplo. Um dos maiores desafios de qualquer Product
Owner , mediante os incndios do dia a dia, encontrar tempo para atuar de forma estratgica. Mas, se o profissional
no desejar ficar parado apenas no mbito operacional, ele
precisa levar muito a srio os espaos na agenda dedicados
estratgia do produto. Bloquear alguns momentos do dia para
isto pode servir como uma boa alternativa para promover esta
organizao.
Outra reclamao constante no universo dos Product Owners a existncia excessiva de reunies. Aqui a priorizao
tambm fundamental: Preciso mesmo estar nesta reunio
ou minha presena dispensvel e posso ser informado sobre
os acordos posteriormente?, H algum do time que possa
me representar?. Muitas vezes o P.O. precisar dizer no ou
delegar. Ele precisa escolher em quais momentos sua presena
de fato imprescindvel.
Outro ponto bem complicado no Brasil que as reunies tendem a ser dispersivas, no possuem objetivos claros, e muitas
vezes duram mais tempo do que o necessrio. O profissional
no deve ter medo de cobrar dos participantes respeito ao tempo e agenda da reunio. Os 30 minutos perdidos esperando
outros participantes atrasados, ou investidos em assuntos
no relativos ao tema proposto, so os mesmos 30 minutos
que vo faltar no final do dia para resolver uma questo de
valor. importante, ainda, que todos na sala saibam antes
de iniciar qualquer discusso qual o objetivo do encontro e o
output esperado. Precisa estar claro onde se quer chegar, quais
respostas se quer obter ou em quais pontos o time presente
deve consentir quando o tempo chegar ao seu fim.
Um aspecto crucial e importantssimo para que o Product
Owner possa ser bem-sucedido o entendimento que este no
est jogando sozinho e no um exrcito de um homem s.
Embora o Product Owner tenha que liderar e seja responsvel
pelo sucesso do produto em diversos aspectos, isto no significa que ele, pessoalmente, tenha que efetuar o trabalho de
todas reas e estar envolvido em 100% do andamento. O papel
do P.O. o de um facilitador, um negociador, um influenciador. Ele precisa abrir a discusso com o marketing a respeito
da divulgao do seu produto e garantir que est na pauta
deste outro time. Precisa engajar o time de desenvolvimento
e transmitir claramente a misso do produto e de onde se quer
chegar. Deve trabalhar em conjunto com as pessoas da rea de
indicadores e mtricas. Mas, a partir da ele deve deixar que
cada um possa colaborar, produzir, construir, enfim, fazer o
seu trabalho. Um produto evoluiu atravs da realizao de
esforos conjuntos e a pior coisa que um Product Owner pode

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

fazer para o seu produto, para seus colegas e para si mesmo,


adotar uma postura altamente centralizadora. A melhor atitude
a de confiana nas pessoas. Tudo se resume em engajar, no
em coordenar.

Troque experincias
Da mesma forma que interessante que o Product Owner
busque mentores e profissionais com mais experincia para se
espelhar, uma boa ideia retribuir este conhecimento adquirido compartilhando suas prprias experincias com outros.
Com profissionais dispostos a compartilhar, ensinar, dividir
e mentorar, toda a comunidade de gestores de produto cresce
e se aprimora. Este tipo de atitude amplamente saudvel e
provavelmente desejvel em qualquer time ou empresa. Hoje
mentorado, amanh mentor.
Cabe ao profissional buscar meios de engajar-se, ainda, com
a comunidade que est inserido atravs de eventos, fruns,
institutos e afins. A troca de informao, experincia e discusses no somente sobre o papel do Product Owner, mas
especialmente sobre a gesto de produto em si s faz o mercado
tornar-se cada vez mais qualificado.
Muitos iniciantes na rea pensam que no possuem nada de
til a ser dividido, posto que seu tempo de experincia ainda
curto. Isto um erro. Todos os profissionais atuantes, independentemente do nvel de senioridade, possuem boas histrias
para contar. Cases de erros e de acertos, de dificuldades ou de
alternativas criadas para resolver velhos problemas. Partindo
do princpio de que ningum o dono da verdade absoluta,
o Product Owner iniciante tem muito a colaborar com a comunidade contando sobre seu prprio processo de formao,
as pedras que encontrou pelo caminho e como conseguiu
transpor estes obstculos. Certamente outros profissionais
em desenvolvimento conseguiro enxergar a si mesmos nestes
relatos e aprender de forma mais rpida a partir da experincia
compartilhada.
Muitas empresas estimulam jovens profissionais a criarem
seus blogs, submeterem propostas de palestras em eventos
da rea ou participarem ativamente de discusses como fishbowls, por exemplo. No mnimo, este Product Owner estar
exercitando suas habilidades de comunicao, alm de dar
sua contribuio pessoal para o desenvolvimento da rea de
gesto de produto como um todo.

A jornada de cada um individual


Cabe a cada um entender o que funciona e o que no funciona
em seu contexto ou empresa, descobrir seu prprio estilo de

atuao e comear a pensar em seus prprios conselhos para


outros colegas. No existe, mesmo, receita de bolo. No existe
curso, manual, ou passo a passo que seja suficiente para criar
um bom P.O. Apenas a prtica e a atitude correta que trazem
a experincia. Aqueles que desejam ser grandes profissionais
devem sair da zona de conforto, se auto provocar constantemente e buscar a melhoria contnua das suas habilidades e
conhecimentos. Devem estar atentos, o tempo todo, sobre o que
h de novo no mercado. E at mesmo por que no? inventar
suas prprias tcnicas.
Ao invs de assumir o papel de um expectador passivo da
prpria carreira, aquele que quer se tornar um grande Product
Owner deve tomar as rdeas do seu prprio desenvolvimento
pessoal e profissional. Quando este sente que j no est mais
aprendendo, hora de mudar. Mudar sua atuao, mudar de
rea ou at mesmo de empresa. o desafio que gera os grandes
profissionais e este, portanto, deve ser constante.

Links:
Apresentao: Concebendo produtos de forma gil (e divertida!)
slideshare.net/llldianalll/workshop-101-concebendo-produtos-de-forma-gil-edivertida-scrum-gathering-rio-2015-51691990
Its All in How You Slice
http://agileproductdesign.com/writing/how_you_slice_it.pdf
Pgina de Roman Pichler
www.romanpichler.com/
The Lean Startup
theleanstartup.com
Product Management
product-management.alltop.com/
Build Better Business Models
http://www.businessmodelgeneration.com/
Lean Startup Machine
https://www.leanstartupmachine.com/

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

17

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

Product Owner ou Product Manager?


Eis a questo!
Conhea problemas decorrentes da m gesto de produtos no mercado de
tecnologia
Fique por dentro:

Romeu Ivolela Neto


romeuivolela@gmail.com

Consultor em Gerenciamento de Produtos e


Designing de Servios. Graduado como tecnlogo pela universidade Opet Paran e psgraduado em histria da filosofia pela PUC-SP.
Certificaes: SCJA, CSM, CSD, CSPO e Accredited Kanban Practitioner Training.

18

om o advento dos mtodos geis,


a complexidade de outrora em
desenvolver e distribuir softwares tem diminudo ao longo dos ltimos
anos. Os mtodos geis como Scrum e
XP promoveram uma verdadeira revoluo na forma de se pensar e construir
software. Times multifuncionais, compostos por desenvolvedores, testadores,
user experience designers, agile masters
e Product Owners, modificaram o mercado de tecnologia e as estruturas das
empresas tradicionais.
Como a histria nos ensina, toda revoluo traz consigo a semente do novo
sobre uma proposta declinante. O conflito inevitvel e as estruturas e ideias
obsoletas no so facilmente esquecidas
ou abandonadas.
Foram interminveis os debates sobre
o que seria feito, por exemplo, com os

Este artigo ser til para entender os problemas vigentes na gesto de produtos web
decorrentes da atuao dos Product Owners e
Product Managers nas empresas. Os conflitos
entre estes papis e as lacunas em suas respectivas atribuies vm corroendo o artefato mais
importante dos times geis: o product backlog.
Elemento central da eficcia e da entrega de
valor ao negcio, este artefato infelizmente
tem sido construdo sobre blocos de requisitos
esmigalhados, viso insuficiente de produto e
distncia dos usurios finais comprometendo,
desta forma, o objetivo de todo time gil: a entrega de valor aos clientes.

gerentes de projetos, uma vez que os


agile masters estavam assumindo as
atribuies daqueles. Qual seria o futuro
dos gerentes? Poderiam estes assumir
este novo papel? Deveriam abraar o
destino e navegar em outros mares?
Alguns gerentes de projetos realmente
abraaram a causa gil e se tornaram
excelentes agilistas. Outros, voltaram
o foco ao desenvolvimento de pessoas,
infelizmente to carente nas empresas.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

Obviamente, no podemos nos esquecer dos que ficaram no


limbo, presos no passado e infelizmente muito presentes em
nosso dia a dia corporativo.
Com a propagao dos mtodos geis, dois papis logo se destacaram nos times: o agile master e o Product Owner. Ambos
os papis so imprescindveis ao sucesso de um produto. O
agile master foca no processo e conduz o time na estrada da eficincia. O Product Owner, por sua vez, se responsabiliza pela
eficcia. Eficcia para um Product Owner tornar o produto
desejvel e til aos clientes, e vivel e rentvel ao negcio.
Para atingir esta eficcia, o Product Owner utiliza vrias
ferramentas: business model canvas, roadmaps, data driven,
lean startup, design thinking, design service dentre tantas
outras tcnicas possveis.
Alm desse conjunto de ferramentas, um profissional de
produtos precisa ter certas caractersticas, como ser capaz de
analisar o produto de forma holstica, autonomia para decidir o que priorizar e cortar do backlog e ter alta capacidade
de negociao para mediar os conflitos de interesses entre
stakeholders e clientes, sendo estes representados nas empresas
pelo gestor de produto.
A viso holstica do produto evita decises com vis especializado ou departamental. A autonomia se apodera deste
profissional para a tomada de decises e o lado negociador
media, trata e alinha com todas as partes interessadas, o que
e o porqu de cada requisito priorizado, gerando convergncia
e unicidade de trabalho e de informao.
Pode-se destacar que a falta de viso e autonomia incapacita e
mina a negociao do produto, resultando em graves problemas
pelos quais os times geis vem enfrentando: Product Owners
sem empowerment e com vises de negcio fragmentadas ou
nulas, tornando estes profissionais geradores de especificaes
ao invs de geradores de oportunidades e valor.
Mas o que est acontecendo realmente? Por que no dado
o empowerment necessrio aos Product Owners? Por que lhes
falta tanta informao? Por que estes profissionais mal conseguem dar o feedback de sucesso ou fracasso do que esto
priorizando?
Podemos achar algumas respostas nas abordagens tradicionais. Vale lembrar que a engenharia de produo de software
foi baseada nas engenharias civil e naval. Estas engenharias
no eram os modelos mais aptos para a engenharia do software, mas eram os sistemas de produo conhecidos at ento.
Junto do famigerado waterfall, as empresas de tecnologia
herdaram toda estrutura matricial que servia de arcabouo
para este sistema de produo. Hoje temos um blend entre este
modelo e as metodologias geis que chegaram com fora nas
empresas a partir de 2001.
O passado e o presente se fundem em um ambiente complexo, catico e nebuloso, gerando insatisfao e desgaste
constantes.
Dentro deste cenrio, uma anlise faz-se necessria. Resqucios e fragmentos da histria da engenharia de produtos
podem ajudar na busca do que se perdeu para entender
melhor o cenrio vigente. Seguindo a ordem cronolgica, a

histria da gesto de produtos comea em 1931, quando Neil


H. McElroy escreve um memorando para a empresa Procter
& Gamble solicitando algumas contrataes. Os candidatos
deveriam acompanhar as vendas para gerenciar melhor o
produto, publicidade e promoes, tudo isto o mais prximo
possvel do cliente. Este memorando projeta os alicerces do
Brand Management e mais tarde da prpria disciplina de
Product Management.
Vale ressaltar que McElroy, alm de lanar os alicerces da
disciplina de Product Management, tambm foi secretrio
de defesa americano, ajudou a fundar a NASA e tornou-se
conselheiro na Universidade de Stanford, onde influenciou
outros dois notveis: Bill Hewlett e David Packard.
Na HP, as ideias de Product Management ganharam impulso.
O usurio ocupava o centro das tomadas de decises e a rea de
produtos representava a voz do cliente internamente, influenciando desta forma grande parte das empresas de hardware e
software daquela poca.
A disciplina de Product Management ganha um novo captulo a partir da dcada de 60, com a introduo de uma nova
abordagem - chamada de mix de marketing - formulada por
Jerome McCarthy em seu livro Basic Marketing. O mix de marketing comea a ser usado para controlar e influenciar a forma
como os consumidores se relacionavam com os produtos. O
modelo composto por 4 Ps: Produto (fornecer bens e servios
que respondam as necessidades dos clientes), Preo (valor cobrado pelo bem e\ou servio prestado), Praa (distribuio dos
produtos aos mercados consumidores) e Promoo ( a parte
de comunicao e propaganda, lembrando e persuadindo o
cliente sobre o produto ofertado).
Entretanto, devido aos longos perodos de desenvolvimento
dos produtos, que poderiam levar meses ou at mesmo anos,
os Product Managers concentravam-se em somente 3 Ps: Preo,
Praa e Promoo. O ltimo P (Produto) era delegado a outras
reas das empresas, como Pesquisa & Desenvolvimento. Esse
foi o padro dominante das quatro dcadas seguintes.
Somente em 2001, com a publicao do manifesto gil, iniciase um novo captulo na histria da disciplina de Product
Management. A partir desse momento, os Product Managers
ganham flexibilidade para mudar, questionar e propor novos requisitos de forma mais dinmica e intensa. possvel
testar mais, ser mais ousado e atender mais aos anseios dos
clientes.
A complexidade, o tempo e os processos de desenvolvimento
de software mudam drasticamente. Requisitos so debatidos
de forma multidisciplinar e intensa, envolvendo as mtricas
do analista de dados, a interao e comportamento do usurio
analisados pelo profissional de UX, o esforo de implementao
dos desenvolvedores, o SEO (Search Engine Optimization) e o
SEM (Search Engine Marketing) do profissional de marketing e
a automao do testador.
O sucesso do produto torna-se o resultado do trabalho multidisciplinar, onde o mix de marketing (Praa, Preo e Promoo)
est agora intimamente ligado e dependente do P abandonado pelos Product Managers de outrora, o P de produto.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

19

Infelizmente, esse cenrio animador no se aplica at hoje na


maioria das empresas, as quais mantm distintas as gestes
de produtos e desenvolvimento, gerando uma srie de infortnios, prejuzos e anomalias que nada trazem de valor s
empresas e aos clientes, ou seja, todos saem perdendo.
Dentre as anomalias est a distino entre Product Owners e
Product Managers dentro das empresas. Estes dois papis so
sinnimos para um mesmo fim (criar produtos de valor aos
clientes e rentveis para as empresas) e sua distino funcional e
nominal pode ser considerada uma anomalia mercadolgica.
Os conflitos decorrentes destas distores so inevitveis.
Delegar somente o desenvolvimento e execuo dos requisitos aos Product Owners e seus respectivos times deix-los
distantes do contato com os clientes, da viso do produto e do
propsito do mesmo, gerando miopia em quem deveria estar
atento aos mnimos detalhes.
Privar Product Managers da priorizao e escrita de requisitos e do contato com o time de desenvolvimento arruinar
a qualidade do trabalho colaborativo, fomentar o handoff de
informaes e a incentivar a falta de unicidade, elementos que
s corroboram para o fracasso do produto.
Outra grave anomalia a transferncia de responsabilidades
e atribuies dos gerentes de produtos a outros profissionais
e reas, promovendo decises cartesianas, departamentais e
especializadas, incentivando a viso de silos ao invs da viso
do propsito.
O ponto mximo destas distores composto pelo tempo
desperdiado, o investimento perdido e o produto que deveria
servir, mas no final no serve para nada.
A gesto holstica e centralizada do produto faz-se necessria.
Desta forma, possvel executar uma priorizao assertiva
dos requisitos, a unicidade do propsito, a comunicao e
transparncia de informaes e mtricas, e desta forma atingir
o sucesso do produto.
Nas prximas sees, sero detalhadas as atribuies dos
product owners e product managers, algumas anomalias
mercadolgicas encontradas e propostas para resolver os
problemas identificados.

Atribuies de Product Manager/Product Owner (PO)


Antes de definir as atribuies de um Product Owner/Product Manager, vlido reforar algo importante: ambos so o
mesmo papel e a coexistncia de ambos no um bom pressgio. O Product Owner (PO) o Product Manager no modelo
gil, mais propriamente dito no framework Scrum. Porm,
outras metodologias como o Kanban (idealizado por David J.
Anderson) tambm trabalham com este profissional.
O Product Owner um papel multifacetado e no especializado, justamente porque precisa navegar entre diversas
disciplinas para obter o sucesso do produto. Vamos listar as
atribuies deste profissional:
Viso do produto: definir e capturar a viso do produto, bem
como partilhar ela com o time e stakeholders. possvel que
o PO tambm represente a viso do CEO ou de um diretor de
produtos e trabalhe para que a mesma seja realizada;

20

Responsvel pelo ROI (Return On Investment): o PO o


principal responsvel por identificar oportunidades de mercado e melhorias que podem trazer mais valor ao produto. O
acompanhamento constante das mtricas e do mercado de
vital importncia para este fim;
Organizao e priorizao do backlog: o backlog do produto
o artefato onde ficam todos os requisitos que sero implementados, geralmente escritos no formato de user story. Sua
organizao e priorizao seguem das histrias de maior valor
para as de menor valor ao negcio;
Planejamento de release: o lanamento de uma nova verso
pode conter correes de bugs, novas features, melhorias e
at mesmo reformatao do modelo de negcio. Cabe ao PO o
planejamento destes releases, orquestrando datas comerciais,
contratos e acordos firmados tanto internamente quanto
externamente;
Gerenciar interesses dos clientes, time e stakeholders:
muito comum haver conflitos entre stakeholders (makerting,
comercial, financeiro, backoffice, P&D, etc.), que podem possuir
interesses divergentes para o mesmo backlog. Cabe ao PO a
mediao e deciso final;
Gerenciar oramento: apesar de infelizmente passar despercebido por muitos profissionais de produtos, cada user story
tem um custo de produo que deve ser usado como critrio
de priorizao. muito comum tambm em Startups, POs
serem responsveis pelo EBTIDA do produto e responderem
pelos gastos dos seus respectivos times;
Autoridade para tomar decises: todos concordam que o
trabalho colaborativo traz muito valor ao produto, e o PO
no o sabe tudo do time, apesar de estar sempre muito bem
informado. Porm, como em qualquer outra rea, algum
precisa ter a palavra final e dar a direo correta. Este profissional o PO.

Perfil de um de Product Manager/Product Owner (PO)


Por ser um profissional multifacetado, a tarefa de encontrar bons gestores de produtos torna-se rdua. Em seu livro
Inspired: How to create products customers love, Marty Cagan
descreve as caractersticas exigidas de um Product Manager/
PO e que compem o mosaico funcional do que deve ser um
gestor de produtos:
Paixo por Produtos: Product Managers so apaixonados
por produtos. Esto sempre falando de modelos de negcios
inovadores e de como estes modelos impactam a vida das
clientes. Um Product Manager que no persegue e aprimora
constantemente um modelo de negcios, somente um gerador
de requisitos, nada mais;
Empatia pelos clientes: clientes so o propsito do produto.
Entenda-se por empatia colocar-se no lugar do cliente, compreender seus medos, anseios e contexto. Cada vez mais, faz
sentido usar abordagens como o Design Thinking para criar
produtos com foco nos usurios, e no em ns mesmos;
Inteligncia: necessria uma mente perspicaz para capturar oportunidades e costurar o trabalho multidisciplinar de
forma valiosa e focada;

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

tica e Integridade: uma grande responsabilidade gerenciar um produto. Quando um profissional se prope a tal
misso, deve agir de forma tica e com zelo pelo produto sobre
sua alada. Negligenciar a gesto de um produto uma forma
rpida de mat-lo. Afinal se o Product Manager no se importa
com o produto, quem mais se importar?
Confiana: o Product Manager um lder, e mais do que isto,
um vendedor do seu produto. A confiana passa a mensagem
de segurana ao time, investidores e demais interessados de
que o produto est em boas mos;
Atitude: decises difceis devem ser tomadas. Atitude a
energia que impulsiona a resoluo de problemas. No seria
incorreto dizer que o sucesso ou fracasso de um produto seja
a somatria das atitudes tomadas ou no pelos Gerentes de
Produtos;
Tecnologia: este um ponto sempre controverso, porm
muito difcil escrever boas user stories sem o mnimo conhecimento de tecnologia. Produtos web so feitos desta matria
prima, e conhecer as principais tecnologias, padres, protocolos e arquitetura web ajudam na negociao com os times e
na priorizao de requisitos com os mesmos;
Foco: um Product Manager deve decorar a frmula de lei
de little: Tempo de espera = quantidade de trabalho em andamento / taxa de entrega. Esta frmula nos ensina que, quanto
mais trabalho em andamento, maior o tempo de espera de
entrega. Imaginando que estamos falando de trs features,
ambas extremamente importantes para a companhia, voc
trabalharia em todas ao mesmo tempo ou faria uma por vez?
Focar no que mais importante trar resultados mais rpidos
para a empresa e, inevitavelmente, o que for de menor valor
ficar para trs;
Gesto de tempo: o foco do Product Manager deve ser as
tarefas mais importantes e valiosas ao Produto. Como key
person, dever estar vigilante quanto ao assdio constante
dos stakeholders, que tm como objetivo a realizao dos seus
respectivos interesses. Faz parte do ofcio do Product Manager gerenciar este assdio, contanto que ele no prejudique o
tempo do produto;
Comunicao: talvez um dos quesitos mais importantes.
Um gestor de produtos est a todo momento negociando e
vendendo o seu produto atravs da fala. A arte de se comunicar de forma clara e objetiva deve ser um trao inerente deste
profissional, e obviamente esta qualidade transferida para
o ato da escrita dos requisitos;
Habilidades de negociao: delegar, vender, comunicar,
mediar, promover, informar, priorizar, todas estas aes se
concretizam no contato com o outro. Trabalhar nos melhores
acordos atravs da empatia, serenidade, foco e tica sempre
garantem um resultado satisfatrio.

desconstruo das responsabilidades e atribuies do gestor


de produtos.

Anomalia 1: Gesto do produto dividido entre Product Owner


e Product Manager
Este cenrio decorrente da fuso dos elementos dos processos geis com a disciplina de product management, principalmente em empresas tradicionais como bancos, governo,
telefonia e grandes empresas de varejo.
A falta de conhecimento do papel do PO por estas empresas
e da disciplina de Product Management pelo movimento gil,
propiciou vrias distores e adaptaes para estes perfis,
dentre elas a diviso da gesto do produto em dois, onde o Product Owner ficou responsvel pela execuo e andamento do
backlog, mas sem muita autoridade sobre o mesmo. O Product
Manager por sua vez ficou encarregado de ouvir e ser a voz
do cliente, de cuidar de toda parte promocional, de aquisio
e vendas, o que explica de certa forma a predominncia de
profissionais de marketing atuando neste papel. Em suma, o
Product Owner olha para dentro da empresa (desenvolvimento), enquanto o Product Manager olha para fora (mercado).
Este cenrio traz uma srie de consequncias: lacunas no entendimento dos requisitos, falta de alinhamento e planejamento
entre as reas envolvidas, fragmentao da autoridade e responsabilidade do produto, problemas decorrentes de rudos e falta
de comunicao, perda de foco e dificuldade de priorizao.

Anomalia 2: Gerente de Marketing atuando como Gerente de


Produtos
Estes profissionais geralmente trabalham focados em metas
agressivas de receita. Inevitavelmente, um profissional de
marketing como gerente de produtos ir priorizar histrias que
favoream o alcance destas respectivas metas e certamente o
mesmo aconteceria se um arquiteto fosse o dono do backlog,
que acabaria por sua vez priorizando histrias mais tcnicas.
O problema que o foco em receita desvaloriza o restante das
mtricas importantes do funil do produto: aquisio, ativao,
reteno e recomendao.
A receita, portanto, a etapa final do caminho do usurio,
desde a sua chegada at o momento que ele paga por um
determinado servio. Porm, o foco obsessivo em receita traz
como consequncia uma gesto de produto imediatista, comprometendo a gesto sustentvel de longo prazo.
Desta forma, toda e qualquer histria que no seja relacionada
diretamente receita, no ser priorizada. uma questo de
tempo para que o valor do produto seja corrodo, e aps algum
tempo, ele perca o valor e interesse dos usurios e deixe de
existir no mercado.

Anomalias encontradas na gesto de produtos web

Anomalia 3: Gerente de Projetos atuando como Gerente de


Produtos

Nesta seo, sero analisadas algumas anomalias envolvendo


Product Owners (PO) / Product Managers no mercado, iniciando pela prpria contradio entre estes dois papis, bem
como outros problemas decorrentes da descaracterizao e

O gerente de projetos tem a responsabilidade de alinhar os


requisitos, garantir a comunicao e o tracking do projeto e,
na maioria das vezes, tambm assume tarefas de gesto de
pessoas, como controle de pontos de horas e demais assuntos

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

21

administrativos. Delegar a gesto do produto a este profissional envolve uma srie de problemas.
O primeiro deles que o gerente de projetos dentro de uma
estrutura matricial extremamente sobrecarregado. O papel
deste profissional chave para fazer toda a engrenagem girar e
o projeto andar. O foco, portanto, extremamente direcionado
para a execuo e entrega do projeto, porque no h tempo para
olhar oportunidades e melhorias do produto.
Ainda dentro da estrutura matricial, raramente este profissional tem a oportunidade de sugerir ou opinar sobre os
requisitos, pois os mesmos so definidos por diretores ou um
board executivo, cabendo ao gerente de projetos o papel de
executor e no de questionador.
A prpria estrutura matricial no pensada para gesto de
produtos, e quando h um gerente de produtos nesta estrutura,
ele compartilha dos mesmos problemas encontrados na anomalia 01, onde o product manager divide a responsabilidade
do produto com outro profissional.
Portanto, um gerente de projetos assumir a gesto de produtos, no cenrio matricial, a mesma coisa de no ter um.
Dentro da perspectiva gil, as responsabilidades de gesto do
projeto so assumidas pelo time de desenvolvimento, o que
libera este profissional do foco em projetos e lhe incube o
foco em desenvolvimento, direcionando suas energias no
desenvolvimento de pessoas e da rea de tecnologia como um
todo, o que preenche todo o tempo deste profissional.
Alm disto, a metodologia gil j delega a gesto do produto
ao Product Owner, o que elimina a necessidade de o gerente
de projetos assumir a gesto de produtos. Porm, caso isto
acontea, o product owner ter assumido tambm a responsabilidade de gesto do projeto, descaracterizando o seu papel no
time e impactando a sade do produto. Esta anomalia tambm
afetar o agile master, que ter um desafio extra na misso de
migrar a gesto do projeto do gerente de produtos para o time
de desenvolvimento.

Anomalia 4: User experience designer (UX) atuando como


Gerente de Produtos
O mercado entendeu finalmente a importncia deste profissional para o sucesso de um produto. O user experience
designer, popularmente conhecido como UX, o profissional
encarregado de toda experincia e interao dos clientes com
os produtos. Isto no pouca coisa, estes profissionais passam
anos estudando tcnicas como user mapping, focus group
e tcnicas de pesquisas qualitativas e quantitativas, design
thinking, design service, psicologia dentre tantas outras.
Apesar de haver uma interseco entre o product manager
e UX, uma vez que ambos advogam em prol do usurio, isto
no os fazem ter as mesmas atribuies e responsabilidades.
A entrega de valor aos clientes obtida atravs do trabalho de
vrias disciplinas, sendo UX somente uma delas.
Muitas vezes necessrio sacrificar o valor ao usurio final
por questes tcnicas, restrio de oramento e conflitos
internos. Achar o ponto de equilbrio, na maioria das vezes,
uma tarefa rdua. Apesar do valor ao cliente ser o ponto a

22

ser perseguido, inegavelmente isto se faz no acordo entre os


interesses destes e os da empresa. Como o foco do profissional
de UX extremamente centrado no usurio, isto o impede de
uma viso mais holstica, principalmente sobre a disciplina
tcnica, o que explica o porqu deste profissional no ser
recomendado para a gesto do produto.

Anomalia 5: Gerente de Tecnologia atuando como Gerente de


Produtos
A matria prima dos produtos web a tecnologia. Somente
os profissionais desta rea compreendem a complexidade que
toda esta disciplina envolve. As reas so diversas: banco de
dados, infraestrutura, operaes e desenvolvimento. E para
aumentar a complexidade, todas estas reas so lideradas por
profissionais especializados e com diferentes skills.
Todo profissional de tecnologia focado em resoluo de
problemas e dentro de sua especialidade, procura sempre fazer
isto de forma tcnica. Aqui reside o perigo em delegar a gesto
de produtos para um gerente de tecnologia.
Tomando como referncia as anomalias 2 e 4, onde se explanou os problemas de especialidades serem donas do backlog
do produto, o gerente de tecnologia ir priorizar naturalmente
histrias de cunho tcnico, e os demais requisitos iro perder
importncia e valor. o tpico caso onde o produto tecnicamente impecvel, porm sem valor de mercado. Conforme
cita Marty Cagan no livro Inspired How to create products
customers love: Construir corretamente o produto diferente
de construir o produto certo.

Anomalia 6: Agile Master atuando como Gerente de Produtos


Processo a forma de se construir ou produzir algo. Um
gestor de produtos eficiente deve ter na manga conhecimentos
e tcnicas desta disciplina, principalmente conceitos provenientes do sistema Toyota de produo (Lean).
O agile master a fonte e autoridade quando o assunto
processo. Ele responsvel por prover coach e treinamento aos
times de desenvolvimento, e muitos destes profissionais vm
se especializando para atender aos anseios dos profissionais
de produtos, lhes ensinando tcnicas como Lean Startup, Lean,
Kanban dentre outras.
Apesar do skill de processos ajudar na gesto do produto,
esta habilidade s ganha impulso se for usada para orquestrar
a evoluo e retorno do investimento de um produto. forte a
tendncia do agile master em focar mais no processo do que na
evoluo do produto, o que explica o porqu deste profissional
no poder lider-lo.

Product Manager/PO generalista x especialista


Como detalhado nas sees anteriores, fica claro o papel
generalista de um Product Manager/PO. O gerente de produto
pluralista e via de regra gosta de navegar entre as demais
disciplinas. por causa deste perfil que este profissional consegue desenvolver a viso holstica e convergir os trabalhos
dos especialistas em um ponto em comum: a proposta de
valor ao produto.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

agilidade

Muitos leitores podem achar que no possvel um gestor


de produtos ser to generalista. Na verdade, o perfil pregado
como ideal no mercado, o do especialista em um determinado
campo, no o nico a ser tido como padro. Esta viso de
especializao profissional fruto da filosofia cartesiana e da
revoluo cientfica, onde a viso pluralista do conhecimento
comea a dar lugar a anlises e estudos mais segmentados.
Porm, no renascimento o modelo era justamente o contrrio,
a pluralidade era cultuada como modelo ideal para desenvolver
o intelecto e potencialidades humanas. A escritora e artista
Emilie Wapnick em sua palestra no TED (ver seo Links),
nomeia estes profissionais de multipotencialidades. Ela explana que existem dois perfis de pessoas: as que gostam de se
aprofundar em um respectivo assunto por muito tempo (os
especialistas) e os que gostam de aprender sobre tudo, e tem
necessidade de conhecer e aprender vrios assuntos diferentes
(os generalistas).
So dois perfis que se complementam e que juntos geram
timos resultados. O Product Manager/PO mapeia, compartilha e gerencia a viso e proposta do produto, e a partir
desta orientao, os especialistas comeam a construo e
materializao da viso.

Contra anomalias, times produtizados


As anomalias citadas prejudicam o trabalho dos times geis e
o valor entregue aos produtos, tendo efeitos negativos em toda
a cadeia produtiva. Porm, estes males podem ser remediados.
Antes de mais nada, vale ressaltar a diferena conceitual entre
produto e projeto.
Projeto uma empreitada com comeo e fim, com objetivo de
entregar um produto ou melhoria. Um produto, por sua vez,
um meio de se entregar um servio e com prazo indefinido de
trmino (termina quando o modelo de negcio se esgotar).
Este conceito deriva do modelo Service Dominant Logic
(SDL), introduzido por Stephen Vargo e Robert Lusch em 2004,
em uma edio do Journal of Marketing. Tennyson Pinheiro
e Luis Alt, explicam este modelo no livro Design Thinking
Brasil: Este modelo defende uma mudana na antiga perspectiva tradicional de produtos, que enxerga servios apenas
como atributos e custos de uma oferta. Segundo a SDL, tudo
servio. Produtos so, ento, bens tangveis que orbitam no
ecossistema de um servio. .
Vamos dar um exemplo: um e-commerce de roupas um
servio de vendas e entrega de vesturio. Esta a serventia e
valor do mesmo ao cliente. Um servio por sua vez composto
por um ou vrios produtos, que so os meios de se entregar
um servio. No caso deste e-commerce, o pagamento um
produto, pois ele permite que o cliente pague suas compras
utilizando vrios meios de pagamento. O delivery outro
produto, pois permite que a compra seja entregue na casa do
cliente. Ambos produtos orbitam o ecossistema do servio de
vendas de vesturio.
O servio de msica Spotify uma das empresas que usam
este modelo. Dentro deste servio, os times de desenvolvimento
so autnomos, multifuncionais e responsveis cada um por

um produto. Exemplo: os playlists do Spotify so gerenciados


por um time, que responsvel pelo uso e entrega de valor
deste produto dentro do servio de msica Spotify. Este time
tem como meta concretizar a viso e melhorar as mtricas
deste respectivo produto, cujo responsvel o Product Owner.
Portanto, o PO define a viso, mtricas e histrias, e todo o
resto do trabalho fica a cargo do time, que executa e responde
por tudo o que for feito.
s vezes acontece de os produtos crescerem mais do que
os servios que os originaram, como foi o caso do PayPal no
eBay. O meio de pagamento criado para sustentar o Ebay hoje
independente e maior do que o prprio eBay. O fato da indstria de software estar adotando o modelo de produtos para o
desenvolvimento de softwares no significa que projetos no
so mais necessrios.
Produtos podem ter projetos, isto perfeitamente normal
dentro da concepo de que um projeto um trabalho finito.
Um projeto bem-vindo quando o escopo e necessidade do
que ser implementado so conhecidos, vlidos e importantes
para o cliente e/ou para o produto. A anormalidade est em
empresas que conduzem produtos como se fossem projetos,
dentro de estruturas matriciais.
Nestes casos, voc no constri times perenes e focados na
evoluo de produtos, mas sim times efmeros focados na entrega de projetos. Quando estes acabam, todo o conhecimento
pulverizado em novos projetos e times. Esta forma de trabalho ineficiente e retrgrada, pois gera pouco envolvimento
dos profissionais, que so sempre alocados temporariamente
em alguma frente. So os profissionais que trabalham mais
focados em tickets do Jira do que em histrias de evoluo e
valor aos clientes.
Um time focado em produto usa sua energia e inteligncia em
melhorar de forma incremental e colaborativa o produto. Estes
times usam de mtodos, como o Lean Startup, para validar as
suas hipteses e aprender com o resultado dos experimentos,
gerando desta forma conhecimento, que por sua vez se reverte
em valor ao produto.
Esta forma de trabalho gera uma atmosfera desafiadora e
dinmica, o sentimento de dono incorporado pelo time,
e os ganhos no demoram a aparecer. Todos integrantes
do time sentem-se de fato parte do produto e do processo:
brigam, discutem, vibram e vivem cada conquista e derrota
intensamente.
A trade proposta no livro Drive, do autor Daniel Pink,
materializa-se em toda a sua potencialidade em um ambiente
produtizado:
Maestria, onde cada profissional especializado faz o seu
melhor;
Autonomia, permitindo a independncia e liberdade de
trabalho;
Propsito, razo pela qual se faz algo, o bem maior que faz
tudo ter sentido.
O papel do Product Manager/Product Owner dar este
sentido, servindo de guia no cenrio dirio de incertezas,

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

23

complexidades e desafios que envolvem o desenvolvimento


de um produto.
O papel Product Manager/Product Owner est sendo debatido como nunca. Esta discusso era previsvel, uma vez que
os times geis vm progredindo e cumprindo o seu papel de
serem mais eficientes no desenvolvimento de software. Logo,
natural que as atenes se voltem para a eficcia, cuja responsabilidade cabe ao Product Manager/Product Owner.
Entender as atribuies, responsabilidades e importncia do
gerente de produtos dentro de um time, fortalece o movimento
gil como um todo e impacta diretamente na entrega de valor
para as empresas, os clientes e a sociedade.

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

24

Links:
Inspire: How to create products love
http://www.amazon.com/Inspired-Create-Products-Customers-Love/
dp/0981690408/ref=sr_1_1?ie=UTF8&qid=1452801031&sr=8-1&keywords=inspired
Vantagens e desvantagens de uma empresa projetizada
http://pmkb.com.br/artigo/vantagens-e-desvantagens-de-uma-empresa-projetizada/
The History and Evolution of Product Management
http://www.mindtheproduct.com/2015/10/history-evolution-product-management/
The Scrum Guide
https://www.scrumalliance.org/why-scrum/scrum-guide
Palestra de Emilie Wapnick no TED: Why some of us dont have one true
calling
https://www.ted.com/talks/emilie_wapnick_why_some_of_us_don_t_have_
one_true_calling

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.

Modelo hbrido de gesto


Unindo abordagens geis e tradicionais

Fique por dentro:


Gerenciar projetos de desenvolvimento de software no uma tarefa simples, pois o uso de guias
como o PMBOK leva muitas empresas a adotarem
mtodos muito rgidos e trabalhosos enquanto o
mercado busca por agilidade. Por outro lado, os
mtodos geis como o Scrum resolvem a questo
da agilidade e entrega de valor agregado e tornam mais clara a visibilidade e previsibilidade da
entrega do produto do projeto, porm com certas
perdas no tratadas por metodologias geis como
controle de custo, riscos, contrataes, aquisies,

O
Srgio Salles Galvo Neto
ssallesinf@hotmail.com

Gerente de Projetos certificado PMP, ITIL,


Microsoft entre outras. Atuando na rea de
informtica desde 1992 e, a mais de 10 anos
liderando equipes em projetos de desenvolvimento e implantao de softwares. Nos ltimos oito anos atuando como Scrum Master
em projetos em diversas tecnologias e ramos
de negcio.

gerenciamento de projetos
envolve um conjunto de atividades no triviais que possuem
variaes geis e nem to geis assim.
Dois arcabouos que se destacam para
apoiar as atividades do gerenciamento
so PMBOK e Scrum. Neste artigo no
abordaremos como estes so diferentes,
nem mesmo as diferenas entre eles.
O foco ser na unio dos pontos fortes e
como os processos podem coexistir tranquilamente e de uma maneira enxuta.
Este artigo resultado de experincias
anteriores em empresas de software as

entre outros. Desta forma, o melhor caminho a


unio dos pontos fortes de cada uma, respeitando
aquilo que de mais valioso em um projeto a
entrega do escopo. Este artigo til por mostrar
como possvel trabalhar com abordagens geis
e tradicionais em conjunto no gerenciamento de
projetos. Essa abordagem hbrida traz benefcios e
permite aos gestores definir um modelo de gesto
gil, documentalmente estruturado, eficiente, eficaz e bem aceito em modelos de maturidade como
o MPS.BR e o CMMI.

quais necessitavam ter controles mais


tradicionais, at mesmo de forma a
controlar os trabalhos e esforos despendidos, bem como ciclos rpidos de
desenvolvimento gerando entregas de
valor ao cliente utilizando-se o mtodo
Scrum. Durante a execuo de todos os
seus processos so geradas diversas informaes relevantes aos clientes e partes interessadas atravs da aplicao de
conceitos e artefatos tradicionais construdos tendo como base o PMBOK.
Um projeto antes de ser iniciado dentro
da empresa, foi orado e precificado, ou

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

25

seja, houve uma anlise prvia da equipe sobre o escopo onde


foram estimados os esforos e, principalmente, estabelecidas as
prioridades por entregvel considerando-se o valor agregado
a cada uma das entregas. Isso significa j existir um Product
Backlog (lista de itens do produto) orada e priorizada. As
etapas seguintes, conforme estabelecido no Guia PMBOK
como iniciao, planejamento, execuo, monitoramento e
controle e, o encerramento ocorrero levando em conta este
artefato Product Backlog o qual foi extrado do contrato
firmado entre as partes.
Sendo assim, o presente artigo descrever os papis, ferramentas utilizadas e artefatos gerados, processos e iteraes
durante todo o perodo de desenvolvimento do software
contratado. Parte-se do pressuposto do conhecimento prvio
da existncia e do funcionamento bsico do Guia PMBOK e
da metodologia Scrum.
necessrio tambm contextualizar o projeto, cujo escopo est
determinado no product backlog o qual contm diversas estrias. No relevante a ordenao das estrias as quais compem
o product backlog, mas sim, a prioridade ou o valor agregado
gerado a cada estria produzida. Outra informao relevante o
esforo planejado para o desenvolvimento de cada estria. Sendo
assim, o projeto contm vrias estrias que sero agrupadas e
produzidas em cada Sprint (a cada duas ou quatro semanas).
Por exemplo: o projeto possui 10 estrias que foram priorizadas
e organizadas em trs Sprints. A primeira Sprint entregar cinco
estrias, a segunda Sprint entregar trs estrias e a terceira
Sprint entregar dois estrias. A grosso modo, entendemos que
o projeto ter durao de 12 semanas, considerando que cada
Sprint possuir quatro semanas de durao. Ento, o plano do
projeto constar exatamente esta informao.
Papel

Sigla

Gerente de Projetos

GP

Product Owner

PO

Scrum Master

SM

Equipe

EQ

Cliente

CL

Papis e responsabilidades Definindo quem faz o que


Todo e qualquer projeto de desenvolvimento de software
depende, em sua maioria, de pessoas. Estabelecer os papis
e responsabilidades de cada um, em qualquer metodologia,
a principal atividade. Em um modelo hbrido de gesto
existiro os papis complementares e exclusivos para que no
haja sobreposio de funes, otimizando e especializando
determinadas atividades. Os papis e suas responsabilidades
esto descritos na Tabela 1.
Ainda sobre os membros da equipe, vale destacar uma diferena
entre o conceito de equipe ao que se refere o Guia PMBOK e a
metodologia Scrum. Para o Guia PMBOK, todos os membros que
compem a equipe so nomeados e atribuem-se atividades a cada
um destes membros, que so chamados de recursos. Este conceito
leva dependncia de atividades entre os recursos. Isso significa
dizer que o trabalho de um recurso depende da concluso do
trabalho de outro. Esta caracterstica leva ainda gerao de cronogramas bastante complexos, podendo gerar informaes como
a alocao e at permitir realizar o chamado balanceamento de
recursos, onde as atividades so distribudas ao longo do tempo
disponvel para cada recurso de forma a alcanar a utilizao
mxima diria possvel para garantir a entrega do projeto. J na
metodologia Scrum existe apenas o conceito do Time (Equipe)
que responsvel pela entrega do projeto. A distribuio das
atividades organizada pela equipe da melhor forma para, da
mesma forma, garantir a entrega da meta da Sprint.

Ferramentas e artefatos
Existem diversas ferramentas e tcnicas recomendadas para
a execuo dos processos no guia PMBOK e Scrum. Neste
artigo ser apresentado o conjunto de ferramentas adotados
Descrio e Responsabilidade

a pessoa de contato e responsvel geral pelo projeto, ou seja, aquele que garantir o bom andamento do projeto tanto pela tica do cliente como internamente,
acompanhando e controlando o andamento do projeto, auxiliando nas dificuldades, monitorando e corrigindo possveis desvios, mantendo as comunicaes entre as partes,
controlando os riscos, escopo, custo, prazo, entre outros.
Gerenciar o Product Backlog garantindo que o que ser produzido pela equipe est de acordo com as expectativas do cliente. Em outras palavras, o PO o detentor das regras
de negcio de cada item do product backlog, o representante dos desejos do cliente no que se refere ao produto a ser produzido e entregue. O PO tambm responsvel por
manter a visibilidade a todos do product backlog.
Disseminador da adoo da metodologia Scrum junto equipe, auxiliando na organizao dos membros da equipe, permitindo que evoluam em sua auto-organizao e
aumentem sua produtividade. Tambm o responsvel por remover quaisquer impedimentos os quais interrompam ou possam vir a interromper o bom andamento do
desenvolvimento das atividades durante a Sprint.
Equipe so as pessoas que trabalham no projeto e na Sprint. Na metodologia Scrum utiliza-se o termo auto organizada e multidisciplinar. Isso no quer dizer que todos os
membros da equipe fazem todas as atividades, pois isso no seria nada produtivo. Ao dizer auto organizada e multidisciplinar deve-se entender:
Auto organizada: todos os membros da equipe sabem o que precisa ser feito e quem dever fazer o que e no momento adequado, afim de garantir a entrega do objetivo;
Multidisciplinar: No restringe o papel principal de cada membro da equipe. Por exemplo: um arquiteto de software poder ser o administrador do banco de dados; um
Desenvolvedor poder fazer uma documentao necessria; um analista de testes tambm pode ser o analista de requisitos, etc.
O principal ponto a ser observado a equipe ser composta por membros experientes e suficientes para a construo do software conforme o estabelecido.
O tamanho da equipe tambm poder variar conforme a necessidade, porm fortemente recomendado que os membros da equipe possuam forte conhecimento da
metodologia Scrum para viabilizar o trabalho em conjunto com os demais. Em outras palavras, caso seja preciso aumentar a equipe, os novos integrantes devem possuir os
conhecimentos da metodologia e da dinmica de trabalho, bem como estarem confortveis com os valores e a cultura da organizao, caso contrrio, a performance poder
no ser a esperada.
a parte mais interessada. Geralmente formada por uma equipe composta de pessoas de departamentos de TI e da rea usuria. Sua participao em todo o processo
fundamental para garantir o alinhamento das expectativas junto ao escopo a ser produzido.

Tabela 1. Papis e Responsabilidades

26

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

planejamento

como padro. Este conjunto no deve, de forma alguma, limitar a adoo de outras ferramentas das quais possam vir a ser
necessrias dentro da cultura da empresa.
Os processos envolvidos neste modelo hbrido, tanto tradicionais quanto os geis, sero explorados e detalhados no
decorrer deste artigo.
O conjunto de ferramentas e artefatos eleitos como essenciais
estaro descritos, em forma de tpicos, a seguir. A organizao
dos tpicos se dar em trs sees, onde:
1. Ferramenta / Artefato (ou processo): contm a nomenclatura
da Ferramenta / Artefato (ou processo);
2. Descrio Ferramenta / Artefato (ou processo): descrever
a funo ou objetivo da Ferramenta, Artefato (ou Processo).
Vale lembrar que os processos sero descritos brevemente para
auxiliar na identificao das interaes entre os processos,
ferramentas e artefatos;
3. Entradas / Resultados (Ferramentas / Artefatos / Processos):
demonstrar, de forma sucinta, quais so as origens de informaes ou melhor, de onde vm as informaes que alimentam
as ferramentas, artefatos ou processos. Os resultados gerados
por eles iro gerar informaes as quais, por conseguinte, ir
alimentar outras ferramentas, artefatos ou processos em outras
etapas do desenvolvimento.

- Entradas:
- Product Backlog;
- Resultados servem para:
- Sprint Backlog;
- Atualizaes Plano Projeto.
Ferramenta / Artefato (ou Processo): Sprint backlog (meta
da Sprint) [Scrum]
- Descrio: toda a fora de trabalho da equipe estar concentrada na entrega do Sprint backlog. Trata-se de uma lista
contendo todas as estrias a serem produzidas na Sprint.
Todos os eventos, a partir do incio da Sprint, tomaro como
base esta meta, tais como reunies dirias, impedimentos,
mudanas, etc.
- Entradas:
- Plano da Sprint;
- Product Backlog;
- Resultados servem para:
- Quadro Kanban;
- Acompanhamento da Sprint;
- Monitoramento e Controle;
- Grfico Burndown;
- Reviso da Sprint (Sprint Review)
- Retrospectiva da Sprint (Sprint Retrospective);
- Encerramento.
Ferramenta / Artefato (ou Processo): quadro Kanban
[Scrum]
- Descrio: o uso do quadro Kanban ideal para uma
melhor visualizao do andamento (o que falta ser feito, o
que est sendo validado ou qual estria possui problemas)
do projeto. No estamos nos referindo ao modelo KanBan
de trabalho que difere dos conceitos do Scrum, mas do
uso do quadro de tarefas. Neste quadro Kanban, todos os
itens da meta da Sprint (Sprint Backlog), ou estrias, so
registrados em post-its. Um exemplo pode ser observado
na Figura 1.

Os itens definidos sero nomeados e haver uma notao


([Scrum] ou [Guia PMBOK]) indicando a qual metodologia
pertence. Por exemplo: o artefato product backlog receber a
nomeao [Scrum], identificando-o como item pertencente
metodologia gil Scrum.
Iremos a partir de agora apresentar os itens do processo:
Ferramenta / Artefato (ou Processo): product backlog
[Scrum]
- Descrio: lista de itens (requisitos) que compe o produto.
Nesta lista encontram-se, alm dos itens, as estrias (regras
de negcio) de como um destes requisitos dever funcionar. Estes itens (estrias) so priorizados conforme o valor
agregado ao negcio. O Product Backlog ser
atualizado conforme a concluso e entrega
das sprints ou conforme mudanas solicitadas
pelo cliente.
- Entradas:
- Contrato assinado
- Resultados servem para:
- Pl a n e j a me nto da Spr i nt (Spr i nt
Planning);
- Plano da Sprint;
- Sprint Backlog.
Ferramenta / Artefato (ou Processo): plano da
Sprint [Scrum];
- Descrio: define o que ser feito e entregue
na Sprint. So os itens priorizados no product
backlog os quais a equipe determinou ser
possvel entregar no perodo de uma Sprint
(uma Sprint tem a durao de duas a quatro
semanas em mdia).
Figura 1. Quadro Kanban

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

27

Geralmente, um quadro Kanban possui as seguintes


colunas:
Sprint Backlog (Meta): so todas as estrias a serem realizadas na Sprint. Assim que cada estria comea a ser produzida,
o respectivo post-it movido da coluna Sprint Backlog para
a coluna Em andamento;
Em andamento: so as atividades em execuo naquele
perodo. Conforme seu andamento, os post-its sero movidos
para as prximas colunas;
Em validao: so as estrias em processo de validao, seja
junto ao cliente ou passando por algum processo automatizado. Antes da estria ser dada como entregue, ela precisar ser
validada. O processo de validao poder variar conforme a
necessidade do cliente e da cultura da empresa que est desenvolvendo o software;
Entregue: so todas as estrias que foram concludas e aceitas pelo cliente. A validao geral ocorrer no evento Sprint
Review onde o conjunto todo ser entregue e ser recebido o
aceite do cliente;
Impedimentos: as estrias onde surgiram problemas, sejam
estes por falta de alguma informao, definio ou dependncia externa, devero ter seu post-it correspondente movido
para esta coluna.
- Entradas:
- Plano da Sprint;
- Sprint Backlog.
- Resultados servem para:
- Grfico Burndown;
- Acompanhamento da Sprint;
- Reunies Dirias;
- Status Report Semanal;
- Controle de Mudanas.
Ferramenta / Artefato (ou Processo): Grfico Burndown
[Scrum]
- Descrio: uma forma grfica de demonstrar o andamento da Sprint. Seu objetivo representar diariamente
o progresso do trabalho em desenvolvimento. Aps cada
dia, o grfico apresenta a poro de trabalho finalizada em
comparao com o trabalho total planejado. Para a gerao
do grfico Burndown, necessrio o preenchimento da
planilha de horas. Vale ressaltar que no h uma indicao
direta da utilizao do grfico Burndown no guia do Scrum,
porm, existe uma citao informando se tratar de uma boa
prtica. comum a equipe de desenvolvimento usar esse
grfico ao longo da Sprint para medir os pontos das histrias
finalizadas ao longo dos dias e ter uma visibilidade do seu
ritmo de trabalho, verificando se ele est adequado para
atingir a meta planejada. Um exemplo de grfico Burndown
est representado na Figura 2.
- Entradas:
- Plano da Sprint;
- Sprint Backlog;
- Planilha de Horas.
- Resultados servem para:
- Monitoramento do Projeto;

28

- Reunio Diria;
- Sprint Review;
- Retrospectiva da Sprint;
- Status Report Semanal;
- Controle de Mudanas.

Figura 2. Grfico Burndown

Ferramenta / Artefato (ou Processo): Planilha de Horas


[Guia PMBOK]
- Descrio: os membros da equipe devem lanar as horas
trabalhadas na realizao de cada estria que compe a
meta da sprint (Sprint Backlog). Esta atualizao deve ser
diria e, preferencialmente, antes da realizao da reunio
diria. O preenchimento da planilha de horas ir gerar o
grfico Burndown, no qual ser possvel equipe verificar
o andamento, problemas ou desvios para o cumprimento
da meta da Sprint (Sprint Backlog). Novamente lembramos
que o grfico Burndown no um artefato obrigatrio, porm se for adotado, a planilha de horas dever ser adotada
obrigatoriamente.
- Entradas:
- Equipe atualiza planilha de horas (lanamento dirio
de horas trabalhadas)
- Resultados servem para:
- Grfico Burndown;
- Reunies Dirias;
- Sprint Review;
- Retrospectiva da Sprint;
- Monitoramento e Controle do Projeto.
Ferramenta / Artefato (ou Processo): Reunio Diria (registro) [Scrum]
- Descrio: na metodologia Scrum, determinado que seja
realizada a reunio diria. Este encontro deve ser rpido (15
a 20 minutos em mdia) e deve abordar trs pontos:
1. O que foi feito;
2. O que ser feito em seguida;
3. Impedimentos encontrados.
Por questes de controles internos e at mesmo alguns modelos de maturidade, sugere-se o registro destas reunies. Este
registro, que pode ser uma ata simples ou uma postagem em
um blog interno, servir como meio de obter transparncia e
registro dos acontecimentos, como um dirio de bordo.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

planejamento

Uma outra grande utilidade deste registro servir de base


para a prxima reunio diria para verificar se houveram mudanas ou desvios desde a ltima reunio. Estas informaes,
uma vez registradas, devero ser utilizadas nos processos de
encerramento.
- Entradas:
- Equipe relata os trs pontos e o Scrum Master registra
na ferramenta escolhida (blog, ata, etc.).
- Resultados servem para:
- Reunio Diria (prxima reunio a acontecer);
- Sprint Review;
- Retrospectiva da Sprint;
- Status Report Semanal;
- Controle de Mudanas.
Ferramenta / Artefato (ou Processo): Sprint Review (registro)
[Scrum]
- Descrio: o registro do que foi produzido como resultado da Sprint. Trata-se de um encontro onde a equipe ir
apresentar o que est sendo entregue com o trmino da
Sprint ao cliente. Neste encontro, o cliente dar o aceite
daquilo que foi disponibilizado.
- Entradas:
- Aceites do Projeto;
- Retrospectiva da Sprint;
- Controle de Mudanas.
- Resultados servem para:
- Registros organizacionais;
- Aceites do Projeto (assinados);
- Aceites Mudanas (assinados);
- Produc t Bac k log at ua l i zao das estr ias
finalizadas.
Ferramenta / Artefato (ou Processo): Retrospectiva da Sprint
(registro) [Scrum]
- Descrio: similar ao conceito do guia PMBOK de lies
aprendidas. uma reunio onde a equipe ir voltar no
tempo e avaliar o andamento e concluso da Sprint. Basicamente, devem ser registrados trs itens:
1. O que foi bom nesta Sprint e deve ser mantido para
as prximas Sprints;
2. O que pode ser melhorado para as prximas
Sprints;
3. O que deve ser abolido das prximas Sprints.
Este registro fundamental para que a empresa possa tomar
decises e realizar mudanas organizacionais de forma a auxiliar o bom andamento das prximas iteraes.
- Entradas:
- Registro de retrospectivas de Sprints concludas;
- Solicitao de mudana nos processos organizacionais
(atualizao de processos de trabalho).
- Resultados servem para:
- Registros organizacionais Retrospectiva da Sprint;
- Encerramento do projeto / lies aprendidas;
- Solicitaes de mudana organizacional (atualizao
de processos de trabalho)

Ferramenta / Artefato (ou Processo): Status Report Semanal


[Guia PMBOK]
- Descrio: Trata-se do registro dos acontecimentos no projeto para o cliente. uma ferramenta vastamente conhecida
e aplicada por aqueles que seguem o Guia PMBOK. Basicamente, o relatrio de Status Report Semanal, demonstra o que
estava planejado, o que foi realizado, a comparao entre o
planejado e realizado (escopo, custo e prazo), as mudanas, os
riscos, o planejamento futuro, etc. Este relatrio elaborado
pelo Gerente de Projeto e enviado s partes interessadas de
forma a dar cincia e transparncia ao que est acontecendo.
As informaes contidas no relatrio de Status Report Semanal, poder variar conforme a necessidade e cultura de cada
Empresa. O seu objetivo principal registrar o que aconteceu
e as aes a serem tomadas para corrigir desvios e gerenciar
riscos, dando cincia s Partes Interessadas. Em algumas
organizaes, os Status Report Semanais so considerados
como aceites parciais do projeto.
- Entradas:
- Grfico Burndown;
- Reunies Dirias (registro).
- Resultados servem para:
- Monitoramento e Controle;
- Controle de Mudanas;
- Encerramentos.
Ferramenta / Artefato (ou Processo): Processo de Controle
de Mudanas [Guia PMBOK]
- Descrio: Ao se utilizar o Scrum, as mudanas so vistas
de maneira a agregar um valor maior ao negcio. Apesar de
raro, o cliente pode vir a solicitar que alguma estria seja
retirada. Tambm possvel que alguma estria possua
desdobramentos maiores do que os previstos inicialmente e
sugerem uma reviso. Geralmente, a equipe ir entender esta
mudana e ir verificar se possvel absorver o esforo ou,
simplesmente, remover a estria reprogramando-a para ser
executada em uma outra Sprint a ser planejada. Para o Guia
PMBOK, toda e qualquer mudana dever ser registrada, avaliada (orada) e discutida verificando a procedncia ou no
de incluso desta mudana ao escopo do projeto. Para tanto,
o planejamento do projeto dever sofrer uma atualizao
considerando a mudana. O fato a necessidade de que as
mudanas sejam registradas e controladas, seus impactos e
o aceite do cliente para que elas sejam implementadas.
- Entradas:
- Grfico Burndown;
- Reunies Dirias (registro);
- Oramentos e Estimativas de Mudanas (registros).
- Resultados servem para:
- Controle de Mudanas atualizado;
- Product Backlog;
- Plano da Sprint;
- Meta da Sprint (Sprint Backlog);
- Plano do Projeto;
- Monitoramento e Controle;
- Status Report Semanal.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

29

Ferramenta / Artefato (ou Processo): Processos de Monitoramento e Controle (Guia PMBOK)


- Descrio: O Scrum avalia o que est acontecendo durante a execuo da Sprint, mas no os impactos gerados
pelos desvios dela no projeto como um todo. Desta forma,
as informaes geradas durante a execuo dos processos
iro alimentar os dados necessrios para o monitoramento
e controle do projeto.
- Entradas:
- Product Backlog;
- Plano da Sprint;
- Meta da Sprint;
- Reunies Dirias;
- Planilha de horas;
- Grfico Burndown;
- Controle de Mudanas.
- Resultados servem para:
- Status Report Semanal;
- Encerramentos;
- Aceites.
Ferramenta / Artefato (ou Processo): Processo de Encerramento (Guia PMBOK)
- Descrio: so os processos responsveis por obter os
aceites formais das entregas do projeto. Durante a execuo
dos processos de encerramento, tambm ocorre o evento
de lies aprendidas o qual, neste modelo hbrido, ser alimentado pelo resultado do evento Scrum Retrospectiva da
Sprint. Podem surgir solicitaes de mudana nos processos
organizacionais os quais sero tratados junto ao PMO (escritrio de projetos) para a devida avaliao e implantao
das mudanas propostas. Em alguns casos, os processos de
encerramento podem tambm servir para desalocar equipes,
encerrar contratos com fornecedores, etc.
- Entradas:
- Retrospectiva da Sprint (registro);
- Aceites;
- S o l i c it a e s d e Mu d a n a s n o s P r o c e s s o s
Organizacionais;
- Status Report Semanal;
- Grfico Burndown.
- Resultados servem para:
- Aceites (registros);
- Lies Aprendidas (registro);
- Atualizao de indicadores organizacionais;
- Solicitaes de Mudanas nos Processos Organizacionais (registro).

Processos geis e tradicionais funcionando juntos


Com as ferramentas, artefatos e processos apresentados,
iremos agora mostrar o funcionamento dos processos geis e
tradicionais de forma conjunta. A Figura 3 representa o paralelismo e a iterao dos processos. A partir de agora sero
apresentadas cada uma das etapas do processo definidas na
figura.

30

Contrato assinado
A aplicao deste modelo hbrido surgiu a partir de necessidades de empresas exclusivamente voltadas para o desenvolvimento de software. A assinatura do contrato significa que o
cliente est de acordo com as condies tcnicas e comerciais
oferecidas pela empresa que desenvolver o software.
Em termos gerais, antes do contrato ser gerado, houveram
etapas anteriores como gerao de proposta tcnica e comercial. A proposta tcnica demonstra o que ser feito, como, o
esforo necessrio e em quanto tempo ser produzido o escopo.
Para se gerar esta proposta, houveram reunies com o cliente
para o entendimento do escopo, as necessidades de negcio,
identificao dos itens mais estratgicos, bem como os itens
de maior valor agregado para o cliente. De posse destas informaes, a equipe tcnica reuniu-se para fazer suas avaliaes,
decomposies, oramentos de esforo e prazo, bem como
dependncias entre estrias e requisitos e, por fim, uma forma
de acomodar a produo do escopo dentro de uma linha do
tempo considerando a execuo das Sprints.
Considera-se uma boa prtica a apresentao da proposta
tcnica ao cliente (geralmente envolvendo a equipe tcnica
e usuria do cliente) de forma a validar se o entendimento e
a dinmica esto realmente de acordo com as expectativas.
Nenhuma quantidade, alm do prazo, deve ser mencionada
neste momento. Logo que a proposta tcnica for validada, a
equipe tcnica encaminhar todas as informaes geradas
como oramentos, estudos e outros artefatos produzidos para
a equipe comercial da empresa.
A proposta comercial toma como base a proposta tcnica e os
demais artefatos encaminhados transformando o esforo, knowhow, qualificao e capacidade da equipe, entre outras variveis,
no que podemos chamar de preo. Este preo o valor que o
cliente pagar pela execuo do servio de produzir o software
de acordo com suas expectativas. Normalmente, a proposta comercial prope uma forma de pagamento atrelada s entregas
do projeto, gerando um fluxo baseado nos aceites. Cada aceite
formalizado pelo cliente gera uma liberao de faturamento.
Diante do exposto, um Contrato um documento redigido
de forma jurdica, mas que tem por obrigao retratar todas
as condies tcnicas (Proposta Tcnica) e condies comerciais (Proposta Comercial). Ento assumimos, diante desta
dinmica de elaboraes das propostas tcnica, comercial e
do contrato, que o escopo do projeto justamente o escopo
descrito no contrato.
A assinatura do contrato, formalizando o aceite do cliente
das condies tcnicas e comerciais, o primeiro passo para
o incio do projeto. Por se tratar de uma questo jurdica,
envolvendo advogados e elaborao de outros documentos
acessrios o que geralmente consome muito tempo, bem
comum o cliente fornecer um aceite das propostas tcnica
e comercial para que seja dado incio ao projeto. Neste caso,
estamos assumindo que todo o trmite jurdico, comercial e
tcnico foram concludos com xito, permitindo assim que a
empresa d incio ao projeto.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

planejamento

Figura 3. Processos Scrum e PMBOK

Em paralelo assinatura do contrato, a empresa nomeia o


gerente de projeto e autoriza a mobilizao da equipe para
trabalhar. Este processo no coberto pelo Scrum, mas sim
pelo PMBOK no processo de Iniciao. Na Tabela 2 podemos
verificar, resumidamente, a relao do contrato assinado em
relao ao Scrum e PMBOK.
Item
Contrato Assinado

Scrum
No tem

PMBOK
Processos de Iniciao

Tabela 2. Contrato assinado e processos Scrum e PMBOK

Product Backlog escopo do projeto


O que est definido no contrato como escopo deve ser considerado como o Product Backlog do projeto acrescido da
priorizao dos itens listados. A priorizao fundamental
pois o cliente que sabe o que deve ser feito antes de outra
estria. Ela traduz a necessidade e estratgia do cliente em
termos comerciais ou organizacionais. O membro da equipe
responsvel por manter o Product Backlog atualizado e centralizar as informaes sobre as regras de negcio das estrias
e do objetivo do produto o Product Owner.
O Product Backlog servir de base em todo o ciclo de vida
do projeto, do incio ao fim, servindo para estruturar o

planejamento das Sprints e o monitoramento do projeto como


um todo dentro dos processos do Scrum. O planejamento da
Sprint sempre dever ser feito contando com a equipe, o Scrum
Master e o Product Owner. A participao do gerente de projeto
e do cliente tambm pode ocorrer, mas no so mandatrias,
desde que haja uma maneira clara e eficaz de se repassar o
plano da sprint s partes interessadas integralmente.
Para o Guia PMBOK, no existe o termo Product Backlog, mas
sim escopo. O grupo de processos de planejamento prev o planejamento de todas as reas de conhecimento representando
sempre a pergunta Como sero gerenciados escopo, prazo,
custo, riscos, comunicaes, stakeholders, etc. produzindo o
plano de projeto?
O plano de projeto poder ser definido a partir do contrato
considerando pontos que no so objetivo do Scrum, porm so
imprescindveis para o Cliente tais como controle do escopo,
monitoramento e controle, Comunicaes, etc. Na Tabela 3
podemos verificar a relao do Product Backlog com o Scrum
e o guia PMBOK.
O prximo passo para a equipe montar o quadro Kanban
(Figura 1) e comear os trabalhos. Deve-se mover os post-its
das estrias pertencentes ao Sprint Backlog para a coluna Em
Andamento para indicar que os trabalhos foram iniciados.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

31

Item

Scrum

Processo de planejamento da
Product Backlog
Sprint (Sprint Plan)

PMBOK
No utilizado desta forma, sendo assim,
sofrer adaptaes para ser aplicado no
processo de planejamento do projeto
(Escopo)

Tabela 3. Product Backlog e processos Scrum e PMBOK.

Em algumas empresas comum haver uma coluna adicional


para abrigar o Product Backlog inteiro, movendo os post-its das
estrias a serem produzidas na Sprint para a coluna Sprint
Backlog. Para alguns, esta prtica ajuda a manter a visibilidade
do escopo a ser entregue integralmente. Esta uma prtica
opcional e pode ser adotada desde que venha de encontro com
os valores culturais da organizao.

Sprint Mos obra e o uso do Quadro Kanban


O formato de uma Sprint no varia muito, mas pode (e deve)
ser adaptado para melhor desempenho e aderncia cultura da
empresa. Existem empresas que prezam por seus indicadores e
a metodologia Scrum no os descarta. Existem aqueles os quais
pensam que ele contra documentao, e este um grande
engano, mas o Scrum preza pela gerao da documentao
necessria, sem excessos, uma documentao clara e objetiva
para auxiliar a equipe a produzir o que foi solicitado, dentro
das expectativas.
No presente cenrio apresentamos alguns eventos importantes para auxiliar a equipe a manter o controle do desempenho da Sprint (lembrando que a equipe auto organizada
e multidisciplinar):
Realizao do trabalho: o trabalho realizado por cada um;
Atualizao da planilha de horas: sempre bom saber
quanto de esforo foi gasto para produzir o Sprint Backlog;
Atualizao do grfico Burndown: a partir da atualizao
da planilha de horas possvel verificar o quanto o andamento
da Sprint est ou no conforme o planejado;
Reunio diria: cada membro da equipe responde s trs
perguntas bsicas: O que foi feito? (Desde a ltima reunio diria), O que ser feito em seguida?, e Existem Impedimentos? Durante a reunio diria, deve-se observar a evoluo do
grfico Burndown atualizado. Atravs desta prtica, a equipe
poder detectar desvios e promover estratgias para correo
deles retomando a Sprint ao seu planejamento inicial.
Conforme o andamento dos trabalhos, as estrias que foram produzidas precisam de validao. Sugere-se que este
processo de validao ocorra, pelo menos, em trs momentos:
teste unitrio, teste integrado e aceite do usurio. Estas trs
etapas aumentam as chances de sucesso da entrega. Sendo
assim, conforme as estrias forem concludas pela equipe de
desenvolvimento, deveremos mover os post-its das estrias da
coluna Em Andamento para a coluna Em validao no quadro
Kanban (Figura 1).
neste ponto onde devemos abordar o chamado Conceito de
Pronto. Deve-se, antecipadamente, estabelecer o estado em que

32

uma estria ser considerada pronta. Por exemplo: uma estria


s ser considerada pronta aps ter sido validada pelo cliente.
Estabelecer o conceito de pronto muito importante para que
no haja falsas expectativas. Se a regra do pronto no for estabelecida, o cliente pode intuir que s estar pronto quando
o software gerado estiver disponvel em sua infraestrutura e
acessvel aos usurios. Esta ideia pode gerar diversos problemas e at prejuzos uma vez que a disponibilizao do software
possui uma dependncia externa junto equipe de TI do cliente
a qual poder possuir prazos totalmente fora da realidade da
Sprint, inviabilizando assim o cumprimento da meta.
Desde que haja um entendimento prvio e o cliente permita
esta dinmica, o conceito de pronto poder ser modificado
para atender s suas necessidades. Tais condies devem ser
estabelecidas ainda na fase de proposta tcnica e comercial de
forma a serem refletidas no contrato.
Conforme o resultado do processo de validao e o aceite do
cliente, o post-it da estria poder ser movido da coluna Em
Validao para a coluna Entregue.
Quando surgirem problemas os quais dificultem a concluso
do desenvolvimento de uma estria, a equipe dever reportar
ao Scrum Master a ocorrncia registrando assim o chamado
Impedimento. Caber ao Scrum Master acionar os meios
necessrios para a resoluo, o mais breve possvel, deste
impedimento. Para resoluo de um impedimento podem
ser envolvidos desde o Product Owner at mesmo o cliente.
O importante que o impedimento seja removido. Para estas
situaes, o membro da equipe dever mover o post-it da estria da coluna Em Andamento ou Em validao para a coluna
Impedimento no Quadro Kanban. Ao fazer isso, o impedimento
ficar visvel e dever permanecer nesta coluna Impedimento
at a sua resoluo.
Outro fator importante para se garantir um bom andamento
do desenvolvimento o envolvimento ativo do cliente durante
todo o processo da Sprint. Este envolvimento ir ajudar a esclarecer dvidas e promover um alinhamento maior com as
expectativas do cliente. Sem contar que, quando ele participa
ativamente do processo, as mudanas tambm podem vir a
surgir de forma mais evidente. Assim, preciso manter o estabelecido no Sprint Backlog, mantendo um dilogo aberto e
transparente com o cliente, caso as mudanas gerem impactos
significativos. Se ocorrer uma mudana, esta dever ser avaliada antes de ser considerada automaticamente inclusa sem
que sejam verificados todos os impactos.
Em algumas empresas, comum considerar uma mudana
como um Impedimento e trat-la como tal. Isto significa que
o post-it da estria que recebeu a solicitao de mudana ser
movido da coluna Em Andamento ou Em Validao para a coluna
Impedimento no quadro Kanban at que se obtenha uma deciso
sobre a execuo, ou no, da mudana.
Outra caracterstica importantssima na adoo de um
modelo hbrido de gesto a chamada blindagem da Sprint.
Blindar a Sprint significa dizer que as interaes com o cliente
so exclusivamente voltadas produo do software contratado. Questes como comunicao com o cliente e partes

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

planejamento

interessadas, discusses sobre mudanas solicitadas, pagamentos, gerao de relatrios, entre tantas outras atividades que
so naturalmente desempenhadas pelo gerente de projetos,
no afetam o bom andamento da Sprint, mantendo-a isolada,
ou melhor, mantendo a Sprint blindada contra interaes
desnecessrias produo do software.
Na Tabela 4 podemos verificar, resumidamente, a relao da
Sprint em com o Scrum e o guia PMBOK.
Deve-se publicar o Sprint Backlog e torn-lo visvel para todos
os interessados. Isso pode parecer redundante uma vez que
haver um quadro Kanban contendo esta informao, porm,
alguns detalhes ou documentos acessrios que auxiliaram na
definio do Sprint Backlog podem ter sido utilizados e de
extrema valia que estas informaes estejam acessveis. Existem empresas as quais possuem a prtica de imprimir a estria
e anexar no Quadro Kanban de forma a facilitar o acesso aos
detalhes e tirar dvidas.
Outra sugesto de boa prtica a realizao de uma reunio
de kick-off de forma a alinhar todos da equipe, cliente e at
mesmo da empresa sobre a Sprint que ser iniciada (seus
objetivos, durao e quais sero as atividades envolvidas).
Para alguns especialistas, uma reunio de kick-off reafirma
o comprometimento da equipe quanto ao resultado esperado
para a Sprint.

Status Report Semanal Dando visibilidade do


andamento ao cliente
O relatrio de status report considerado uma fotografia da
situao do projeto naquele momento em que foi tirado. uma
das principais ferramentas de comunicao adotado pelo guia
PMBOK. atravs da comunicao do status report do projeto
ao cliente e partes interessadas que se pode ter uma viso consolidada do andamento do projeto. Recomenda-se que ele seja
entregue e explicado durante uma reunio de acompanhamento
semanal junto ao cliente. Esta reunio permitir que o gerente de
projetos explique a situao do projeto e, em caso de problemas,
enderece solues para riscos e impedimentos. Somente aps
a reunio, a cpia do status report semanal dever ser encaminhada por meio eletrnico (e-mail) ou fsico.
Item

Sprint

Scrum

O contedo de um status report pode variar conforme a


necessidade e a cultura da empresa, mas basicamente contm:
a situao do projeto (atrasado, adiantado ou no prazo comparado com o planejado), as realizaes do perodo versus o
planejamento, e anlise de riscos. Existem diversos modelos
de relatrio de status report semanal bem como existem status
report mensais em forma de um resumo executivo. Enfim, a
adoo de um modelo ou de outro depende exclusivamente
da cultura da empresa.
Vale lembrar que o guia PMBOK no uma metodologia,
ou seja, no determina como e/ou o que deve ser feito, mas
sim, que deve existir uma forma de controlar ou registrar
determinado processo. O uso de maior ou menor quantidade
de informao depender da necessidade e da capacidade de
gerar a informao. Toda e qualquer informao a ser divulgada dever possuir uma fonte a qual, preferencialmente, deve
ser automatizada ou eletrnica, evitando dispndio de horas
desnecessrias.
Para elaborao do status report semanal, o gerente de projeto poder captar as informaes registradas nas reunies
dirias e no grfico de burndown. Caso seja necessrio um
controle de custos, a planilha de horas aliada ao cronograma
do projeto podero demonstrar indicadores como CPI (Cost
Performance Index) e o SPI (Schedule Performance Index) que so,
respectivamente, os indicadores de custo e prazo calculados
a partir da quantidade de horas apontadas e o percentual de
concluso.
O status report semanal um entregvel e, portanto, sugerese que seja recebido e aceito pelo cliente atravs de assinatura.
Mesmo soando burocrtico, este ato de aceitar ou rejeitar o
status report semanal pode auxiliar na resoluo de conflitos
ou desalinhamento de expectativas de ambas as partes. Em
algumas empresas, o status report semanal tambm considerado como um aceite parcial caso sejam listadas as entregas
realizadas no perodo.

Sprint Review Entregando ao cliente


Aps todo o trabalho estar concludo, conforme o conceito
de pronto estabelecido, chega o momento de apresentar ao
PMBOK

Dos ritos e eventos do Scrum, sero aproveitadas as informaes da execuo da Sprint geradas principalmente nas
reunies dirias e no grfico de Burndown para alimentar os artefatos do processo de monitoramento e controle. No se
limitando a somente estas, mas, principalmente:
Controle de Riscos (Impedimentos);
Controle de Prazo
Processo de execuo da Sprint, no qual o produto ser Controle de Custos
construdo a partir do estabelecido no Sprint Backlog.
Controle de Escopo
Controle de Mudanas
Controle de Qualidade
Entre outros;
A utilizao destes processos do Guia PMBOK so facultadas cultura da empresa a qual considerar relevante, ou no,
estes controles.

Tabela 4. Sprint e os processos Scrum e PMBOK

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

33

cliente o que foi realizado de uma forma integrada. Sugere-se


uma reunio formal onde a equipe e o cliente iro demonstrar
todo o conjunto de software produzido funcionando. Deve-se
aplicar a ltima verso do software produzido em um ambiente
destinado homologao, apartado do ambiente de desenvolvimento afim de garantir o isolamento e funcionamento
do software.
Nesta reunio, o cliente dever fornecer o aceite formal das
entregas realizadas considerando a Sprint como concluda.
O registro atravs de algum meio como ata, ou at mesmo um
e-mail, deve ser gerado afim de comunicar o resultado final
da Sprint s partes interessadas.
De posse deste aceite e do registro da reunio de Sprint Review,
o gerente de projeto poder acionar os processos de encerramento, atualizando os registros e indicadores do projeto e emitindo,
quando necessrio, um informe em formato especfico quanto
a finalizao da Sprint e da respectiva fase estabelecida no contrato. A equipe Scrum dever prosseguir para o prximo passo
de encerramento a retrospectiva da Sprint.
Na Tabela 5 podemos verificar a relao da concluso da
Sprint atravs da reunio de Sprint Review realizada junto
ao cliente. Essa reunio um evento exclusivo do Scrum, mas
que gera informaes para os processos de encerramento do
guia PMBOK.

Retrospectiva da Sprint Como foi o andamento do


trabalho?
Aps a concluso da Sprint Review, onde o cliente aceitou
o software entregue e emitiu o aceite das entregas, chega o
momento da equipe se reunir e avaliar como foi o andamento
do trabalho durante a execuo da Sprint.
Trata-se de um ritual de maturidade e melhoria contnua
onde todos devem participar e expor suas opinies respondendo a trs perguntas bsicas: O que foi bom nesta Sprint
e deve ser mantido para as prximas Sprints?, O que pode
ser melhorado para as prximas Sprints? e, O que deve ser
abolido das prximas Sprints?.
Item
Sprint Review

Scrum

PMBOK

Os aceites obtidos durante a Sprint


Processo de Entrega da Sprint
Review sero absorvidos pelo Processo de
(Sprint Review) resultado
Encerramento Encerrar Fase ou Projeto.

Tabela 5. Sprint Review e processos Scrum e PMBOK

A equipe poder tomar como base o grfico de Burndown e os


registros das reunies dirias em busca de um resumo para responder s trs perguntas da retrospectiva da Sprint. Percebam
que as perguntas esto focando sobre os processos de trabalho
para a realizao das Sprints. Isto significa que devem surgir
solicitaes de mudana para a execuo das prximas.
Em empresas que possuem um escritrio de projetos (PMO)
ou um grupo voltado para os processos, so estes departamentos ou grupos os quais recebero tais solicitaes. Eles
so institudos para estabelecerem suas formas de trabalho e
os processos a serem definidos e seguidos. Geralmente, nestas
empresas existem auditorias peridicas para a verificao se
os processos esto sendo executados conforme o estabelecido.
Comumente so membros de outros departamentos e at
empresas externas que executam tais auditorias. Modelos de
maturidade e normas de qualidade exigem a realizao destas
auditorias de maneira a garantir que os nveis de maturidade
esto sendo mantidos, verificados e evoludos.
Para tanto, a atuao destes departamentos dever ser muito
gil em funo de que uma nova Sprint est prestes a comear
assim que a reunio de retrospectiva for concluda. A forma
de trabalho da prxima iterao depender da aprovao das
solicitaes encaminhadas pela equipe aps a reunio. extremamente salutar que os representantes destes departamentos
estejam presentes na reunio de maneira que deem os devidos
encaminhamentos para implementar as mudanas solicitadas
para que no ocorra a incidncia de no conformidades de
processos durante as auditorias peridicas.
Na Tabela 6 podemos verificar a relao da concluso da
reunio de retrospectiva da Sprint realizada pelos membros
da equipe. O cliente e os grupos ou departamentos de PMO
ou de processos tambm podem participar. A reunio de
retrospectiva um evento exclusivo do Scrum, porm, com
grande aderncia ao processo de lies aprendidas proposto
pelo guia PMBOK durante a execuo dos processos de encerramento do projeto.

Processos de encerramento
Os processos de encerramento sugeridos pelo guia PMBOK
tratam do encerramento de uma fase ou do projeto. Este encerramento depende de uma formalizao dos respectivos aceites
emitidos pelo cliente. Nestes aceites, o cliente entende que
recebeu o que foi contratado (escopo no contrato) e as entregas
atendem aos requisitos de qualidade estipulados.

Item

Scrum

PMBOK

Retrospectiva da Sprint

Processo de Retrospectiva da Sprint demonstrar,


de forma sinttica, como foi o andamento da Sprint,
o que foi bom, o que pode ser melhorado e o que
deve ser abolido em termos de processos.
A velocidade da Sprint tambm pode ser considerada
registrando-se os tempos de construo das estrias.
Tal informao fundamental para a emisso de
oramentos futuros, servindo como referncia.

O artefato similar no guia PMBOK o de lies aprendidas, pertencente ao grupo de processos de encerramento. Desta forma,
com pequenos ajustes, o gerente de projetos poder se valer destas informaes para o preenchimento deste artefato.
A performance da Sprint pode e deve alimentar os registros organizacionais de forma a gerar dados histricos e comparativos
para futuros projetos.
Com relao s solicitaes de mudana dos processos, tambm dever se buscar uma maneira eficiente junto ao PMO
de forma a garantir a adaptabilidade dos processos da forma mais gil afim de garantir maior performance nas prximas
iteraes.

Tabela 6. Retrospectiva da Sprint e processos Scrum e PMBOK

34

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

planejamento

Em funo de estarmos utilizando um modelo hbrido de


gesto, se faz necessrio perceber onde estes aceites sero
emitidos e assinados. Por ser uma metodologia gil, o Scrum
estabelece que toda entrega validada junto ao cliente aceita e,
ao final da Sprint, o resultado formalizado atravs da reunio
chamada Sprint Review. Tanto em uma entrega parcial quanto
na Sprint Review, os aceites sero obtidos pela equipe Scrum
e remetidos ao gerente do projeto.
De posse dos aceites recebidos, o gerente de Projetos poder
formalizar o encerramento da fase ou do projeto. Na maioria
das vezes este aceite est vinculado liberao de pagamento
do cliente para a empresa. Ento, caber ao gerente dar os devidos encaminhamentos internos tanto para o pagamento quanto
para alimentar os arquivos e registros organizacionais.
A Figura 3 apresenta uma viso resumida da adoo do
chamado modelo hbrido de gesto, unindo os pontos fortes
da metodologia gil Scrum e do guia PMBOK do PMI. Demonstramos nesse artigo a viabilidade da adoo deste modelo.
Alm da viabilidade, nota-se alguns ganhos como reduo de
controles e gerao de informaes, tudo ocorrendo de forma
mais gil e com equipes melhor dimensionadas.
Foi enfatizado tambm a atuao dos papis de gerente de
projeto e Scrum Master, to facilmente confundidos pelas
empresas e pessoas ainda no familiarizadas com os mtodos
apresentados. Alm disso, o modelo possibilita uma construo de software mais blindada contra fatores externos e no
relacionados sua produo.
Existe uma grande tendncia na especializao de gestores
utilizando-se de modelos hbridos de gesto, no se restringindo gesto de projetos, mas tambm gesto de TI aliando a
biblioteca ITIL e a Cultura DevOps. A procura deste perfil de
profissional se tornar mais intensa em um futuro prximo.

Da mesma forma que os mtodos geis surgiram e j demarcam seu espao nas empresas e organizaes, a adoo
dos modelos hbridos tambm demonstra que veio para ficar
pois une os pontos fortes de todas as metodologias e guias
permitindo aos gestores definir um modelo de gesto gil,
documentalmente estruturado, eficiente, eficaz e j bem aceito
em modelos de maturidade como o MPS.BR e o CMMI.
Links:
Grfico Burndown
http://blog.myscrumhalf.com/2012/01/burndown-chart-medindo-o-progresso-de-suasprint-e-trazendo-indicativos-do-processo-de-trabalho-da-equipe/
Livro Scrum e PMBOK: unidos no Gerenciamento de Projetos
http://www.brasport.com.br/gerenciamento-de-projetos/metodologia/scrum-epmbok-unidos-no-gerenciamento-de-projetos/
A Guide to the Project Management Body of Knowledge (PMBOK Guide)
Fifth Edition Project Management Institute (PMI)
http://www.pmi.org/pmbok-guide-and-standards/pmbok-guide.aspx
Guia do Scrum
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
Papis do Scrum
http://pt.slideshare.net/ScrumHalf_GPE/papeis-scrum-faq

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

35

Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros

Gerncia de mudanas utilizando Git


Uma abordagem simplificada para implantao de um sistema de controle
de verses
Fique por dentro:

lex Leocdio Jlio


Graduado em Cincia da Computao pela
Universidade Federal de Viosa. Atualmente
trabalha com gerenciamento de mudanas
em projetos Android.

36

processo de desenvolvimento
de software, desde o surgimento da proposta at a concepo
final do sistema, pode se tornar muitas
vezes uma tarefa longa e rdua devido
no utilizao de tcnicas fundamentais
de engenharia de software. Isso pode
acontecer, por exemplo, devido ao desconhecimento da equipe da existncia
de tais mtodos. Neste cenrio se enquadram aqueles que esto comeando
na rea de tecnologia, ou seja, pela
inexperincia da equipe em saber definir
quais metodologias devem ser aplicadas
e em qual momento. Da mesma forma, o
foco exacerbado em metodologias e na
aplicao destas puramente da forma
expressa nos livros torna o processo
enfadonho e lento.
A engenharia de software tem como
desafio demonstrar a necessidade de

Abordaremos uma viso geral sobre a gesto de


mudana, apresentando seu conceito e elucidando as facilidades trazidas atravs de sua utilizao. Alm disso, iremos exemplificar, de maneira
prtica, como implantar um sistema controle
de verso para pequenos projetos utilizando o
servio de hospedagem Bitbucket e o sistema de
controle de verses Git. Este artigo til porque,
para qualquer projeto de software onde h mais
de uma pessoa envolvida, a gerncia de mudanas uma necessidade. J realizou alteraes
em seu cdigo para realizar algum teste e no
conseguiu retornar ao ponto em que estava? J
teve seu cdigo sobrescrito por algum da equipe? Tem dificuldade em lembrar quando e por
quem alguma alterao foi feita? Se sua resposta
sim para qualquer uma destas perguntas, ento este artigo essencial.

etapas bem definidas no processo de


desenvolvimento, produzindo assim
softwares com qualidade superior, mas
estes processos devem estar adaptados
realidade da equipe e projeto.
Sabendo disso, iremos introduzir os
conceitos da gerncia de configurao voltado para equipes reduzidas e

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

en gen haria

projetos de pequeno porte. Projetos onde os papis assumidos


por cada membro da equipe no so nicos e funes so
acumuladas. Ao final desta leitura, esperamos que voc esteja
apto a implantar um sistema de controle de verses em seus
projetos. Iremos, primeiramente, definir o que a gerncia
de mudanas e demonstrar sua importncia no processo de
desenvolvimento de software. Em seguida, vamos apresentar
o Git como um sistema de controle de verses e ensinar o
fundamental para que seja possvel dar os primeiros passos
na utilizao dessa formidvel ferramenta.

A origem da demanda

Inicialmente necessrio entender o significado do
termo configurao do sistema. Podemos dizer que gerenciamento de configurao nada mais do que controlar a evoluo
do sistema e dos produtos gerados, tanto cdigos-fonte quanto
documentos ou quaisquer outros elementos adicionados.
Tomada essa definio, imagine agora que daremos incio
a um projeto de um sistema. Como exemplo, consideremos
um website, e, para executar esse projeto, iremos contar com
a ajuda de mais uma pessoa trabalhando no mesmo ambiente
em que ns, na mesa nossa frente. Talvez, neste contexto, o
gerenciamento de mudanas no se faa to necessrio, uma
vez que possvel que ns e nosso companheiro de projeto
tenhamos total controle sobre o que acontece, quanto aos arquivos que foram modificados ou bugs que foram consertados.
Em cenrios como esses, o que vemos so as pessoas utilizando
formas bem particulares de gerir as mudanas, executando
essa tarefa muitas vezes de forma inconsciente.
Agora tomemos um cenrio bem distinto do anterior. Suponha o desenvolvimento de um sistema amplo, com centenas
de funcionalidades, para uma empresa multinacional, onde a
equipe escalada para seu projeto e desenvolvimento composta de dezenas de pessoas, cada uma delas especializada em
uma rea de conhecimento, tanto funcional quanto tcnica.
Neste contexto, a equipe sequer trabalha no mesmo pas.
Como trabalhar de forma paralela sem sobrescrever cdigos
de outros membros? Como saber quais alteraes foram feitas?
E quando? Por quem?
Como se pode perceber, so muitas as perguntas a serem
respondidas e sem a automatizao desses controles seria
impossvel responder a cada uma destas questes e outras
tantas que surgem durante o processo de desenvolvimento
de software.
Para o nosso exemplo prtico, que ser explicado mais a
frente, usaremos um meio termo entre o primeiro e o segundo cenrios citados: um projeto em que podemos resumir o
gerenciamento de configurao ao controle de verses dos
arquivos de projeto.

Sistemas de controle de verso


Chamamos de controle de verso um sistema capaz de registrar as mudanas efetuadas em cada arquivo ao longo do tempo
e, o mais importante, de forma que seja possvel recuperar
uma verso especfica dele. Alm disso, outras informaes

teis podem ser extradas a partir de um sistema de controle


de verso (SCV). Atravs de um SCV podemos ver, por exemplo, quem alterou certo trecho de cdigo e em que momento,
comparar duas verses distintas e verificar as diferenas entre
elas ou reverter todo um projeto a um estado anterior onde
certo bug no ocorria.
Os SCV podem ser categorizados de trs formas:
Sistemas de controle de verso locais: provavelmente j utilizamos esse mtodo sem saber que fazamos uso de um SCV.
Quando se cria uma cpia de um arquivo para um outro diretrio
com o intuito de preservar tal arquivo, ns estamos realizando
um controle de verso. Este mtodo to simples e amplamente
utilizado pode ser eficiente em alguns cenrios de trabalho,
porm muito suscetvel a falha. Algum poderia esquecer de
fazer a cpia de alguma das verses, sobrescrever alguns arquivos
acidentalmente, ou ainda, deletar alguma verso anterior. Para
automatizar este processo foram desenvolvidos sistemas de controle de verso, que armazenavam todas as alteraes;
Sistemas de controle de verso centralizados: essa soluo
surgiu, principalmente, para atender a demanda do trabalho
em conjunto. Nesse modelo, como o prprio nome sugere,
h um servidor central com o versionamento dos arquivos e
cada um dos clientes desse servidor podem fazer cpias da
verso desejada. Ao ato de realizar uma cpia dos arquivos
versionados, seja fisicamente ou virtualmente, d-se o nome
de checkout. Utilizando-se deste sistema, cada integrante da
equipe pode ter uma viso geral do projeto, tornando mais
fcil administrar o trabalho como um todo. Em contrapartida,
utilizar um servidor central leva a ter um nico ponto de falha.
Um servidor sem um bom sistema de backups ou que tem o
servio interrompido vrias vezes e por muito tempo, poderia
ter como consequncia a perda de informaes e de tempo de
trabalho dos colaboradores.
Sistemas de controle de verso distribudos: tal modelo
surgiu para suprir a principal deficincia dos sistemas centralizados a falha do servidor central. Desta forma, o que
temos nos sistemas distribudos so os clientes fazendo cpias
completas do repositrio, tornando cada checkout um backup
completo de todos os dados, conforme ilustrado na Figura 1.
Os dois primeiros modelos de sistemas, apesar de ainda
utilizados, no so o foco deste artigo. Por isso, no nos prolongamos em suas descries, apresentando apenas uma viso
geral de cada um. A partir de agora vamos nos ater aos sistemas
distribudos, utilizando o Git para exemplificar e introduzir
os conceitos bsicos do controle de verses de maneira prtica
atravs desta poderosa ferramenta.

Comeando com o Git


Primeiramente, vamos mostrar como realizar a instalao e
configurao do Git (no ambiente Windows) e, mais a frente,
aps nosso ambiente estar devidamente configurado e integrado ao servidor, vamos abordar as principais caractersticas de
um SCV distribudo, fornecendo exemplos prticos de como o
Git trata cada uma delas.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

37

ao fato do SSH permitir a leitura e a escrita em um servidor


de forma autenticada, alm de ser relativamente simples de
configurar.
Para ter acesso a um repositrio remoto via SSH ser necessria uma chave pblica para autenticao. Executando o
comando ssh-keygen, um diretrio chamado .ssh ser criado
em sua home e dentro deste sero criadas uma chave privada e uma chave pblica (.pub). Ao executar o comando ser
questionado se necessria uma senha. Deixe em branco caso
no deseje autenticar toda vez que for preciso utilizar a chave.
A chave pblica ser inserida em nosso repositrio remoto, o
qual iremos criar e configurar mais adiante.
Na seo Links h um tutorial completo demonstrando o processo de criao de chaves SSH, caso encontre dificuldade.
Nota. Documentao do Git
Figura 1. Estrutura de acesso para um sistema de controle de verso
distribudo

Para realizar a instalao do Git basta rodar o arquivo .exe


disponvel no site oficial (ver seo Links) e seguir as instrues
de instalao. As nicas opes que sero necessrias alterar
para nosso treinamento so as de ajuste de ambiente. Iremos
optar por integrar os comandos Git ao prompt de comando
do Windows.
Aps a instalao, teremos uma verso de linha de comando,
que ser a que utilizaremos, e uma verso GUI.
O primeiro passo ser realizado com o Git em nosso sistema
realizar a configurao do usurio. Tais configuraes so
salvas no arquivo .gitconfig na home de seu usurio e sero
utilizadas para identificar o responsvel por cada alterao
realizada no projeto, conforme vemos no cdigo a seguir:

O Git possui uma infinidade de comandos e argumentos. Neste artigo apresentaremos


comandos bsicos para utilizao e muito importante que o leitor consulte a documentao
oferecida para entender mais sobre os comandos disponveis. O endereo para acess-la pode
ser encontrado na seo Links.

Criando um projeto no Bitbucket


Como opo para servio de hospedagem aos repositrios do
projeto utilizaremos o Bitbucket, pois este oferece uma opo
de servio gratuito com excelente suporte ao trabalho com Git.
Uma alternativa ao uso do Gitbucket o GitHub, porm este s
oferece planos gratuitos para projetos de cdigo aberto.
Para iniciarmos, crie uma conta no Bitbucket optando pelo
plano que d suporte a um time de at cinco usurios, uma vez
que nosso grande objetivo criar um projeto compartilhado.
Aps criar uma conta, voc tambm dever criar um time e
adicionar os membros que faro parte dele (Figura 2), sendo

git config --global user.name nome


git config --global user.email nome@email

O parmetro --global permite que


se realize a configurao apenas uma
vez, assim esses valores sero sempre
utilizados pelo Git. Caso seja necessrio
atribuir outros valores s variveis de
configurao para um projeto especfico,
deveremos executar os comandos sem
esse parmetro, com isso, seria criado
dentro do projeto o arquivo .git/config
com informaes que sobrescrevem as
configuraes globais.
Uma vez que nosso objetivo criar
um projeto colaborativo, precisaremos
ter um repositrio remoto, para o qual
deveremos estar aptos a enviar (push) e
receber alteraes (pull). A nossa comunicao com o repositrio se dar atravs
do protocolo SSH. Esta escolha se deve

38

Figura 2. Criando time e adicionando membros

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

en gen haria

que todos os membros tambm devem


possuir uma conta para serem includos
ao projeto. O usurio que cria o time ter
permisso de Administrador e ser responsvel pela atribuio das permisses
para os demais membros.
Agora que j temos um time formado, vamos criar um repositrio (Figura 3) atravs
da opo Create a new repository. Este ir
armazenar nossos cdigos, documentos
e o que mais for necessrio ao projeto. O
acesso a esse repositrio, tanto para leitura
quanto para escrita, se dar atravs do Git
para cada membro do projeto.

Uma vez estruturada a equipe, ser necessrio cadastrar no servidor as chaves


pblicas geradas por cada membro, pois,
como dito anteriormente, a comunicao
entre cada estao de trabalho e o repositrio remoto se dar atravs do protocolo
SSH. Este protocolo ser responsvel
pela segurana de permisso de leitura
e escrita apenas aos desenvolvedores
devidamente autorizados.
A Figura 4 mostra como realizar o cadastro das chaves, que dever ser feito
pelo Administrador do time atravs das
suas configuraes de conta.

Figura 3. Criando repositrio do projeto

Figura 4. Adicionando chaves SSH dos membros do time

Pronto! Nosso ambiente de trabalho


est montado. Agora iremos demonstrar
como esse simples processo construdo
permite, funcionalmente, realizar o gerenciamento de mudanas. Alm disso,
vamos explorar na prtica as funcionalidades do Git para realizar o controle
de verso.

Git na prtica
At este momento ainda no mostramos como um SCV funciona na prtica
e nem como o Git implementa estas
funcionalidades. A partir de agora veremos como ser possvel trabalhar de
maneira colaborativa, segura e controlada atravs da implantao deste fluxo
de trabalho.
Para darmos incio ao desenvolvimento do nosso projeto, tomando o ponto
de vista de um desenvolvedor, ser
necessrio obter o projeto Git, o que
ser feito clonando o projeto existente
no servidor.
Clonar um projeto nada mais do que
obter do servidor cada arquivo e cada
histrico j registrado. Logo, por ser uma
cpia exata das informaes contidas no
servidor, caso o mesmo seja perdido ou
corrompido, poderemos restabelecer o
projeto reavendo o servidor atravs de
um dos clones.
Clona-se um repositrio atravs do comando git clone <url>. No nosso exemplo,
obtm-se o comando na home do projeto
criado no Bitbucket, que oferece a clonagem HTTPS e SSH, sendo esta a utilizada.
Assim, cada desenvolvedor far git clone
git@bitbucket.org:gitdevmedia/<seu_projeto>.git, trazendo para a sua estao de
trabalho uma cpia do servidor dentro
do diretrio com o nome do projeto Git
(ver Figura 5).
Agora que temos um diretrio vazio
conectado ao servidor, iremos comear
a manipular os arquivos de projeto e
controlar a implementao. Para exemplificar o funcionamento, adicionamos
ao diretrio clonado uma estrutura
de pastas e arquivos como exibido na
Figura 6. A partir daqui, pode-se adicionar outros tipos de arquivos ou j adicionar os arquivos de um projeto real.
evidente que cada um dos arquivos
que foram adicionados no diretrio local

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

39

ainda no est disponvel no servidor.


Na verdade, sequer foram consolidados
pelo Git localmente. Ao ato de salvar
estas informaes damos o nome de
commit.
O Git trata os dados salvos como
um conjunto de snapshots (como uma
foto), retratando o status do sistema em
determinado instante. Assim que a clonagem do projeto foi realizada, como
se tivesse uma foto vazia e cada commit
que realizarmos ser como uma nova
foto sendo tirada.
O Git atribui a um arquivo, um entre
trs estados possveis:
consolidado (commited): que so os
arquivos salvos;
modificado (modified): no qual se
encontram os arquivos no consolidados
na base de dados do Git;
preparado (staged): quando determinado arquivo foi modificado na verso
corrente e se deseja que ele faa parte do
prximo commit.
Agora, utilizando os arquivos adicionados, podemos navegar entre estes trs
estados e determinar como desejamos salvar as mudanas realizadas no projeto.
Primeiramente devemos estar aptos a
identificar em qual estado se encontram
os arquivos. Para isso utilizamos o comando git status. Executando em nosso
exemplo, obteremos o resultado mostrado na Figura 7 e, conforme podemos
observar, nossos arquivos se encontram
untracked, o que significa que no
esto preparados para entrar no prximo commit. Entretanto, o prprio Git j
informa como preparar nossos arquivos
atravs do comando git add.

Figura 5. Clonagem do projeto do Bitbucket

Figura 6. Exemplo de estrutura de arquivos de projeto

Nota. Mensagens do Git


muito importante que as mensagens retornadas pelo
Git sejam lidas para entender qual o prximo passo a ser
realizado. Apenas aprendendo a l-las e a interpret-las
estaremos aptos a explorar o mximo da ferramenta.

Figura 7. Arquivo README.txt sendo preparado para o commit

Preparados os arquivos que desejamos adicionar ao prximo snapshot,


devemos executar o comando git commit
m <mensagem> para que o Git salve
as informaes. Atente-se em sempre
utilizar uma mensagem de commit que

40

seja explicativa quanto s alteraes que


foram salvas para facilitar o entendimento do que foi realizado. Alm disso,
certifique-se de realizar o commit de todos os arquivos necessrios ao projeto.
Aps realizar as alteraes desejadas
em seus arquivos e consolid-las atravs

dos commits, de se esperar que se queira ver o histrico de alteraes, afinal de


contas uma das necessidades supridas
pelo controle de verso dizer quando
e por quem uma mudana foi realizada.
Para consultar a lista de commits execute
o comando git log.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

en gen haria

Ao fazer isso, as informaes de commit sero exibidas em ordem cronolgica


inversa.
Para exibir o diff introduzido em cada
commit podemos executar o comando de
log com o argumento p. Esta apenas
uma das diversas opes teis para levantar informaes histricas do projeto.
Explore a documentao para conhecer
mais argumentos.
Agora que todas as alteraes necessrias foram salvas em seu repositrio
local, devemos disponibilizar tais
mudanas aos demais integrantes da
equipe. Para isso, iremos realizar o
upload dos commits para o nosso servidor remoto atravs do comando git
push <remote> <branch_remoto>, onde
<remote> o endereo do nosso servidor
remoto e este nomeado como origin por
default pelo Bitbucket. Utilize git remote

Figura 8. Listagem de commits

Figura 9. Servidor com diversos branches

v para atestar o mapeamento para o


servidor. Por hora, vamos executar git
push origin master para realizar o upload
para o branch master.
Acabamos de realizar um envio de
verso ao servidor. Se navegarmos pela
interface do Bitbucket, notaremos que
algumas coisas mudaram: conseguimos
navegar graficamente pelos commits,
conforme Figura 8. Os commits so
exibidos como uma sequncia de alteraes realizadas e, para cada um,
gerado uma pgina com informaes
detal hadas sobre o mesmo, como
arquivos modificados e quais alteraes foram feitas, alm de permitir a
adio de comentrios e definir que
outros integrantes da equipe revisem
e aprovem sua change, construindo
assim um processo a se seguir para o
desenvolvimento.

Atravs de tags podemos ainda marcar


pontos de release, ou seja, assinalar momentos especficos em que uma verso
oficial determinada. Para criar uma
tag basta executar git tag a <tag> -m
<mensagem>. Para nosso exemplo, vamos
considerar que os commits feitos at este
momento compem a verso 0.1, logo iremos fazer git tag a v0.1 m versao inicial
v0.1. Alm disso, da mesma forma que
demos push nos commits para o servidor, devemos fazer o mesmo para as tags
que criamos. Assim, execute o seguinte
comando git push origin v0.1.

Utilizando a ramificao para


trabalhar em equipe
Chegamos, enfim, ao objetivo maior
deste artigo: a ramificao (branching) do
projeto para permitir o trabalho paralelo e
o gerenciamento destas mudanas.
Imagine que criar um branch como
criar bifurcaes na linha de desenvolvimento, possibilitando que alteraes
sejam feitas em pontos distintos e depois
tais alteraes podem ser mescladas
(merge) de volta linha principal. O
poder que o Git possui para criar e gerenciar branches, executando operaes de
maneira quase instantnea, destaca-se
entre todos os SCV.
Criar um branch local muito til,
por exemplo, para realizar um teste
isoladamente, sem mexer em seu cdigo
principal. Caso o teste seja realizado
com sucesso, mesclamos o cdigo com
o branch principal, tradicionalmente
chamado de master. O Bitbucket permite a criao de branches graficamente.
Criar branches no servidor permite que
organizemos uma forma de trabalho.
Podemos criar um branch para cada
desenvolvedor, ou um branch para cada
tipo de arquivo a ser mexido.
Para prosseguir com o nosso exemplo,
criamos trs branches pelo Bitbucket,
simulando trs desenvolvedores trabalhando em arquivos distintos do projeto
e realizando cada um os seus devidos
commits.
Para chegarmos nesta configurao,
cada um dos trs desenvolvedores clonou o projeto a partir da tag v0.1 que
havamos criado, como mostra a Figura 9.
Feito isso, realizaram um checkout para

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

41

seu respectivo branch localmente, isso


, executaram git checkout b <nome_do_
branch>, sendo o nome_do_branch idntico aos criados pela interface do Bitbucket.
O argumento b passado no comando
git checkout cria um novo branch local.
Para listar os branches existentes utilize
git branch. O branch assinalado com *
aquele no qual estamos trabalhando
no instante. Para alternar para um dos
demais branches, utilize git checkout
<branch>, sem o parmetro b.
Posteriormente, os desenvolvedores
modificaram arquivos, deram o commit
nas alteraes e realizaram o push para
seus branches remotos. Desta forma, os
quatro branches existentes no servidor
se encontravam diferentes.
Porm, o que desejamos que as alteraes feitas por cada desenvolvedor sejam
compartilhadas entre eles, gerando uma
nova verso comum entre todos. Para que
isso ocorra, iremos realizar um merge
entre estes branches, criando um novo
snapshot que possui todos os commits.
O Bitbucket permite realizar essa tarefa
facilmente pelo menu de navegao de
branches, conforme mostra a Figura 10.
evidente que um merge deve ser feito
sob algum critrio. possvel revisar
os commits, logo pode-se adotar que o
merge de determinado branch s ser
executado aps a verificao das changes por outro desenvolvedor.
Podemos chamar o cenrio descrito de
otimista, pois os merges ocorrem sem
conflitos entre os commits que compe
cada branch. Um conflito ocorre quando
duas pessoas modificam um mesmo trecho de um arquivo e ambas tentam dar
push destas modificaes para o servidor. Neste caso, o primeiro que realizar
o push ter suas informaes salvas e o
segundo ser informado do conflito.
Caso este conflito ocorra no instante de
realizar o merge de branches pelo Bitbucket, o mesmo informa que h conflitos,
mostra quais foram os arquivos em que
ocorreram e descreve que tais conflitos
devem ser resolvidos manualmente,
disponibilizando um link instruindo
como faz-lo, conforme Figura 11. Para
montar este cenrio, dois desenvolvedores
modificaram um mesmo arquivo, adicionando uma linha com a data em formatos

42

Figura 10. Realizando merge

Figura 11. Exibio de conflito em merge pelo Bitbucket

diferentes, e cada um realizou o push de


seu commit em um branch diferente.
Desta forma, quando h um conflito,
ser necessria a anlise de causa e qual
o trecho de cdigo dever ser mantido,
dependendo assim de uma ao manual
de um dos desenvolvedores.
Uma boa prtica para minimizar a
ocorrncia de conflitos sempre baixar
dos servidores as mudanas recentes
imediatamente antes de subir suas
alteraes, ou seja, executamos um
pull, trazendo os commits dos demais
membros para seu cdigo, realizar as
mudanas desejadas e executar um push
em seguida para o servidor.
Esse artigo apresentou as facilidades
que a implantao de um sistema de controle de verso pode trazer a processos
de desenvolvimento de software. Com as
informaes apresentadas, o leitor estar
apto a explorar o universo do Git e perceber como so inmeras as possibilidades
de executar adequadamente o controle
de mudanas necessrio ao projeto.

Links:
[1] Instalador Git para Windows
https://git-for-windows.github.io/
[2] Tutorial chaves SSH
https://help.github.com/articles/generating-ssh-keys/
[3] Livro Pro Git
https://git-scm.com/book/en/v2
[4] Bitbucket
https://bitbucket.org/
[5] GitHub
https://github.com/

Voc gostou deste artigo?


D seu voto em
www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros

Utilizando as ferramentas Mantis,


Subversion e Google Code
Gerncia de configurao de software
Fique por dentro:
A gerncia de configurao de software consiste em um conjunto de atividades que tem como
objetivo gerenciar as mudanas do software
atravs de um controle de verso e controle
de mudanas. Neste artigo ser apresentado
de que maneira possvel implantar um ambiente de gerncia de configurao de software
integrando os servios de controle de verses e
gerncia de mudanas, atravs de um ambiente
totalmente baseado em software livre utilizando ferramentas open source. Este artigo til
para quem busca implantar um ambiente de
gerncia de configurao organizado e eficaz,
com baixo custo, visando a qualidade do software a ser desenvolvido e evitando assim a perda de controle devido s mudanas ocorridas
durante um processo de desenvolvimento.

Priscila Martins Oliveira


priscilamoliveira17@gmail.com

Licenciada em Informtica em 2008, Bacharel


em Sistemas de Informao em 2012, experincia de 4 anos na rea de TI atuando como
Analista de Teste de Software, Certified Tester
Foundation Level (CTFL) desde 2011.

urante o processo de desenvolvimento de software, as


mudanas ocorrem de forma
inevitvel. Independentemente de onde
estamos no ciclo de vida de um software, este ir se modificar e o desejo de
modific-lo ir persistir ao longo de seu
ciclo de vida. Vrios motivos podem
levar um software a ser modificado,
tais como: a identificao de novos requisitos, mudana do entendimento dos
usurios sobre a aplicao, mudana no
ambiente no qual o software ir operar,
modificao de regras de negcio, restries de oramento ou cronograma,
avanos tecnolgicos, mudanas de
legislao, ou o mais comum deles: a
correo de defeitos.
Tais modificaes podem representar
aspectos positivos e negativos. Atravs
das mudanas o produto de software
pode ser melhorado e corrigido constantemente, proporcionando maior

qualidade ao mesmo. Porm, se este


processo de mudana for aplicado sem
critrio e organizao, muitos problemas podem acontecer, podendo levar
perda de controle e consequentemente
comprometer a integridade e qualidade
do software.
Devido a este motivo, se torna necessrio aplicar dentro das empresas

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

43

prticas de desenvolvimento que possam controlar de forma


sistemtica e organizada as modificaes ocorridas em um
software tornando possvel a permanncia de sua qualidade
e integridade ao longo do tempo.
Neste contexto, surge a Gerncia de Configurao de Software (GCS), que consiste em um conjunto de atividades que tm
como objetivo gerenciar as mudanas atravs de um controle
de verso e de mudanas.
O gerenciamento de verses se refere ao processo de acompanhamento de diferentes verses de componentes de software
ou itens de configurao e os sistemas em que esses componentes so usados. Ele tambm envolve a garantia de que as
mudanas feitas por diferentes desenvolvedores para essas
verses no interferem umas nas outras.
A GCS uma disciplina da engenharia de software que ocorre
durante o todo o ciclo de vida de desenvolvimento e no apenas
na etapa de manuteno (que ocorre quando o produto j foi
entregue ao cliente). Pelo fato das solicitaes de mudanas
ocorrerem em qualquer perodo, as atividades de GCS devem
ocorrer desde o incio do projeto e somente devem terminar
quando o software retirado de operao.
A GCS um conjunto de atividades de apoio ao processo de
desenvolvimento que permite gerenciar e controlar a evoluo
de um software atravs do controle de verses e solicitao de
mudanas, visando manter a estabilidade na evoluo do projeto,
tornando-o sistemtico e rastrevel. A GCS permite que todas
as pessoas envolvidas no desenvolvimento tenham acesso ao
histrico das modificaes ocorridas no software bem como o entendimento do sistema na situao atual e situaes anteriores.
Tamanha a importncia da GCS que a aplicao das suas
atividades nas empresas imprescindvel para a obteno da
certificao do Capability Maturity Model Integration (CMMI) nvel 2 e certificao no modelo Melhoria do Processo do Software
Brasileiro (MPS-BR) nvel F. Por isso, a GCS tem um papel muito
importante na garantia da qualidade do software e no apoio
gesto de projetos. De forma resumida, as atividades de GCS
so: identificao das modificaes, controle das modificaes,
garantia de implementao adequada das modificaes, relato
das modificaes e controle de verses.
Para a qualidade deste processo, necessrio dispor de ferramentas adequadas para garantir que suas atividades sejam
realizadas de forma eficiente e atenda ao objetivo para o qual
foi aplicada.
Em empresas de grande porte, esta tarefa pode no ser um
problema, pois elas geralmente possuem capital para investir
em ferramentas e recursos qualificados para estabelecer tais
prticas. Porm, em empresas de pequeno porte, a realidade
pode ser diferente, pois normalmente estas organizaes tm
dificuldade de adotar este modelo devido ao alto custo aplicado
para adquirir ferramentas de apoio e recursos adequados.
Ainda assim, possvel implantar uma soluo de GCS com
qualidade e baixo custo nas empresas atravs de softwares
livres. Neste artigo demonstramos como isto possvel atravs
da integrao das ferramentas Mantis, Subversion (Subclipse)
e Google Code.

44

Para o entendimento da forma como estas tarefas so executadas necessrio entender alguns conceitos fundamentais
que sero descritos nos tpicos a seguir.

Configurao
Durante todo o processo de desenvolvimento de software,
so produzidas diversas informaes, que podem ser: arquivos
de cdigos fonte, programas executveis, especificaes do
sistema, planos de projeto, especificaes de requisitos, especificaes de interface, manual do usurio, planos, casos, roteiros
e cenrios de teste, manual de instalao, descrio de banco
de dados, ferramentas de software, entre outros. Ao conjunto
de toda informao produzida no processo de engenharia de
software denominamos Configurao de Software.

Item de Configurao
Um item de configurao de software o menor item de
controle em um processo de GCS. um dos conceitos mais
importantes da disciplina de GCS, pois sobre o item de configurao que a GCS aplicada.
Um item de Configurao de Software (ICS) consiste em
cada unidade de informao que criada durante o desenvolvimento de um produto de software, ou seja, cada artefato
gerado. Alm dos itens criados, tambm so considerados
ICSs as ferramentas que so necessrias para a construo
do software.
Os ICSs podero sofrer alteraes ao longo do tempo e sero
geradas diversas verses de um mesmo ICS resultante das
modificaes realizadas. Tambm podero ser criados novos
itens ao longo do ciclo de vida.
Os ICSs devem ser identificados para que seja possvel
gerenci-los de forma eficaz. Cada ICS deve ser identificado
distintamente de forma que ele seja caracterizado unicamente.
Cada empresa pode definir sua prpria forma de identificao,
que pode ser um nome, uma descrio, entre outros. Porm, o
ICS deve ser nomeado de maneira que seja possvel identificar
a evoluo de sua verso.

Baseline
Baseline ou configurao base do sistema compreende em
um conjunto de itens de configurao que foram formalmente aprovados e armazenados de forma controlada em um
determinado momento do ciclo de vida do sistema. Os itens
de configurao que compem a baseline do projeto somente
podem ser modificados atravs de uma solicitao formal de
mudanas. As baselines podem ser definidas ao final de cada
uma das fases do processo de desenvolvimento do sistema ou
de qualquer outra forma definida pela gerncia.
As baselines so importantes porque, muitas vezes, voc
precisa recriar uma verso especfica de um sistema completo.
Por exemplo, uma linha de produto pode ser instanciada para
que existam verses de sistema individuais para diferentes
clientes. Talvez voc precise recriar a verso entregue a um
cliente especfico se, por exemplo, esse cliente relatar bugs em
seu sistema os quais precisam ser ajustados.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

en gen haria

Gerenciamento de releases
Um release de um software uma verso de um sistema
distribuda aos clientes. Quando um release de sistema produzido, deve-se documentar para se garantir que ele possa
ser recriado no futuro. Isso importante, principalmente para
sistemas embutidos, customizados e com um ciclo de vida
longo. Sistemas como esses tendem a ser usados por clientes
durante um bom perodo de tempo. Esses clientes podem exigir
mudanas especficas para uma determinada release muito
depois da data de lanamento daquela verso do produto.

Repositrio
Um repositrio um mecanismo capaz armazenar fisicamente os itens de configurao, mant-los relacionados a diversas
verses e ainda permitir o acesso s verses anteriores. Devem
ser capazes tambm de armazenar informaes sobre baselines, alm de informaes sobre quando, porque e por quem
as modificaes foram realizadas.

Controle de verses
Quando um item de configurao gerado, ele pode sofrer
diversas modificaes, evoluindo de forma a atender as necessidades dos stakeholders. Esta necessidade de mudana implica
que alteraes sejam realizadas e, consequentemente, a cada
alterao uma nova verso do item gerada.
necessrio, portanto, identificar, armazenar e controlar
as diversas verses dos itens de configurao. Antigamente
quando no existiam ferramentas para dar suporte a este controle, os itens de configurao eram mantidos em documentos
de papel, colocados em pastas de arquivos e armazenados em
armrios. Esta abordagem era problemtica por vrias razes:
encontrar um item de configurao era frequentemente difcil;
determinar que itens foram modificados quando e por quem
era um desafio; construir uma nova verso de um programa
existente consumia tempo e era propenso a erros; descrever
relacionamentos detalhados e complexos entre itens de configurao era virtualmente impossvel. Hoje em dia o controle
de verses pode ser feito com o auxlio de ferramentas.
Um sistema de controle de verses permite que os itens de
configurao sob a gerncia de configurao evoluam de forma
concorrente e disciplinada. Controlar verses significa gerenciar
diversas verses dos itens de configurao gerados no desenvolvimento do software, permitindo a edio colaborativa dos
artefatos, compartilhamento dos dados impedindo que um desenvolvedor implemente uma verso desatualizada do artefato
sobrepondo a verso atual disponibilizada por outro, evitando
perdas e sobreposies durante a manuteno do artefato.
Algumas caractersticas perceptveis de um sistema de controle de verso so:
mantm e disponibiliza cada verso j produzida de cada
item do projeto;
possui mecanismos para gerenciar diferentes ramos de
desenvolvimento possibilitando a existncia de diferentes
verses de maneira simultnea;

estabelece uma poltica de sincronizao de mudanas que


evita a sobreposio de mudanas;
fornece um histrico completo de alteraes sobre cada item
do projeto.
O sistema de controle de verses responsvel por armazenar
as verses dos ICSs atravs de um mecanismo de arquivos e
diretrios constantes no repositrio, registrando as alteraes
realizadas. A fim de evitar perda de um trabalho ocasionada
quando algum sobrescreve o trabalho de outra pessoa, o sistema de controle de verses prov um mecanismo para controlar
as alteraes assegurando que as pessoas envolvidas no projeto
no trabalhem diretamente nos arquivos armazenados no repositrio, porm em cpias dos itens em sua rea de trabalho.
A este procedimento denominamos check-out. Desta forma,
um desenvolvedor pode trabalhar de forma independente sem
interferir no trabalho do outro. Aps as modificaes, o artefato revisado e pode ser colocado novamente no repositrio
atravs de um processo que denominamos check-in. Neste
momento poder ser estabelecida uma nova baseline.
O controle de verses apoia as atividades de controle de mudana e integrao contnua, que tambm so atividades que
formam a gerncia de configurao de software.

Controle de mudanas
O controle de mudanas o processo de avaliar, coordenar
e decidir sobre a realizao de mudanas propostas a itens de
configurao. Mudanas aprovadas so implementadas nos
itens de configurao.
Mudanas so um fato da vida para sistemas grandes de
software. As necessidades e requisitos organizacionais so
alterados durante a vida til de um software. Isso significa
que necessrio fazer as mudanas correspondentes. Para
garantir que essas mudanas sero aplicadas ao sistema de
maneira controlada, preciso um conjunto de procedimentos
de gerenciamento de mudana apoiado por ferramentas.
Esses procedimentos devem ser concebidos para assegurar que
os custos e os benefcios das mudanas sejam adequadamente
analisados e elas sejam feitas de maneira controlada. Durante
o processo de desenvolvimento de software, modificaes sem
controle levam rapidamente ao caos. Alguns problemas podem
ser causados em projetos devido a mudanas no controladas,
como: aumento de custos, atraso em entregas, impacto em outros
ICSs, baixa qualidade do software, retrabalho, entre outros.
As mudanas de um ou mais itens de configurao so propostas, avaliadas, aceitas e aplicadas. Sendo assim, necessrio
estabelecer processos que combinem procedimentos humanos
e ferramentas para proporcionar um mecanismo controlado.
Existem diversas ferramentas disponveis no mercado que
oferecem servios para identificar, rastrear, analisar e controlar
as mudanas nos ICSs. Seus objetivos so manter as informaes sobre os pedidos de mudana, controlar as modificaes
e as implementaes realizadas nos ICSs.
Em um processo de controle de mudanas, quando h a necessidade que um ICS seja modificado, um pedido de mudanas

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

45

requisitado, analisado e um relatrio de mudanas gerado.


O relatrio encaminhado para avaliao. Caso seja aprovado,
o mesmo enviado para o gerente de configurao, o qual tem
o controle de acesso dos ICSs no repositrio. O gerente de
configurao libera para a equipe de desenvolvimento realizar a mudana solicitada e recebe os itens quando o mesmo
atualizado no repositrio. Quando o pedido de mudana no
aprovado, o relatrio e o pedido so arquivados e dado um
retorno ao solicitante. Todo esse controle possibilita que as
mudanas sejam efetuadas de modo disciplinado.
Assim, o processo de gerenciamento de mudanas est relacionado com a anlise de custos e benefcios das mudanas
propostas, a aprovaes dessas mudanas que valem a pena
e o acompanhamento dos componentes do sistema que foram
alterados.

Mantis
O Mantis uma ferramenta open source, que funciona como
um rastreador de bugs que tem como objetivo principal gerenciar os defeitos encontrados durante o desenvolvimento de
um software. O Mantis gerencia o ciclo de vida de um defeito
desde o seu relato at sua resoluo e, consequentemente, seu
fechamento. O Mantis tambm pode ser utilizado para dar
suporte ao processo de controle de mudanas, gerenciando as
solicitaes de modificaes. Ele permite relatar solicitaes
atravs da opo Relatar Caso. Para cada solicitao criada
gerado um nmero sequencial nico que a identifica.
Ao cadastrar uma solicitao, pode-se inserir informaes
como: categoria, gravidade, status, atualizao, resumo, etc. No
Mantis, existe um controle de acesso s solicitaes atravs de
tipos de usurio tais como: relator, desenvolvedor, atualizador,
administrador, visualizador, etc. Cada um possui suas restries de acesso. Alm disso, o Mantis proporciona uma viso
de todas as solicitaes e seus status, exibindo detalhadamente
o histrico contendo todas as situaes pela qual a solicitao
de mudana passou. Desta forma, todas as pessoas envolvidas
no processo de GCS podem se manter informadas a respeito
do estgio de suas solicitaes.

programao. Para participar, os membros obrigatoriamente


precisam possuir uma conta Google. Este sistema disponibiliza alguns recursos como o gerenciador de verses (utilizando
Subversion ou Mercurial) e um bug tracker prprio.
O Google Code disponibiliza vrias abas as quais correspondem aos diversos recursos que este sistema oferece,
como: Project Home, Downloads, Wiki, Issues, Source e Administer (este ltimo pode ser visto apenas pelo responsvel
do projeto).
Alm disso, os membros do projeto podem hospedar,
compartilhar e alterar artefatos inerentes ao projeto, cdigosfonte (com o auxlio do sistema de controle de verses), dar
sugestes de melhoria e comunicar possveis falhas do projeto atravs da opo Issue, documentar o projeto medida
que o mesmo desenvolvido atravs da opo Wiki, entre
outras funes.

Estudo de caso
A seguir ser descrito um exemplo da implantao de um
processo de gerncia de configurao atravs da integrao
das trs ferramentas citadas:
Mantis para o controle de mudanas;
Subclipse como cliente SVN e controle de verses;
Google Code como repositrio dos dados.
Todo este processo pode ser visualizado na Figura 1.

Subclipse
O Subclipse uma ferramenta open source disponibilizada
pela Tigris que funciona como um cliente SVN para a IDE
Eclipse. Com ele instalado na ferramenta Eclipse, o mesmo se
torna capaz de realizar praticamente todas as funes fornecidas pelo SVN. A utilizao do Subclipse integrado ao Eclipse
torna o processo de gerncia de configurao mais gil, pois
com o ele possvel realizar aes de versionamento dentro do
prprio Eclipse, tais como: commit, update, merge, visualizao
de histrico de alteraes, check-in, check-out, entre outros.

Google Code
O Google Code um recurso gratuito disponibilizado pela
Google destinado principalmente a programadores e desenvolvedores de software. um site de cdigo fonte aberto que
permite hospedar um projeto em qualquer linguagem de

46

Figura 1. Grfico do processo

Podemos resumir da seguinte forma: primeiramente surge


uma necessidade de alterao em algum artefato do projeto.
Ento aberta uma solicitao de mudanas atravs da ferramenta Mantis. Em seguida, para que a alterao seja feita,
realizado um update para se certificar de que os dados esto
atualizados com o repositrio. Ento a alterao efetuada e
o commit realizado no repositrio de dados. Por fim, a solicitao de mudanas fechada. Veremos a partir de agora como
funciona esse processo atravs de um exemplo prtico.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

en gen haria

A partir da identificao de uma necessidade de mudana no cdigo do projeto


gerada no Mantis uma solicitao de
mudana. Esta solicitao enviada para
a autoridade responsvel por decidir se
a mudana dever ser implementada. A
solicitao ento gerada com estado
igual a Novo. Uma vez aprovado o
pedido de mudanas, este atribudo
para o desenvolvedor responsvel por
realizar a alterao e o mesmo notificado. Esta solicitao ento recebe o
estado Atribudo, conforme ilustrado
na Figura 2.
Para realizar a alterao solicitada, o
desenvolvedor, atravs do Eclipse aps
realizar o update em sua estao de
trabalho, realiza a modificao no software e solicita o commit no repositrio.
Ento exibida uma janela conforme a
Figura 3, a qual corresponde janela de
confirmao de commit. Esta solicita o
preenchimento do nmero da solicitao
do Mantis associado a esta mudana e
uma breve descrio que pode ser inserida opcionalmente. Estes campos so
preenchidos pelo desenvolvedor.
Aps a realizao do commit, atravs
do comando Show History, pode ser
verificado o histrico de atualizaes
de um determinado item. So exibidas
as informaes data, autor, comentrio
e o nmero da solicitao do Mantis.
Nota-se que o nmero da solicitao
exibido em formato de link, conforme
demonstra a Figura 4.
Atravs deste link possvel visualizar
a ocorrncia do Mantis correspondente
dentro do Eclipse. Isto possibilita identificar qual solicitao de mudana est
associada alterao.
A partir da o desenvolvedor pode
dar o devido tratamento ocorrncia,
ou seja, pode alterar o seu estado para
Resolvido e, posteriormente, o gerente
ou relator podem acessar o mesmo histrico de alteraes, acessar o link da
solicitao e definir a solicitao como
Fechada. Lembrando que toda essa
atualizao salva no repositrio criado
no Google Code.
Atravs da interao destes softwares,
o desenvolvimento de um projeto poder
ser melhor controlado. A cada alterao
efetuada, a mesma poder ser associada

Figura 2. Solicitao com status atribudo

Figura 3. Janela de Confirmao de Commit

Figura 4. Alteraes efetuadas

a uma solicitao do Mantis o que facilita


entender o porqu das alteraes ocorridas em um determinado artefato.
Atravs dos exemplos utilizados,
pode-se concluir que tais ferramentas

so capazes de apoiar de forma eficaz as atividades especficas da GCS.


O Subversion apoia a atividade de
controle de verso, gerando verso dos
artefatos e disponibilizando histrico

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

47

Figura 5. Ocorrncia do Mantis

das modificaes realizadas a cada verso. J o Subclipse (que


funciona como cliente do Subversion) foi utilizado pois permite
a integrao ao Eclipse possibilitando a realizao do check-in
dentro do prprio ambiente de desenvolvimento.
O Mantis responsvel por dar apoio ao processo de controle
de mudanas o qual permite relatar cada necessidade de mudana, atribu-la ao responsvel pela alterao, alm de gerar
histrico de relatrio das solicitaes. O Google Code funciona
como um repositrio de artefatos, onde ficam armazenados
todos os itens de configurao.
Atravs da integrao destas trs ferramentas foi possvel
verificar que vivel implantar uma soluo de GCS com baixo custo, qualidade e que pode ser facilmente implementada
nas empresas. Esta soluo de GCS foi demonstrada atravs
de um exemplo o qual mostrou que para cada necessidade
de mudana identificada, pode ser gerada uma solicitao no
Mantis a qual pode ser vinculada a cada alterao realizada
no artefato. Esta vinculao ocorre durante o procedimento
de check-in no repositrio do Google Code, quando atravs do
Subclipse exibida a tela de confirmao de commit solicitando
o preenchimento do nmero do Mantis.
Vimos tambm que, atravs da visualizao do histrico de
alteraes, possvel identificar dentro do Eclipse quais solicitaes do Mantis correspondem a cada verso do artefato. Esta
solicitao pode ser acessada diretamente do Eclipse atravs
de um link, o que possibilita indicar que tratamento deve ser

48

dado solicitao de mudana,


ou seja, se a mesma deve ser
resolvida ou fechada.
A utilizao de ferramentas
open source no gera custos
para as empresas e a GCS
aplicada com a integrao de
ferramentas simples e fcil
de ser seguida. O tempo gasto
com a realizao das atividades
de GCS certamente ser menor
do que o tempo que seria gasto
para realizar a manuteno de
um software desenvolvido sem
qualquer controle.
A implantao de GCS apoiado pela integrao de ferramentas contribui para a construo
de softwares de qualidade, manuteno da rastreabilidade,
evita que esforos sejam concentrados na modificao de
uma verso errada, assegura a produtividade e permite que
os custos e esforos envolvidos na realizao de mudanas em
um sistema sejam controlados.
Referncias:
PRESSMAN, R. S. Engenharia de Software. 6. ed. [S.l.]: McGraw-Hill , 2006.
SOMMERVILLE, I. Engenharia de Software. 8 Edio. ed. [S.l.]: Pearson, 2007.
PACHECO, R. F. Uma forma de implantao de gerenciamento de configurao de software em empresas de pequeno porte. Dissertao (mestrado)
- Instituto de Cincias Matemticas de Computao - Universidade de So
Paulo, So Carlos, 1997.
QUADROS, Moacir. Gerncia de projetos de software: Tcnicas e ferramentas.
1. ed. Florianpolis: Visual Books, 2002. 502 p. 5. ex.
PFLEEGER, Shari Lawrence. Engenharia de software: Teoria e prtica. 2. ed.
So Paulo: Pearson Prentice Hall, 2004. 535 p. 5. ex.

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software

Boas prticas para testes de performance


Conhea prticas de teste simples e diretas para comear no caminho certo

Fique por dentro:


Este artigo possui orientaes e fundamentos
destinados a profissionais de teste de software, contendo os principais conceitos de testes
de performance atravs de uma abordagem
simples e direta, baseada em lies aprendidas na prtica da execuo deste tipo. O artigo
tambm apresenta seus princpios e prticas,
servindo como um guia para adaptar os critrios apresentados a outros cenrios e projetos
especficos. Os usurios avanados podem utilizar o mesmo para melhorar sua abordagem,
tornando seus esforos de testes mais bemsucedidos.

T
Fernando Oliveira
oliveira.fer@outlook.com - https://br.linkedin.com/in/
fernandooliveirabauru

Graduado em Gesto de Tecnologia da Informao, com experincia em Software Quality


Assurance (SQA), especializado em testes funcionais e no funcionais em aplicaes Web.
Trabalha atualmente como Analista de Testes,
executando testes de performance e carga
orientados a aplicaes Web.

estes de performance so testes


nos quais uma aplicao submetida a uma carga de trabalho
dentro de condies especficas por um
tempo determinado com o objetivo de
verificar os comportamentos diferentes
que essas condies e cargas podem
proporcionar. Com estes procedimentos,
podemos observar o comportamento de
todo o ambiente da aplicao, desde os
defeitos de desempenho (como timeouts
e tempo de resposta inaceitveis), funcionais (como inconsistncia de dados),
estruturais (como memory leak, dados
corrompidos e rede com problemas) e
at mesmo de segurana (exposio dos
dados, etc.).

Basicamente, o teste de performance


a criao de simulaes de uso da
aplicao ou sistema o mais prximo
possvel de uma situao real, utilizando
ferramentas que automatizam diferentes
tarefas. Isso inclui tambm a infraestrutura onde a aplicao ser alocada
(servidores de dados, servidores web,
balanceamento de carga, rede, etc.).
A melhor garantia para evitar que
uma aplicao web fique indisponvel
devido grande quantidade de acessos

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

49

simultneos ou que os usurios procurarem alternativas


devido lentido no site a realizao de testes de performance. Podem parecer caros, complexos e demorados, mas
se realizados, permitem encontrar e corrigir problemas de
desempenho antes que a soluo torne-se disponvel para o
pblico, reduzindo o risco de perder receita e valor da marca,
pois sites ou aplicaes instveis afetam a confiana do visitante ou consumidor.
A realizao de testes de performance permite avaliar a
prontido da aplicao e verificar se seu desempenho ou
no uma preocupao futura. Uma aplicao hoje pode ter um
desempenho aceitvel nos testes, mas com base em previses
de crescimento e dados de performance, esta mesma aplicao
pode se tornar lenta ou instvel demais caso ocorra aumento
significativo dos acessos. A infraestrutura de hospedagem
poder ser readequada para melhorar o desempenho ou a
prpria aplicao dever passar por uma manuteno para
atingir os nveis de performance desejados.
muito comum empresas e equipes que desenvolvem
aplicaes web, mas no realizam testes de performance, se
depararem com problemas de lentido, quedas e sobrecarga
dos recursos dos servidores quando uma nova aplicao
implantada. O primeiro culpado normalmente a infraestrutura (rede, memria, processadores). A soluo podia ter sido
testada incansavelmente pelos desenvolvedores e testadores
antes da implantao, mas apenas testes funcionais no conseguem identificar um simples problema de performance que
pode gerar inmeros transtornos quando o sistema colocado
em produo (ler BOX 1). Via de regra, os testes funcionais
simulam apenas um indivduo que utiliza o sistema, no
10.000 usurios realizando a mesma tarefa simultaneamente.
BOX 1. Testes funcionais
Os testes funcionais so aqueles cujo o objetivo avaliar o comportamento da aplicao
e medir a qualidade funcional de algum componente de um sistema. O teste funcional
confronta o resultado com comportamento esperado do sistema incluindo a entrada de
dados, o processamento e a resposta.

Os gargalos podem ocorrer em todos os nveis de arquitetura


de um sistema, tais como a camada de rede, servidor de aplicaes, servidor de dados e servidor web. Entretanto, conforme
apontam muitos estudos e experincias, quem causa a maior
parte dos gargalos de desempenho o cdigo do aplicativo,
conforme mostrado na Figura 1.

Figura 1. Estimativa dos gargalos distribudos pela infraestrutura de um


sistema

Throughput
Basicamente, throughput ou vazo a capacidade da aplicao
ou uma parte da mesma de executar uma operao de forma
repetida, em um determinado perodo de tempo. Por exemplo,
o throughput de uma pgina a quantidade de vezes por segundo que conseguimos receber uma resposta dessa pgina.
Esses nmeros so muito importantes porque definem a
capacidade da aplicao, medida em acessos por segundo,
pginas por segundo ou megabits por segundo. A maior
parte de todos os problemas de desempenho causada por
limitaes no throughput.

Tempos de resposta
Como a maioria dos profissionais que trabalham com
testes de software ainda no tm experincia ou no tiveram nenhum contato inicial com os testes de performance,
apresentaremos neste artigo alguns dos critrios mais importantes a serem considerados ao se realizar avaliaes de
desempenho, considerando melhores prticas e estratgias
que podem ser adaptadas conforme a realidade da aplicao
ou web site testado.

O que so gargalos?
Qualquer tipo de recurso do sistema (hardware, software,
banda de rede, etc.) que limite o fluxo dos dados ou a velocidade de processamento cria um gargalo. Nas aplicaes
web, eles afetam o desempenho e at mesmo a escalabilidade,
limitando o throughput de dados e/ou o nmero de conexes
suportadas pela aplicao.

50

o tempo que a aplicao demora para concluir um processo de transao. No caso de uma pgina, o tempo que a
aplicao demora para dar o retorno apropriado para o usurio final. importante medir o tempo de resposta porque
a aplicao pode ser rejeitada pelo usurio se no responder
dentro de um tempo esperado, mesmo tendo disponibilidade
imediata levando o mesmo a abandonar a pgina ou at
mesmo acessar a pgina de concorrentes.
O tempo de resposta envolve o perodo necessrio para
retornar solicitao realizada no servidor web. Cada solicitao deve ser processada e enviada para o servidor de
aplicao, que tambm pode realizar um pedido ao servidor
de banco de dados. Tudo isso voltar pelo mesmo caminho
at o usurio. O tempo necessrio para o retorno tambm
est relacionado com a latncia da rede entre os servidores
e o usurio.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

desen volvimento

Boas prticas nos testes de desempenho


Todos os profissionais que trabalham com testes de performance j se depararam com a criao de cenrios irrealistas
ou com a coleta de dados de performance irrelevantes.
Mesmo considerando que tais dados coletados estejam
corretos, os mtodos estatsticos escolhidos para resumir
e apresentar os resultados esto errados.
Em alguns casos, os resultados dos testes de performance
superestimaram a performance das aplicaes web avaliadas
e seus problemas de desempenho s foram notados quando
as mesmas j estavam em estgio de implantao pelo cliente.
Estes resultados podem levar a gastos desnecessrios com hardware e infraestrutura, caso os resultados dos testes concluam
que a infraestrutura necessita de aumento em sua capacidade.
Na maioria das vezes, estes erros foram causados pela inobservncia de alguns pontos simples, mas importantes, quando se
trata de testes de performance em aplicaes web.
As informaes detalhadas a seguir so algumas prticas
baseadas em observaes, experincias e lies aprendidas
visando simplificar o conceito de testes de performance.
Nenhuma metodologia ou ferramenta em especfico sero
abordadas, pois o foco descrever as melhores prticas com
o intuito de auxiliar os iniciantes a poupar tempo e evitar
esforos desnecessrios.

Antes de tudo, avalie a infraestrutura da rede da


aplicao
Antes de executar cada teste de performance, faa uma
avaliao minuciosa na infraestrutura da rede que suporta
a aplicao. Se o sistema no suportar a carga de usurios
dimensionada na aplicao, ele apresentar gargalos. Essa
avaliao de nvel bsico e validar a largura da banda,
taxa de acessos, conexes etc.
Um teste simples otimiza tempo e recursos, pois evita
que tarefas demoradas e complexas sejam executadas em
uma infraestrutura que futuramente no atender carga
esperada. Ao detectar qualquer sinal de gargalo, antes de
executar os testes de performance propriamente ditos, a
estrutura readequada para suportar a carga estimada nos
cenrios de teste.

Evite iniciar com cenrios complexos


Na maioria das vezes, os testes iniciais so executados
com cenrios extremamente complexos, que operam muitos
componentes da aplicao ao mesmo tempo. Esse tipo de
abordagem no deixa os gargalos aparecerem, ocultando
futuros problemas de desempenho.
Antes mesmo da aplicao estar totalmente pronta para
implantao, o ideal realizar testes com cenrios menos
complexos, um de cada vez.
Consideremos uma aplicao web com quatro cenrios
de teste definidos:
Cenrio 1: Pgina de vendas, 30% de carga de usurios;
Cenrio 2: Listagem de produtos, 10% de carga de
usurios;

Cenrio 3: Login de vendedores externos, 5% de carga


de usurios;
Cenrio 4: Pgina de ofertas, 55% de carga de
usurios.
Se executados concorrentemente, a carga de usurios
simultneos ir distribuir os usurios conforme o percentual de carga definidos. Observa-se que o menor percentual de carga para o cenrio 3: Login de vendedores
externos, pois a equipe de testes definiu que o acesso
a esta funcionalidade ser mnimo, considerando que
durante o dia de trabalho h pouco acesso por parte dos
vendedores externos. Uma vez executados os testes, nenhum tipo de gargalo foi identificado. Apesar disso, dias
aps a implantao, a aplicao demorava a responder,
gerando reclamaes de usurios e dos vendedores externos que no conseguiam realizar o login. Detectou-se que
o problema estava no cenrio 3. Havia um componente
complexo dentro do cdigo que demandava muito recurso
de processamento ao servidor de dados, causando demora
no processamento dos demais pedidos.
Como o percentual de carga definido nos testes foi pequeno para este cenrio, o gargalo no foi identificado.
Apesar dos cenrios criados serem baseados na utilizao
real do sistema, a equipe no previu que durante determinado perodo do ms os vendedores externos acessassem
o sistema ao mesmo tempo para lanar os pedidos de
clientes. Neste caso, os testes individuais de cada cenrio
poderiam ter detectado o problema e o gargalo poderia
ter sido evitado antes da implantao.

Nunca esquea do think time


Think time (ou tempo de raciocnio) o tempo definido
em uma transao no mesmo ritmo de um usurio real.
Os cenrios tentam prever aquilo que os usurios normalmente fazem (navegar, pesquisar, login, comprar,
etc.), e o tempo que eles levam para ler, pensar, digitar
e clicar. Cada etapa de cada transao deve ter seu think
time estabelecido. Dependendo do contexto da transao, o
valor do think time ir variar e, por isso, no aconselhvel
estabelecer um padro.
Um exemplo: o acesso pgina de login pode demorar
de 15 a 20 segundos para um usurio completar. Voc
pode informar ferramenta de teste para usar um tempo
randmico entre 15 e 20 segundos, ao invs de fixar um
valor nico. De qualquer forma, sempre melhor definir
um valor de think time do que no definir nenhum, caso
contrrio os cenrios executados causaro um enorme
impacto nos servidores, uma vez que transaes sem
think time ou com valores irreais acarretam sobrecarga nos
mesmos. Deve-se sempre lembrar de modelar os cenrios
com tempos reais previstos de think time
Algumas ferramentas de teste utilizam recursos de gravao das transaes registrando o tempo de raciocnio
que o usurio levou para finalizar cada uma delas.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

51

Ambiente de testes
Alm de ser exclusivo para realizao dos testes de performance, a infraestrutura da mesma deve ser a mais prxima
possvel da de produo. Todas as configuraes, aplicativos,
servios, massa de dados e outros itens que fazem parte do
ambiente de produo devem ser reproduzidos.
Evite testar a aplicao em sistemas de produo, uma vez
que o mesmo acessado por outros usurios e impossvel
garantir o que est sendo executado nesse ambiente. Sendo assim, ser difcil determinar se as falhas na aplicao
so ocasionadas pelos testes ou por outros usurios no
sistema.
Uma aplicao simples com apenas um servidor perfeitamente possvel de ser replicada, ao contrrio de uma
infraestrutura com recursos de grande porte que demandam
altos custos de implantao. Nessas situaes, mantenha a
mesma infraestrutura em propores menores, mas sempre
mantendo a escalabilidade da mesma.
Considere incorporar procedimentos que no so evidentes, pois a degradao do desempenho pode ocorrer
em tarefas peridicas que no so identificadas facilmente
como backup de base de dados, gerao de relatrios demorados, etc.

Gargalos de performance podem ocultar outros


gargalos
Sistemas que utilizam muitas APIs devem ter ateno redobrada ao identificar gargalos (ler BOX 2). Uma API que
no funciona como desejado pode esconder outros possveis
gargalos de outras APIs.
Por exemplo, uma determinada aplicao possui trs APIs.
Ao final dos testes de performance, a anlise dos resultados
detectou que a API problemtica gerou um tempo de resposta muito alto para uma certa pgina. Essa API no est
respondendo como esperado, mas no h como garantir
que as outras APIs estejam funcionando como deveriam.
Se uma API demora para responder, o nmero de requests
encaminhados para as APIs posteriores reduzido, ocultando possveis problemas nas mesmas.
BOX 2. API Application Programming Interface
API um conjunto de rotinas e padres de programao para acesso a um aplicativo de
software ou plataforma baseada na Web. A sigla API refere-se ao termo em ingls Application
Programming Interface que significa Interface de Programao de Aplicativos.

O equipamento gerador de carga tambm deve ser


testado
Em um ambiente de testes, alm da infraestrutura dos
servidores utilizados pela aplicao (servidor web, de dados, etc.), existe tambm a estrutura geradora de carga. So
equipamentos configurados para que uma determinada
ferramenta de testes execute os cenrios de testes, submetendo toda a estrutura utilizada pela aplicao carga
determinada.

52

Uma estrutura geradora de carga pode esconder problemas


e limitaes que geram rudos nos testes, ocasionando falsos
resultados (como um nmero reduzido de throughput). Cada
equipamento desse ambiente deve ser avaliado e os resultados individuais comparados em busca de inconsistncias.
O objetivo identificar se um desses equipamentos tem
consumo diferenciado (CPU, memria, banda, etc.).

Monitore os recursos do ambiente submetido


carga
Durante a execuo dos testes de performance, importante utilizar alguma ferramenta que monitore os diferentes
recursos dos servidores como forma de acompanhar o seu
comportamento conforme o crescimento e estabilidade da
carga. Esse tipo de monitoramento se torna fundamental
para verificar quando o hardware est se tornando um
gargalo.
Caso o testador possua conhecimentos avanados no
sistema operacional do servidor, existem ferramentas nativas que monitoram os recursos, gravando os contadores
selecionados conforme a necessidade de cada teste (ver
seo Links).

Nunca inicie a carga de uma nica vez


Em cada ciclo de testes, a carga de usurios deve subir
de forma gradativa durante um perodo longo de tempo,
seguido de um tempo estvel de pelo menos uma hora, para
ento descer gradativamente. Devem ser consideradas apenas as mtricas do perodo estvel, tanto no comportamento
dos servidores quanto da aplicao. Ou seja, o que deve ser
avaliado apenas o tempo de carga estvel de uma hora.
Submeter o sistema carga mxima de uma vez pode
sobrecarregar a aplicao Web, e os resultados apresentados durante o perodo de testes podem no corresponder
realidade.

O poder da regenerao do ambiente de testes


Um ambiente de testes composto pelo gerador de carga
e tambm pela aplicao que ser submetida aos testes.
extremamente importante que antes de cada ciclo de teste
executado, todos os ambientes estejam iguais, pois qualquer
alterao pode acarretar resultados no correspondentes
realidade da aplicao.
Um exemplo: aps o primeiro ciclo de testes, no servidor
de dados, um dos bancos teve um acrscimo considervel de
dados nas tabelas devido a um dos cenrios que alimentava
um formulrio de dados. Se esse ambiente no for regenerado nos prximos ciclos de testes, o mesmo banco ter mais
dados carregados e seu desempenho pode ficar abaixo do
esperado, ocasionando consultas mais lentas. Nessa situao, importante restaurar o banco de dados a um estado
conhecido antes de cada ciclo de teste.
Se esses ambientes forem criados em uma soluo virtualizada, fica muito mais simples manter esse controle, pois
essa tecnologia permite criar checkpoints que salvam

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

desen volvimento

um instantneo do servidor, podendo este ser restaurado


a qualquer momento revertendo a mquina virtual a um
ponto especfico do tempo.

Teste a aplicao considerando o uso aps


determinado perodo
Muitos testes de performance no consideram a utilizao
de toda a estrutura aps determinado perodo. Uma pergunta que sempre deve ser feita : Como meu sistema vai se
comportar daqui a um ano, quando quase 70.000 usurios
forem registrados nos bancos?.
As ferramentas de teste possuem relativa facilidade para
preenchimento do banco com grande quantidade de dados.
Como utilizada a mesma interface dos usurios reais,
existe a garantia de que os dados passaram pelas regras de
limpeza e verificao da aplicao. Os prprios cenrios
podem ser utilizados para realizar esse preenchimento.
Os mesmos testes de performance executados anteriormente sero rodados com o intuito de alimentar os bancos,
simulando a utilizao prevista daqui a um determinado
perodo. Assim possvel comparar os testes executados
com poucos dados e os testes executados com muitos dados
j inseridos no banco.

Se for possvel, replique o ambiente do seu cliente


Se a aplicao a ser testada um produto que j funciona
em seu cliente, no seria ideal realizar os testes de performance com dados reais? sempre importante manter o
ambiente de testes o mais prximo possvel do real e isso
ser de grande valia se existir a possibilidade de oferecer o
teste utilizando os dados reais do cliente.
O importante nessa situao sempre garantir que dados
crticos do cliente sero protegidos ou removidos, com sua
cincia e autorizao prvia.

Isole o ambiente de testes


Utilizando um ambiente de testes dedicado, importante
isolar a sua rede do restante da rede da empresa para que
nenhuma das duas seja afetada durante as atividades de teste.
Alm dos testes utilizarem uma parte considervel da banda
de rede, a prpria atividade da empresa pode afetar as simulaes e seus resultados, pois obviamente utiliza uma parte
da banda. Tambm se deve garantir que somente usurios
virtuais autorizados acessaro seu aplicativo em teste.

Participe ativamente desde o incio do projeto


natural que o teste de performance seja executado somente ao final do projeto (caso a metodologia de desenvolvimento no envolva processos geis). Na maior parte das vezes,
s possvel executar os testes no final do desenvolvimento
da aplicao ou quando a mesma j est em implantao
pelo cliente. De qualquer forma, importante que o testador
participe tambm do projeto durante o desenvolvimento do
produto. Devemos lembrar que os cenrios propostos devem
combinar e simular um cenrio real com a maior fidelidade

possvel. Participando do ciclo de vida do produto, o testador ter mais condies de criar os cenrios de teste com
entendimento adequado dos padres comuns de uso.
Objetivos mal definidos para os testes de performance so
ocasionados por entendimento inadequado das expectativas
dos testes, e muitas vezes vo acarretar na criao demorada
de cenrios complexos de forma desnecessria. Isto resulta
em dados de performance inadequados para uma anlise
do real desempenho da aplicao.

Testes de performance devem procurar problemas


de performance
Em alguns casos, as equipes procuram os testes de
performance para confirmar seus requisitos ao invs de
tentar identificar problemas. Essa viso pode at mesmo
influenciar na criao dos cenrios de teste. Se o objetivo
pura e simplesmente executar testes buscando confirmar
os requisitos de desempenho da aplicao, a equipe dificilmente pensar em um cenrio hipottico fora dos padres
para incluir nos testes. Um cenrio no previsto pode deixar
potenciais problemas ocultos.

Teste muitas vezes


Quando finalizar um determinado ciclo de teste de
performance, utilize-o como um ponto de comparao e
execute-o novamente com as mesmas definies mais de
uma vez com o objetivo de procurar possveis regresses
de desempenho. Uma mudana simples no prevista pode
causar algum problema inesperado, acarretando perdas de
desempenho que no seriam detectadas em apenas um ciclo
de avaliao. Por exemplo: foram definidos ciclos de teste
de 100, 250, 300 e 500 usurios simultneos. Nessa situao,
no ser executado apenas um ciclo de teste para cada carga de usurios, e sim cinco ciclos de teste para cada carga
de usurios comparando os resultados entre si. Caso seja
encontrada uma discrepncia ao comparar os resultados, o
problema dever ser investigado em detalhes.

Para o tempo de resposta, considere a proporo de


usurios que atingem a meta
O tempo de resposta o que define a satisfao de um
usurio do sistema. Para esse valor, no consideramos
o tempo mdio que cada transao demora a responder.
Deve-se buscar nos registros do teste quantos por cento
dessas transaes esto abaixo de um tempo de resposta
estabelecido.
Supondo que para determinada aplicao, o tempo de
resposta estabelecido como aceitvel igual ou inferior a
sete segundos. Ao executar os testes, se o tempo mdio de
resposta foi de seis segundos, o resultado atingindo poderia
ser considerado dentro do esperado. Entretanto, h um problema nessa anlise. Ao analisar em detalhes os resultados,
observou-se que o tempo de resposta dessa transao foi
varivel, estando to baixo e to alto que o tempo mdio
fez parecer que estava baixo.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

53

Portanto, o ideal sempre determinar uma quantidade de


usurios que sero atendidos por este tempo de resposta,
por exemplo: 85% das transaes devem responder no tempo
mximo de sete segundos.
Nessa situao, analisando novamente os resultados, concluise que 78% das transaes responderam no mximo em sete
segundos, e as demais atingiram tempo de resposta superior a
sete segundos. Considerando essa forma de anlise, o sistema
seria reprovado nos testes de desempenho.

Faa a sondagem com um nico usurio


Enquanto o aplicativo est sob carga, acesse-o e procure
explor-lo para ajud-lo a compreender a experincia do usurio (como tempos de resposta). Por exemplo, acesse a aplicao
pelo browser e navegue pelos cenrios propostos, executando
aes no previstas.
Muitos problemas no comportamento do sistema s so detectados ao interagir diretamente com a aplicao quando ela
est sendo submetida aos testes de performance. Uma lentido
em uma rotina que no estava no plano de testes pode esconder
possveis gargalos da aplicao.
Percebe-se que o sucesso do teste de performance de uma
aplicao no depende apenas das ferramentas utilizadas.
Desde o planejamento, desenvolvimento de teste, execuo
e anlise, so necessrios testadores competentes com conhecimento do sistema, da rede e das aplicaes de testes, alm
de uma boa experincia com servidores e, principalmente,
habilidade para descobrir problemas ocultos e isolados.

54

Links:
Ferramentas de teste Apache Jmeter
http://jmeter.apache.org/
Ferramentas de teste Microsoft Visual Studio
https://msdn.microsoft.com/pt-br/library/dd293540(v=vs.110).aspx
Ferramentas de teste HP LoadRunner
http://www8.hp.com/br/pt/software-solutions/loadrunner-load-testing/
Ferramentas de monitoramento New Relic
http://newrelic.com
Ferramentas de monitoramento PerfMon
http://blogs.technet.com/b/dbordini/archive/2008/08/05/usando-o-perfmon-paraavaliar-o-desempenho-de-servidores.aspx
MERRIL, Christopher L. Loading Test by Example Best Practices. V1.1, 2007
http://www.webperformance.com/library/tutorials/BestPractices/
RIBEIRO, CAMILO. Destilando JMeter I: Introduo e Conceitos. The Bug Bang
Theory, 2013
http://www.bugbang.com.br/destilando-jmeter-i-introducao-e-conceitos/

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software

Teste de performance com JMeter


Conhea um conjunto de prticas para avaliar a qualidade de seu sistema

Fique por dentro:


Este artigo apresenta como e quando aplicar
testes de performance em aplicaes web utilizando a ferramenta JMeter. Sero abordadas
funcionalidades da ferramenta, quais recursos
voc pode utilizar para auxiliar o seu projeto e
qual a melhor forma de aplicar cada um. Alm
disso, podemos entender um pouco mais sobre
os tipos de teste de performance que podem ser
aplicados para conseguirmos extrair a informao que precisamos do sistema. Este artigo ser
til para quem est iniciando o teste de performance e tem interesse em entender como a ferramenta JMeter pode ser utilizada para colocar
o teste em prtica e at ajudar na organizao
dos scripts da avaliao.

N
Dieny Oliveira
dieny.sttefanye@gmail.com

Testadora certificada CTFL, Graduada em Anlise e Desenvolvimento de Sistemas e apaixonada por Teste de Software. Atuou em projetos
de teste de performance, automao de teste,
teste de servio e testes funcionais. Experincia com criao de plano de testes, criao
e execuo de casos de testes e execuo de
testes exploratrios.

os ltimos anos a internet


evoluiu radicalmente, o acesso
aumentou e a cada dia que
passa as atividades antes feitas off-line
passaram a ser online como compras,
trabalho, negcios e entretenimento.
Com esta evoluo, sempre temos muitos usurios acessando, navegando e
efetuando transaes na aplicao. Para
garantir que a aplicao aguentar uma
certa quantidade de usurios e avaliar
a experincia que ele ter na aplicao
verificando qual o tempo de resposta
a cada iterao, muitas empresas esto
aderindo ao teste de performance para
garantir a qualidade do seu sistema. Mas
afinal, do que realmente se trata o teste
de performance?
Simplificando, aquele em que submetemos o sistema a uma avaliao

de carga, stress ou desempenho para


avaliar se os resultados esto de acordo
com o esperado, garantindo assim a
qualidade do sistema. Nestas avaliaes,
simulamos picos de usurios no sistema
para investigar at onde ele suporta.
O teste iniciado com uma carga baixa e
vai aumentando gradativamente.
O teste de stress a avaliao em que
colocaremos de primeira o mximo que
o sistema aguenta.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

55

J o de desempenho serve para medirmos o que a aplicao


j suporta. executado com uma carga constante e mantido
por horas. Neste caso, feita a anlise do tempo de resposta
do sistema a cada interao do usurio.
Lembrando que quando estamos falando de teste de performance, no temos uma nomenclatura padronizada. Neste
artigo iremos considerar a nomenclatura definida no livro
Performance Testing Guidance.
interessante que a primeira avaliao realizada seja a de
carga, para que tenhamos uma perspectiva do quanto o sistema
aguenta, para depois definirmos a carga que iremos utilizar
no teste de stress e desempenho.
Uma outra forma de definirmos a carga que iremos utilizar em cada avaliao monitorar o sistema em produo
durante um tempo. Se soubermos a quantidade de visitas
que o sistema recebe diariamente, quais os horrios com
mais acessos e quais as funcionalidades mais utilizadas,
saberemos quais cargas definir para realizar o teste em
cada funcionalidade.
A anlise final do teste de performance realizada atravs
dos dados coletados de sua execuo, dos logs do banco de
dados e dos logs do servidor de aplicaes. importante, neste
cenrio, estar em contato com a equipe de infraestrutura e a
equipe de redes, pois a anlise por completo da estrutura do
sistema ser mais eficiente e o resultado ser mais preciso e
abranger muitas informaes importantes no momento da
tomada de deciso sobre os resultados.
Neste artigo sero abordados conceitos utilizados em teste
de performance, como teste de carga, stress e desempenho. A
ferramenta utilizada para executar o teste o JMeter e no artigo
sero apresentados os principais recursos desta ferramenta,
como: requisies, temporizador, extrator de expresso regular,
asseres, utilizao de variveis, configurao e execuo do
teste e anlise dos resultados. Veremos como e quando utilizar
cada um desses recursos.

JMeter
Quando falamos em teste de performance, sempre a primeira
ferramenta que nos vem cabea o JMeter, isso porque
um software que est h um tempo no mercado e tem vrios
projetos de sucesso relatados na comunidade. Foi criada em
2007 pela Apache Software e a ferramenta mais utilizada
para este seguimento. Pelo fato de ser gratuita e ter o cdigo
aberto, podemos desenvolver melhorias para atender melhor o
projeto que iremos utiliz-la, como plug-ins para gerar outros
relatrios alm dos que a ferramenta j oferece.
A instalao do JMeter bem simples. Seu download pode
ser efetuado no site da Apache (ver seo Links). Basta fazer o
download e ele estar pronto para uso. Para isso, basta apenas
ter o Java 6 ou superior e executar o arquivo .bat que est no
pacote baixado do site.
A ferramenta, apesar de ser gratuita, tem muitos recursos
para atender ao projeto, como componentes:
que auxiliam na gesto dos scripts de teste e no controle de
cenrios aplicados, facilitando a manuteno dos mesmos;

56

para configuraes de ambientes de testes para execuo em


servidores e vrios terminais;
para auxiliar nas avaliaes das respostas recebidas para as
requisies enviadas aos servidores.
Estes so os principais recursos da ferramenta e sero abordados de forma mais detalhada nos tpicos a seguir. Outros
recursos que sero apresentados so:
os controles de gravao que so importantes no momento
da gravao dos scripts, ajudando a economizar tempo no
projeto;
o extrator de expresso regular que auxilia a coleta de dados dos resultados retornados para o JMeter, podendo assim
realizar validaes durante o teste;
como utilizar variveis no script de teste para deixar o teste o
mais prximo do cenrio real do sistema e do seu dia a dia.
Neste artigo iremos falar do JMeter para teste de performance,
porm, tambm possvel criar e executar testes funcionais
e em banco de dados, embora existam outras ferramentas no
mercado com melhores recursos para executar estes tipos de
avaliao.

Criando o script de teste


Assim como em outros tipos de teste, importante decidir o
que deve ser testado e como proceder essas avaliaes. No
interessante avaliar todas as funcionalidades do sistema uma
vez que o esforo seria muito alto, ento devemos avaliar quais
devem ser priorizadas. No caso do teste de performance, devemos considerar dois pontos: funcionalidades que tm muito
acesso simultneo (por exemplo, em um e-commerce, o cenrio
de compra o mais importante e o que devemos garantir que
tenha performance excelente para que o cliente no passe a
comprar em outro local motivado por um desempenho ruim
enquanto realizava sua compra) e funcionalidades em que a
requisio possa ser mais lenta, como upload e download de
arquivo.
Aps definir quais funcionalidades sero testadas, devemos
dividi-las em casos de testes, que podero ser organizados
por grupos de usurios. Ento teremos o plano de teste para
agrupar os casos de testes. Todos os casos de testes podero
ser executados simultaneamente ou separadamente. Cada
um deles ser configurado de uma forma diferente de acordo
com o objetivo da funcionalidade. Por exemplo, digamos que
os cenrios de avaliao definidos foram Realizar Login,
Cadastrar Usurio e Realizar e Concluir uma Compra.
Nestes cenrios podemos definir que o Login ter uma
carga de 40 usurios simultneos, o Cadastrar Usurio 10
usurios simultneos e o Realizar e Concluir uma Compra,
50 usurios simultneos. Desta forma, cada caso de teste pode
ser adequado ao cenrio real que temos em produo. Veremos
mais sobre configuraes de execuo no tpico Configuraes e Execuo do Teste. Depois de definidos todos os casos
de testes, iremos criar um script de teste para automatizar
sua execuo.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

desen volvimento

O JMeter possui uma estrutura muito


fcil para organizar os testes. Na Figura 1
podemos ver a rvore onde ficam todos
os componentes utilizados por eles.
O componente Plano de Teste que vemos
o responsvel por controlar a execuo
de todos os grupos de usurios. Nele que
iremos agrupar todos os componentes.
Alm disso, tambm iremos definir
algumas configuraes das execues,
como se os grupos de usurios devem
ser executados simultaneamente ou consecutivamente; ativar o modo de teste
funcional para o JMeter salvar dados das
respostas do sistema, e; podemos definir
variveis globais que sero utilizadas
na execuo do teste. Falaremos mais
sobre a utilizao de variveis no tpico
Utilizando Variveis.
No plano de teste, podemos inserir
inmeros grupos de usurios. Cada um
executar um teste diferente podendo
ser este executado simultaneamente
ou no.
O grupo de usurios o componente
que controla a execuo dos cenrios.
Nele definimos quantos usurios devem
interagir com o sistema simultaneamente, qual o tempo de durao e qual ao
o JMeter deve tomar quando ocorrer um
erro com um usurio.
Para criar o teste devemos adicionar,
no grupo de usurios, as requisies
necessrias para simular o teste. Relembrando que devemos adicionar um
grupo de usurio para cada caso de teste
do plano.
Alm das requisies, importante
adicionar Asseres para garantir que o
teste execute de forma correta. Por exemplo, aps realizar um login na aplicao,
interessante inserir uma assero para
garantir que o login foi feito com sucesso
antes de realizar o prximo passo. Neste
cenrio, se a aplicao travar no login,
ser fcil identificar no relatrio final
onde est o gargalo.
Devemos tambm adicionar o temporizador para que o tempo de cada
requisio simule o tempo real que o
usurio leva para realizar cada iterao
com o sistema e o extractor de expresso
regular caso a aplicao necessite passar
dados de uma resposta para a prxima
requisio enviada ao servidor. Por fim,

Figura 1. rvore de componentes do JMeter

Figura 2. Componente Requisio HTTP

devemos adicionar os componentes


ouvintes para realizar a anlise aps a
execuo do teste. Nos prximos tpicos,
falaremos destes componentes e qual sua
importncia no teste.

Controlador de gravao
No grupo de usurios, devemos adicionar as requisies que representam
cada passo do caso de teste. As requisies podem ser adicionadas uma a
uma manualmente ou podemos utilizar
um componente que o JMeter oferece
chamado controlador de gravao. Este
componente faz parte do grupo de controladores lgicos. Ele nos permite gravar
a execuo de um cenrio, com isso todas
as requisies so geradas dessa forma
sem a necessidade de insero manual,
sendo basicamente um record/play.
Porm, necessrio realizar ajustes nas
requisies para a execuo ocorrer com

sucesso, como trocar os valores fixos por


variveis e ajustar algumas configuraes. Por exemplo, em um cenrio de
download e upload, as configuraes da
requisio devem ser diferentes de como
o controlador de gravao se comporta
em cenrios comuns de interao com
o usurio.

Requisies
Para enviarmos requisies aos servidores, devemos utilizar os componentes
do sampler. Nele temos disponveis
vrias opes de requisies, como
FTP, SOAP/XML-RCP, Java, HTTP, entre
outros.
Na Figura 2 temos um exemplo de uma
requisio HTTP para realizar um login.
O endereo acessado o 127.0.0.1, j o caminho foi definido para /Login. Estamos
enviando os parmetros para realizar o
login e o mtodo definido POST.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

57

Temos vrias opes de mtodos para


definir na requisio, porm os mais
utilizados so GET e POST. O GET
envia uma requisio ao servidor e ela
somente de leitura ou consulta. J o
POST tambm envia uma requisio ao
servidor, porm ela pode enviar dados
para incluso ou edio de registros.
Nos parmetros enviados, podemos
ver a varivel ${USUARIO}declarada.
Neste caso, cada usurio enviar a requisio com um dado diferente, porm
simultaneamente. Falaremos mais sobre
configurao de variveis no tpico
Utilizando Variveis.

Temporizador
Para simular a ao real do usurio
na aplicao, devemos emular o Thiking
time, ou seja, o tempo que o usurio
pensa entre as aes que ele realiza no
sistema. O JMeter disponibiliza alguns
componentes, como o temporizador
constante e o temporizador aleatrio
uniforme para simularmos esta ao.

Extrator de expresso regular



Sempre que optamos por realizar teste de performance em um sistema, devemos conhecer a sua estrutura
para sabermos que recursos teremos
que utilizar para que a avaliao seja
executada corretamente. Por exemplo,
se a aplicao foi desenvolvida em ASP.
NET, teremos que extrair e repassar a
VIEWSTATE em todas requisies.

VIEWSTATE uma soluo
ASP.NET que armazena as informaes
e o estado dos controles e objetos da
pgina para se manterem quando um
Postback ocorrer na pgina.

Quando gravamos o teste pela
primeira vez com o JMeter, ele armazena a VIEWSTATE atual da gravao.
Sendo assim, quando executamos o

teste novamente, ele enviar na requisio uma VIEWSTATE invlida. Para


solucionarmos isso, deveremos extrair
a VIEWSTATE das respostas que recebemos utilizando o componente extrator
de expresso regular e repass-la na
prxima requisio.
Na Figura 3 podemos ver uma configurao de expresso regular. Nele est
definido que a extrao deve ser feita no
corpo da resposta (Campo da Resposta a
ser verificado), mas poderamos extrair a
expresso de outras partes da resposta,
como da URL ou cabealho.
No campo Nome de Referncia devemos definir o nome da varivel onde o
JMeter salvar a que ser extrada. No
caso da Figura 1, a varivel foi nomeada
para VIEWSTATE. Depois devemos utilizar esta varivel como ${VIEWSTATE}
onde for necessrio usar a expresso
extrada.
No campo Expresso Regular devemos
inserir a frmula para extrair a expresso que queremos. No caso da Figura
3, a expresso id=__VIEWSTATE
value=(.+?). Neste caso, o JMeter ir
extrair da resposta da requisio o valor
onde est o cdigo (.+?) e armazen-lo
na varivel ${VIEWSTATE}.
Existem vrias formas de extrair um
dado. interessante estudar o componente Extrao de Expresso Regular
para utiliz-lo de forma eficiente em
cenrios onde a extrao complexa, por
exemplo, em casos em que o resultado
contenha mais de uma resposta para a
expresso simples.
No campo Modelo devemos apontar
a quantidade de variveis que estamos extraindo neste componente. No
exemplo da Figura 1, estamos indicando que apenas uma varivel ser
extrada. Se fossem duas variveis,
deveramos inserir $1$$2$ no campo.

Figura 3. Componente Extractor de Expresso Regular

58

E no momento de utilizar os dados, declararamos ${VIEWSTATE_g1} para


acessar o dado da primeira varivel e
${VIEWSTATE_2} para acessar o dado
da segunda varivel.
Por fim, no campo Valor Padro, definimos o valor que o JMeter utilizar quando no encontrar a expresso regular na
resposta da requisio.
Uma forma de avaliar se a expresso
regular est correta conferir a resposta
da requisio utilizando o componente
ouvinte. Falaremos mais sobre os componentes ouvintes no tpico Avaliao
e relatrio da Execuo do Teste.

Asseres
Para garantir que o script de teste esteja
executando com sucesso, que o sistema
no deu timeout durante a execuo, devemos utilizar asseres para verificar
o resultado da resposta da requisio
que enviamos.
Para validar contedo das respostas
das requisies, podemos utilizar Extrao de Expresso Regular e XPath. Outra
assero que podemos usar a assero
de durao que onde definimos o
tempo mximo que a aplicao tem para
responder a requisio enviada.
Para visualizar o resultado das asseres, devemos utilizar o componente
ouvinte. Com o resultado das asseres,
podemos inserir condies para o JMeter realizar, por exemplo, quando uma
assero falhar para a execuo do teste
com aquele usurio.

Utilizando variveis
Para o teste de performance simular
uma situao real, importante que
cada usurio utilize variveis diferente
dos outros usurios simultneos. No
cenrio de login, por exemplo, podemos
conectar ao sistema utilizando usurios
com perfis de acesso diferentes.
Caso a varivel utilizada seja a mesma
para todos os usurios, uma boa prtica
declar-la como varivel global no componente plano de teste. Assim, quando
quisermos alter-la, ser necessrio realizar a alterao em apenas um local.
Para configurar as variveis por usurio, devemos utilizar o componente
Configurao dos dados CSV.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

desen volvimento

Na Figura 4 podemos ver um exemplo


de configurao de variveis com CSV.
Na configurao apresentada, podemos ver que no Nome do arquivo
inserido o caminho onde o arquivo CSV
est salvo. As variveis so definidas
no campo Nomes das variveis. Estas
devem estar na mesma sequncia do
CSV. Tambm podemos definir quais
usurios utilizaro o CSV na execuo.
No exemplo temos Todos os usurios
virtuais. Para declarar as variveis na
requisio devemos utilizar ${}.
Figura 4. Componente Configurador dos dados CSV

Configuraes e execuo do teste


Aps termos todos os scripts de teste
criados, necessrio realizar algumas
config uraes. Em cada grupo de
usurio devemos definir quantos deles executaro aquele teste, tempo de
inicializao e tempo de execuo. Mas
antes, devemos avaliar qual o objetivo
do teste para definir como deve ser a
configurao realizada. Os objetivos
podem ser:
Avaliar como o sistema se comporta
com a carga atual;
Avaliar qual a carga mxima que o
sistema suporta;
Descobrir os pontos de gargalo;
Te mp o m x i m o e s p e r ado n a s
requisies.
Na Figura 5 podemos observar um
teste configurado para executar 100
usurios (nmero de usurios virtuais).
Ele ir aguardar 10 segundos para inicializar o teste (tempo de inicializao)
e ir executar o teste durante uma hora
(tempo de incio e tempo de trmino).
Uma outra forma de configurar a
quantidade de execues dos usurios
colocando quantidade no contador de
iterao e desabilitar o modo infinito.
Desta maneira, o JMeter ir executar o
teste com 100 usurios a quantidade de
vezes definida neste campo.
No teste da Figura 5 tambm foi definido que quando ocorrer um erro no teste
do usurio, o JMeter deve comear a prxima avaliao a partir deste usurio.
Para garantir o sucesso da execuo
do teste e que os resultados sejam verdadeiros, o ambiente deve estar bem
configurado. Deve-se avaliar a carga que

Figura 5. Configurador do componente Grupo de Usurios

o teste ir executar para definir qual ser


o tamanho do seu ambiente. A execuo
pode ser feita na nuvem ou pode ser distribudo em IPs fsicos ou virtuais.
Na Figura 6 temos uma representao
de uma configurao de ambiente onde
o JMeter cliente gerencia todo o teste e,
ao iniciar a execuo, ele distribui todos
os usurios nos quatro IPs que so os
JMeter Servers, que por sua vez enviam
requisies acessando o alvo de teste.

Avaliao e relatrio da execuo


do teste
A anlise dos resultados a parte mais
importante do teste, afinal se passarmos
resultados falsos para o cliente ou supervisores, o sistema apresentar erros
em produo e teremos retrabalho para
a equipe do projeto.
Para monitorar os testes, o JMeter disponibiliza vrios componentes que so
chamados de ouvintes que podemos adicionar ao plano de teste, em cada grupo

de usurio ou em cada requisio. Lembrando que quanto mais ouvintes inserirmos, mais memria consumiremos da
mquina na hora da execuo e isto pode
afetar a execuo da avaliao.
A seguir sero apresentados trs dos
ouvintes mais utilizados para monitorar
o teste.

Ouvinte rvore de resultados


O ouvinte rvore de resultados, representado na Figura 7, captura muitas
informaes de cada requisio feita por
cada usurio durante o teste. Por exemplo, quais parmetros foram enviados na
requisio e qual o tempo de resposta do
servidor, e exibe o contedo da resposta
da requisio na aba dados da resposta.
Nele tambm conseguimos visualizar
quais variveis aquela requisio enviou
como parmetro. possvel selecionar
vrias opes de exibio dos dados da
resposta, como: texto, HTML, JSON e
JavaScript.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

59

Podemos tambm selecionar as opes


XPath Tester e RegExp Tester para testar
as frmulas utilizadas nas extraes de
expresses regulares e asseres.

Ouvinte resultado de assero


Este ouvinte no influencia na gerao
do relatrio, mas importante para
sabermos quais asseres passaram e
quais falharam.

Ouvinte relatrio de sumrio

Figura 6. Representao do ambiente de execuo do JMeter

Figura 7. Ouvinte rvore de Resultados

Figura 8. Ouvinte Relatrio de Sumrio

60

Esse ouvinte apresentado na Figura 8,


que nada mais do que uma planilha
que o JMeter gera com as principais
informaes da execuo do teste, como:
quantidade de usurios (amostras) que
executaram cada requisio (rtulo),
tempo mdio em milissegundos (mdia),
tempo mnimo em milissegundos (mn)
e tempo mximo em milissegundos
(mx), entre outras. Esses tempos so
calculados considerando todas as execues simultneas.
Alm destes ouvintes, o JMeter tem
muitos outros que geram grficos e fornecem muitas informaes importantes.
Por exemplo, interessante tambm monitorarmos o banco de dados e o servidor
da aplicao. Assim, possvel avaliar
em que momento do teste a aplicao
caiu, se teve picos elevados e qual a carga
mxima que a aplicao suportar.
A execuo do teste deve ser feita
enquanto o sistema no tem nenhum
outro acesso, apenas a nossa avaliao
rodando para evitar interferncia nos
resultados.
O teste de performance deve ser trabalhado como um projeto de teste, para o
qual precisa ser feito um planejamento
completo, estimar o tempo de criao dos
scripts, o tempo de execuo, tempo de
anlise e da gerao do relatrio final.
Este tipo de teste tem o momento certo
para ser executado: a aplicao deve estar estvel, j deve ter passado por teste
funcional, estar sem bugs e no deve
ter nenhuma melhoria para ser aplicada
durante sua execuo. Por exemplo, no
interessante criar um script de teste
para uma funcionalidade que ainda sofrer alteraes antes da execuo, pois
o script ter que ser atualizado, assim
gerando retrabalho.

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

desen volvimento

O ideal realizar este teste na verso que ser liberada para


ou j est em produo, tomando o cuidado com o horrio da
execuo e configuraes para no afetar os dados reais de
produo.
Neste artigo, a ferramenta utilizada para demonstrao foi o
JMeter, mas antes de iniciar o projeto de teste de performance
em sua organizao, interessante avaliar todas ferramentas
no mercado e avaliar qual delas melhor atende aos requisitos
de seu projeto.

Voc gostou deste artigo?


D seu voto em www.devmedia.com.br/esmag/feedback
Ajude-nos a manter a qualidade da revista!

Referncias e Links:
Bringmann, E. and Kramer, A.: Model-based testing of automotive systems.
In Software Testing, Verification, and Validation, 2008 1st International
Conference on, pages 485-493 (2008).
Maldonado, J. C.; Auri, E. F. B.; Vincenzi, M. R.; Delamaro, M. E.; Souza, S.;
Jino, M. Introduo ao teste de software. Instituto de Cincias Matemticas
e de Computao - ICMC/USP, Nota Didtica, n. 65, 2004.
Leitner, A., Ciupa, I., Meyer, B., and Howard, M.: Reconciling manual and
automated testing: The autotest experience. In System Sciences, 2007. HICSS
2007. 40th Annual Hawaii International Conference on, pages 261 (2007).
Moon, H., Kim, G., Kim, Y., Shin, S., Kim, K., and Im, S.: Automation test
method for automotive embedded software based on autosar. In Software
Engineering Advances, 2009. ICSEA 09. Fourth International Conference on,
pages 158-162 (2009).
[1]Apache JMeter Users Manual
http://jmeter.apache.org/usermanual/index.html
[2] Manual de Utilizao da Ferramenta JMeter
http://www.freetest.net.br/downloads/Ferramentas/JMeter/Manual_JMeter.pdf
[3] Performance Testing Guidance for Web Applications
https://msdn.microsoft.com/en-us/library/bb924375.aspx

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia

61

62

Copyright - Proibido copiar ou distribuir. Todos os direitos reservados para DevMedia