9 771983 127008
00085
85 Edio - 2016
Corpo Editorial
Editor
Rodrigo Oliveira Spnola
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
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
Sumrio
Contedo sobre Agilidade
Destaque - Reflexo
D
s
Feedback
eu
edio
ta
sobre e
s
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.
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.
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.
agilidade
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
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
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.
agilidade
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.
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
agilidade
Estoque
Produo em excesso
Espera
Transporte
Superprocessamento
Movimentao
Defeitos
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.
11
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
O
Diana Corra
llldianalll@gmail.com
https://es.linkedin.com/in/dianacorrea
12
agilidade
13
14
agilidade
15
16
agilidade
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.
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/
17
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
18
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.
agilidade
19
20
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.
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.
22
agilidade
23
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
Planejamento e Gerncia
Nesta seo voc encontra artigos voltados para o planejamento
e gerncia de seus projetos de software.
O
Srgio Salles Galvo Neto
ssallesinf@hotmail.com
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
25
Sigla
Gerente de Projetos
GP
Product Owner
PO
Scrum Master
SM
Equipe
EQ
Cliente
CL
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.
26
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.
27
28
- Reunio Diria;
- Sprint Review;
- Retrospectiva da Sprint;
- Status Report Semanal;
- Controle de Mudanas.
planejamento
29
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.
planejamento
Scrum
No tem
PMBOK
Processos de Iniciao
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)
32
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.
Sprint
Scrum
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.
33
Scrum
PMBOK
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
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.
34
planejamento
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
35
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
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
en gen haria
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.
37
38
en gen haria
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
39
40
en gen haria
41
42
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/
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
43
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.
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;
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
45
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.
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
en gen haria
47
48
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
T
Fernando Oliveira
oliveira.fer@outlook.com - https://br.linkedin.com/in/
fernandooliveirabauru
49
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.
desen volvimento
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.
52
desen volvimento
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.
53
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/
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
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.
55
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
desen volvimento
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
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.
57
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.
58
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.
desen volvimento
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.
59
60
desen volvimento
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
61
62