engenharia software 85 gestao de configuração

9 771983 127008 58000

ISSN 1983127-7

Corpo Editorial

EditorRodrigo Oliveira Spínola

ColaboradoresMarco Antônio Pereira Araújo Eduardo Oliveira SpínolaNicolli Souza Rios Alves

Consultora TécnicaDaniella Costa

Jornalista ResponsávelKaline Dolabella - JP24185

Na Webhttp://www.devmedia.com.br/revista-engenharia-de-software-magazine

85 ª Edição - 2016

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, endereço de bancas de

jornal, entre outros, entre em contato com:

www.devmedia.com.br/central(21) 3382-5038

Publicidade

Para informações sobre veiculação de anúncio na revista ou no site entre em

contato com:

[email protected]

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 sugestão!

Se você estiver interessado em publicar um artigo na revista ou no site ES Magazine,

entre em contato com os editores, informando o título e mini-resumo do tema que você gostaria

de publicar.

Rodrigo Oliveira Spínola [email protected] e Mestre em Engenharia de Software pela COPPE/UFRJ. Realizou seu Pós-Doutorado na

University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos. Atualmente é

Professor Titular do Programa de Pós-Graduação em Sistemas e Computação da Universidade

Salvador - UNIFACS.

Marco Antônio Pereira Araú[email protected] e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em

Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Infor-

mática pela UFJF.

Eduardo Oliveira Spí[email protected]É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine.

É bacharel em Ciência da Computação pela Universidade Salvador (UNIFACS).

Nicolli Souza Rios [email protected]

Bacharel em Ciência da Computação na Universidade Salvador (UNIFACS), Mestranda em Sistemas

e Computação no Programa de Pós-Graduação em Sistemas e Computação da UNIFACS na linha de

Engenharia de Software. É editora da Engenharia de Software Magazine.

12 – Conselhos para Product Owners em formação[ Diana Corrêa ]

Destaque - Reflexão Conteúdo sobre Agilidade, Artigo no estilo Mentoring

18 – Product Owner ou Product Manager? Eis a questão![ Romeu Ivolela Neto ]

Conteúdo sobre Agilidade

06 – Lean IT – Além dos métodos ágeis [ Rodrigo S. Prudente de Aquino ]


Conteúdo sobre Arquitetura e Desenvolvimento, Conteúdo sobre Boas Práticas

Artigo no estilo Prático

43 – Utilizando as ferramentas Mantis, Subversion e Google Code[ Priscila Martins Oliveira ]

Artigo no estilo Prático

36 – Gerência de mudanças utilizando Git [ Álex Leocádio Júlio ]


25 – Modelo híbrido de gestão[ Sérgio Salles Galvão Neto ]

49 – Boas práticas para testes de performance[ Fernando Oliveira ]

Conteúdo sobre Arquitetura e Desenvolvimento, Artigo no estilo Prático

55 – Teste de performance com JMeter[ Dieny Oliveira ]

Sumário

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

Dê

seu Feedback

sob

re esta edição

Dê seu feedback sobre esta edição!

Edição 05 - Engenharia de Software Magazine 5

Programador Java:Por onde começar?Programador Java:Por onde começar?

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

Descubra nesse vídeo como entrar na carreira Java com o pé direito!

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

Fique por dentro:O conjunto de práticas e conceitos Lean aplica-dos em TI vão muito além dos métodos ágeis utilizados no desenvolvimento de software. Nesse artigo, você entenderá que a filosofia Lean sugere não apenas entregar valor rapida-mente ao cliente por meio desses métodos, mas estabelecer uma mudança na cultura da orga-nização levando em consideração os princípios utilizados, o estilo da liderança, o comporta-mento entre os colaboradores, a maneira como as pessoas entendem e resolvem problemas, etc. Entregar valor mais rápido à próxima etapa do processo e, como consequência, perceber a motivação e satisfação da equipe de progra-madores, é um dos grandes benefícios que esse método pode gerar ao negócio.

Lean IT – Além dos métodos ágeisA entrega de valor ao cliente envolvendo todas as áreas da empresa

Rodrigo S. Prudente de Aquino [email protected]

Atua há 18 anos na área de TI. MBA em Enge-nharia de Software pela USP e Bacharel em Ci-ência da Computação pela PUC-SP. Atualmen-te é Coordenador de Tecnologia da Informação no Lean Institute Brasil, o qual trabalha por 5 anos. Trabalhou na ICEC (Coordenador Web), Totvs (Líder de Projeto), Wunderman (Gerente de Tecnologia Web) e Petrobras (Analista de Sistema). Responsável pela revisão técnica do primeiro livro de Lean IT lançado no Brasil (TI Lean - Capacitando e Sustentando sua Trans-formação Lean), revisor dos termos técnicos do livro Liderar com Respeito e autor do livro: WPage - Padronizando o desenvolvimento de Web Sites.

Há anos, equipes de desenvol-vimento de software buscam melhorar seu trabalho no dia a

dia utilizando abordagens tradicionais da engenharia de software como o mo-delo cascata, espiral, etc. No geral, essas abordagens dividiam o desenvolvimento de software em várias etapas antes de um projeto ser entregue ao cliente. Nes-ses modelos, quanto maior o projeto, maiores os riscos de atraso, mudança 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 mudanças de escopo após o projeto ser entregue), porém, quando re-cebiam o sistema, conseguiam entender melhor o problema e consequentemente vislumbrar uma melhor solução.

A entrega de software em pequenos lotes começava a fazer sentido, pois era

uma forma do programador assumir que os problemas dos clientes seriam resolvidos com entregas frequentes e mais rápidas. Essa técnica gerava ótimos resultados e clientes satisfeitos – nasciam os métodos ágeis.

Em 2001, um grupo de programadores assinaram um manifesto que formalizou o movimento para desenvolvimento ágil de software.

Agilidade

Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.

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

AgiLidAdE


Com essa formalização, vários métodos passaram a ser mais conhecidos pela comunidade de TI como o Kanban, XP, Scrum, etc.

O manifesto contém 12 princípios que realçam principalmen-te: as pessoas e interações mais do que processos e ferramentas, software funcionando mais do que documentação abrangente, colaboração com o cliente mais do que negociação de contratos e respostas às mudanças mais do que seguir um plano.

Embora ainda haja programadores que não aceitem total-mente o uso de métodos ágeis em seu ambiente de trabalho (podemos notar pelos debates nacionais e internacionais em grupos no LinkedIn), não seria difícil negar a grande popula-ridade e benefícios que esses métodos trouxeram para várias empresas, principalmente aquelas ligadas ao desenvolvimento de software.

Entregar valor mais rápido à próxima etapa do processo e, como consequência, perceber a motivação e satisfação da equipe de programadores, é um dos grandes benefícios que esses métodos podem gerar ao negócio.

O problemaNa maioria das vezes, o uso desses métodos é uma iniciativa

dos desenvolvedores, coordenadores e, no máximo, gerentes de TI que buscam melhorar seu trabalho no dia a dia sem o apoio da alta administração. Sem esse apoio, não há garantia de que o desenvolvimento terá integração com as demais áreas da empresa e, com isso, as pequenas entregas nem sempre chegarão rapidamente ao cliente.

Desenvolver um produto sem que a empresa toda (pós-vendas, suporte, helpdesk, infra, etc.) esteja alinhada com a maneira em que as entregas são feitas aos clientes pode acarre-tar alguns problemas como: organizações que possuem vários tipos de clientes e, por alguma razão, 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 vários dias depois de pronta. Outro pro-blema que ocorre devido à falta de integração entre as equipes é a velocidade com que chega a especificação da tarefa para a área de desenvolvimento. Diversas vezes, os programadores até conseguem finalizar rapidamente a produção de alguma tarefa, porém ela sempre será entregue atrasada caso a espe-cificação chegue tarde demais.

Antes de aderir a algum método ágil, é necessário que todos os envolvidos na cadeia de valor (fluxo por onde a informa-ção passará) consigam responder as seguintes perguntas: a estratégia está clara para todos da TI sobre o que representa determinado cliente para a organização? As outras áreas da empresa estão preparadas para responder tão rapidamente ao cliente quanto sua área consegue entregar? O seu cliente está preparado para receber nessa velocidade?

Nem sempre as respostas estão claras e bem definidas para todos os colaboradores da organização e qualquer problema de comunicação, dependendo do tamanho da companhia, poderá significar atrasos e modificações nos pedidos dos clientes. Talvez seja por isso que muitas empresas fornecedoras

de produtos ou serviços relacionados a TI começaram a se interessar por algumas das possíveis origens dos métodos ágeis: o Lean.

A filosofia LeanO termo Lean surgiu no final da década de 80 devido a

um estudo organizado pelo MIT (Massachusetts Institute of Technology) sobre a indústria automobilística mundial. Esse estudo resultou em um livro chamado “A máquina que mu-dou o mundo”. O livro destaca, além de outras montadoras, a maneira como a Toyota fabricava seus veículos – algo total-mente inovador. O Sistema Toyota de Produção (STP), como era conhecido, apresentava características muito diferentes do sistema de produção em massa. Os autores entenderam que o STP poderia ser adaptado e utilizado por qualquer empresa de qualquer segmento e então descreveram, no livro, a mentalidade enxuta nas empresas (1996), cinco princípios básicos para que o público pudesse entender melhor a funcionalidade desse sistema revolucionário. Os princípios são:• 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 serviço. Ao identificar o que não agrega valor, você identificará os desperdícios e, com isso, conseguirá eliminar processos, materiais, custos diretos, indiretos e utilizar melhor o tempo das pessoas para se esforçarem em outras tarefas nas quais realmente agregam valor ao produto sob o ponto de vista do cliente;• 2º Fluxo de valor: Identificar quais etapas não agregam valor na concepção do produto e, posteriormente, eliminá-las. 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 em-presas a identificarem onde está o desperdício;• 3º Fluxo Contínuo: Após identificar e eliminar o desperdí-cio seguindo o princípio anterior, nesse momento, a empresa deve criar fluxo contínuo na produção, ou seja, realizar tarefas sem interrupções. Em outras palavras, atender as necessidades dos clientes quase que instantaneamente;• 4º Sistema Puxado: Ao invés da empresa produzir base-ado em estudos ou histórico das demandas, segundo esse princípio, a organização passa a produzir somente quando o cliente realmente compra o produto. Dessa maneira, diminui-se a quantidade de itens em estoques e consequen-temente o dinheiro investido pela empresa para fabricar esses produtos;• 5º Perfeição: Pode ser entendido também como melhoria contínua. É a busca incessante para melhorar o produto, os processos, as pessoas, o fluxo de valor, os fornecedores, etc. Para seguir esse princípio, os colaboradores da empresa devem reconsiderar a maneira como entendem os problemas e passar a utilizá-los como oportunidades de melhoria.

Além dos princípios, a filosofia Lean também aborda modelos mentais de forma a sustentar uma transformação


nas empresas. Diferentemente das práticas tradicionais, no decorrer do artigo destacaremos como o comportamento das pessoas é importante para estabelecer um crescimento organizacional consistente.

No modelo Lean, a opinião do colaborador é valorizada fazendo com que ele amadureça profissionalmente cada vez mais. As pessoas são os elementos mais valiosos de uma empresa e líderes motivadores são o que ela preci-sa para manter e aumentar cada vez mais seu valor no mercado.

Toda pessoa deve adotar a prática do “Genchi Genbutsu” – vá e veja com os próprios olhos. O termo Gemba está relacionado a essa prática e significa local real ou lugar verdadeiro. Ele resume a expressão de ir até o local para viver a situação real com o intuito de entender o problema que está acontecendo naquele momento profundamente. Esse conceito é usado, por exemplo, quando: pessoas ex-perientes de diversas áreas da empresa, que desenvolvem algum produto, participam de reuniões na fase inicial de um projeto junto ao cliente, fazem pessoalmente ajustes de sistemas, protótipos, etc.

Estar no local exatamente no instante em que o erro ocor-reu te ajudará a ter sua própria visão do problema e com ela, informações adicionais importantes para entender o fato por completo e identificar a melhor solução para que ele não volte mais a acontecer.

Uma maneira de entender mais claramente como o tra-balho deverá ser feito é criar padrões simples e visuais para coisas importantes. Esses padrões ajudarão a garantir a qualidade dos produtos e/ou serviços oferecidos pela organização.

Parar a produção é uma maneira de levar a empresa à falência no entendimento de líderes convencionais. Na Toyota, a linha de produção deve ser parada sempre que ocorrer qualquer tipo de problema que prejudique a quali-dade do produto final. Um procedimento chamado cadeia de ajuda faz com que o operador chame o supervisor depois de alguns segundos caso não consiga resolver o problema – o escalonamento é feito até que o problema seja resolvido ou contido. Após alguns escalonamentos, ocorre a parada na linha de produção (não em primeira instância).

Esconder problemas é uma forma direta ou indireta de contribuir para a diminuição da qualidade no produto ou serviço prestado ao cliente final. Deixar os problemas visíveis é uma forma de fazer com que todos saibam o que está acontecendo para que possam ajudar uns aos outros e dar sugestões de melhoria. Com isso, as pessoas poderão aprender também com as falhas cometidas em outros de-partamentos, se prevenindo e melhorando seu trabalho.

Faça uma análise profunda antes de resolver qualquer problema. Veja se o problema possui conexão com outro e tente visualizar a situação 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 solução irá aumentar o trabalho outros colaboradores?• Já possuo algo pronto de forma que possa me ajudar a resolver essa pendência?

A filosofia Lean está sendo difundida cada vez mais por meio de diversas empresas que oferecem consultoria, trei-namentos, eventos e até publicações sobre o tema. Essa nova forma de trabalho vem sendo aplicada há pelo menos 25 anos em organizações de diversos países, e o mais importante: vem trazendo resultados surpreendentes em relação à qualidade e rapidez de entrega de produtos e/ou serviços prestados aos clientes, além de gerar alta lucratividade para companhia.

Não há setores empresariais que essa filosofia não possa ser aplicada e, talvez por isso, ela esteja se expandindo para as demais áreas das organizações chegando ao setor de TI.

Lean ITLean IT é a adaptação dos conceitos do Sistema Toyota de

Produção e da filosofia Lean para a área de TI. Além dos con-ceitos, existem várias ferramentas que devem ser entendidas com plenitude antes de serem adaptadas para TI. Algumas delas serão apresentadas a seguir.

MFVO mapeamento do fluxo de valor ou mapa do fluxo de

valor (MFV) é uma poderosa ferramenta de comunicação e planejamento e serve para que os colaboradores conheçam seus processos de fabricação/produção detalhadamente. Com ela, cria-se uma linguagem entre os colaboradores ini-ciando, posteriormente, um processo de melhoria. A partir de um produto ou serviço que a empresa oferece, inicia-se o desenho do estado atual coletando informações como: eta-pas, número de envolvidos em cada processo, tempos, etc. O próximo passo é o desenho do estado futuro acompanhado do plano de trabalho e implementação. 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 método para resolução de problemas representado

por uma folha de papel de tamanho padrão 297x420 mm. Por meio dela é feita a comunicação entre o subordinado (autor) e o supervisor (orientador) em relação ao problema em que se deseja resolver.

Seu preenchimento se dá da esquerda para direita e algumas de suas características são: fazer com que as pessoas cheguem à causa raiz do problema, utilização do modelo PDCA (Plan, Do, Check, Act) como base para o desenvolvimento do conteúdo, fazer com que o mentor e subordinado obtenham consenso sobre o que deve ser feito, etc.


AgiLidAdE


No A3 é comum a utilização de alguns métodos para encon-trar a causa raiz dos problemas como cinco porquês, espinha de peixe, etc. Veja um exemplo na Figura 2 e tente identificar o problema.

Vejamos agora um exemplo de como utilizar os cinco porquês para identificar o problema indicado na figura:

Por que o computador não está funcionando?Resposta: Porque não está ligado à tomada.

Por que não 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 chão e fica no caminho.Por que o cabo está no chão e fica no caminho?Resposta: Porque é muito longo.Por que o cabo é muito longo?Resposta: ... Não sei.Solução 1: Diminua o comprimento do cabo.Solução 2: Prenda-o com fita na parede.Solução 3: Etc.

Com esse exemplo, percebe-se a dificuldade que as pessoas possuem em realmente identificar os problemas.

Figura 2. Porque não devemos ligar o computador na tomada?

Figura 1. MFV - estado atual (estamparia)

Muitas vezes elas querem chegar rapidamente na solução e nem sempre são eficazes, fazendo com que o problema ocorra novamente. É válido lembrar que podemos utilizar somente um ou mais de cinco porquês para chegar à solução de um problema.

Por que devemos utilizar Lean em TI?Os profissionais da área de TI buscam incessantemente

métodos, bibliotecas, processos e quaisquer boas práticas que


possam ajudá-los no dia a dia a resolver problemas. Porém, nem todas elas possuem grande número de adeptos atualmente.

O uso dos processos de desenvolvimento como RUP, espiral, cascata e modelos como CMMI são exemplos dos que tiveram uma grande perda de profissionais de TI quanto sua utiliza-ção. Talvez, uma das possíveis causas dessa perda foi não ter apresentado os benefícios que as empresas e/ou os clientes esperavam.

Diferentemente de um processo, o Lean é uma filosofia de trabalho. Sua aplicação deve ser usada não 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;• Inovar e melhorar a gestão, além dos processos empresariais;• Auxiliar a organização a alcançar excelência operacional;• Desenvolver as pessoas, melhorando-as cada vez mais sob o ponto de vista do trabalho em equipe, da liderança e na maneira como resolvem os problemas;• Alcançar melhoria dos serviços e desenvolvimento de software.

O framework Lean ITO framework Lean IT, representado na Figura 3, apresenta

um conjunto de conceitos, práticas e métodos a serem utiliza-dos por empresas que desejam passar por uma transformação em TI.

O significado de cada item e algumas relações entre eles são: • Valor ao Cliente: serve como uma premissa básica para o início da transformação. A todo momento, deveríamos pensar como a atividade que desenvolvemos no dia a dia gera valor ao cliente. O que não agrega valor precisa ser entendido como um desperdício e deve ser eliminado. A definição de valor, segundo James Womack no livro Soluções Enxutas, pode ser entendida como:

- Solucione meu problema completamente;- Não desperdice o meu tempo;- Forneça exatamente aquilo que eu quero;- Entregue valor exatamente onde eu quiser;- Forneça valor exatamente quando eu quiser;- Reduza o número de decisões que eu devo tomar para solucionar meus problemas.

• Hoshin Kanri: o Hoshin deve ter uma relação direta com a geração de valor da empresa (norte verdadeiro, plano estra-tégico). Ele serve como um direcionador para as atividades desenvolvidas com objetivo de gerar valor mais rapidamente ao cliente. Por meio do gerenciamento diário, a empresa atu-aliza os dados de seus indicadores informando se está ou não dentro da meta;• Fluxo Contínuo: as atividades da organização devem ser desenvolvidas em fluxo contínuo (sem intervenções);• Sistema Puxado e Nivelamento da Produção: sistema puxado significa fazer algo quando houver uma demanda real do mercado e não uma suposição baseada em estimati-vas que podem falhar. Nivelar a produção significa variar o

desenvolvimento das atividades não gastando esforços em apenas um item ou produto. O propósito é liberar pequenos lotes de diferentes produtos a vários clientes;• Jidoka: esse termo possui vários significados nos quais al-guns deles são: autonomação (automação com toque humano), parar sempre que ocorrer uma falha (não passar o problema adiante), etc.;• Kaizen: a ideia de melhoria contínua deve ser incorporada aos colaboradores da empresa. As pessoas devem dedicar tempo não somente a resolver pendências, mas melhorar seus processos de trabalho constantemente, além de seus produtos e serviços;• Padronização: é preciso ter padrões, seja na manutenção, na construção 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 práticas de ITIL e COBIT não devem ser descartadas, o impor-tante é utilizar apenas o necessário para suportar o fluxo de valor ao cliente e não o interromper;• Estabilização: é necessário ter estabilidade básica nas ope-rações diárias da empresa. A estabilidade fará com que todos os termos explicados anteriormente possam ser utilizados sem interrupção.

A aplicação da filosofia Lean em qualquer tipo de empresa não se faz em poucos dias. Ela pode levar meses para iniciar consistentemente e até anos para estabelecer uma mudança cultural na organização. Os modelos mentais descritos an-teriormente apoiarão essa mudança, porém há outro fator importante que cada colaborador deve ser treinado: identificar os desperdícios.

Kiichiro Toyoda, em 1945, disse a Taiichi Ohno (gerente de produção da Toyota): “Alcancemos os Estados Unidos em três anos. Caso contrário, a indústria automobilística do Japão não sobreviverá”. Naquela época, a produção de um trabalhador americano era nove vezes maior que de um japonês. Estava claro que os japoneses estavam desperdiçando algo. Foi então que Ohno percebeu que se a maior parte dos desperdícios fosse eliminada, a Toyota teria uma chance de se manter no mercado.

Figura 3. Framework Lean TI


AgiLidAdE


Ele categorizou os desperdícios em: superprodução, es-pera, transporte, processamento, estoque, movimentação e defeitos. Essa categorização era uma maneira de facilitar a identificação.

Mesmo naquela época, identificar claramente um desper-dício não era uma tarefa nada fácil. Quando comentamos sobre desperdícios em TI, a dificuldade é ainda maior em identificá-los, pois a informação nem sempre é entendida da mesma maneira por todos da companhia, além de muitas vezes estar mal representada visualmente. Para entendermos melhor sobre o que devemos eliminar em nossas organizações, elaboramos na Tabela 1 alguns tipos de desperdícios em TI e os categorizamos.

O pior tipo de desperdício seja em TI, manufatura ou escritó-rio é a produção em excesso, pois com ele encontramos todos os outros. Entender os desperdícios e focar em sua redução é um dos passos para a conscientização das pessoas e a evolução da organização.

Ter a visão de todos os fluxos de valor da empresa é importan-te para conseguirmos identificar onde há maiores desperdícios. Ao eliminá-los, a organização estará indiretamente contribuin-do para a diminuição do tempo em relação à entrega de valor ao cliente. Em outras palavras, não adianta apenas uma etapa do processo ser ágil (e isso não é uma crítica aos métodos ágeis), é necessário que o cliente perceba o valor nas entregas, e para essa situação ocorrer precisamos de uma empresa enxuta, ou seja, uma empresa Lean.

Estoque

• Excesso de especificações (Backlog);

• Funções no código fonte com as mesmas funcionalidades de outras que já são utilizadas no software;

• O número de licenças de software é maior do que a quantidade de usuários;

• Informações duplicadas desnecessariamente no banco de dados;

• Muitos e-mails não lidos na caixa de entrada dos colaboradores;

• Links não acessados no menu de um sistema.

Produção em excesso

• Produzir alguma coisa que o cliente não usará;

• Reescrever funções que já estão prontas para um projeto;

• Relatórios com informações sem utilidade.

Espera• Desenvolvimento aguardando especificação;

• Usuário espera vários segundos o sistema passar de uma tela para outra.

Transporte• Um programador especificar novamente o que está desenvolvendo e enviar ao responsável (Product Owner);

• Integrações desnecessárias com outras aplicações.

Superprocessamento

• Super processamento da máquina causado por código de baixa qualidade;

• Reuniões improdutivas;

• Muitas funcionalidades acumuladas em poucas telas da aplicação.

Movimentação• Deixar o ambiente de desenvolvimento para esclarecer dúvidas simples de programação (Help);

• Necessidade de o usuário buscar informações em outras telas da aplicação e voltar para onde estava.

Defeitos

• Inconsistência entre a especificação, o resultado esperado e a real necessidade do cliente (este último também pode ser entendido como produção em excesso);

• Erro de programação quando usuário está utilizando;

• Usuário não consegue encontrar o que deseja devido a um problema de usabilidade do sistema.

Tabela 1. Exemplos de desperdícios sob o ponto de vista Lean IT

Referências:

Soares, H. F.; Alves, N.S.R.; Mendes, T.S.; Mendonça, M.G.; Spínola, 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. São 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 An-nual ACM Conference on Object Oriented Programming Systems, Languages, and Applications, Austin, Texas, USA, 1995.

Dê seu voto em www.devmedia.com.br/esmag/feedback

Ajude-nos a manter a qualidade da revista!

Você gostou deste artigo?


Fique por dentro:O Product Owner é um papel em crescente valorização não só no mercado brasileiro, mas também no global. As opções de trabalho para essa função em diferentes indústrias de todos os portes são inúmeras, mesmo em tempos de crise. Mas o que faz de um profissional um grande Product Owner? Este artigo traz 10 pon-tos para que os profissionais ainda em formação possam desempenhar um papel cada dia mais estratégico e menos operacional tornando-se, como alguns chamam, verdadeiros Product Champions.

Conselhos para Product Owners em formaçãoComo se tornar um Product Champion

Diana Corrê[email protected]

https://es.linkedin.com/in/dianacorrea

Publicitária por formação, agilista de coração e gestora de produto por diversão. Há mais de 10 anos atuando na área de tecnologia, metade deles praticando a gestão de produ-tos ágil para criar e desenvolver os produtos certos para o público certo. Possui experiência tanto em produtos para audiências de massa quanto em sistemas que servem para resol-ver grandes problemas das corporações. Atua hoje na Espanha como Product Owner de um e-commerce de viagens e lazer.

O Product Owner é um papel que já se tornou imprescindível na maior parte das empresas atu-

ais. Empresas de mídia e comunicação, comércio eletrônico, fábricas de softwa-re, instituições financeiras, fábricas de tratores... Sistemas internos, aplicativos nativos, portais de massa, software as a service... Independentemente do produto ou da indústria, o Product Owner está presente cumprindo uma função funda-mental para o sucesso do negócio. Mas qual o caminho a seguir para se tornar um grande profissional da área?

O trajeto óbvio é o analista de requisi-tos, de sistemas ou de negócios que, ao ingressar no mundo ágil, faz um curso de um final de semana, tira uma certi-ficação e pronto: nasce mais um Scrum Product Owner no mercado. Na verdade, esses cursos são um excelente pontapé

inicial, mas estão longe de ser suficientes como formação. É um primeiro passo e não o último passo. De modo geral, nessa etapa, o profissional ainda não tem ba-gagem o suficiente para ter uma atuação mais estratégica e menos operacional. É capaz de interagir com a área de negócio, mas de forma muito subordinada. Não possui, ainda, conhecimento suficiente para realmente construir uma visão e uma estratégia de produto sólida. Envolve-se muito mais com o sucesso do desenvolvimento do que com o êxito

EstE artigo é do tipo mEntoring

saiba mais: www.dEvmEdia.com.br/

mEntoring-saibamais

Agilidade



AgiLidAdE


do produto em si. Pouco investe nas fases de concepção e otimização. E, provavelmente, ainda não consegue realmente colocar à prova suas habilidades de comunicação.

Ao ingressar na carreira de Product Owner, o profissional tem duas possibilidades de caminho a seguir. Ou para no básico, faz o arroz e feijão e, com tempo e experiência, pode vir a cumprir o papel de forma adequada ou mesmo boa; ou vence o comodismo e vai além, buscando se tornar um Product Champion.

Mas qual seria então o próximo passo de formação para quem está começando sua carreira e quer ir além do curso do CSPO? Há algum MBA, mestrado ou treinamento adicional? Infeliz-mente não. E também não há receita de bolo. Os caminhos que levam um profissional a se tornar um grande Product Owner são tortuosos e exigem tempo, esforço e dedicação. Mas, para aqueles que possuem a vontade ingressar nessa jornada, a compensação é gigantesca. Na realidade, ser um Product Ow-ner é um trabalho que pode ser muito gratificante e divertido. É uma função extremamente criativa, mas também analítica. É business, mas também é tecnologia. É buscar resultado econômico, mas também a melhor experiência para o usuário final. A vida de um Product Owner é esta eterna dicotomia e aqueles que seguem essa carreira certamente não terão dias monótonos pela frente.

Além disso, o Product Owner é um papel em crescente valori-zação não só no mercado brasileiro, mas também globalmente. As opções de trabalho em diferentes indústrias de todos os portes são inúmeras, mesmo em tempos de crise.

Entenda a carreira que você está escolhendo Um dos motivos pelos quais alguns profissionais nunca con-

seguem sair do operacional é a falta de consciência a respeito do universo em que está inserido. É simples, determinante, mas por incrível que pareça não tão óbvio: a escola de estudo de um Product Owner é a escola da gestão de produto. Muitos iniciantes buscam muita informação sobre Scrum, Kanban, metodologias ágeis, desenvolvimento ágil, priorização do backlog ou como escrever boas user stories. Tudo isso faz parte e é fundamental, mas não é suficiente. É só o básico. Quando olhamos o ciclo de gestão de um produto de forma mais ampla, entendemos que existem as fases de concepção, desenvolvi-mento e otimização, e o Product Owner precisa entender e aperfeiçoar-se em cada uma delas.

Uma boa expressão chave de busca é “gerenciamento de pro-duto ágil” e não apenas “desenvolvimento ágil”. A gestão de produto engloba mais do que coletar requisitos, definir o que o produto tem ou não tem. É mais do que uma lista priorizada de itens a fazer, histórias de usuários e critérios de aceite. É um pouco de modelagem de negócios, de mercado, de experiência de usuário, de marketing digital e de análise de dados. Um excelente Product Owner entende o negócio que está atuando, a função do seu produto dentro desse negócio, quem é seu público alvo, quais os indicadores de performance e como medi-los, e, especialmente, como desenhar, executar e ajustar a estratégia para atingir aquilo que chamamos de sucesso.

O Product Owner é alguém que quer se tornar um grande gerente de produto. Definido isto, há diversos sites, blogs, comunidades de prática e livros que começam 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 também 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 conteúdo, parceiros de mercado, investidores, áreas de ne-gócio, operação e diversas outras áreas. Ele precisa trazer todos esses diferentes interlocutores à colaboração 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 solução. 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 estão impedindo o produto de atingir seus objetivos. Ou, então, adaptar sua estratégia quando necessário.

A verdade é que, estando no papel de Product Owner, reclamar e encontrar desculpas não é uma atitude que gera resultados: “O problema é que o Business Owner não tem tempo para falar de negócio”, “O problema é a área usuária, que se recusa a usar o produto”, “A área de marketing não se interessa pelo produto e não estamos conseguindo uma boa divulgação”. Todas essas são frases possíveis para o contexto de atuação desse papel. Porém, ao se deparar com esse tipo de situação, a melhor atitude a ser tomada em prol do produto é: “O que eu, dono desse produto, posso e vou fazer para mudar este cenário?”, “Qual será a minha estratégia para mudar essa situação?”. Um grande Product Owner tem a consciência de que, mesmo quando a responsabilidade não é sua, de certa forma a responsabilidade é sua. Ou, em linguagem mais mo-derna, é menos “mimimi” e mais “go go go”.

Todo herói tem um mentor Todo aprendiz tem um mentor. Alguém mais experiente para

se observar, obter conhecimento, tirar dúvidas e anseios. No Vale do Silício ou em aceleradoras, o processo de mentoria é bem estabelecido e altamente valorizado. Startups promissoras são mentoradas por gestores de produto e de negócio bem-sucedidos e com mais bagagem de mercado. É uma boa ideia, portanto, repetir esse modelo em um âmbito mais pessoal e de carreira, identificando possíveis mentores que possam ser uma referência, fonte de conhecimento e inspiração para o Product Owner em formação.

O mentor não necessariamente é o gestor direto do profis-sional. Pode ser um colega. Um consultor. Alguém de outra área. O importante é que seja alguém que possua o conjunto


de conhecimentos e habilidades que se deseja desenvolver. É importante dizer que o mentor não é um professor. Seu

papel e obrigação principal dentro da empresa provavelmen-te não é ensinar. É possível, portanto, que essa pessoa não possua muita disponibilidade de tempo. Sempre utilizando o bom senso, o Product Owner deve buscar criar esses espaços para aprendizagem, troca de conhecimento e, principalmente, obtenção de feedback e orientação. “Posso participar do seu workshop como observador? Gostaria de aprender mais sobre como conduzir um momento como este”, “Excelente o traba-lho que você realizou. Poderia me explicar a lógica que você usou?”, “Você teria 30 minutos para fornecer feedback sobre roadmap do meu produto? Seria interessante eu obter a visão de alguém mais experiente”, “Você gostaria de um assistente para seu próximo workshop com clientes? Seria uma grande experiência para mim” são apenas alguns cenários possíveis para aprender mais rápido a partir do conhecimento alheio.

Posto que as habilidades que um Product Owner deseja obter são vastas e de campos diferenciados, é bem possível 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á começando a ter seus pró-prios mentorados.

É importante aprender a falar negócioMuitos Product Owners reclamam que não se sentem re-

almente donos do produto. Que não possuem espaço para tomada de decisão. Embora, infelizmente, isso de fato ocorra mesmo em empresas ditas ágeis, a verdade é que autonomia não se ganha, se conquista. E é bem mais difícil conquistar autonomia sem falar a língua dos negócios.

Um profissional só ganha liberdade para trabalhar quando conquista a confiança das pessoas que o circundam: gestores, investidores, áreas de negócio, colegas, entre outros. Essa con-fiança muitas vezes se constrói com base no nível de segurança e conhecimento que o Product Owner demonstra a respeito do trabalho que está desenvolvendo. Mas, como determinar uma boa estratégia de produto desconhecendo as particula-ridades do negócio? Como ter bons argumentos para provar seus pontos de vista quando não se conhece os dados? Um Product Owner que não entende do seu negócio de atuação provavelmente não conseguirá agir em um âmbito estratégico e se estagnará em uma atuação meramente operacional. Não conseguirá de fato colaborar ativamente com a área de negócio, pois não 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 tra-balhar em diversos negócios e contextos diferentes – mesmo dentro de uma mesma área ou empresa. A tarefa número um para esse profissional quando inicia em um produto qualquer é entender tudo o que puder não só sobre o produto, mas também sobre o negócio que está inserido: qual o mercado, como ele funciona, quem são os players e as referências, qual o modelo de negócio, quais os objetivos de negócio, o que está

indo bem e o que está indo mal, quais as oportunidades de atuação, quem são as pessoas, como funcionam ou não fun-cionam os processos, etc. Ao longo do caminho ele verá que algumas dessas respostas podem inclusive ser inexistentes. Nesse caso, ao invés de se conformar e trabalhar no escuro, o profissional deve buscar construir e trazer a luz esse co-nhecimento junto com as pessoas pertinentes. O produto não tem modelo de negócios bem definido? Pois bem, o Product Owner deve trazer as pessoas competentes para clarificar ou criar conjuntamente essa visão.

Leva um tempo, mas o quanto antes o P.O. entender tudo isso, o quanto antes ele vai ganhar a confiança daqueles que o rodeiam. E certamente poderá executar um trabalho mais sólido e bem embasado. Nesse nível, Product Owner e Business Owner de fato poderão trabalhar como um par. Obviamente, é esperado que o Business Owner tenha um conhecimento um pouco maior do negócio que o Product Owner. Mas este terá um conhecimento maior de gestão de produtos. Conseguindo conversar de igual para igual, essa dupla tem condições de chegar mais longe e obter melhores resultados.

Mas como obter este conhecimento? Conversando com pessoas de diversas áreas, acessando relatórios e números que a empresa já tenha disponível, acessando as ferramen-tas corporativas (QlikView, Google Analytics, etc.), fazendo pesquisas, lendo matérias sobre o mercado ou pesquisando os concorrentes. Enfim, os meios são inúmeros, mas o impor-tante é, aos poucos, planejar como ir preenchendo os gaps de conhecimento que todo Product Owner que está ingressando em um novo negócio, independentemente do nível de senio-ridade, possui.

Cultura data drivenUm dos aspectos mais valorizados atualmente pelo mercado

em um Product Owner é a sua capacidade de tomar decisões com base em dados. No campo da gestão de produto, há cada vez menos espaço para achismos, palpites e estratégias pouco embasadas. Quando um P.O. toma uma decisão a respeito do seu produto, ele deve ser capaz de explicar seus motivos. Ele precisa saber mostrar qual o racional utilizado para chegar àquela conclusão. E isso provavelmente só será possível através de números.

Independente se este possui uma área de métricas como apoio ou não, o bom Product Owner define quais são os indicadores que precisa acompanhar para entender se o seu produto está cumprindo seus objetivos. Ele monitora esses números com frequência. Mais importante ainda: ele compartilha essa infor-mação com seu time, ajudando a fortalecer essa cultura em toda a empresa. Frente aos resultados, ele planeja ações para mudar aquilo que vai mal e comemora com todos os aspectos que vão bem. E, principalmente, questiona o tempo inteiro as suas pró-prias decisões: “Eu realmente possuo argumentos, fatos e dados suficientes para seguir este caminho?”. Um bom P.O. antecipa e está preparado para responder as perguntas difíceis.

A cultura analítica, na verdade, auxilia muito nas discussões e negociações a respeito do roadmap e do futuro do produto.


AgiLidAdE


Não é à toa que a frase “contra fatos não há argumentos” se torna cada vez mais célebre no mundo corporativo. A verdade é que aqueles que estão fora de contexto não são obrigados a entender imediatamente a lógica que um Product Owner utili-zou – depois de muito raciocínio e trabalho - para traçar a sua estratégia de produto. É de responsabilidade deste, portanto, torna-la mais visível, clara e facilmente compreensível para to-dos os interlocutores. O fato é que, com um bom embasamento, orientado à dados, o P.O. tende a conquistar cada vez mais a confiança 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 experimentação. Na gestão de produto, os profissionais devem ter a humildade de entender que, até que se comprovem, suas expectativas de resultado são meras hipóteses. Hoje existem diversas ferramentas e meios para realização de teste A/B, por exemplo. Uma boa prática é testar se as hipóteses são válidas antes de tornar-se aparentes as novas funcionalidades do pro-duto para todo o universo de utilização. Quem trabalha com e-commerce sabe: uma mera mudança de texto pode impactar a conversão e gerar um prejuízo financeiro considerável. Se o impacto de uma funcionalidade é zero ou negativo, o Product Owner provavelmente vai tomar a decisão de não lançá-la. E tudo bem. Uma vez que a gestão de produtos é baseada em hipóteses, muitas vezes os palpites estão mesmo errados. Faz parte do jogo. Não tem problema falhar desde que se falhe rápido e o erro gere aprendizagem e mudança de estratégia. Mais importante que isto, é não deixar o ego insistir no erro. Se o “feeling in my guts” aponta para um lado, mas os resulta-dos apontam claramente para outro, o bom profissional tende a ser pragmático e, pelo menos para esta rodada, admite a derrota.

Há muita literatura disponível hoje em dia a respeito de teste e validação de hipóteses mesmo quando o produto não está em uma etapa de otimização. Lean Startup, Customer Development, Lean Metrics e Javelin Board são boas fontes de informação para aqueles Product Owners em formação que querem aprender mais sobre isto. E se não existem no Brasil muitos cursos dispo-níveis sobre a gestão de produto propriamente dita, há diversos workshops e eventos focados em empreendedorismo e startups que contribuem imensamente para a formação dos profis-sionais da área. O P.O. não deixa de ser um empresário, um empreendedor, e o quanto mais envolver-se com este campo de estudo, mais desenvolverá as habilidades e conhecimentos necessários para realizar uma boa gestão de produto.

Outro ponto importante é que a cultura data driven não exclui a realização de testes com uma abordagem mais qualitativa. O Product Owner e os números devem ser os melhores amigos, mas, ainda assim, clientes são pessoas. O fator humano não deve ser esquecido. É sempre uma boa estratégia, para aqueles que possuem esta oportunidade, ouvir e trazer o usuário para perto, observar como este interage com o produto e entender melhor seu perfil e expectativas. Sendo assim, durante qual-quer fase do produto, o P.O. pode contar com seus colegas de UX para desenvolver pesquisas com clientes, testar navegação

e fluxos, coletar impressões sobre concorrentes e responder diversas outras perguntas e indagações.

O Product Owner também é um comunicadorUma das habilidades fundamentais de um bom Product

Owner é a sua capacidade de comunicação. Ele deve falar várias línguas. Não, não estamos falando aqui de línguas estrangeiras – embora certamente a aprendizagem de uma segunda língua sempre é um diferencial, especialmente em empresas multinacionais. O P.O. deve saber falar business, como já mencionado. Mas, mesmo não tendo perfil técnico, também tem que conhecer um pouco de “tequiniquês” para conseguir entender e interagir com o time de desenvolvimento. Em muitos cenários, terá que aprender, ainda, a falar a língua das pessoas da operação. Quase todo o profissional da área possui diversos interlocutores, de diversos perfis, e diferentes estilos de comunicação. Cabe ao Product Owner saber circular naturalmente em todos estes meios e falar a língua de todas estas pessoas. Comunicar-se com as partes interessadas, ga-nhar engajamento e empatia. Ser e fazer parte.

Adicionalmente, todo o Product Owner deve usar sua capa-cidade de interagir para comunicar também o seu produto. Vende-lo internamente. Ser seu maior advogado. E gerar nos outros a vontade de advogar em prol do produto também. Um produto bem comunicado é aquele que, quando o P.O não está na sala, uma parte interessada qualquer – desenvolvedor, Business Owner, operação – saiba responder pelo menos as questões básicas a respeito do mesmo. A sua visão de futuro. Os próximos passos. Onde estamos agora. É incrível como um Product Owner que também é um bom comunicador encontra aliados para a sua estratégia.

Por fim, faz parte ainda do trabalho estar sempre pensando em como comunicar o produto para o público final. Como o produto vai interagir com o usuário? Qual a linguagem de comunicação? Um bom P.O. sabe que não precisa depender apenas do marketing para divulgação. A melhor promoção é a espontânea. É aquela feita dentro do próprio produto. Quando o LinkedIn mostra uma lista de amigos que já estão cadastrados no site e no final instiga o usuário a convidar os conhecidos ainda não registrados, ele está fazendo nada mais do que comunicação. Este é o tipo de promoção que um Product Owner deve estar sempre pensando. Como utilizar o próprio produto e a própria base de usuários para conquistar ainda mais clientes?

A prática leva à perfeiçãoAssim como o ágil prega a aprendizagem prática, a formação

de um P.O. também é iterativa incremental. Muitos iniciantes sentem-se inseguros em atuar com técnicas antes nunca uti-lizadas. Não se sentem capazes por não terem experiência. Mas a verdade é que a única forma de aprender realmente é expondo-se à prática. Um bom exemplo disto são os workshops. Este tipo de técnica 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


são só algumas opções que podem vir a calhar para quem está dando os primeiros passos na construção de uma nova iniciativa. A ideia é pegar um time de pessoas multidisciplinar, que tenha as habilidades e conhecimentos necessários para que seja atingido o objetivo final do workshop. Neste caso, o papel do P.O. é o de facilitador da criação colaborativa. Este é outro ponto importante a ser considerado: as decisões e criações compartilhadas tendem a ser mais assertivas. É fato que várias mentes pensam melhor do que uma. Um Product Owner sábio é aquele que sabe aproveitar o conhecimento e potencial das pessoas ao seu redor.

Para quem nunca conduziu um workshop, ou mesmo de-seja utilizar qualquer outra técnica 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 quórum menor e com pessoas que o Product Owner se sente mais à vontade. Quando é possível, pode-se buscar ainda o auxílio de um profissional com mais senioridade para servir de coa-ching nesta primeira experiência. O importante é sempre pedir feedback ao final. Entender o que os participantes gostaram e o que mudariam. A partir das opiniões coletadas, ajusta-se o planejamento para uma próxima vez. Certamente, técnica e performance vão melhorando progressivamente a cada nova facilitação. O fato é que não existe possibilidade de melhoria na falta de tentativa. Então, o melhor que um Product Owner em formação pode fazer é começar a testar as técnicas que lhe interessam, e já.

Gestão de tempo e trabalho colaborativoProvavelmente aqui o Product Owner em formação já che-

gou à conclusão de que precisará ser um verdadeiro herói. Vai ter que jogar no gol, no ataque, na defesa e ser o técnico, tudo simultaneamente. Além de se qualificar em seu foco de atuação, precisará aprender também sobre negócio, tecnologia, comunicação, marketing e responsabilizar-se sobre o produto em um âmbito global. Sim, é muito a fazer e são poucas as horas em um dia. Bom, ninguém disse que ia ser fácil e, como já mencionado, os caminhos que levam um Product Owner a tornar-se um Product Champion são mesmo tortuosos.

Como, então, organizar o tempo para cumprir todos os as-pectos do trabalho de um Product Owner e ainda conseguir ter vida?

Primeiramente, uma das habilidades mais básicas deste papel é a capacidade de fazer uma boa priorização. Da mesma forma que este profissional prioriza seu backlog, ele deve também fazer escolhas a respeito do seu próprio tempo. Um P.O. não precisa lidar com todos os assuntos relacionados ao seu produto ao mesmo tempo. Ele tem que ser capaz de entender qual é o seu próximo passo: aquilo que, se não for feito agora, prejudicará o produto. O Lean prega que as coisas sejam feitas no “último momento responsável” para que, em caso de mu-dança, não tenhamos desperdícios relativos a trabalhos que nunca serão aproveitados. E esta é provavelmente uma boa diretriz para qualquer Product Owner: o foco apenas naquilo

que é importante neste momento. Os conceitos do ágil também são muito úteis aqui. Melhor iniciar uma só tarefa e finaliza-la do que abrir várias frentes ao mesmo tempo e não conseguir direcionar nenhuma adequadamente.

Há algumas atividades, é claro, que são on going. É inte-ressante reservar alguns momentos do dia e da semana para estudar os números do produto, pensar no futuro, ou fazer benchmark de mercado, por exemplo. É fundamental entender este tempo como algo tão fixo como uma reunião recorrente, por exemplo. Um dos maiores desafios de qualquer Product Owner é, mediante os incêndios do dia a dia, encontrar tem-po para atuar de forma estratégica. Mas, se o profissional não desejar ficar parado apenas no âmbito operacional, ele precisa levar muito a sério os espaços na agenda dedicados à estratégia do produto. Bloquear alguns momentos do dia para isto pode servir como uma boa alternativa para promover esta organização.

Outra reclamação constante no universo dos Product Ow-ners é a existência excessiva de reuniões. Aqui a priorização também é fundamental: “Preciso mesmo estar nesta reunião ou minha presença é dispensável e posso ser informado sobre os acordos posteriormente?”, “Há alguém do time que possa me representar?”. Muitas vezes o P.O. precisará dizer não ou delegar. Ele precisa escolher em quais momentos sua presença de fato é imprescindível.

Outro ponto bem complicado no Brasil é que as reuniões ten-dem a ser dispersivas, não possuem objetivos claros, e muitas vezes duram mais tempo do que o necessário. O profissional não deve ter medo de cobrar dos participantes respeito ao tem-po e à agenda da reunião. Os 30 minutos perdidos esperando outros participantes atrasados, ou investidos em assuntos não relativos ao tema proposto, são os mesmos 30 minutos que vão faltar no final do dia para resolver uma questão de valor. É importante, ainda, que todos na sala saibam antes de iniciar qualquer discussão 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 importantíssimo para que o Product Owner possa ser bem-sucedido é o entendimento que este não está jogando sozinho e não é um exército de um homem só. Embora o Product Owner tenha que liderar e seja responsável pelo sucesso do produto em diversos aspectos, isto não sig-nifica 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 influencia-dor. Ele precisa abrir a discussão com o marketing a respeito da divulgação do seu produto e garantir que está na pauta deste outro time. Precisa engajar o time de desenvolvimento e transmitir claramente a missão do produto e de onde se quer chegar. Deve trabalhar em conjunto com as pessoas da área de indicadores e métricas. Mas, a partir daí ele deve deixar que cada um possa colaborar, produzir, construir, enfim, fazer o seu trabalho. Um produto evoluiu através da realização de esforços conjuntos e a pior coisa que um Product Owner pode


AgiLidAdE


fazer para o seu produto, para seus colegas e para si mesmo, é adotar uma postura altamente centralizadora. A melhor atitude é a de confiança nas pessoas. Tudo se resume em engajar, não em coordenar.

Troque experiênciasDa mesma forma que é interessante que o Product Owner

busque mentores e profissionais com mais experiência para se espelhar, é uma boa ideia retribuir este conhecimento adqui-rido compartilhando suas próprias experiências 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 saudável e provavelmente desejável em qualquer time ou empresa. Hoje mentorado, amanhã mentor.

Cabe ao profissional buscar meios de engajar-se, ainda, com a comunidade que está inserido através de eventos, fóruns, institutos e afins. A troca de informação, experiência e dis-cussões não somente sobre o papel do Product Owner, mas especialmente sobre a gestão de produto em si só faz o mercado tornar-se cada vez mais qualificado.

Muitos iniciantes na área pensam que não possuem nada de útil a ser dividido, posto que seu tempo de experiência ainda é curto. Isto é um erro. Todos os profissionais atuantes, indepen-dentemente do nível de senioridade, possuem boas histórias para contar. Cases de erros e de acertos, de dificuldades ou de alternativas criadas para resolver velhos problemas. Partindo do princípio de que ninguém é o dono da verdade absoluta, o Product Owner iniciante tem muito a colaborar com a co-munidade contando sobre seu próprio processo de formação, as pedras que encontrou pelo caminho e como conseguiu transpor estes obstáculos. Certamente outros profissionais em desenvolvimento conseguirão enxergar a si mesmos nestes relatos e aprender de forma mais rápida a partir da experiência compartilhada.

Muitas empresas estimulam jovens profissionais a criarem seus blogs, submeterem propostas de palestras em eventos da área ou participarem ativamente de discussões como fish-bowls, por exemplo. No mínimo, este Product Owner estará exercitando suas habilidades de comunicação, além de dar sua contribuição pessoal para o desenvolvimento da área de gestão de produto como um todo.

A jornada de cada um é individualCabe a cada um entender o que funciona e o que não funciona

em seu contexto ou empresa, descobrir seu próprio estilo de

atuação e começar a pensar em seus próprios conselhos para outros colegas. Não existe, mesmo, receita de bolo. Não existe curso, manual, ou passo a passo que seja suficiente para criar um bom P.O. Apenas a prática e a atitude correta é que trazem a experiência. Aqueles que desejam ser grandes profissionais devem sair da zona de conforto, se auto provocar constante-mente e buscar a melhoria contínua das suas habilidades e conhecimentos. Devem estar atentos, o tempo todo, sobre o que há de novo no mercado. E até mesmo – por que não? – inventar suas próprias técnicas.

Ao invés de assumir o papel de um expectador passivo da própria carreira, aquele que quer se tornar um grande Product Owner deve tomar as rédeas do seu próprio desenvolvimento pessoal e profissional. Quando este sente que já não está mais aprendendo, é hora de mudar. Mudar sua atuação, mudar de área ou até mesmo de empresa. É o desafio que gera os grandes profissionais e este, portanto, deve ser constante.

Links:

Apresentação: Concebendo produtos de forma ágil (e divertida!)slideshare.net/llldianalll/workshop-101-concebendo-produtos-de-forma-gil-e-divertida-scrum-gathering-rio-2015-51691990

It´s All in How You Slicehttp://agileproductdesign.com/writing/how_you_slice_it.pdf

Página de Roman Pichlerwww.romanpichler.com/

The Lean Startuptheleanstartup.com

Product Managementproduct-management.alltop.com/

Build Better Business Modelshttp://www.businessmodelgeneration.com/

Lean Startup Machinehttps://www.leanstartupmachine.com/





Fique por dentro:Este artigo será útil para entender os pro-blemas vigentes na gestão de produtos web decorrentes da atuação dos Product Owners e Product Managers nas empresas. Os conflitos entre estes papéis e as lacunas em suas respec-tivas atribuições vêm corroendo o artefato mais importante dos times ágeis: o product backlog. Elemento central da eficácia e da entrega de valor ao negócio, este artefato infelizmente tem sido construído sobre blocos de requisitos esmigalhados, visão insuficiente de produto e distância dos usuários finais comprometendo, desta forma, o objetivo de todo time ágil: a en-trega de valor aos clientes.

Product Owner ou Product Manager? Eis a questão!Conheça problemas decorrentes da má gestão de produtos no mercado de tecnologia

Romeu Ivolela [email protected]

Consultor em Gerenciamento de Produtos e Designing de Serviços. Graduado como tec-nólogo pela universidade Opet Parané e pós-graduado em história da filosofia pela PUC-SP. Certificações: SCJA, CSM, CSD, CSPO e Accredi-ted Kanban Practitioner Training.

Com o advento dos métodos ágeis, a complexidade de outrora em desenvolver e distribuir softwa-

res tem diminuído ao longo dos últimos anos. Os métodos ágeis como Scrum e XP promoveram uma verdadeira revo-lução na forma de se pensar e construir software. Times multifuncionais, com-postos por desenvolvedores, testadores, user experience designers, agile masters e Product Owners, modificaram o mer-cado de tecnologia e as estruturas das empresas tradicionais.

Como a história nos ensina, toda re-volução traz consigo a semente do novo sobre uma proposta declinante. O con-flito é inevitável e as estruturas e ideias obsoletas não são facilmente esquecidas ou abandonadas.

Foram intermináveis os debates sobre o que seria feito, por exemplo, com os

gerentes de projetos, uma vez que os agile masters estavam assumindo as atribuições daqueles. Qual seria o futuro dos gerentes? Poderiam estes assumir este novo papel? Deveriam abraçar o destino e navegar em outros mares?

Alguns gerentes de projetos realmente abraçaram a causa ágil e se tornaram excelentes agilistas. Outros, voltaram o foco ao desenvolvimento de pessoas, infelizmente tão carente nas empresas.

Agilidade



AgiLidAdE


Obviamente, não podemos nos esquecer dos que ficaram no limbo, presos no passado e infelizmente muito presentes em nosso dia a dia corporativo.

Com a propagação dos métodos ágeis, dois papéis logo se des-tacaram nos times: o agile master e o Product Owner. Ambos os papéis são imprescindíveis ao sucesso de um produto. O agile master foca no processo e conduz o time na estrada da efi-ciência. O Product Owner, por sua vez, se responsabiliza pela eficácia. Eficácia para um Product Owner é tornar o produto desejável e útil aos clientes, e viável e rentável ao negócio.

Para atingir esta eficácia, o Product Owner utiliza várias ferramentas: business model canvas, roadmaps, data driven, lean startup, design thinking, design service dentre tantas outras técnicas possíveis.

Além desse conjunto de ferramentas, um profissional de produtos precisa ter certas características, como ser capaz de analisar o produto de forma holística, autonomia para deci-dir o que priorizar e cortar do backlog e ter alta capacidade de negociação para mediar os conflitos de interesses entre stakeholders e clientes, sendo estes representados nas empresas pelo gestor de produto.

A visão holística do produto evita decisões com viés espe-cializado ou departamental. A autonomia se apodera deste profissional para a tomada de decisões e o lado negociador media, trata e alinha com todas as partes interessadas, o que e o porquê de cada requisito priorizado, gerando convergência e unicidade de trabalho e de informação.

Pode-se destacar que a falta de visão e autonomia incapacita e mina a negociação do produto, resultando em graves problemas pelos quais os times ágeis vem enfrentando: Product Owners sem empowerment e com visões de negócio fragmentadas ou nulas, tornando estes profissionais geradores de especificações ao invés de geradores de oportunidades e valor.

Mas o que está acontecendo realmente? Por que não é dado o empowerment necessário aos Product Owners? Por que lhes falta tanta informação? Por que estes profissionais mal con-seguem dar o feedback de sucesso ou fracasso do que estão priorizando?

Podemos achar algumas respostas nas abordagens tradicio-nais. Vale lembrar que a engenharia de produção de software foi baseada nas engenharias civil e naval. Estas engenharias não eram os modelos mais aptos para a engenharia do softwa-re, mas eram os sistemas de produção conhecidos até então.

Junto do famigerado waterfall, as empresas de tecnologia herdaram toda estrutura matricial que servia de arcabouço para este sistema de produção. Hoje temos um blend entre este modelo e as metodologias ágeis que chegaram com força nas empresas a partir de 2001.

O passado e o presente se fundem em um ambiente com-plexo, caótico e nebuloso, gerando insatisfação e desgaste constantes.

Dentro deste cenário, uma análise faz-se necessária. Res-quícios e fragmentos da história da engenharia de produtos podem ajudar na busca do que se perdeu para entender melhor o cenário vigente. Seguindo a ordem cronológica, a

história da gestão de produtos começa em 1931, quando Neil H. McElroy escreve um memorando para a empresa Procter & Gamble solicitando algumas contratações. Os candidatos deveriam acompanhar as vendas para gerenciar melhor o produto, publicidade e promoções, tudo isto o mais próximo possível do cliente. Este memorando projeta os alicerces do “Brand Management” e mais tarde da própria disciplina de “Product Management”.

Vale ressaltar que McElroy, além de lançar os alicerces da disciplina de Product Management, também foi secretário de defesa americano, ajudou a fundar a NASA e tornou-se conselheiro na Universidade de Stanford, onde influenciou outros dois notáveis: Bill Hewlett e David Packard.

Na HP, as ideias de Product Management ganharam impulso. O usuário ocupava o centro das tomadas de decisões e a área de produtos representava a voz do cliente internamente, influen-ciando desta forma grande parte das empresas de hardware e software daquela época.

A disciplina de Product Management ganha um novo capí-tulo a partir da década de 60, com a introdução de uma nova abordagem - chamada de “mix de marketing” - formulada por Jerome McCarthy em seu livro Basic Marketing. O mix de ma-rketing começa 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 serviços que respondam as necessidades dos clientes), Preço (valor co-brado pelo bem e\ou serviço prestado), Praça (distribuição dos produtos aos mercados consumidores) e Promoção (é a parte de comunicação e propaganda, lembrando e persuadindo o cliente sobre o produto ofertado).

Entretanto, devido aos longos períodos de desenvolvimento dos produtos, que poderiam levar meses ou até mesmo anos, os Product Managers concentravam-se em somente 3 Ps: Preço, Praça e Promoção. O último P (Produto) era delegado a outras áreas das empresas, como Pesquisa & Desenvolvimento. Esse foi o padrão dominante das quatro décadas seguintes.

Somente em 2001, com a publicação do manifesto ágil, inicia-se um novo capítulo na história da disciplina de Product Management. A partir desse momento, os Product Managers ganham flexibilidade para mudar, questionar e propor no-vos requisitos de forma mais dinâmica e intensa. É possível 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 são debatidos de forma multidisciplinar e intensa, envolvendo as métricas do analista de dados, a interação e comportamento do usuário analisados pelo profissional de UX, o esforço de implementação dos desenvolvedores, o SEO (Search Engine Optimization) e o SEM (Search Engine Marketing) do profissional de marketing e a automação do testador.

O sucesso do produto torna-se o resultado do trabalho multi-disciplinar, onde o mix de marketing (Praça, Preço e Promoção) está agora intimamente ligado e dependente do “P “abandona-do pelos Product Managers de outrora, o P de produto.


Infelizmente, esse cenário animador não se aplica até hoje na maioria das empresas, as quais mantém distintas as gestões de produtos e desenvolvimento, gerando uma série de infor-túnios, prejuízos e anomalias que nada trazem de valor às empresas e aos clientes, ou seja, todos saem perdendo.

Dentre as anomalias está a distinção entre Product Owners e Product Managers dentro das empresas. Estes dois papéis são sinônimos para um mesmo fim (criar produtos de valor aos clientes e rentáveis para as empresas) e sua distinção funcional e nominal pode ser considerada uma anomalia mercadológica.

Os conflitos decorrentes destas distorções são inevitáveis. Delegar somente o desenvolvimento e execução dos requisi-tos aos Product Owners e seus respectivos times é deixá-los distantes do contato com os clientes, da visão do produto e do propósito do mesmo, gerando miopia em quem deveria estar atento aos mínimos detalhes.

Privar Product Managers da priorização e escrita de requi-sitos e do contato com o time de desenvolvimento é arruinar a qualidade do trabalho colaborativo, fomentar o handoff de informações e a incentivar a falta de unicidade, elementos que só corroboram para o fracasso do produto.

Outra grave anomalia é a transferência de responsabilidades e atribuições dos gerentes de produtos a outros profissionais e áreas, promovendo decisões cartesianas, departamentais e especializadas, incentivando a visão de silos ao invés da visão do propósito.

O ponto máximo destas distorções é composto pelo tempo desperdiçado, o investimento perdido e o produto que deveria servir, mas no final não serve para nada.

A gestão holística e centralizada do produto faz-se necessária. Desta forma, é possível executar uma priorização assertiva dos requisitos, a unicidade do propósito, a comunicação e transparência de informações e métricas, e desta forma atingir o sucesso do produto.

Nas próximas seções, serão detalhadas as atribuições dos product owners e product managers, algumas anomalias mercadológicas encontradas e propostas para resolver os problemas identificados.

Atribuições de Product Manager/Product Owner (PO)Antes de definir as atribuições de um Product Owner/Pro-

duct Manager, é válido reforçar algo importante: ambos são o mesmo papel e a coexistência de ambos não é um bom pres-ságio. O Product Owner (PO) é o Product Manager no modelo ágil, mais propriamente dito no framework Scrum. Porém, outras metodologias como o Kanban (idealizado por David J. Anderson) também trabalham com este profissional.

O Product Owner é um papel multifacetado e não espe-cializado, justamente porque precisa navegar entre diversas disciplinas para obter o sucesso do produto. Vamos listar as atribuições deste profissional:• Visão do produto: definir e capturar a visão do produto, bem como partilhar ela com o time e stakeholders. É possível que o PO também represente a visão do CEO ou de um diretor de produtos e trabalhe para que a mesma seja realizada;

• Responsável pelo ROI (Return On Investment): o PO é o principal responsável por identificar oportunidades de mer-cado e melhorias que podem trazer mais valor ao produto. O acompanhamento constante das métricas e do mercado é de vital importância para este fim;• Organização e priorização do backlog: o backlog do produto é o artefato onde ficam todos os requisitos que serão imple-mentados, geralmente escritos no formato de user story. Sua organização e priorização seguem das histórias de maior valor para as de menor valor ao negócio;• Planejamento de release: o lançamento de uma nova versão pode conter correções de bugs, novas features, melhorias e até mesmo reformatação do modelo de negócio. 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 mediação e decisão final;• Gerenciar orçamento: apesar de infelizmente passar desper-cebido por muitos profissionais de produtos, cada user story tem um custo de produção que deve ser usado como critério de priorização. É muito comum também em Startups, POs serem responsáveis pelo EBTIDA do produto e responderem pelos gastos dos seus respectivos times;• Autoridade para tomar decisões: todos concordam que o trabalho colaborativo traz muito valor ao produto, e o PO não é o sabe tudo do time, apesar de estar sempre muito bem informado. Porém, como em qualquer outra área, alguém precisa ter a palavra final e dar a direção correta. Este profis-sional é o PO.

Perfil de um de Product Manager/Product Owner (PO)Por ser um profissional multifacetado, a tarefa de encon-

trar bons gestores de produtos torna-se árdua. Em seu livro “Inspired: How to create products customers love”, Marty Cagan descreve as características exigidas de um Product Manager/PO e que compõem o mosaico funcional do que deve ser um gestor de produtos:• Paixão por Produtos: Product Managers são apaixonados por produtos. Estão sempre falando de modelos de negócios inovadores e de como estes modelos impactam a vida das clientes. Um Product Manager que não persegue e aprimora constantemente um modelo de negócios, é somente um gerador de requisitos, nada mais;• Empatia pelos clientes: clientes são o propósito do produto. Entenda-se por empatia colocar-se no lugar do cliente, com-preender seus medos, anseios e contexto. Cada vez mais, faz sentido usar abordagens como o Design Thinking para criar produtos com foco nos usuários, e não em nós mesmos;• Inteligência: é necessária uma mente perspicaz para cap-turar oportunidades e costurar o trabalho multidisciplinar de forma valiosa e focada;


AgiLidAdE


• Ética e Integridade: é uma grande responsabilidade ge-renciar um produto. Quando um profissional se propõe a tal missão, deve agir de forma ética e com zelo pelo produto sobre sua alçada. Negligenciar a gestão de um produto é uma forma rápida de matá-lo. Afinal se o Product Manager não se importa com o produto, quem mais se importará?• Confiança: o Product Manager é um líder, e mais do que isto, um vendedor do seu produto. A confiança passa a mensagem de segurança ao time, investidores e demais interessados de que o produto está em boas mãos;• Atitude: decisões difíceis devem ser tomadas. Atitude é a energia que impulsiona a resolução de problemas. Não seria incorreto dizer que o sucesso ou fracasso de um produto seja a somatória das atitudes tomadas ou não pelos Gerentes de Produtos;• Tecnologia: este é um ponto sempre controverso, porém é muito difícil escrever boas user stories sem o mínimo conhe-cimento de tecnologia. Produtos web são feitos desta matéria prima, e conhecer as principais tecnologias, padrões, proto-colos e arquitetura web ajudam na negociação com os times e na priorização de requisitos com os mesmos;• Foco: um Product Manager deve decorar a fórmula de lei de little: Tempo de espera = quantidade de trabalho em anda-mento / taxa de entrega. Esta fórmula nos ensina que, quanto mais trabalho em andamento, maior o tempo de espera de entrega. Imaginando que estamos falando de três 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 rápidos para a empresa e, inevitavelmente, o que for de menor valor ficará para trás;• Gestão 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 assédio constante dos stakeholders, que têm como objetivo a realização dos seus respectivos interesses. Faz parte do ofício do Product Mana-ger gerenciar este assédio, contanto que ele não prejudique o tempo do produto;• Comunicação: talvez um dos quesitos mais importantes. Um gestor de produtos está a todo momento negociando e vendendo o seu produto através da fala. A arte de se comuni-car de forma clara e objetiva deve ser um traço inerente deste profissional, e obviamente esta qualidade é transferida para o ato da escrita dos requisitos;• Habilidades de negociação: delegar, vender, comunicar, mediar, promover, informar, priorizar, todas estas ações se concretizam no contato com o outro. Trabalhar nos melhores acordos através da empatia, serenidade, foco e ética sempre garantem um resultado satisfatório.

Anomalias encontradas na gestão de produtos webNesta seção, serão analisadas algumas anomalias envolvendo

Product Owners (PO) / Product Managers no mercado, ini-ciando pela própria contradição entre estes dois papéis, bem como outros problemas decorrentes da descaracterização e

desconstrução das responsabilidades e atribuições do gestor de produtos.

Anomalia 1: Gestão do produto dividido entre Product Owner e Product Manager

Este cenário é decorrente da fusão dos elementos dos pro-cessos ágeis com a disciplina de product management, prin-cipalmente 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 várias distorções e adaptações para estes perfis, dentre elas a divisão da gestão do produto em dois, onde o Pro-duct Owner ficou responsável pela execução 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 aquisição e vendas, o que explica de certa forma a predominância de profissionais de marketing atuando neste papel. Em suma, o Product Owner olha para dentro da empresa (desenvolvimen-to), enquanto o Product Manager olha para fora (mercado).

Este cenário traz uma série de consequências: lacunas no en-tendimento dos requisitos, falta de alinhamento e planejamento entre as áreas envolvidas, fragmentação da autoridade e respon-sabilidade do produto, problemas decorrentes de ruídos e falta de comunicação, perda de foco e dificuldade de priorização.

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 histórias que favoreçam o alcance destas respectivas metas e certamente o mesmo aconteceria se um arquiteto fosse o dono do backlog, que acabaria por sua vez priorizando histórias mais técnicas. O problema é que o foco em receita desvaloriza o restante das métricas importantes do funil do produto: aquisição, ativação, retenção e recomendação.

A receita, portanto, é a etapa final do caminho do usuário, desde a sua chegada até o momento que ele paga por um determinado serviço. Porém, o foco obsessivo em receita traz como consequência uma gestão de produto imediatista, com-prometendo a gestão sustentável de longo prazo.

Desta forma, toda e qualquer história que não seja relacionada diretamente à receita, não será priorizada. É uma questão de tempo para que o valor do produto seja corroído, e após algum tempo, ele perca o valor e interesse dos usuários e deixe de existir no mercado.

Anomalia 3: Gerente de Projetos atuando como Gerente de Produtos

O gerente de projetos tem a responsabilidade de alinhar os requisitos, garantir a comunicação e o tracking do projeto e, na maioria das vezes, também assume tarefas de gestão de pessoas, como controle de pontos de horas e demais assuntos


administrativos. Delegar a gestão do produto a este profissio-nal envolve uma série 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 execução e entrega do projeto, porque não há tempo para olhar oportunidades e melhorias do produto.

Ainda dentro da estrutura matricial, raramente este pro-fissional tem a oportunidade de sugerir ou opinar sobre os requisitos, pois os mesmos são definidos por diretores ou um board executivo, cabendo ao gerente de projetos o papel de executor e não de questionador.

A própria estrutura matricial não é pensada para gestão de produtos, e quando há um gerente de produtos nesta estrutura, ele compartilha dos mesmos problemas encontrados na ano-malia 01, onde o product manager divide a responsabilidade do produto com outro profissional.

Portanto, um gerente de projetos assumir a gestão de pro-dutos, no cenário matricial, é a mesma coisa de não ter um. Dentro da perspectiva ágil, as responsabilidades de gestão do projeto são 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.

Além disto, a metodologia ágil já delega a gestão do produto ao Product Owner, o que elimina a necessidade de o gerente de projetos assumir a gestão de produtos. Porém, caso isto aconteça, o product owner terá assumido também a responsa-bilidade de gestão do projeto, descaracterizando o seu papel no time e impactando a saúde do produto. Esta anomalia também afetará o agile master, que terá um desafio extra na missão de migrar a gestão 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 importância deste pro-fissional para o sucesso de um produto. O user experience designer, popularmente conhecido como UX, é o profissional encarregado de toda experiência e interação dos clientes com os produtos. Isto não é pouca coisa, estes profissionais passam anos estudando técnicas como user mapping, focus group e técnicas de pesquisas qualitativas e quantitativas, design thinking, design service, psicologia dentre tantas outras.

Apesar de haver uma intersecção entre o product manager e UX, uma vez que ambos advogam em prol do usuário, isto não os fazem ter as mesmas atribuições e responsabilidades. A entrega de valor aos clientes é obtida através do trabalho de várias disciplinas, sendo UX somente uma delas.

Muitas vezes é necessário sacrificar o valor ao usuário final por questões técnicas, restrição de orçamento e conflitos internos. Achar o ponto de equilíbrio, na maioria das vezes, é uma tarefa árdua. Apesar do valor ao cliente ser o ponto a

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 usuário, isto o impede de uma visão mais holística, principalmente sobre a disciplina técnica, o que explica o porquê deste profissional não ser recomendado para a gestão do produto.

Anomalia 5: Gerente de Tecnologia atuando como Gerente de Produtos

A matéria prima dos produtos web é a tecnologia. Somente os profissionais desta área compreendem a complexidade que toda esta disciplina envolve. As áreas são diversas: banco de dados, infraestrutura, operações e desenvolvimento. E para aumentar a complexidade, todas estas áreas são lideradas por profissionais especializados e com diferentes skills.

Todo profissional de tecnologia é focado em resolução de problemas e dentro de sua especialidade, procura sempre fazer isto de forma técnica. Aqui reside o perigo em delegar a gestão de produtos para um gerente de tecnologia.

Tomando como referência as anomalias 2 e 4, onde se expla-nou os problemas de especialidades serem donas do backlog do produto, o gerente de tecnologia irá priorizar naturalmente histórias de cunho técnico, e os demais requisitos irão perder importância e valor. É o típico caso onde o produto tecnica-mente é impecável, porém 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 ProdutosProcesso é a forma de se construir ou produzir algo. Um

gestor de produtos eficiente deve ter na manga conhecimentos e técnicas desta disciplina, principalmente conceitos prove-nientes do sistema Toyota de produção (Lean).

O agile master é a fonte e autoridade quando o assunto é processo. Ele é responsável por prover coach e treinamento aos times de desenvolvimento, e muitos destes profissionais vêm se especializando para atender aos anseios dos profissionais de produtos, lhes ensinando técnicas como Lean Startup, Lean, Kanban dentre outras.

Apesar do skill de processos ajudar na gestão do produto, esta habilidade só ganha impulso se for usada para orquestrar a evolução e retorno do investimento de um produto. É forte a tendência do agile master em focar mais no processo do que na evolução do produto, o que explica o porquê deste profissional não poder liderá-lo.

Product Manager/PO generalista x especialistaComo detalhado nas seções 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 con-segue desenvolver a visão holística e convergir os trabalhos dos especialistas em um ponto em comum: a proposta de valor ao produto.


AgiLidAdE


Muitos leitores podem achar que não é possível um gestor de produtos ser tão generalista. Na verdade, o perfil pregado como ideal no mercado, o do especialista em um determinado campo, não é o único a ser tido como padrão. Esta visão de especialização profissional é fruto da filosofia cartesiana e da revolução científica, onde a visão pluralista do conhecimento começa a dar lugar a análises e estudos mais segmentados.

Porém, no renascimento o modelo era justamente o contrário, 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 seção Links), nomeia estes profissionais de multipotencialidades. Ela ex-plana 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 vários assuntos diferentes (os generalistas).

São dois perfis que se complementam e que juntos geram ótimos resultados. O Product Manager/PO mapeia, com-partilha e gerencia a visão e proposta do produto, e a partir desta orientação, os especialistas começam a construção e materialização da visão.

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. Porém, estes males podem ser remediados. Antes de mais nada, vale ressaltar a diferença conceitual entre produto e projeto.

Projeto é uma empreitada com começo e fim, com objetivo de entregar um produto ou melhoria. Um produto, por sua vez, é um meio de se entregar um serviço e com prazo indefinido de término (termina quando o modelo de negócio se esgotar).

Este conceito deriva do modelo Service Dominant Logic (SDL), introduzido por Stephen Vargo e Robert Lusch em 2004, em uma edição do Journal of Marketing. Tennyson Pinheiro e Luis Alt, explicam este modelo no livro Design Thinking Brasil: “Este modelo defende uma mudança na antiga pers-pectiva tradicional de produtos, que enxerga serviços apenas como atributos e custos de uma oferta. Segundo a SDL, tudo é serviço. Produtos são, então, bens tangíveis que orbitam no ecossistema de um serviço. “.

Vamos dar um exemplo: um e-commerce de roupas é um serviço de vendas e entrega de vestuário. Esta é a “serventia” e valor do mesmo ao cliente. Um serviço por sua vez é composto por um ou vários produtos, que são os meios de se entregar um serviço. No caso deste e-commerce, o pagamento é um produto, pois ele permite que o cliente pague suas compras utilizando vários meios de pagamento. O delivery é outro produto, pois permite que a compra seja entregue na casa do cliente. Ambos produtos orbitam o ecossistema do serviço de vendas de vestuário.

O serviço de música Spotify é uma das empresas que usam este modelo. Dentro deste serviço, os times de desenvolvimento são autônomos, multifuncionais e responsáveis cada um por

um produto. Exemplo: os playlists do Spotify são gerenciados por um time, que é responsável pelo uso e entrega de valor deste produto dentro do serviço de música Spotify. Este time tem como meta concretizar a visão e melhorar as métricas deste respectivo produto, cujo responsável é o Product Owner. Portanto, o PO define a visão, métricas e histórias, 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 serviços 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 próprio eBay. O fato da indús-tria de software estar adotando o modelo de produtos para o desenvolvimento de softwares não significa que projetos não são mais necessários.

Produtos podem ter projetos, isto é perfeitamente normal dentro da concepção de que um projeto é um trabalho finito. Um projeto é bem-vindo quando o escopo e necessidade do que será implementado são conhecidos, válidos 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ê não constrói times perenes e focados na evolução de produtos, mas sim times efêmeros focados na en-trega de projetos. Quando estes acabam, todo o conhecimento é pulverizado em novos projetos e times. Esta forma de traba-lho é ineficiente e retrógrada, pois gera pouco envolvimento dos profissionais, que são sempre alocados temporariamente em alguma frente. São os profissionais que trabalham mais focados em tickets do Jira do que em histórias de evolução e valor aos clientes.

Um time focado em produto usa sua energia e inteligência em melhorar de forma incremental e colaborativa o produto. Estes times usam de métodos, como o Lean Startup, para validar as suas hipóteses 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 dinâmica, o sentimento de “dono” é incorporado pelo time, e os ganhos não 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 tríade 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 independência e liberdade de trabalho; • Propósito, razão 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 cenário diário de incertezas,

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

complexidades e desafios que envolvem o desenvolvimento de um produto.

O papel Product Manager/Product Owner está sendo deba-tido como nunca. Esta discussão era previsível, uma vez que os times ágeis vêm progredindo e cumprindo o seu papel de serem mais eficientes no desenvolvimento de software. Logo, é natural que as atenções se voltem para a eficácia, cuja respon-sabilidade cabe ao Product Manager/Product Owner.

Entender as atribuições, responsabilidades e importância 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.




Links:

Inspire: How to create products lovehttp://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 projetizadahttp://pmkb.com.br/artigo/vantagens-e-desvantagens-de-uma-empresa-projetizada/

The History and Evolution of Product Managementhttp://www.mindtheproduct.com/2015/10/history-evolution-product-management/

The Scrum Guidehttps://www.scrumalliance.org/why-scrum/scrum-guide

Palestra de Emilie Wapnick no TED: Why some of us don’t have one true callinghttps://www.ted.com/talks/emilie_wapnick_why_some_of_us_don_t_have_one_true_calling

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

Fique por dentro:Gerenciar projetos de desenvolvimento de softwa-re não é uma tarefa simples, pois o uso de guias como o PMBOK leva muitas empresas a adotarem métodos muito rígidos e trabalhosos enquanto o mercado busca por agilidade. Por outro lado, os métodos ágeis como o Scrum resolvem a questão da agilidade e entrega de valor agregado e tor-nam mais clara a visibilidade e previsibilidade da entrega do produto do projeto, porém com certas perdas não tratadas por metodologias ágeis como controle de custo, riscos, contratações, aquisições,

entre outros. Desta forma, o melhor caminho é a união 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 é possível trabalhar com abordagens ágeis e tradicionais em conjunto no gerenciamento de projetos. Essa abordagem híbrida traz benefícios e permite aos gestores definir um modelo de gestão ágil, documentalmente estruturado, eficiente, efi-caz e bem aceito em modelos de maturidade como o MPS.BR e o CMMI.

Modelo híbrido de gestãoUnindo abordagens ágeis e tradicionais

Sérgio Salles Galvão [email protected]

Gerente de Projetos certificado PMP, ITIL, Microsoft entre outras. Atuando na área de informática desde 1992 e, a mais de 10 anos liderando equipes em projetos de desenvol-vimento e implantação de softwares. Nos úl-timos oito anos atuando como Scrum Master em projetos em diversas tecnologias e ramos de negócio.

Planejamento e Gerência

Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.

O gerenciamento de projetos envolve um conjunto de ativi-dades não triviais que possuem

variações ágeis e nem tão ágeis assim. Dois arcabouços que se destacam para apoiar as atividades do gerenciamento são PMBOK e Scrum. Neste artigo não abordaremos como estes são diferentes, nem mesmo as diferenças entre eles. O foco será na união dos pontos fortes e como os processos podem coexistir tran-quilamente e de uma maneira enxuta.

Este artigo é resultado de experiências anteriores em empresas de software as

quais necessitavam ter controles mais tradicionais, até mesmo de forma a controlar os trabalhos e esforços des-pendidos, bem como ciclos rápidos de desenvolvimento gerando entregas de valor ao cliente utilizando-se o método Scrum. Durante a execução de todos os seus processos são geradas diversas in-formações relevantes aos clientes e par-tes interessadas através da aplicação de conceitos e artefatos tradicionais cons-truídos tendo como base o PMBOK.

Um projeto antes de ser iniciado dentro da empresa, foi orçado e precificado, ou


seja, houve uma análise prévia da equipe sobre o escopo onde foram estimados os esforços e, principalmente, estabelecidas as prioridades por entregável considerando-se o valor agregado a cada uma das entregas. Isso significa já existir um Product Backlog (lista de itens do produto) orçada e priorizada. As etapas seguintes, conforme estabelecido no Guia PMBOK como iniciação, planejamento, execução, monitoramento e controle e, o encerramento ocorrerão levando em conta este artefato – Product Backlog o qual foi extraído do contrato firmado entre as partes.

Sendo assim, o presente artigo descreverá os papéis, ferra-mentas utilizadas e artefatos gerados, processos e iterações durante todo o período de desenvolvimento do software contratado. Parte-se do pressuposto do conhecimento prévio da existência e do funcionamento básico do Guia PMBOK e da metodologia Scrum.

É necessário também contextualizar o projeto, cujo escopo está determinado no product backlog o qual contém diversas estó-rias. Não é relevante a ordenação das estórias as quais compõem o product backlog, mas sim, a prioridade ou o valor agregado gerado a cada estória produzida. Outra informação relevante é o esforço planejado para o desenvolvimento de cada estória. Sendo assim, o projeto contém várias estórias que serão agrupadas e produzidas em cada Sprint (a cada duas ou quatro semanas). Por exemplo: o projeto possui 10 estórias que foram priorizadas e organizadas em três Sprints. A primeira Sprint entregará cinco estórias, a segunda Sprint entregará três estórias e a terceira Sprint entregará dois estórias. A grosso modo, entendemos que o projeto terá duração de 12 semanas, considerando que cada Sprint possuirá quatro semanas de duração. Então, o plano do projeto constará exatamente esta informação.

Papéis e responsabilidades – Definindo quem faz o queTodo e qualquer projeto de desenvolvimento de software

depende, em sua maioria, de pessoas. Estabelecer os papéis e responsabilidades de cada um, em qualquer metodologia, é a principal atividade. Em um modelo híbrido de gestão existirão os papéis complementares e exclusivos para que não haja sobreposição de funções, otimizando e especializando determinadas atividades. Os papéis e suas responsabilidades estão descritos na Tabela 1.

Ainda sobre os membros da equipe, vale destacar uma diferença entre o conceito de equipe ao que se refere o Guia PMBOK e a metodologia Scrum. Para o Guia PMBOK, todos os membros que compõem a equipe são nomeados e atribuem-se atividades a cada um destes membros, que são chamados de recursos. Este conceito leva à dependência de atividades entre os recursos. Isso significa dizer que o trabalho de um recurso depende da conclusão do trabalho de outro. Esta característica leva ainda à geração de cro-nogramas bastante complexos, podendo gerar informações como a alocação e até permitir realizar o chamado balanceamento de recursos, onde as atividades são distribuídas ao longo do tempo disponível para cada recurso de forma a alcançar a utilização máxima diária possível para garantir a entrega do projeto. Já na metodologia Scrum existe apenas o conceito do Time (Equipe) que é responsável pela entrega do projeto. A distribuição das atividades é organizada pela equipe da melhor forma para, da mesma forma, garantir a entrega da meta da Sprint.

Ferramentas e artefatosExistem diversas ferramentas e técnicas recomendadas para

a execução dos processos no guia PMBOK e Scrum. Neste artigo será apresentado o conjunto de ferramentas adotados

Papel Sigla Descrição e Responsabilidade

Gerente de Projetos GP

É a pessoa de contato e responsável 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 possíveis desvios, mantendo as comunicações entre as partes,

controlando os riscos, escopo, custo, prazo, entre outros.

Product Owner PO

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 negócio 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 também é responsável por

manter a visibilidade a todos do product backlog.

Scrum Master SM

Disseminador da adoção da metodologia Scrum junto à equipe, auxiliando na organização dos membros da equipe, permitindo que evoluam em sua auto-organização e

aumentem sua produtividade. Também é o responsável por remover quaisquer impedimentos os quais interrompam ou possam vir a interromper o bom andamento do

desenvolvimento das atividades durante a Sprint.

Equipe EQ

Equipe são as pessoas que trabalham no projeto e na Sprint. Na metodologia Scrum utiliza-se o termo auto organizada e multidisciplinar. Isso não quer dizer que todos os

membros da equipe fazem todas as atividades, pois isso não 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: Não 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 documentação necessária; um analista de testes também pode ser o analista de requisitos, etc.

O principal ponto a ser observado é a equipe ser composta por membros experientes e suficientes para a construção do software conforme o estabelecido.

O tamanho da equipe também poderá variar conforme a necessidade, porém é 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 dinâmica de trabalho, bem como estarem confortáveis com os valores e a cultura da organização, caso contrário, a performance poderá

não ser a esperada.

Cliente CLÉ a parte mais interessada. Geralmente é formada por uma equipe composta de pessoas de departamentos de TI e da área usuária. Sua participação em todo o processo é

fundamental para garantir o alinhamento das expectativas junto ao escopo a ser produzido.

Tabela 1. Papéis e Responsabilidades


PL ANEJAMENTo


- Entradas:- Product Backlog;

- Resultados servem para:- Sprint Backlog;- Atualizações Plano Projeto.

• Ferramenta / Artefato (ou Processo): Sprint backlog (meta da Sprint) [Scrum]

- Descrição: toda a força de trabalho da equipe estará con-centrada na entrega do Sprint backlog. Trata-se de uma lista contendo todas as estórias a serem produzidas na Sprint. Todos os eventos, a partir do início da Sprint, tomarão como base esta meta, tais como reuniões diárias, impedimentos, mudanças, etc. - Entradas:

- Plano da Sprint;- Product Backlog;

- Resultados servem para:- Quadro Kanban;- Acompanhamento da Sprint;- Monitoramento e Controle;- Gráfico Burndown;- Revisão da Sprint (Sprint Review)- Retrospectiva da Sprint (Sprint Retrospective); - Encerramento.

• Ferramenta / Artefato (ou Processo): quadro Kanban [Scrum]

- Descrição: o uso do quadro Kanban é ideal para uma melhor visualização do andamento (o que falta ser feito, o que está sendo validado ou qual estória possui problemas) do projeto. Não 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 estórias, são registrados em post-its. Um exemplo pode ser observado na Figura 1.

como padrão. Este conjunto não deve, de forma alguma, limi-tar a adoção de outras ferramentas das quais possam vir a ser necessárias dentro da cultura da empresa.

Os processos envolvidos neste modelo híbrido, tanto tra-dicionais quanto os ágeis, serão explorados e detalhados no decorrer deste artigo.

O conjunto de ferramentas e artefatos eleitos como essenciais estarão descritos, em forma de tópicos, a seguir. A organização dos tópicos se dará em três seções, onde:1. Ferramenta / Artefato (ou processo): contém a nomenclatura da Ferramenta / Artefato (ou processo);2. Descrição Ferramenta / Artefato (ou processo): descreverá a função ou objetivo da Ferramenta, Artefato (ou Processo). Vale lembrar que os processos serão descritos brevemente para auxiliar na identificação das interações entre os processos, ferramentas e artefatos;3. Entradas / Resultados (Ferramentas / Artefatos / Processos): demonstrará, de forma sucinta, quais são as origens de infor-mações ou melhor, de onde vêm as informações que alimentam as ferramentas, artefatos ou processos. Os resultados gerados por eles irão gerar informações as quais, por conseguinte, irá alimentar outras ferramentas, artefatos ou processos em outras etapas do desenvolvimento.

Os itens definidos serão nomeados e haverá uma notação ([Scrum] ou [Guia PMBOK]) indicando a qual metodologia pertence. Por exemplo: o artefato product backlog receberá a nomeação [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]

- Descrição: lista de itens (requisitos) que compõe o produto. Nesta lista encontram-se, além dos itens, as estórias (regras de negócio) de como um destes requisitos deverá funcio-nar. Estes itens (estórias) são priorizados conforme o valor agregado ao negócio. O Product Backlog será atualizado conforme a conclusão e entrega das sprints ou conforme mudanças solicitadas pelo cliente.- Entradas:

- Contrato assinado- Resultados servem para:

- Plane jamento da Spr int (Spr int Planning);- Plano da Sprint;- Sprint Backlog.

• Ferramenta / Artefato (ou Processo): plano da Sprint [Scrum];

- Descrição: define o que será feito e entregue na Sprint. São os itens priorizados no product backlog os quais a equipe determinou ser possível entregar no período de uma Sprint (uma Sprint tem a duração de duas a quatro semanas em média). Figura 1. Quadro Kanban


Geralmente, um quadro Kanban possui as seguintes colunas:• Sprint Backlog (Meta): são todas as estórias a serem realiza-das na Sprint. Assim que cada estória começa a ser produzida, o respectivo post-it é movido da coluna “Sprint Backlog” para a coluna “Em andamento”;• Em andamento: são as atividades em execução naquele período. Conforme seu andamento, os post-its serão movidos para as próximas colunas;• Em validação: são as estórias em processo de validação, seja junto ao cliente ou passando por algum processo automatiza-do. Antes da estória ser dada como entregue, ela precisará ser validada. O processo de validação poderá variar conforme a necessidade do cliente e da cultura da empresa que está de-senvolvendo o software;• Entregue: são todas as estórias que foram concluídas e acei-tas pelo cliente. A validação geral ocorrerá no evento Sprint Review onde o conjunto todo será entregue e será recebido o aceite do cliente;• Impedimentos: as estórias onde surgiram problemas, sejam estes por falta de alguma informação, definição ou dependên-cia externa, deverão ter seu post-it correspondente movido para esta coluna.

- Entradas:- Plano da Sprint;- Sprint Backlog.

- Resultados servem para:- Gráfico Burndown;- Acompanhamento da Sprint;- Reuniões Diárias;- Status Report Semanal;- Controle de Mudanças.

• Ferramenta / Artefato (ou Processo): Gráfico Burndown [Scrum]

- Descrição: é uma forma gráfica de demonstrar o anda-mento da Sprint. Seu objetivo é representar diariamente o progresso do trabalho em desenvolvimento. Após cada dia, o gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado. Para a geração do gráfico Burndown, é necessário o preenchimento da planilha de horas. Vale ressaltar que não há uma indicação direta da utilização do gráfico Burndown no guia do Scrum, porém, existe uma citação informando se tratar de uma boa prática. É comum a equipe de desenvolvimento usar esse gráfico ao longo da Sprint para medir os pontos das histórias 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 gráfico Burndown está representado na Figura 2. - Entradas:

- Plano da Sprint;- Sprint Backlog;- Planilha de Horas.

- Resultados servem para:- Monitoramento do Projeto;

- Reunião Diária;- Sprint Review;- Retrospectiva da Sprint;- Status Report Semanal;- Controle de Mudanças.

Figura 2. Gráfico Burndown

• Ferramenta / Artefato (ou Processo): Planilha de Horas [Guia PMBOK]

- Descrição: os membros da equipe devem lançar as horas trabalhadas na realização de cada estória que compõe a meta da sprint (Sprint Backlog). Esta atualização deve ser diária e, preferencialmente, antes da realização da reunião diária. O preenchimento da planilha de horas irá gerar o gráfico Burndown, no qual será possível à equipe verificar o andamento, problemas ou desvios para o cumprimento da meta da Sprint (Sprint Backlog). Novamente lembramos que o gráfico Burndown não é um artefato obrigatório, po-rém se for adotado, a planilha de horas deverá ser adotada obrigatoriamente.- Entradas:

- Equipe atualiza planilha de horas (lançamento diário de horas trabalhadas)

- Resultados servem para:- Gráfico Burndown;- Reuniões Diárias;- Sprint Review;- Retrospectiva da Sprint;- Monitoramento e Controle do Projeto.

• Ferramenta / Artefato (ou Processo): Reunião Diária (regis-tro) [Scrum]

- Descrição: na metodologia Scrum, é determinado que seja realizada a reunião diária. Este encontro deve ser rápido (15 a 20 minutos em média) e deve abordar três pontos:

1. O que foi feito;2. O que será feito em seguida;3. Impedimentos encontrados.

Por questões de controles internos e até mesmo alguns mo-delos de maturidade, sugere-se o registro destas reuniões. Este registro, que pode ser uma ata simples ou uma postagem em um blog interno, servirá como meio de obter transparência e registro dos acontecimentos, como um diário de bordo.


PL ANEJAMENTo


Uma outra grande utilidade deste registro é servir de base para a próxima reunião diária para verificar se houveram mu-danças ou desvios desde a última reunião. Estas informações, uma vez registradas, deverão ser utilizadas nos processos de encerramento.

- Entradas:- Equipe relata os três pontos e o Scrum Master registra na ferramenta escolhida (blog, ata, etc.).

- Resultados servem para:- Reunião Diária (próxima reunião a acontecer);- Sprint Review;- Retrospectiva da Sprint;- Status Report Semanal;- Controle de Mudanças.

• Ferramenta / Artefato (ou Processo): Sprint Review (registro) [Scrum]

- Descrição: é o registro do que foi produzido como resul-tado da Sprint. Trata-se de um encontro onde a equipe irá apresentar o que está sendo entregue com o término da Sprint ao cliente. Neste encontro, o cliente dará o aceite daquilo que foi disponibilizado.- Entradas:

- Aceites do Projeto;- Retrospectiva da Sprint;- Controle de Mudanças.

- Resultados servem para: - Registros organizacionais;- Aceites do Projeto (assinados);- Aceites Mudanças (assinados);- Product Backlog – atual ização das estórias finalizadas.

• Ferramenta / Artefato (ou Processo): Retrospectiva da Sprint (registro) [Scrum]

- Descrição: é similar ao conceito do guia PMBOK de lições aprendidas. É uma reunião onde a equipe irá voltar no tempo e avaliar o andamento e conclusão da Sprint. Basi-camente, devem ser registrados três itens:

1. O que foi bom nesta Sprint e deve ser mantido para as próximas Sprints;2. O que pode ser melhorado para as próximas Sprints;3. O que deve ser abolido das próximas Sprints.

Este registro é fundamental para que a empresa possa tomar decisões e realizar mudanças organizacionais de forma a au-xiliar o bom andamento das próximas iterações.

- Entradas:

- Registro de retrospectivas de Sprints concluídas;- Solicitação de mudança nos processos organizacionais (atualização de processos de trabalho).

- Resultados servem para:- Registros organizacionais – Retrospectiva da Sprint;- Encerramento do projeto / lições aprendidas;- Solicitações de mudança organizacional (atualização de processos de trabalho)

• Ferramenta / Artefato (ou Processo): Status Report Semanal [Guia PMBOK]

- Descrição: Trata-se do registro dos acontecimentos no pro-jeto para o cliente. É uma ferramenta vastamente conhecida e aplicada por aqueles que seguem o Guia PMBOK. Basica-mente, o relatório de Status Report Semanal, demonstra o que estava planejado, o que foi realizado, a comparação entre o planejado e realizado (escopo, custo e prazo), as mudanças, os riscos, o planejamento futuro, etc. Este relatório é elaborado pelo Gerente de Projeto e enviado às partes interessadas de forma a dar ciência e transparência ao que está acontecendo. As informações contidas no relatório de Status Report Sema-nal, poderá variar conforme a necessidade e cultura de cada Empresa. O seu objetivo principal é registrar o que aconteceu e as ações a serem tomadas para corrigir desvios e gerenciar riscos, dando ciência às Partes Interessadas. Em algumas organizações, os Status Report Semanais são considerados como aceites parciais do projeto. - Entradas:

- Gráfico Burndown;- Reuniões Diárias (registro).

- Resultados servem para:- Monitoramento e Controle;- Controle de Mudanças;- Encerramentos.

• Ferramenta / Artefato (ou Processo): Processo de Controle de Mudanças [Guia PMBOK]

- Descrição: Ao se utilizar o Scrum, as mudanças são vistas de maneira a agregar um valor maior ao negócio. Apesar de raro, o cliente pode vir a solicitar que alguma estória seja retirada. Também é possível que alguma estória possua desdobramentos maiores do que os previstos inicialmente e sugerem uma revisão. Geralmente, a equipe irá entender esta mudança e irá verificar se é possível absorver o esforço ou, simplesmente, remover a estória reprogramando-a para ser executada em uma outra Sprint a ser planejada. Para o Guia PMBOK, toda e qualquer mudança deverá ser registrada, ava-liada (orçada) e discutida verificando a procedência ou não de inclusão desta mudança ao escopo do projeto. Para tanto, o planejamento do projeto deverá sofrer uma atualização considerando a mudança. O fato é a necessidade de que as mudanças sejam registradas e controladas, seus impactos e o aceite do cliente para que elas sejam implementadas. - Entradas:

- Gráfico Burndown;- Reuniões Diárias (registro);- Orçamentos e Estimativas de Mudanças (registros).

- Resultados servem para:- Controle de Mudanças atualizado;- Product Backlog;- Plano da Sprint;- Meta da Sprint (Sprint Backlog);- Plano do Projeto;- Monitoramento e Controle;- Status Report Semanal.


• Ferramenta / Artefato (ou Processo): Processos de Mo-nitoramento e Controle (Guia PMBOK) - Descrição: O Scrum avalia o que está acontecendo du-rante a execução da Sprint, mas não os impactos gerados pelos desvios dela no projeto como um todo. Desta forma, as informações geradas durante a execução dos processos irão alimentar os dados necessários para o monitoramento e controle do projeto.- Entradas:

- Product Backlog;- Plano da Sprint;- Meta da Sprint;- Reuniões Diárias;- Planilha de horas;- Gráfico Burndown;- Controle de Mudanças.

- Resultados servem para:- Status Report Semanal;- Encerramentos; - Aceites.

• Ferramenta / Artefato (ou Processo): Processo de Encerra-mento (Guia PMBOK)

- Descrição: são os processos responsáveis por obter os aceites formais das entregas do projeto. Durante a execução dos processos de encerramento, também ocorre o evento de lições aprendidas o qual, neste modelo híbrido, será ali-mentado pelo resultado do evento Scrum – Retrospectiva da Sprint. Podem surgir solicitações de mudança nos processos organizacionais os quais serão tratados junto ao PMO (es-critório de projetos) para a devida avaliação e implantação das mudanças propostas. Em alguns casos, os processos de encerramento podem também servir para desalocar equipes, encerrar contratos com fornecedores, etc. - Entradas:

- Retrospectiva da Sprint (registro);- Aceites;- Sol ic it açõ e s de Muda nç a s nos Proce s sos Organizacionais;- Status Report Semanal;- Gráfico Burndown.

- Resultados servem para:- Aceites (registros);- Lições Aprendidas (registro);- Atualização de indicadores organizacionais;- Solicitações de Mudanças nos Processos Organiza-cionais (registro).

Processos ágeis e tradicionais funcionando juntosCom as ferramentas, artefatos e processos apresentados,

iremos agora mostrar o funcionamento dos processos ágeis e tradicionais de forma conjunta. A Figura 3 representa o pa-ralelismo e a iteração dos processos. A partir de agora serão apresentadas cada uma das etapas do processo definidas na figura.

Contrato assinadoA aplicação deste modelo híbrido surgiu a partir de necessi-

dades de empresas exclusivamente voltadas para o desenvol-vimento de software. A assinatura do contrato significa que o cliente está de acordo com as condições técnicas e comerciais oferecidas pela empresa que desenvolverá o software.

Em termos gerais, antes do contrato ser gerado, houveram etapas anteriores como geração de proposta técnica e comer-cial. A proposta técnica demonstra o que será feito, como, o esforço necessário e em quanto tempo será produzido o escopo. Para se gerar esta proposta, houveram reuniões com o cliente para o entendimento do escopo, as necessidades de negócio, identificação dos itens mais estratégicos, bem como os itens de maior valor agregado para o cliente. De posse destas infor-mações, a equipe técnica reuniu-se para fazer suas avaliações, decomposições, orçamentos de esforço e prazo, bem como dependências entre estórias e requisitos e, por fim, uma forma de acomodar a produção do escopo dentro de uma linha do tempo considerando a execução das Sprints.

Considera-se uma boa prática a apresentação da proposta técnica ao cliente (geralmente envolvendo a equipe técnica e usuária do cliente) de forma a validar se o entendimento e a dinâmica estão realmente de acordo com as expectativas. Nenhuma quantidade, além do prazo, deve ser mencionada neste momento. Logo que a proposta técnica for validada, a equipe técnica encaminhará todas as informações geradas como orçamentos, estudos e outros artefatos produzidos para a equipe comercial da empresa.

A proposta comercial toma como base a proposta técnica e os demais artefatos encaminhados transformando o esforço, know-how, qualificação e capacidade da equipe, entre outras variáveis, no que podemos chamar de preço. Este preço é o valor que o cliente pagará pela execução do serviço de produzir o software de acordo com suas expectativas. Normalmente, a proposta co-mercial propõe uma forma de pagamento atrelada às entregas do projeto, gerando um fluxo baseado nos aceites. Cada aceite formalizado pelo cliente gera uma liberação de faturamento.

Diante do exposto, um Contrato é um documento redigido de forma jurídica, mas que tem por obrigação retratar todas as condições técnicas (Proposta Técnica) e condições comer-ciais (Proposta Comercial). Então assumimos, diante desta dinâmica de elaborações das propostas técnica, 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 condições técnicas e comerciais, é o primeiro passo para o início do projeto. Por se tratar de uma questão jurídica, envolvendo advogados e elaboração de outros documentos acessórios o que geralmente consome muito tempo, é bem comum o cliente fornecer um aceite das propostas técnica e comercial para que seja dado início ao projeto. Neste caso, estamos assumindo que todo o trâmite jurídico, comercial e técnico foram concluídos com êxito, permitindo assim que a empresa dê início ao projeto.


PL ANEJAMENTo


Figura 3. Processos Scrum e PMBOK

Em paralelo à assinatura do contrato, a empresa nomeia o gerente de projeto e autoriza a mobilização da equipe para trabalhar. Este processo não é coberto pelo Scrum, mas sim pelo PMBOK no processo de Iniciação. Na Tabela 2 podemos verificar, resumidamente, a relação do contrato assinado em relação ao Scrum e PMBOK.

Item Scrum PMBOK

Contrato Assinado Não tem Processos de Iniciação

Tabela 2. Contrato assinado e processos Scrum e PMBOK

Product Backlog – escopo do projetoO que está definido no contrato como escopo deve ser con-

siderado como o Product Backlog do projeto acrescido da priorização dos itens listados. A priorização é fundamental pois é o cliente que sabe o que deve ser feito antes de outra estória. Ela traduz a necessidade e estratégia do cliente em termos comerciais ou organizacionais. O membro da equipe responsável por manter o Product Backlog atualizado e cen-tralizar as informações sobre as regras de negócio das estórias e do objetivo do produto é o Product Owner.

O Product Backlog servirá de base em todo o ciclo de vida do projeto, do início 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 participação do gerente de projeto e do cliente também pode ocorrer, mas não são mandatórias, desde que haja uma maneira clara e eficaz de se repassar o plano da sprint às partes interessadas integralmente.

Para o Guia PMBOK, não existe o termo Product Backlog, mas sim escopo. O grupo de processos de planejamento prevê o pla-nejamento de todas as áreas de conhecimento representando sempre a pergunta – Como serão gerenciados escopo, prazo, custo, riscos, comunicações, stakeholders, etc. produzindo o plano de projeto?

O plano de projeto poderá ser definido a partir do contrato considerando pontos que não são objetivo do Scrum, porém são imprescindíveis para o Cliente tais como controle do escopo, monitoramento e controle, Comunicações, etc. Na Tabela 3 podemos verificar a relação do Product Backlog com o Scrum e o guia PMBOK.

O próximo passo para a equipe é montar o quadro Kanban (Figura 1) e começar os trabalhos. Deve-se mover os post-its das estórias pertencentes ao Sprint Backlog para a coluna Em Andamento para indicar que os trabalhos foram iniciados.


Em algumas empresas é comum haver uma coluna adicional para abrigar o Product Backlog inteiro, movendo os post-its das estórias a serem produzidas na Sprint para a coluna Sprint Backlog. Para alguns, esta prática ajuda a manter a visibilidade do escopo a ser entregue integralmente. Esta é uma prática opcional e pode ser adotada desde que venha de encontro com os valores culturais da organização.

Sprint – Mãos à obra e o uso do Quadro KanbanO formato de uma Sprint não varia muito, mas pode (e deve)

ser adaptado para melhor desempenho e aderência à cultura da empresa. Existem empresas que prezam por seus indicadores e a metodologia Scrum não os descarta. Existem aqueles os quais pensam que ele é contra documentação, e este é um grande engano, mas o Scrum preza pela geração da documentação necessária, sem excessos, uma documentação clara e objetiva para auxiliar a equipe a produzir o que foi solicitado, dentro das expectativas.

No presente cenário apresentamos alguns eventos impor-tantes para auxiliar a equipe a manter o controle do desem-penho da Sprint (lembrando que a equipe é auto organizada e multidisciplinar): • Realização do trabalho: o trabalho realizado por cada um;• Atualização da planilha de horas: é sempre bom saber quanto de esforço foi gasto para produzir o Sprint Backlog;• Atualização do gráfico Burndown: a partir da atualização da planilha de horas é possível verificar o quanto o andamento da Sprint está ou não conforme o planejado; • Reunião diária: cada membro da equipe responde às três perguntas básicas: “O que foi feito? (Desde a última reunião di-ária)”, “O que será feito em seguida?”, e “Existem Impedimen-tos?” Durante a reunião diária, deve-se observar a evolução do gráfico Burndown atualizado. Através desta prática, a equipe poderá detectar desvios e promover estratégias para correção deles retomando a Sprint ao seu planejamento inicial.

Conforme o andamento dos trabalhos, as estórias que fo-ram produzidas precisam de validação. Sugere-se que este processo de validação ocorra, pelo menos, em três momentos: teste unitário, teste integrado e aceite do usuário. Estas três etapas aumentam as chances de sucesso da entrega. Sendo assim, conforme as estórias forem concluídas pela equipe de desenvolvimento, deveremos mover os post-its das estórias da coluna Em Andamento para a coluna Em validação no quadro Kanban (Figura 1).

É neste ponto onde devemos abordar o chamado Conceito de Pronto. Deve-se, antecipadamente, estabelecer o estado em que

uma estória será considerada pronta. Por exemplo: uma estória só será considerada pronta após ter sido validada pelo cliente. Estabelecer o conceito de pronto é muito importante para que não haja falsas expectativas. Se a regra do pronto não for es-tabelecida, o cliente pode intuir que só estará pronto quando o software gerado estiver disponível em sua infraestrutura e acessível aos usuários. Esta ideia pode gerar diversos proble-mas e até prejuízos uma vez que a disponibilização do software possui uma dependência 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 prévio e o cliente permita esta dinâmica, o conceito de pronto poderá ser modificado para atender às suas necessidades. Tais condições devem ser estabelecidas ainda na fase de proposta técnica e comercial de forma a serem refletidas no contrato.

Conforme o resultado do processo de validação e o aceite do cliente, o post-it da estória poderá ser movido da coluna Em Validação para a coluna Entregue.

Quando surgirem problemas os quais dificultem a conclusão do desenvolvimento de uma estória, a equipe deverá reportar ao Scrum Master a ocorrência registrando assim o chamado Impedimento. Caberá ao Scrum Master acionar os meios necessários para a resolução, o mais breve possível, deste impedimento. Para resolução de um impedimento podem ser envolvidos desde o Product Owner até mesmo o cliente. O importante é que o impedimento seja removido. Para estas situações, o membro da equipe deverá mover o post-it da es-tória da coluna Em Andamento ou Em validação para a coluna Impedimento no Quadro Kanban. Ao fazer isso, o impedimento ficará visível e deverá permanecer nesta coluna Impedimento até a sua resolução.

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 es-clarecer dúvidas e promover um alinhamento maior com as expectativas do cliente. Sem contar que, quando ele participa ativamente do processo, as mudanças também podem vir a surgir de forma mais evidente. Assim, é preciso manter o es-tabelecido no Sprint Backlog, mantendo um diálogo aberto e transparente com o cliente, caso as mudanças gerem impactos significativos. Se ocorrer uma mudança, esta deverá ser ava-liada antes de ser considerada automaticamente inclusa sem que sejam verificados todos os impactos.

Em algumas empresas, é comum considerar uma mudança como um Impedimento e tratá-la como tal. Isto significa que o post-it da estória que recebeu a solicitação de mudança será movido da coluna Em Andamento ou Em Validação para a coluna Impedimento no quadro Kanban até que se obtenha uma decisão sobre a execução, ou não, da mudança.

Outra característica importantíssima na adoção de um modelo híbrido de gestão é a chamada blindagem da Sprint. Blindar a Sprint significa dizer que as interações com o cliente são exclusivamente voltadas à produção do software con-tratado. Questões como comunicação com o cliente e partes

Item Scrum PMBOK

Product BacklogProcesso de planejamento da

Sprint (Sprint Plan)

Não é utilizado desta forma, sendo assim,

sofrerá adaptações para ser aplicado no

processo de planejamento do projeto

(Escopo)

Tabela 3. Product Backlog e processos Scrum e PMBOK.


PL ANEJAMENTo


interessadas, discussões sobre mudanças solicitadas, pagamen-tos, geração de relatórios, entre tantas outras atividades que são naturalmente desempenhadas pelo gerente de projetos, não afetam o bom andamento da Sprint, mantendo-a isolada, ou melhor, mantendo a Sprint blindada contra interações desnecessárias à produção do software.

Na Tabela 4 podemos verificar, resumidamente, a relação da Sprint em com o Scrum e o guia PMBOK.

Deve-se publicar o Sprint Backlog e torná-lo visível para todos os interessados. Isso pode parecer redundante uma vez que haverá um quadro Kanban contendo esta informação, porém, alguns detalhes ou documentos acessórios que auxiliaram na definição do Sprint Backlog podem ter sido utilizados e é de extrema valia que estas informações estejam acessíveis. Exis-tem empresas as quais possuem a prática de imprimir a estória e anexar no Quadro Kanban de forma a facilitar o acesso aos detalhes e tirar dúvidas.

Outra sugestão de boa prática é a realização de uma reunião de kick-off de forma a alinhar todos da equipe, cliente e até mesmo da empresa sobre a Sprint que será iniciada (seus objetivos, duração e quais serão as atividades envolvidas). Para alguns especialistas, uma reunião 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 relatório de status report é considerado uma fotografia da situação do projeto naquele momento em que foi tirado. É uma das principais ferramentas de comunicação adotado pelo guia PMBOK. É através da comunicação do status report do projeto ao cliente e partes interessadas que se pode ter uma visão con-solidada do andamento do projeto. Recomenda-se que ele seja entregue e explicado durante uma reunião de acompanhamento semanal junto ao cliente. Esta reunião permitirá que o gerente de projetos explique a situação do projeto e, em caso de problemas, enderece soluções para riscos e impedimentos. Somente após a reunião, a cópia do status report semanal deverá ser encami-nhada por meio eletrônico (e-mail) ou físico.

O conteúdo de um status report pode variar conforme a necessidade e a cultura da empresa, mas basicamente contém: a situação do projeto (atrasado, adiantado ou no prazo com-parado com o planejado), as realizações do período versus o planejamento, e análise de riscos. Existem diversos modelos de relatório de status report semanal bem como existem status report mensais em forma de um resumo executivo. Enfim, a adoção de um modelo ou de outro depende exclusivamente da cultura da empresa.

Vale lembrar que o guia PMBOK não é uma metodologia, ou seja, não 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 informação dependerá da necessidade e da capacidade de gerar a informação. Toda e qualquer informação a ser divulga-da deverá possuir uma fonte a qual, preferencialmente, deve ser automatizada ou eletrônica, evitando dispêndio de horas desnecessárias.

Para elaboração do status report semanal, o gerente de pro-jeto poderá captar as informações registradas nas reuniões diárias e no gráfico de burndown. Caso seja necessário um controle de custos, a planilha de horas aliada ao cronograma do projeto poderão demonstrar indicadores como CPI (Cost Performance Index) e o SPI (Schedule Performance Index) que são, respectivamente, os indicadores de custo e prazo calculados a partir da quantidade de horas apontadas e o percentual de conclusão.

O status report semanal é um entregável e, portanto, sugere-se que seja recebido e aceito pelo cliente através de assinatura. Mesmo soando burocrático, este ato de aceitar ou rejeitar o status report semanal pode auxiliar na resolução de conflitos ou desalinhamento de expectativas de ambas as partes. Em algumas empresas, o status report semanal também é consi-derado como um aceite parcial caso sejam listadas as entregas realizadas no período.

Sprint Review – Entregando ao cliente Após todo o trabalho estar concluído, conforme o conceito

de pronto estabelecido, chega o momento de apresentar ao

Item Scrum PMBOK

SprintProcesso de execução da Sprint, no qual o produto será

construído a partir do estabelecido no Sprint Backlog.

Dos ritos e eventos do Scrum, serão aproveitadas as informações da execução da Sprint geradas principalmente nas

reuniões diárias e no gráfico de Burndown para alimentar os artefatos do processo de monitoramento e controle. Não se

limitando a somente estas, mas, principalmente:

Controle de Riscos (Impedimentos);

Controle de Prazo

Controle de Custos

Controle de Escopo

Controle de Mudanças

Controle de Qualidade

Entre outros;

A utilização destes processos do Guia PMBOK são facultadas à cultura da empresa a qual considerará relevante, ou não,

estes controles.

Tabela 4. Sprint e os processos Scrum e PMBOK


cliente o que foi realizado de uma forma integrada. Sugere-se uma reunião formal onde a equipe e o cliente irão demonstrar todo o conjunto de software produzido funcionando. Deve-se aplicar a última versão do software produzido em um ambiente destinado à homologação, apartado do ambiente de desen-volvimento afim de garantir o isolamento e funcionamento do software.

Nesta reunião, o cliente deverá fornecer o aceite formal das entregas realizadas considerando a Sprint como concluída. O registro através 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 reunião de Sprint Review, o gerente de projeto poderá acionar os processos de encerramen-to, atualizando os registros e indicadores do projeto e emitindo, quando necessário, um informe em formato específico quanto a finalização da Sprint e da respectiva fase estabelecida no con-trato. A equipe Scrum deverá prosseguir para o próximo passo de encerramento – a retrospectiva da Sprint.

Na Tabela 5 podemos verificar a relação da conclusão da Sprint através da reunião de Sprint Review realizada junto ao cliente. Essa reunião é um evento exclusivo do Scrum, mas que gera informações para os processos de encerramento do guia PMBOK.

Retrospectiva da Sprint – Como foi o andamento do trabalho?

Após a conclusão 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 execução da Sprint.

Trata-se de um ritual de maturidade e melhoria contínua onde todos devem participar e expor suas opiniões respon-dendo a três perguntas básicas: “O que foi bom nesta Sprint e deve ser mantido para as próximas Sprints?”, “O que pode ser melhorado para as próximas Sprints?” e, “O que deve ser abolido das próximas Sprints?”.

Item Scrum PMBOK

Retrospectiva da Sprint

Processo de Retrospectiva da Sprint – demonstrará,

de forma sintética, 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 também pode ser considerada

registrando-se os tempos de construção das estórias.

Tal informação é fundamental para a emissão de

orçamentos futuros, servindo como referência.

O artefato similar no guia PMBOK é o de lições aprendidas, pertencente ao grupo de processos de encerramento. Desta forma,

com pequenos ajustes, o gerente de projetos poderá se valer destas informações para o preenchimento deste artefato.

A performance da Sprint pode e deve alimentar os registros organizacionais de forma a gerar dados históricos e comparativos

para futuros projetos.

Com relação às solicitações de mudança dos processos, também 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 próximas

iterações.

Item Scrum PMBOK

Sprint ReviewProcesso de Entrega da Sprint

(Sprint Review) – resultado

Os aceites obtidos durante a Sprint

Review serão absorvidos pelo Processo de

Encerramento – Encerrar Fase ou Projeto.

Tabela 5. Sprint Review e processos Scrum e PMBOK

A equipe poderá tomar como base o gráfico de Burndown e os registros das reuniões diárias em busca de um resumo para res-ponder às três perguntas da retrospectiva da Sprint. Percebam que as perguntas estão focando sobre os processos de trabalho para a realização das Sprints. Isto significa que devem surgir solicitações de mudança para a execução das próximas.

Em empresas que possuem um escritório de projetos (PMO) ou um grupo voltado para os processos, são estes departa-mentos ou grupos os quais receberão tais solicitações. Eles são instituídos para estabelecerem suas formas de trabalho e os processos a serem definidos e seguidos. Geralmente, nestas empresas existem auditorias periódicas para a verificação se os processos estão sendo executados conforme o estabelecido. Comumente são membros de outros departamentos e até empresas externas que executam tais auditorias. Modelos de maturidade e normas de qualidade exigem a realização destas auditorias de maneira a garantir que os níveis de maturidade estão sendo mantidos, verificados e evoluídos.

Para tanto, a atuação destes departamentos deverá ser muito ágil em função de que uma nova Sprint está prestes a começar assim que a reunião de retrospectiva for concluída. A forma de trabalho da próxima iteração dependerá da aprovação das solicitações encaminhadas pela equipe após a reunião. É extre-mamente salutar que os representantes destes departamentos estejam presentes na reunião de maneira que deem os devidos encaminhamentos para implementar as mudanças solicitadas para que não ocorra a incidência de não conformidades de processos durante as auditorias periódicas.

Na Tabela 6 podemos verificar a relação da conclusão da reunião de retrospectiva da Sprint realizada pelos membros da equipe. O cliente e os grupos ou departamentos de PMO ou de processos também podem participar. A reunião de retrospectiva é um evento exclusivo do Scrum, porém, com grande aderência ao processo de lições aprendidas proposto pelo guia PMBOK durante a execução dos processos de en-cerramento do projeto.

Processos de encerramento Os processos de encerramento sugeridos pelo guia PMBOK

tratam do encerramento de uma fase ou do projeto. Este encer-ramento depende de uma formalização 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.

Tabela 6. Retrospectiva da Sprint e processos Scrum e PMBOK


PL ANEJAMENTo


Em função de estarmos utilizando um modelo híbrido de gestão, se faz necessário perceber onde estes aceites serão 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 através da reunião chamada Sprint Review. Tanto em uma entrega parcial quanto na Sprint Review, os aceites serão 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 à liberação de pagamento do cliente para a empresa. Então, caberá ao gerente dar os devi-dos encaminhamentos internos tanto para o pagamento quanto para alimentar os arquivos e registros organizacionais.

A Figura 3 apresenta uma visão resumida da adoção do chamado modelo híbrido de gestão, unindo os pontos fortes da metodologia ágil Scrum e do guia PMBOK do PMI. De-monstramos nesse artigo a viabilidade da adoção deste modelo. Além da viabilidade, nota-se alguns ganhos como redução de controles e geração de informações, tudo ocorrendo de forma mais ágil e com equipes melhor dimensionadas.

Foi enfatizado também a atuação dos papéis de gerente de projeto e Scrum Master, tão facilmente confundidos pelas empresas e pessoas ainda não familiarizadas com os métodos apresentados. Além disso, o modelo possibilita uma constru-ção de software mais blindada contra fatores externos e não relacionados à sua produção.

Existe uma grande tendência na especialização de gestores utilizando-se de modelos híbridos de gestão, não se restringin-do à gestão de projetos, mas também à gestão de TI aliando a biblioteca ITIL e a Cultura DevOps. A procura deste perfil de profissional se tornará mais intensa em um futuro próximo.

Da mesma forma que os métodos ágeis surgiram e já de-marcam seu espaço nas empresas e organizações, a adoção dos modelos híbridos também demonstra que veio para ficar pois une os pontos fortes de todas as metodologias e guias permitindo aos gestores definir um modelo de gestão ágil, documentalmente estruturado, eficiente, eficaz e já bem aceito em modelos de maturidade como o MPS.BR e o CMMI.

Links:

Gráfico Burndownhttp://blog.myscrumhalf.com/2012/01/burndown-chart-medindo-o-progresso-de-sua-sprint-e-trazendo-indicativos-do-processo-de-trabalho-da-equipe/

Livro Scrum e PMBOK: unidos no Gerenciamento de Projetoshttp://www.brasport.com.br/gerenciamento-de-projetos/metodologia/scrum-e-pmbok-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 Scrumhttp://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf

Papéis do Scrumhttp://pt.slideshare.net/ScrumHalf_GPE/papeis-scrum-faq





Fique por dentro:Abordaremos uma visão geral sobre a gestão de mudança, apresentando seu conceito e elucidan-do as facilidades trazidas através de sua utiliza-ção. Além disso, iremos exemplificar, de maneira prática, como implantar um sistema controle de versão para pequenos projetos utilizando o serviço de hospedagem Bitbucket e o sistema de controle de versões Git. Este artigo é útil porque, para qualquer projeto de software onde há mais de uma pessoa envolvida, a gerência de mudan-ças é uma necessidade. Já realizou alterações em seu código para realizar algum teste e não conseguiu retornar ao ponto em que estava? Já teve seu código sobrescrito por alguém da equi-pe? Tem dificuldade em lembrar quando e por quem alguma alteração foi feita? Se sua resposta é “sim” para qualquer uma destas perguntas, en-tão este artigo é essencial.

Gerência de mudanças utilizando GitUma abordagem simplificada para implantação de um sistema de controle de versões

Álex Leocádio JúlioGraduado em Ciência da Computação pela Universidade Federal de Viçosa. Atualmente trabalha com gerenciamento de mudanças em projetos Android.

O processo de desenvolvimento de software, desde o surgimen-to da proposta até a concepção

final do sistema, pode se tornar muitas vezes uma tarefa longa e árdua devido à não utilização de técnicas fundamentais de engenharia de software. Isso pode acontecer, por exemplo, devido ao des-conhecimento da equipe da existência de tais métodos. Neste cenário se en-quadram aqueles que estão começando na área de tecnologia, ou seja, pela inexperiência da equipe em saber definir quais metodologias devem ser aplicadas e em qual momento. Da mesma forma, o foco exacerbado em metodologias e na aplicação destas puramente da forma expressa nos livros torna o processo enfadonho e lento.

A engenharia de software tem como desafio demonstrar a necessidade de

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 gerência de configura-ção voltado para equipes reduzidas e

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros


ENgENhARiA


projetos de pequeno porte. Projetos onde os papéis assumidos por cada membro da equipe não são únicos e funções são acumuladas. Ao final desta leitura, esperamos que você esteja apto a implantar um sistema de controle de versões em seus projetos. Iremos, primeiramente, definir o que é a gerência de mudanças e demonstrar sua importância no processo de desenvolvimento de software. Em seguida, vamos apresentar o Git como um sistema de controle de versões e ensinar o fundamental para que seja possível dar os primeiros passos na utilização dessa formidável ferramenta.

A origem da demanda Inicialmente é necessário entender o significado do

termo configuração do sistema. Podemos dizer que gerencia-mento de configuração nada mais é do que controlar a evolução do sistema e dos produtos gerados, tanto códigos-fonte quanto documentos ou quaisquer outros elementos adicionados.

Tomada essa definição, imagine agora que daremos início 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 nós, na mesa à nossa frente. Talvez, neste contexto, o gerenciamento de mudanças não se faça tão necessário, uma vez que é possível que nós e nosso companheiro de projeto tenhamos total controle sobre o que acontece, quanto aos ar-quivos que foram modificados ou bugs que foram consertados. Em cenários como esses, o que vemos são as pessoas utilizando formas bem particulares de gerir as mudanças, executando essa tarefa muitas vezes de forma inconsciente.

Agora tomemos um cenário bem distinto do anterior. Supo-nha o desenvolvimento de um sistema amplo, com centenas de funcionalidades, para uma empresa multinacional, onde a equipe escalada para seu projeto e desenvolvimento é compos-ta de dezenas de pessoas, cada uma delas especializada em uma área de conhecimento, tanto funcional quanto técnica. Neste contexto, a equipe sequer trabalha no mesmo país. Como trabalhar de forma paralela sem sobrescrever códigos de outros membros? Como saber quais alterações foram feitas? E quando? Por quem?

Como se pode perceber, são muitas as perguntas a serem respondidas e sem a automatização desses controles seria impossível responder a cada uma destas questões e outras tantas que surgem durante o processo de desenvolvimento de software.

Para o nosso exemplo prático, que será explicado mais a frente, usaremos um meio termo entre o primeiro e o segun-do cenários citados: um projeto em que podemos resumir o gerenciamento de configuração ao controle de versões dos arquivos de projeto.

Sistemas de controle de versãoChamamos de controle de versão um sistema capaz de regis-

trar as mudanças efetuadas em cada arquivo ao longo do tempo e, o mais importante, de forma que seja possível recuperar uma versão específica dele. Além disso, outras informações

úteis podem ser extraídas a partir de um sistema de controle de versão (SCV). Através de um SCV podemos ver, por exem-plo, quem alterou certo trecho de código e em que momento, comparar duas versões distintas e verificar as diferenças entre elas ou reverter todo um projeto a um estado anterior onde certo bug não ocorria.

Os SCV podem ser categorizados de três formas:• Sistemas de controle de versão locais: provavelmente já uti-lizamos esse método sem saber que fazíamos uso de um SCV. Quando se cria uma cópia de um arquivo para um outro diretório com o intuito de preservar tal arquivo, nós estamos realizando um controle de versão. Este método tão simples e amplamente utilizado pode ser eficiente em alguns cenários de trabalho, porém é muito suscetível a falha. Alguém poderia esquecer de fazer a cópia de alguma das versões, sobrescrever alguns arquivos acidentalmente, ou ainda, deletar alguma versão anterior. Para automatizar este processo foram desenvolvidos sistemas de con-trole de versão, que armazenavam todas as alterações;• Sistemas de controle de versão centralizados: essa solução surgiu, principalmente, para atender a demanda do trabalho em conjunto. Nesse modelo, como o próprio nome sugere, há um servidor central com o versionamento dos arquivos e cada um dos clientes desse servidor podem fazer cópias da versão desejada. Ao ato de realizar uma cópia dos arquivos versionados, seja fisicamente ou virtualmente, dá-se o nome de checkout. Utilizando-se deste sistema, cada integrante da equipe pode ter uma visão geral do projeto, tornando mais fácil 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 serviço interrompido várias vezes e por muito tempo, poderia ter como consequência a perda de informações e de tempo de trabalho dos colaboradores.• Sistemas de controle de versão distribuídos: tal modelo surgiu para suprir a principal deficiência dos sistemas cen-tralizados – a falha do servidor central. Desta forma, o que temos nos sistemas distribuídos são os clientes fazendo cópias completas do repositório, 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, não são o foco deste artigo. Por isso, não nos pro-longamos em suas descrições, apresentando apenas uma visão geral de cada um. A partir de agora vamos nos ater aos sistemas distribuídos, utilizando o Git para exemplificar e introduzir os conceitos básicos do controle de versões de maneira prática através desta poderosa ferramenta.

Começando com o GitPrimeiramente, vamos mostrar como realizar a instalação e

configuração do Git (no ambiente Windows) e, mais a frente, após nosso ambiente estar devidamente configurado e integra-do ao servidor, vamos abordar as principais características de um SCV distribuído, fornecendo exemplos práticos de como o Git trata cada uma delas.


Figura 1. Estrutura de acesso para um sistema de controle de versão distribuído

Para realizar a instalação do Git basta rodar o arquivo .exe disponível no site oficial (ver seção Links) e seguir as instruções de instalação. As únicas opções que serão necessárias alterar para nosso treinamento são as de ajuste de ambiente. Iremos optar por integrar os comandos Git ao prompt de comando do Windows.

Após a instalação, teremos uma versão de linha de comando, que será a que utilizaremos, e uma versão GUI.

O primeiro passo ser realizado com o Git em nosso sistema é realizar a configuração do usuário. Tais configurações são salvas no arquivo .gitconfig na home de seu usuário e serão utilizadas para identificar o responsável por cada alteração realizada no projeto, conforme vemos no código a seguir:

git config --global user.name “nome”

git config --global user.email “nome@email”

O parâmetro --global permite que se realize a configuração apenas uma vez, assim esses valores serão sempre utilizados pelo Git. Caso seja necessário atribuir outros valores às variáveis de configuração para um projeto específico, deveremos executar os comandos sem esse parâmetro, com isso, seria criado dentro do projeto o arquivo .git/config com informações que sobrescrevem as configurações globais.

Uma vez que nosso objetivo é criar um projeto colaborativo, precisaremos ter um repositório remoto, para o qual deveremos estar aptos a enviar (push) e receber alterações (pull). A nossa comu-nicação com o repositório se dará através do protocolo SSH. Esta escolha se deve

ao fato do SSH permitir a leitura e a escrita em um servidor de forma autenticada, além de ser relativamente simples de configurar.

Para ter acesso a um repositório remoto via SSH será ne-cessária uma chave pública para autenticação. Executando o comando ssh-keygen, um diretório chamado .ssh será criado em sua home e dentro deste serão criadas uma chave priva-da e uma chave pública (.pub). Ao executar o comando será questionado se é necessária uma senha. Deixe em branco caso não deseje autenticar toda vez que for preciso utilizar a chave. A chave pública será inserida em nosso repositório remoto, o qual iremos criar e configurar mais adiante.

Na seção Links há um tutorial completo demonstrando o pro-cesso de criação de chaves SSH, caso encontre dificuldade.

Figura 2. Criando time e adicionando membros

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

comandos básicos para utilização e é muito importante que o leitor consulte a documentação

oferecida para entender mais sobre os comandos disponíveis. O endereço para acessá-la pode

ser encontrado na seção Links.

Nota. Documentação do Git

Criando um projeto no BitbucketComo opção para serviço de hospedagem aos repositórios do

projeto utilizaremos o Bitbucket, pois este oferece uma opção de serviço gratuito com excelente suporte ao trabalho com Git. Uma alternativa ao uso do Gitbucket é o GitHub, porém este só oferece planos gratuitos para projetos de código aberto.

Para iniciarmos, crie uma conta no Bitbucket optando pelo plano que dá suporte a um time de até cinco usuários, uma vez que nosso grande objetivo é criar um projeto compartilhado. Após criar uma conta, você também deverá criar um time e adicionar os membros que farão parte dele (Figura 2), sendo


ENgENhARiA


Figura 4. Adicionando chaves SSH dos membros do time

Figura 3. Criando repositório do projeto

que todos os membros também devem possuir uma conta para serem incluídos ao projeto. O usuário que cria o time terá permissão de Administrador e será res-ponsável pela atribuição das permissões para os demais membros.

Agora que já temos um time formado, va-mos criar um repositório (Figura 3) através da opção Create a new repository. Este irá armazenar nossos códigos, documentos e o que mais for necessário ao projeto. O acesso a esse repositório, tanto para leitura quanto para escrita, se dará através do Git para cada membro do projeto.

Uma vez estruturada a equipe, será ne-cessário cadastrar no servidor as chaves públicas geradas por cada membro, pois, como dito anteriormente, a comunicação entre cada estação de trabalho e o reposi-tório remoto se dará através do protocolo SSH. Este protocolo será responsável pela segurança de permissão de leitura e escrita apenas aos desenvolvedores devidamente autorizados.

A Figura 4 mostra como realizar o ca-dastro das chaves, que deverá ser feito pelo Administrador do time através das suas configurações de conta.

Pronto! Nosso ambiente de trabalho está montado. Agora iremos demonstrar como esse simples processo construído permite, funcionalmente, realizar o ge-renciamento de mudanças. Além disso, vamos explorar na prática as funciona-lidades do Git para realizar o controle de versão.

Git na práticaAté este momento ainda não mostra-

mos como um SCV funciona na prática e nem como o Git implementa estas funcionalidades. A partir de agora ve-remos como será possível trabalhar de maneira colaborativa, segura e contro-lada através da implantação deste fluxo de trabalho.

Para darmos início ao desenvolvimen-to do nosso projeto, tomando o ponto de vista de um desenvolvedor, será necessário 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 histórico já registrado. Logo, por ser uma cópia exata das informações contidas no servidor, caso o mesmo seja perdido ou corrompido, poderemos restabelecer o projeto reavendo o servidor através de um dos clones.

Clona-se um repositório através do co-mando git clone <url>. No nosso exemplo, obtém-se o comando na home do projeto criado no Bitbucket, que oferece a clona-gem HTTPS e SSH, sendo esta a utilizada. Assim, cada desenvolvedor fará git clone [email protected]:gitdevmedia/<seu_proje-to>.git, trazendo para a sua estação de trabalho uma cópia do servidor dentro do diretório com o nome do projeto Git (ver Figura 5).

Agora que temos um diretório vazio conectado ao servidor, iremos começar a manipular os arquivos de projeto e controlar a implementação. Para exem-plificar o funcionamento, adicionamos ao diretório clonado uma estrutura de pastas e arquivos como exibido na Figura 6. A partir daqui, pode-se adicio-nar outros tipos de arquivos ou já adicio-nar os arquivos de um projeto real.

É evidente que cada um dos arquivos que foram adicionados no diretório local


ainda não está disponível no servidor. Na verdade, sequer foram consolidados pelo Git localmente. Ao ato de salvar estas informações 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 clo-nagem 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 três estados possíveis: • consolidado (commited): que são os arquivos salvos;• modificado (modified): no qual se encontram os arquivos não consolidados na base de dados do Git;• preparado (staged): quando determi-nado arquivo foi modificado na versão corrente e se deseja que ele faça parte do próximo commit.

Agora, utilizando os arquivos adicio-nados, podemos navegar entre estes três estados e determinar como desejamos sal-var as mudanças realizadas no projeto.

Primeiramente devemos estar aptos a identificar em qual estado se encontram os arquivos. Para isso utilizamos o co-mando git status. Executando em nosso exemplo, obteremos o resultado mos-trado na Figura 7 e, conforme podemos observar, nossos arquivos se encontram “untracked”, o que significa que não estão preparados para entrar no próxi-mo commit. Entretanto, o próprio Git já informa como preparar nossos arquivos através do comando git add.

É muito importante que as mensagens retornadas pelo

Git sejam lidas para entender qual o próximo passo a ser

realizado. Apenas aprendendo a lê-las e a interpretá-las

estaremos aptos a explorar o máximo da ferramenta.

Nota. Mensagens do Git

Preparados os arquivos que deseja-mos adicionar ao próximo snapshot, devemos executar o comando git commit –m “<mensagem>” para que o Git salve as informações. Atente-se em sempre utilizar uma mensagem de commit que

Figura 6. Exemplo de estrutura de arquivos de projeto

Figura 5. Clonagem do projeto do Bitbucket

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

seja explicativa quanto às alterações que foram salvas para facilitar o entendi-mento do que foi realizado. Além disso, certifique-se de realizar o commit de to-dos os arquivos necessários ao projeto.

Após realizar as alterações desejadas em seus arquivos e consolidá-las através

dos commits, é de se esperar que se quei-ra ver o histórico de alterações, afinal de contas uma das necessidades supridas pelo controle de versão é dizer quando e por quem uma mudança foi realizada. Para consultar a lista de commits execute o comando git log.


ENgENhARiA


Ao fazer isso, as informações de com-mit serão exibidas em ordem cronológica inversa.

Para exibir o diff introduzido em cada commit podemos executar o comando de log com o argumento –p. Esta é apenas uma das diversas opções úteis para le-vantar informações históricas do projeto. Explore a documentação para conhecer mais argumentos.

Agora que todas as alterações neces-sárias foram salvas em seu repositório local, devemos disponibilizar tais mudanças aos demais integrantes da equipe. Para isso, iremos realizar o upload dos commits para o nosso ser-vidor remoto através do comando git push <remote> <branch_remoto>, onde <remote> é o endereço do nosso servidor remoto e este é nomeado como origin por default pelo Bitbucket. Utilize git remote

–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 versão ao servidor. Se navegarmos pela interface do Bitbucket, notaremos que algumas coisas mudaram: conseguimos navegar graficamente pelos commits, conforme Figura 8. Os commits são exibidos como uma sequência de al-terações realizadas e, para cada um, é gerado uma página com informações detalhadas sobre o mesmo, como arquivos modificados e quais altera-ções foram feitas, além de permitir a adição de comentários e definir que outros integrantes da equipe revisem e aprovem sua change, construindo assim um processo a se seguir para o desenvolvimento.

Através de tags podemos ainda marcar pontos de release, ou seja, assinalar mo-mentos específicos em que uma versão 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 compõem a versão 0.1, logo ire-mos fazer git tag –a v0.1 –m “versao inicial v0.1”. Além disso, da mesma forma que demos push nos commits para o servi-dor, devemos fazer o mesmo para as tags que criamos. Assim, execute o seguinte comando git push origin v0.1.

Utilizando a ramificação para trabalhar em equipe

Chegamos, enfim, ao objetivo maior deste artigo: a ramificação (branching) do projeto para permitir o trabalho paralelo e o gerenciamento destas mudanças.

Imagine que criar um branch é como criar bifurcações na linha de desenvol-vimento, possibilitando que alterações sejam feitas em pontos distintos e depois tais alterações podem ser mescladas (merge) de volta à linha principal. O poder que o Git possui para criar e geren-ciar branches, executando operações de maneira quase instantânea, destaca-se entre todos os SCV.

Criar um branch local é muito útil, por exemplo, para realizar um teste isoladamente, sem mexer em seu código principal. Caso o teste seja realizado com sucesso, mesclamos o código com o branch principal, tradicionalmente chamado de master. O Bitbucket permi-te a criação 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 três branches pelo Bitbucket, simulando três desenvolvedores traba-lhando em arquivos distintos do projeto e realizando cada um os seus devidos commits.

Para chegarmos nesta configuração, cada um dos três desenvolvedores clo-nou o projeto a partir da tag v0.1 que havíamos criado, como mostra a Figura 9. Feito isso, realizaram um checkout para

Figura 8. Listagem de commits

Figura 9. Servidor com diversos branches


seu respectivo branch localmente, isso é, executaram git checkout –b <nome_do_branch>, sendo o nome_do_branch idênti-co 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 parâmetro –b.

Posteriormente, os desenvolvedores modificaram arquivos, deram o commit nas alterações e realizaram o push para seus branches remotos. Desta forma, os quatro branches existentes no servidor se encontravam diferentes.

Porém, o que desejamos é que as altera-ções feitas por cada desenvolvedor sejam compartilhadas entre eles, gerando uma nova versão 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 navegação de branches, conforme mostra a Figura 10.

É evidente que um merge deve ser feito sob algum critério. É possível revisar os commits, logo pode-se adotar que o merge de determinado branch só será executado após a verificação das chan-ges por outro desenvolvedor.

Podemos chamar o cenário descrito de otimista, pois os merges ocorrem sem conflitos entre os commits que compõe cada branch. Um conflito ocorre quando duas pessoas modificam um mesmo tre-cho de um arquivo e ambas tentam dar push destas modificações para o servi-dor. Neste caso, o primeiro que realizar o push terá suas informações salvas e o segundo será informado do conflito.

Caso este conflito ocorra no instante de realizar o merge de branches pelo Bitbu-cket, 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 cenário, dois desenvolvedores modificaram um mesmo arquivo, adicio-nando uma linha com a data em formatos

Figura 10. Realizando merge

diferentes, e cada um realizou o push de seu commit em um branch diferente.

Desta forma, quando há um conflito, será necessária a análise de causa e qual o trecho de código deverá ser mantido, dependendo assim de uma ação manual de um dos desenvolvedores.

Uma boa prática para minimizar a ocorrência de conflitos é sempre baixar dos servidores as mudanças recentes imediatamente antes de subir suas alterações, ou seja, executamos um pull, trazendo os commits dos demais membros para seu código, realizar as mudanças desejadas e executar um push em seguida para o servidor.

Esse artigo apresentou as facilidades que a implantação de um sistema de con-trole de versão pode trazer a processos de desenvolvimento de software. Com as informações apresentadas, o leitor estará apto a explorar o universo do Git e perce-ber como são inúmeras as possibilidades de executar adequadamente o controle de mudanças necessário ao projeto.

Figura 11. Exibição de conflito em merge pelo Bitbucket

Links:

[1] Instalador Git para Windowshttps://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] Bitbuckethttps://bitbucket.org/

[5] GitHubhttps://github.com/

Dê seu voto em

www.devmedia.com.br/esmag/feedback




Fique por dentro:A gerência de configuração de software consis-te em um conjunto de atividades que tem como objetivo gerenciar as mudanças do software através de um controle de versão e controle de mudanças. Neste artigo será apresentado de que maneira é possível implantar um am-biente de gerência de configuração de software integrando os serviços de controle de versões e gerência de mudanças, através de um ambiente totalmente baseado em software livre utilizan-do ferramentas open source. Este artigo é útil para quem busca implantar um ambiente de gerência de configuração organizado e eficaz, com baixo custo, visando a qualidade do soft-ware a ser desenvolvido e evitando assim a per-da de controle devido às mudanças ocorridas durante um processo de desenvolvimento.

Utilizando as ferramentas Mantis, Subversion e Google CodeGerência de configuração de software

Priscila Martins [email protected]

Licenciada em Informática em 2008, Bacharel em Sistemas de Informação em 2012, experi-ência de 4 anos na área de TI atuando como Analista de Teste de Software, Certified Tester Foundation Level (CTFL) desde 2011.

Durante o processo de desen-volvimento de software, as mudanças ocorrem de forma

inevitável. Independentemente de onde estamos no ciclo de vida de um softwa-re, este irá se modificar e o desejo de modificá-lo irá persistir ao longo de seu ciclo de vida. Vários motivos podem levar um software a ser modificado, tais como: a identificação de novos re-quisitos, mudança do entendimento dos usuários sobre a aplicação, mudança no ambiente no qual o software irá operar, modificação de regras de negócio, res-trições de orçamento ou cronograma, avanços tecnológicos, mudanças de legislação, ou o mais comum deles: a correção de defeitos.

Tais modificações podem representar aspectos positivos e negativos. Através das mudanças o produto de software pode ser melhorado e corrigido cons-tantemente, proporcionando maior

qualidade ao mesmo. Porém, se este processo de mudança for aplicado sem critério e organização, muitos proble-mas podem acontecer, podendo levar à perda de controle e consequentemente comprometer a integridade e qualidade do software.

Devido a este motivo, se torna ne-cessário aplicar dentro das empresas

Engenharia

Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros


práticas de desenvolvimento que possam controlar de forma sistemática e organizada as modificações ocorridas em um software tornando possível a permanência de sua qualidade e integridade ao longo do tempo.

Neste contexto, surge a Gerência de Configuração de Softwa-re (GCS), que consiste em um conjunto de atividades que têm como objetivo gerenciar as mudanças através de um controle de versão e de mudanças.

O gerenciamento de versões se refere ao processo de acompa-nhamento de diferentes versões de componentes de software ou itens de configuração e os sistemas em que esses compo-nentes são usados. Ele também envolve a garantia de que as mudanças feitas por diferentes desenvolvedores para essas versões não interferem umas nas outras.

A GCS é uma disciplina da engenharia de software que ocorre durante o todo o ciclo de vida de desenvolvimento e não apenas na etapa de manutenção (que ocorre quando o produto já foi entregue ao cliente). Pelo fato das solicitações de mudanças ocorrerem em qualquer período, as atividades de GCS devem ocorrer desde o início do projeto e somente devem terminar quando o software é retirado de operação.

A GCS é um conjunto de atividades de apoio ao processo de desenvolvimento que permite gerenciar e controlar a evolução de um software através do controle de versões e solicitação de mudanças, visando manter a estabilidade na evolução do projeto, tornando-o sistemático e rastreável. A GCS permite que todas as pessoas envolvidas no desenvolvimento tenham acesso ao histórico das modificações ocorridas no software bem como o en-tendimento do sistema na situação atual e situações anteriores.

Tamanha é a importância da GCS que a aplicação das suas atividades nas empresas é imprescindível para a obtenção da certificação do Capability Maturity Model Integration (CMMI) ní-vel 2 e certificação no modelo Melhoria do Processo do Software Brasileiro (MPS-BR) nível F. Por isso, a GCS tem um papel muito importante na garantia da qualidade do software e no apoio à gestão de projetos. De forma resumida, as atividades de GCS são: identificação das modificações, controle das modificações, garantia de implementação adequada das modificações, relato das modificações e controle de versões.

Para a qualidade deste processo, é necessário dispor de fer-ramentas 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 não ser um problema, pois elas geralmente possuem capital para investir em ferramentas e recursos qualificados para estabelecer tais práticas. Porém, em empresas de pequeno porte, a realidade pode ser diferente, pois normalmente estas organizações têm dificuldade de adotar este modelo devido ao alto custo aplicado para adquirir ferramentas de apoio e recursos adequados.

Ainda assim, é possível implantar uma solução de GCS com qualidade e baixo custo nas empresas através de softwares livres. Neste artigo demonstramos como isto é possível através da integração das ferramentas Mantis, Subversion (Subclipse) e Google Code.

Para o entendimento da forma como estas tarefas são execu-tadas é necessário entender alguns conceitos fundamentais que serão descritos nos tópicos a seguir.

ConfiguraçãoDurante todo o processo de desenvolvimento de software,

são produzidas diversas informações, que podem ser: arquivos de códigos fonte, programas executáveis, especificações do sistema, planos de projeto, especificações de requisitos, especi-ficações de interface, manual do usuário, planos, casos, roteiros e cenários de teste, manual de instalação, descrição de banco de dados, ferramentas de software, entre outros. Ao conjunto de toda informação produzida no processo de engenharia de software denominamos “Configuração de Software”.

Item de ConfiguraçãoUm item de configuração 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 con-figuração que a GCS é aplicada.

Um item de Configuração de Software (ICS) consiste em cada unidade de informação que é criada durante o desen-volvimento de um produto de software, ou seja, cada artefato gerado. Além dos itens criados, também são considerados ICS’s as ferramentas que são necessárias para a construção do software.

Os ICS’s poderão sofrer alterações ao longo do tempo e serão geradas diversas versões de um mesmo ICS resultante das modificações realizadas. Também poderão ser criados novos itens ao longo do ciclo de vida.

Os ICS’s devem ser identificados para que seja possível gerenciá-los de forma eficaz. Cada ICS deve ser identificado distintamente de forma que ele seja caracterizado unicamente. Cada empresa pode definir sua própria forma de identificação, que pode ser um nome, uma descrição, entre outros. Porém, o ICS deve ser nomeado de maneira que seja possível identificar a evolução de sua versão.

BaselineBaseline ou configuração base do sistema compreende em

um conjunto de itens de configuração que foram formalmen-te aprovados e armazenados de forma controlada em um determinado momento do ciclo de vida do sistema. Os itens de configuração que compõem a baseline do projeto somente podem ser modificados através de uma solicitação formal de mudanças. 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 gerência.

As baselines são importantes porque, muitas vezes, você precisa recriar uma versão específica de um sistema completo. Por exemplo, uma linha de produto pode ser instanciada para que existam versões de sistema individuais para diferentes clientes. Talvez você precise recriar a versão entregue a um cliente específico se, por exemplo, esse cliente relatar bugs em seu sistema os quais precisam ser ajustados.


ENgENhARiA


Gerenciamento de releasesUm release de um software é uma versão de um sistema

distribuída aos clientes. Quando um release de sistema é pro-duzido, 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 período de tempo. Esses clientes podem exigir mudanças específicas para uma determinada release muito depois da data de lançamento daquela versão do produto.

RepositórioUm repositório é um mecanismo capaz armazenar fisicamen-

te os itens de configuração, mantê-los relacionados a diversas versões e ainda permitir o acesso às versões anteriores. Devem ser capazes também de armazenar informações sobre baseli-nes, além de informações sobre quando, porque e por quem as modificações foram realizadas.

Controle de versõesQuando um item de configuração é gerado, ele pode sofrer

diversas modificações, evoluindo de forma a atender as neces-sidades dos stakeholders. Esta necessidade de mudança implica que alterações sejam realizadas e, consequentemente, a cada alteração uma nova versão do item é gerada.

É necessário, portanto, identificar, armazenar e controlar as diversas versões dos itens de configuração. Antigamente quando não existiam ferramentas para dar suporte a este con-trole, os itens de configuração eram mantidos em documentos de papel, colocados em pastas de arquivos e armazenados em armários. Esta abordagem era problemática por várias razões: encontrar um item de configuração era frequentemente difícil; determinar que itens foram modificados quando e por quem era um desafio; construir uma nova versão de um programa existente consumia tempo e era propenso a erros; descrever relacionamentos detalhados e complexos entre itens de confi-guração era virtualmente impossível. Hoje em dia o controle de versões pode ser feito com o auxílio de ferramentas.

Um sistema de controle de versões permite que os itens de configuração sob a gerência de configuração evoluam de forma concorrente e disciplinada. Controlar versões significa gerenciar diversas versões dos itens de configuração gerados no desen-volvimento do software, permitindo a edição colaborativa dos artefatos, compartilhamento dos dados impedindo que um de-senvolvedor implemente uma versão desatualizada do artefato sobrepondo a versão atual disponibilizada por outro, evitando perdas e sobreposições durante a manutenção do artefato.

Algumas características perceptíveis de um sistema de con-trole de versão são: • mantém e disponibiliza cada versão já produzida de cada item do projeto; • possui mecanismos para gerenciar diferentes ramos de desenvolvimento possibilitando a existência de diferentes versões de maneira simultânea;

• estabelece uma política de sincronização de mudanças que evita a sobreposição de mudanças;• fornece um histórico completo de alterações sobre cada item do projeto.

O sistema de controle de versões é responsável por armazenar as versões dos ICS’s através de um mecanismo de arquivos e diretórios constantes no repositório, registrando as alterações realizadas. A fim de evitar perda de um trabalho ocasionada quando alguém sobrescreve o trabalho de outra pessoa, o siste-ma de controle de versões provê um mecanismo para controlar as alterações assegurando que as pessoas envolvidas no projeto não trabalhem diretamente nos arquivos armazenados no re-positório, porém em cópias 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. Após as modificações, o arte-fato é revisado e pode ser colocado novamente no repositório através de um processo que denominamos check-in. Neste momento poderá ser estabelecida uma nova baseline.

O controle de versões apoia as atividades de controle de mu-dança e integração contínua, que também são atividades que formam a gerência de configuração de software.

Controle de mudançasO controle de mudanças é o processo de avaliar, coordenar

e decidir sobre a realização de mudanças propostas a itens de configuração. Mudanças aprovadas são implementadas nos itens de configuração.

Mudanças são um fato da vida para sistemas grandes de software. As necessidades e requisitos organizacionais são alterados durante a vida útil de um software. Isso significa que é necessário fazer as mudanças correspondentes. Para garantir que essas mudanças serão aplicadas ao sistema de maneira controlada, é preciso um conjunto de procedimentos de gerenciamento de mudança apoiado por ferramentas.

Esses procedimentos devem ser concebidos para assegurar que os custos e os benefícios das mudanças sejam adequadamente analisados e elas sejam feitas de maneira controlada. Durante o processo de desenvolvimento de software, modificações sem controle levam rapidamente ao caos. Alguns problemas podem ser causados em projetos devido a mudanças não controladas, como: aumento de custos, atraso em entregas, impacto em outros ICS’s, baixa qualidade do software, retrabalho, entre outros.

As mudanças de um ou mais itens de configuração são pro-postas, avaliadas, aceitas e aplicadas. Sendo assim, é necessário estabelecer processos que combinem procedimentos humanos e ferramentas para proporcionar um mecanismo controlado.

Existem diversas ferramentas disponíveis no mercado que oferecem serviços para identificar, rastrear, analisar e controlar as mudanças nos ICS’s. Seus objetivos são manter as informa-ções sobre os pedidos de mudança, controlar as modificações e as implementações realizadas nos ICS’s.

Em um processo de controle de mudanças, quando há a neces-sidade que um ICS seja modificado, um pedido de mudanças é


requisitado, é analisado e um relatório de mudanças é gerado. O relatório é encaminhado para avaliação. Caso seja aprovado, o mesmo é enviado para o gerente de configuração, o qual tem o controle de acesso dos ICS’s no repositório. O gerente de configuração libera para a equipe de desenvolvimento reali-zar a mudança solicitada e recebe os itens quando o mesmo é atualizado no repositório. Quando o pedido de mudança não é aprovado, o relatório e o pedido são arquivados e é dado um retorno ao solicitante. Todo esse controle possibilita que as mudanças sejam efetuadas de modo disciplinado.

Assim, o processo de gerenciamento de mudanças está re-lacionado com a análise de custos e benefícios das mudanças propostas, a aprovações dessas mudanças que valem a pena e o acompanhamento dos componentes do sistema que foram alterados.

MantisO Mantis é uma ferramenta open source, que funciona como

um rastreador de “bugs” que tem como objetivo principal ge-renciar 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 resolução e, consequentemente, seu fechamento. O Mantis também pode ser utilizado para dar suporte ao processo de controle de mudanças, gerenciando as solicitações de modificações. Ele permite relatar solicitações através da opção “Relatar Caso”. Para cada solicitação criada é gerado um número sequencial único que a identifica.

Ao cadastrar uma solicitação, pode-se inserir informações como: categoria, gravidade, status, atualização, resumo, etc. No Mantis, existe um controle de acesso às solicitações através de tipos de usuário tais como: relator, desenvolvedor, atualizador, administrador, visualizador, etc. Cada um possui suas restri-ções de acesso. Além disso, o Mantis proporciona uma visão de todas as solicitações e seus status, exibindo detalhadamente o histórico contendo todas as situações pela qual a solicitação de mudança passou. Desta forma, todas as pessoas envolvidas no processo de GCS podem se manter informadas a respeito do estágio de suas solicitações.

SubclipseO 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 funções forneci-das pelo SVN. A utilização do Subclipse integrado ao Eclipse torna o processo de gerência de configuração mais ágil, pois com o ele é possível realizar ações de versionamento dentro do próprio Eclipse, tais como: commit, update, merge, visualização de histórico de alterações, check-in, check-out, entre outros.

Google CodeO Google Code é um recurso gratuito disponibilizado pela

Google destinado principalmente a programadores e desen-volvedores de software. É um site de código fonte aberto que permite hospedar um projeto em qualquer linguagem de

programação. Para participar, os membros obrigatoriamente precisam possuir uma conta Google. Este sistema disponibili-za alguns recursos como o gerenciador de versões (utilizando Subversion ou Mercurial) e um bug tracker próprio.

O Google Code disponibiliza várias “abas” as quais cor-respondem aos diversos recursos que este sistema oferece, como: Project Home, Downloads, Wiki, Issues, Source e Ad-minister (este último pode ser visto apenas pelo responsável do projeto).

Além disso, os membros do projeto podem hospedar, compartilhar e alterar artefatos inerentes ao projeto, códigos-fonte (com o auxílio do sistema de controle de versões), dar sugestões de melhoria e comunicar possíveis falhas do pro-jeto através da opção Issue, documentar o projeto à medida que o mesmo é desenvolvido através da opção Wiki, entre outras funções.

Estudo de casoA seguir será descrito um exemplo da implantação de um

processo de gerência de configuração através da integração das três ferramentas citadas: • Mantis para o controle de mudanças;• Subclipse como cliente SVN e controle de versões;• Google Code como repositório dos dados.

Todo este processo pode ser visualizado na Figura 1.

Figura 1. Gráfico do processo

Podemos resumir da seguinte forma: primeiramente surge uma necessidade de alteração em algum artefato do projeto. Então é aberta uma solicitação de mudanças através da ferra-menta Mantis. Em seguida, para que a alteração seja feita, é realizado um update para se certificar de que os dados estão atualizados com o repositório. Então a alteração é efetuada e o commit é realizado no repositório de dados. Por fim, a solici-tação de mudanças é fechada. Veremos a partir de agora como funciona esse processo através de um exemplo prático.


ENgENhARiA


A partir da identificação de uma neces-sidade de mudança no código do projeto é gerada no Mantis uma solicitação de mudança. Esta solicitação é enviada para a autoridade responsável por decidir se a mudança deverá ser implementada. A solicitação então é gerada com estado igual a “Novo”. Uma vez aprovado o pedido de mudanças, este é atribuído para o desenvolvedor responsável por realizar a alteração e o mesmo é noti-ficado. Esta solicitação então recebe o estado “Atribuído”, conforme ilustrado na Figura 2.

Para realizar a alteração solicitada, o desenvolvedor, através do Eclipse após realizar o update em sua estação de trabalho, realiza a modificação no sof-tware e solicita o commit no repositório. Então é exibida uma janela conforme a Figura 3, a qual corresponde à janela de confirmação de commit. Esta solicita o preenchimento do número da solicitação do Mantis associado a esta mudança e uma breve descrição que pode ser inse-rida opcionalmente. Estes campos são preenchidos pelo desenvolvedor.

Após a realização do commit, através do comando Show History, pode ser verificado o histórico de atualizações de um determinado item. São exibidas as informações data, autor, comentário e o número da solicitação do Mantis. Nota-se que o número da solicitação é exibido em formato de link, conforme demonstra a Figura 4.

Através deste link é possível visualizar a ocorrência do Mantis correspondente dentro do Eclipse. Isto possibilita iden-tificar qual solicitação de mudança está associada à alteração.

A partir daí o desenvolvedor pode dar o devido tratamento à ocorrência, ou seja, pode alterar o seu estado para “Resolvido” e, posteriormente, o gerente ou relator podem acessar o mesmo his-tórico de alterações, acessar o link da solicitação e definir a solicitação como “Fechada”. Lembrando que toda essa atualização é salva no repositório criado no Google Code.

Através da interação destes softwares, o desenvolvimento de um projeto poderá ser melhor controlado. A cada alteração efetuada, a mesma poderá ser associada

Figura 2. Solicitação com status atribuído

Figura 3. Janela de Confirmação de Commit

Figura 4. Alterações efetuadas

a uma solicitação do Mantis o que facilita entender o porquê das alterações ocorri-das em um determinado artefato.

Através dos exemplos utilizados, pode-se concluir que tais ferramentas

são capazes de apoiar de forma efi-caz as atividades específicas da GCS. O Subversion apoia a atividade de controle de versão, gerando versão dos artefatos e disponibilizando histórico


das modificações realizadas a cada versão. Já o Subclipse (que funciona como cliente do Subversion) foi utilizado pois permite a integração ao Eclipse possibilitando a realização do check-in dentro do próprio ambiente de desenvolvimento.

O Mantis é responsável por dar apoio ao processo de controle de mudanças o qual permite relatar cada necessidade de mu-dança, atribuí-la ao responsável pela alteração, além de gerar histórico de relatório das solicitações. O Google Code funciona como um repositório de artefatos, onde ficam armazenados todos os itens de configuração.

Através da integração destas três ferramentas foi possível verificar que é viável implantar uma solução de GCS com bai-xo custo, qualidade e que pode ser facilmente implementada nas empresas. Esta solução de GCS foi demonstrada através de um exemplo o qual mostrou que para cada necessidade de mudança identificada, pode ser gerada uma solicitação no Mantis a qual pode ser vinculada a cada alteração realizada no artefato. Esta vinculação ocorre durante o procedimento de check-in no repositório do Google Code, quando através do Subclipse é exibida a tela de confirmação de commit solicitando o preenchimento do número do Mantis.

Vimos também que, através da visualização do histórico de alterações, é possível identificar dentro do Eclipse quais solici-tações do Mantis correspondem a cada versão do artefato. Esta solicitação pode ser acessada diretamente do Eclipse através de um link, o que possibilita indicar que tratamento deve ser

dado à solicitação de mudança, ou seja, se a mesma deve ser resolvida ou fechada.

A utilização de ferramentas open source não gera custos para as empresas e a GCS aplicada com a integração de ferramentas é simples e fácil de ser seguida. O tempo gasto com a realização das atividades de GCS certamente será menor do que o tempo que seria gasto para realizar a manutenção de um software desenvolvido sem qualquer controle.

A implantação de GCS apoia-do pela integração de ferramen-tas contribui para a construção

de softwares de qualidade, manutenção da rastreabilidade, evita que esforços sejam concentrados na modificação de uma versão errada, assegura a produtividade e permite que os custos e esforços envolvidos na realização de mudanças em um sistema sejam controlados.

Figura 5. Ocorrência do Mantis

Referências:

PRESSMAN, R. S. Engenharia de Software. 6. ed. [S.l.]: McGraw-Hill , 2006.

SOMMERVILLE, I. Engenharia de Software. 8ª Edição. ed. [S.l.]: Pearson, 2007.

PACHECO, R. F. Uma forma de implantação de gerenciamento de configura-ção de software em empresas de pequeno porte. Dissertação (mestrado) - Instituto de Ciências Matemáticas de Computação - Universidade de São Paulo, São Carlos, 1997.

QUADROS, Moacir. Gerência de projetos de software: Técnicas e ferramentas. 1. ed. Florianópolis: Visual Books, 2002. 502 p. 5. ex.

PFLEEGER, Shari Lawrence. Engenharia de software: Teoria e prática. 2. ed. São Paulo: Pearson Prentice Hall, 2004. 535 p. 5. ex.





Fique por dentro:Este artigo possui orientações e fundamentos destinados a profissionais de teste de softwa-re, contendo os principais conceitos de testes de performance através de uma abordagem simples e direta, baseada em lições aprendi-das na prática da execução deste tipo. O artigo também apresenta seus princípios e práticas, servindo como um guia para adaptar os crité-rios apresentados a outros cenários e projetos específicos. Os usuários avançados podem uti-lizar o mesmo para melhorar sua abordagem, tornando seus esforços de testes mais bem-sucedidos.

Boas práticas para testes de performance Conheça práticas de teste simples e diretas para começar no caminho certo

Fernando [email protected] - https://br.linkedin.com/in/

fernandooliveirabauru

Graduado em Gestão de Tecnologia da Infor-mação, com experiência em Software Quality Assurance (SQA), especializado em testes fun-cionais e não funcionais em aplicações Web. Trabalha atualmente como Analista de Testes, executando testes de performance e carga orientados a aplicações Web.

Testes de performance são testes nos quais uma aplicação é sub-metida a uma carga de trabalho

dentro de condições específicas por um tempo determinado com o objetivo de verificar os comportamentos diferentes que essas condições e cargas podem proporcionar. Com estes procedimentos, podemos observar o comportamento de todo o ambiente da aplicação, desde os defeitos de desempenho (como timeouts e tempo de resposta inaceitáveis), fun-cionais (como inconsistência de dados), estruturais (como memory leak, dados corrompidos e rede com problemas) e até mesmo de segurança (exposição dos dados, etc.).

Basicamente, o teste de performance é a criação de simulações de uso da aplicação ou sistema o mais próximo possível de uma situação real, utilizando ferramentas que automatizam diferentes tarefas. Isso inclui também a infraes-trutura onde a aplicação será alocada (servidores de dados, servidores web, balanceamento de carga, rede, etc.).

A melhor garantia para evitar que uma aplicação web fique indisponível devido à grande quantidade de acessos

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software


simultâneos ou que os usuários procurarem alternativas devido à lentidão no site é a realização de testes de perfor-mance. Podem parecer caros, complexos e demorados, mas se realizados, permitem encontrar e corrigir problemas de desempenho antes que a solução torne-se disponível para o público, reduzindo o risco de perder receita e valor da marca, pois sites ou aplicações instáveis afetam a confiança do visi-tante ou consumidor.

A realização de testes de performance permite avaliar a prontidão da aplicação e verificar se seu desempenho é ou não uma preocupação futura. Uma aplicação hoje pode ter um desempenho aceitável nos testes, mas com base em previsões de crescimento e dados de performance, esta mesma aplicação pode se tornar lenta ou instável demais caso ocorra aumento significativo dos acessos. A infraestrutura de hospedagem poderá ser readequada para melhorar o desempenho ou a própria aplicação deverá passar por uma manutenção para atingir os níveis de performance desejados.

É muito comum empresas e equipes que desenvolvem aplicações web, mas não realizam testes de performance, se depararem com problemas de lentidão, quedas e sobrecarga dos recursos dos servidores quando uma nova aplicação é implantada. O primeiro culpado normalmente é a infraestru-tura (rede, memória, processadores). A solução podia ter sido testada incansavelmente pelos desenvolvedores e testadores antes da implantação, mas apenas testes funcionais não con-seguem identificar um simples problema de performance que pode gerar inúmeros transtornos quando o sistema é colocado em produção (ler BOX 1). Via de regra, os testes funcionais simulam apenas um indivíduo que utiliza o sistema, não 10.000 usuários realizando a mesma tarefa simultaneamente.

Os testes funcionais são aqueles cujo o objetivo é avaliar o comportamento da aplicação

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.

BOX 1. Testes funcionais

Como a maioria dos profissionais que trabalham com testes de software ainda não têm experiência ou não tive-ram nenhum contato inicial com os testes de performance, apresentaremos neste artigo alguns dos critérios mais im-portantes a serem considerados ao se realizar avaliações de desempenho, considerando melhores práticas e estratégias que podem ser adaptadas conforme a realidade da aplicação ou web site testado.

O que são gargalos?Qualquer tipo de recurso do sistema (hardware, software,

banda de rede, etc.) que limite o fluxo dos dados ou a velo-cidade de processamento cria um gargalo. Nas aplicações web, eles afetam o desempenho e até mesmo a escalabilidade, limitando o throughput de dados e/ou o número de conexões suportadas pela aplicação.

Os gargalos podem ocorrer em todos os níveis de arquitetura de um sistema, tais como a camada de rede, servidor de aplica-ções, servidor de dados e servidor web. Entretanto, conforme apontam muitos estudos e experiências, quem causa a maior parte dos gargalos de desempenho é o código do aplicativo, conforme mostrado na Figura 1.

Figura 1. Estimativa dos gargalos distribuídos pela infraestrutura de um sistema

ThroughputBasicamente, throughput ou vazão é a capacidade da aplicação

ou uma parte da mesma de executar uma operação de forma repetida, em um determinado período de tempo. Por exemplo, o throughput de uma página é a quantidade de vezes por segun-do que conseguimos receber uma resposta dessa página.

Esses números são muito importantes porque definem a capacidade da aplicação, medida em acessos por segundo, páginas por segundo ou megabits por segundo. A maior parte de todos os problemas de desempenho é causada por limitações no throughput.

Tempos de respostaÉ o tempo que a aplicação demora para concluir um pro-

cesso de transação. No caso de uma página, é o tempo que a aplicação demora para dar o retorno apropriado para o usu-ário final. É importante medir o tempo de resposta porque a aplicação pode ser rejeitada pelo usuário se não responder dentro de um tempo esperado, mesmo tendo disponibilidade imediata – levando o mesmo a abandonar a página ou até mesmo acessar a página de concorrentes.

O tempo de resposta envolve o período necessário para retornar à solicitação realizada no servidor web. Cada so-licitação deve ser processada e enviada para o servidor de aplicação, que também pode realizar um pedido ao servidor de banco de dados. Tudo isso voltará pelo mesmo caminho até o usuário. O tempo necessário para o retorno também está relacionado com a latência da rede entre os servidores e o usuário.


dESENvoLviMENTo


Boas práticas nos testes de desempenhoTodos os profissionais que trabalham com testes de perfor-

mance já se depararam com a criação de cenários irrealistas ou com a coleta de dados de performance irrelevantes. Mesmo considerando que tais dados coletados estejam corretos, os métodos estatísticos escolhidos para resumir e apresentar os resultados estão errados.

Em alguns casos, os resultados dos testes de performance superestimaram a performance das aplicações web avaliadas e seus problemas de desempenho só foram notados quando as mesmas já estavam em estágio de implantação pelo cliente. Estes resultados podem levar a gastos desnecessários com har-dware 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 inobser-vância de alguns pontos simples, mas importantes, quando se trata de testes de performance em aplicações web.

As informações detalhadas a seguir são algumas práticas baseadas em observações, experiências e lições aprendidas visando simplificar o conceito de testes de performance. Nenhuma metodologia ou ferramenta em específico serão abordadas, pois o foco é descrever as melhores práticas com o intuito de auxiliar os iniciantes a poupar tempo e evitar esforços desnecessários.

Antes de tudo, avalie a infraestrutura da rede da aplicação

Antes de executar cada teste de performance, faça uma avaliação minuciosa na infraestrutura da rede que suporta a aplicação. Se o sistema não suportar a carga de usuários dimensionada na aplicação, ele apresentará gargalos. Essa avaliação é de nível básico e validará a largura da banda, taxa de acessos, conexões etc.

Um teste simples otimiza tempo e recursos, pois evita que tarefas demoradas e complexas sejam executadas em uma infraestrutura que futuramente não 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 cenários de teste.

Evite iniciar com cenários complexosNa maioria das vezes, os testes iniciais são executados

com cenários extremamente complexos, que operam muitos componentes da aplicação ao mesmo tempo. Esse tipo de abordagem não deixa os gargalos aparecerem, ocultando futuros problemas de desempenho.

Antes mesmo da aplicação estar totalmente pronta para implantação, o ideal é realizar testes com cenários menos complexos, um de cada vez.

Consideremos uma aplicação web com quatro cenários de teste definidos:• Cenário 1: Página de vendas, 30% de carga de usuários;• Cenário 2: Listagem de produtos, 10% de carga de usuários;

• Cenário 3: Login de vendedores externos, 5% de carga de usuários;• Cenário 4: Página de ofertas, 55% de carga de usuários.

Se executados concorrentemente, a carga de usuários simultâneos irá distribuir os usuários conforme o per-centual de carga definidos. Observa-se que o menor per-centual de carga é para o cenário 3: “Login de vendedores externos”, pois a equipe de testes definiu que o acesso a esta funcionalidade será mínimo, considerando que durante o dia de trabalho há pouco acesso por parte dos vendedores externos. Uma vez executados os testes, ne-nhum tipo de gargalo foi identificado. Apesar disso, dias após a implantação, a aplicação demorava a responder, gerando reclamações de usuários e dos vendedores exter-nos que não conseguiam realizar o login. Detectou-se que o problema estava no cenário 3. Havia um componente complexo dentro do código 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 pe-queno para este cenário, o gargalo não foi identificado. Apesar dos cenários criados serem baseados na utilização real do sistema, a equipe não previu que durante determi-nado período do mês os vendedores externos acessassem o sistema ao mesmo tempo para lançar os pedidos de clientes. Neste caso, os testes individuais de cada cenário poderiam ter detectado o problema e o gargalo poderia ter sido evitado antes da implantação.

Nunca esqueça do think timeThink time (ou tempo de raciocínio) é o tempo definido

em uma transação no mesmo ritmo de um usuário real. Os cenários tentam prever aquilo que os usuários nor-malmente fazem (navegar, pesquisar, login, comprar, etc.), e o tempo que eles levam para ler, pensar, digitar e clicar. Cada etapa de cada transação deve ter seu think time estabelecido. Dependendo do contexto da transação, o valor do think time irá variar e, por isso, não é aconselhável estabelecer um padrão.

Um exemplo: o acesso à página de login pode demorar de 15 a 20 segundos para um usuário completar. Você pode informar à ferramenta de teste para usar um tempo randômico entre 15 e 20 segundos, ao invés de fixar um valor único. De qualquer forma, é sempre melhor definir um valor de think time do que não definir nenhum, caso contrário os cenários executados causarão um enorme impacto nos servidores, uma vez que transações sem think time ou com valores irreais acarretam sobrecarga nos mesmos. Deve-se sempre lembrar de modelar os cenários com tempos reais previstos de think time

Algumas ferramentas de teste utilizam recursos de gra-vação das transações registrando o tempo de raciocínio que o usuário levou para finalizar cada uma delas.


Ambiente de testesAlém de ser exclusivo para realização dos testes de perfor-

mance, a infraestrutura da mesma deve ser a mais próxima possível da de produção. Todas as configurações, aplicativos, serviços, massa de dados e outros itens que fazem parte do ambiente de produção devem ser reproduzidos.

Evite testar a aplicação em sistemas de produção, uma vez que o mesmo é acessado por outros usuários e é impossível garantir o que está sendo executado nesse ambiente. Sen-do assim, será difícil determinar se as falhas na aplicação são ocasionadas pelos testes ou por outros usuários no sistema.

Uma aplicação simples com apenas um servidor é per-feitamente possível de ser replicada, ao contrário de uma infraestrutura com recursos de grande porte que demandam altos custos de implantação. Nessas situações, mantenha a mesma infraestrutura em proporções menores, mas sempre mantendo a escalabilidade da mesma.

Considere incorporar procedimentos que não são evi-dentes, pois a degradação do desempenho pode ocorrer em tarefas periódicas que não são identificadas facilmente como backup de base de dados, geração de relatórios de-morados, etc.

Gargalos de performance podem ocultar outros gargalos

Sistemas que utilizam muitas APIs devem ter atenção re-dobrada ao identificar gargalos (ler BOX 2). Uma API que não funciona como desejado pode esconder outros possíveis gargalos de outras APIs.

Por exemplo, uma determinada aplicação possui três APIs. Ao final dos testes de performance, a análise dos resultados detectou que a API problemática gerou um tempo de res-posta muito alto para uma certa página. Essa API não está respondendo como esperado, mas não há como garantir que as outras APIs estejam funcionando como deveriam. Se uma API demora para responder, o número de requests encaminhados para as APIs posteriores é reduzido, ocul-tando possíveis problemas nas mesmas.

API é um conjunto de rotinas e padrões de programação para acesso a um aplicativo de

software ou plataforma baseada na Web. A sigla API refere-se ao termo em inglês “Application

Programming Interface” que significa “Interface de Programação de Aplicativos”.

BOX 2. API – Application Programming Interface

O equipamento gerador de carga também deve ser testado

Em um ambiente de testes, além da infraestrutura dos servidores utilizados pela aplicação (servidor web, de da-dos, etc.), existe também a estrutura geradora de carga. São equipamentos configurados para que uma determinada ferramenta de testes execute os cenários de testes, sub-metendo toda a estrutura utilizada pela aplicação à carga determinada.

Uma estrutura geradora de carga pode esconder problemas e limitações que geram ruídos nos testes, ocasionando falsos resultados (como um número reduzido de throughput). Cada equipamento desse ambiente deve ser avaliado e os resulta-dos individuais comparados em busca de inconsistências. O objetivo é identificar se um desses equipamentos tem consumo diferenciado (CPU, memória, banda, etc.).

Monitore os recursos do ambiente submetido à carga

Durante a execução dos testes de performance, é impor-tante 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 avançados no sistema operacional do servidor, existem ferramentas na-tivas que monitoram os recursos, gravando os contadores selecionados conforme a necessidade de cada teste (ver seção Links).

Nunca inicie a carga de uma única vez Em cada ciclo de testes, a carga de usuários deve subir

de forma gradativa durante um período longo de tempo, seguido de um tempo estável de pelo menos uma hora, para então descer gradativamente. Devem ser consideradas ape-nas as métricas do período estável, tanto no comportamento dos servidores quanto da aplicação. Ou seja, o que deve ser avaliado é apenas o tempo de carga estável de uma hora.

Submeter o sistema à carga máxima de uma vez pode sobrecarregar a aplicação Web, e os resultados apresenta-dos durante o período de testes podem não corresponder à realidade.

O poder da regeneração do ambiente de testesUm ambiente de testes é composto pelo gerador de carga

e também pela aplicação que será submetida aos testes. É extremamente importante que antes de cada ciclo de teste executado, todos os ambientes estejam iguais, pois qualquer alteração pode acarretar resultados não correspondentes à realidade da aplicação.

Um exemplo: após o primeiro ciclo de testes, no servidor de dados, um dos bancos teve um acréscimo considerável de dados nas tabelas devido a um dos cenários que alimentava um formulário de dados. Se esse ambiente não for regenera-do nos próximos ciclos de testes, o mesmo banco terá mais dados carregados e seu desempenho pode ficar abaixo do esperado, ocasionando consultas mais lentas. Nessa situa-ção, é importante restaurar o banco de dados a um estado conhecido antes de cada ciclo de teste.

Se esses ambientes forem criados em uma solução virtu-alizada, fica muito mais simples manter esse controle, pois essa tecnologia permite criar “checkpoints” que salvam


dESENvoLviMENTo


um instantâneo do servidor, podendo este ser restaurado a qualquer momento revertendo a máquina virtual a um ponto específico do tempo.

Teste a aplicação considerando o uso após determinado período

Muitos testes de performance não consideram a utilização de toda a estrutura após determinado período. Uma pergun-ta que sempre deve ser feita é: “Como meu sistema vai se comportar daqui a um ano, quando quase 70.000 usuários 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 usuários reais, existe a garantia de que os dados passaram pelas regras de limpeza e verificação da aplicação. Os próprios cenários podem ser utilizados para realizar esse preenchimento.

Os mesmos testes de performance executados anterior-mente serão rodados com o intuito de alimentar os bancos, simulando a utilização prevista daqui a um determinado período. Assim é possível comparar os testes executados com poucos dados e os testes executados com muitos dados já inseridos no banco.

Se for possível, replique o ambiente do seu clienteSe a aplicação a ser testada é um produto que já funciona

em seu cliente, não seria ideal realizar os testes de perfor-mance com dados reais? É sempre importante manter o ambiente de testes o mais próximo possível 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 situação é sempre garantir que dados críticos do cliente serão protegidos ou removidos, com sua ciência e autorização prévia.

Isole o ambiente de testesUtilizando 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. Além dos testes utilizarem uma parte considerável da banda de rede, a própria atividade da empresa pode afetar as simu-lações e seus resultados, pois obviamente utiliza uma parte da banda. Também se deve garantir que somente usuários virtuais autorizados acessarão seu aplicativo em teste.

Participe ativamente desde o início do projetoÉ natural que o teste de performance seja executado somen-

te ao final do projeto (caso a metodologia de desenvolvimen-to não envolva processos ágeis). Na maior parte das vezes, só é possível executar os testes no final do desenvolvimento da aplicação ou quando a mesma já está em implantação pelo cliente. De qualquer forma, é importante que o testador participe também do projeto durante o desenvolvimento do produto. Devemos lembrar que os cenários propostos devem combinar e simular um cenário real com a maior fidelidade

possível. Participando do ciclo de vida do produto, o tes-tador terá mais condições de criar os cenários de teste com entendimento adequado dos padrões comuns de uso.

Objetivos mal definidos para os testes de performance são ocasionados por entendimento inadequado das expectativas dos testes, e muitas vezes vão acarretar na criação demorada de cenários complexos de forma desnecessária. Isto resulta em dados de performance inadequados para uma análise do real desempenho da aplicação.

Testes de performance devem procurar problemas de performance

Em alguns casos, as equipes procuram os testes de performance para confirmar seus requisitos ao invés de tentar identificar problemas. Essa visão pode até mesmo influenciar na criação dos cenários de teste. Se o objetivo é pura e simplesmente executar testes buscando confirmar os requisitos de desempenho da aplicação, a equipe dificil-mente pensará em um cenário hipotético fora dos padrões para incluir nos testes. Um cenário não previsto pode deixar potenciais problemas ocultos.

Teste muitas vezesQuando finalizar um determinado ciclo de teste de

performance, utilize-o como um ponto de comparação e execute-o novamente com as mesmas definições mais de uma vez com o objetivo de procurar possíveis regressões de desempenho. Uma mudança simples não prevista pode causar algum problema inesperado, acarretando perdas de desempenho que não seriam detectadas em apenas um ciclo de avaliação. Por exemplo: foram definidos ciclos de teste de 100, 250, 300 e 500 usuários simultâneos. Nessa situação, não será executado apenas um ciclo de teste para cada car-ga de usuários, e sim cinco ciclos de teste para cada carga de usuários comparando os resultados entre si. Caso seja encontrada uma discrepância ao comparar os resultados, o problema deverá ser investigado em detalhes.

Para o tempo de resposta, considere a proporção de usuários que atingem a meta

O tempo de resposta é o que define a satisfação de um usuário do sistema. Para esse valor, não consideramos o tempo médio que cada transação demora a responder. Deve-se buscar nos registros do teste quantos por cento dessas transações estão abaixo de um tempo de resposta estabelecido.

Supondo que para determinada aplicação, o tempo de resposta estabelecido como aceitável é igual ou inferior a sete segundos. Ao executar os testes, se o tempo médio de resposta foi de seis segundos, o resultado atingindo poderia ser considerado dentro do esperado. Entretanto, há um pro-blema nessa análise. Ao analisar em detalhes os resultados, observou-se que o tempo de resposta dessa transação foi variável, estando tão baixo e tão alto que o tempo médio fez parecer que estava baixo.


Portanto, o ideal é sempre determinar uma quantidade de usuários que serão atendidos por este tempo de resposta, por exemplo: 85% das transações devem responder no tempo máximo de sete segundos.

Nessa situação, analisando novamente os resultados, conclui-se que 78% das transações responderam no máximo em sete segundos, e as demais atingiram tempo de resposta superior a sete segundos. Considerando essa forma de análise, o sistema seria reprovado nos testes de desempenho.

Faça a sondagem com um único usuárioEnquanto o aplicativo está sob carga, acesse-o e procure

explorá-lo para ajudá-lo a compreender a experiência do usuá-rio (como tempos de resposta). Por exemplo, acesse a aplicação pelo browser e navegue pelos cenários propostos, executando ações não previstas.

Muitos problemas no comportamento do sistema só são de-tectados ao interagir diretamente com a aplicação quando ela está sendo submetida aos testes de performance. Uma lentidão em uma rotina que não estava no plano de testes pode esconder possíveis gargalos da aplicação.

Percebe-se que o sucesso do teste de performance de uma aplicação não depende apenas das ferramentas utilizadas.

Desde o planejamento, desenvolvimento de teste, execução e análise, são necessários testadores competentes com conhe-cimento do sistema, da rede e das aplicações de testes, além de uma boa experiência com servidores e, principalmente, habilidade para descobrir problemas ocultos e isolados.




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 – PerfMonhttp://blogs.technet.com/b/dbordini/archive/2008/08/05/usando-o-perfmon-para-avaliar-o-desempenho-de-servidores.aspx

MERRIL, Christopher L. Loading Test by Example – Best Practices. V1.1, 2007http://www.webperformance.com/library/tutorials/BestPractices/

RIBEIRO, CAMILO. Destilando JMeter I: Introdução e Conceitos. The Bug Bang Theory, 2013http://www.bugbang.com.br/destilando-jmeter-i-introducao-e-conceitos/


Fique por dentro:Este artigo apresenta como e quando aplicar testes de performance em aplicações web uti-lizando a ferramenta JMeter. Serão abordadas funcionalidades da ferramenta, quais recursos você pode utilizar para auxiliar o seu projeto e qual a melhor forma de aplicar cada um. Além disso, podemos entender um pouco mais sobre os tipos de teste de performance que podem ser aplicados para conseguirmos extrair a informa-ção que precisamos do sistema. Este artigo será útil para quem está iniciando o teste de perfor-mance e tem interesse em entender como a fer-ramenta JMeter pode ser utilizada para colocar o teste em prática e até ajudar na organização dos scripts da avaliação.

Teste de performance com JMeterConheça um conjunto de práticas para avaliar a qualidade de seu sistema

Dieny [email protected]

Testadora certificada CTFL, Graduada em Aná-lise e Desenvolvimento de Sistemas e apaixo-nada por Teste de Software. Atuou em projetos de teste de performance, automação de teste, teste de serviço e testes funcionais. Experi-ência com criação de plano de testes, criação e execução de casos de testes e execução de testes exploratórios.

Nos ú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, negócios e entretenimento. Com esta evolução, sempre temos mui-tos usuários acessando, navegando e efetuando transações na aplicação. Para garantir que a aplicação aguentará uma certa quantidade de usuários e avaliar a experiência que ele terá na aplicação verificando qual o tempo de resposta a cada iteração, muitas empresas estão 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 sub-metemos o sistema a uma avaliação

de carga, stress ou desempenho para avaliar se os resultados estão de acordo com o esperado, garantindo assim a qualidade do sistema. Nestas avaliações, simulamos picos de usuários no sistema para investigar até onde ele suporta. O teste é iniciado com uma carga baixa e vai aumentando gradativamente.

O teste de stress é a avaliação em que colocaremos de primeira o máximo que o sistema aguenta.

Desenvolvimento

Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software


Já o de desempenho serve para medirmos o que a aplicação já suporta. É executado com uma carga constante e mantido por horas. Neste caso, é feita a análise do tempo de resposta do sistema a cada interação do usuário.

Lembrando que quando estamos falando de teste de per-formance, não temos uma nomenclatura padronizada. Neste artigo iremos considerar a nomenclatura definida no livro Performance Testing Guidance.

É interessante que a primeira avaliação 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 utili-zar em cada avaliação é monitorar o sistema em produção durante um tempo. Se soubermos a quantidade de visitas que o sistema recebe diariamente, quais os horários com mais acessos e quais as funcionalidades mais utilizadas, saberemos quais cargas definir para realizar o teste em cada funcionalidade.

A análise final do teste de performance é realizada através dos dados coletados de sua execução, dos logs do banco de dados e dos logs do servidor de aplicações. É importante, neste cenário, estar em contato com a equipe de infraestrutura e a equipe de redes, pois a análise por completo da estrutura do sistema será mais eficiente e o resultado será mais preciso e abrangerá muitas informações importantes no momento da tomada de decisão sobre os resultados.

Neste artigo serão 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 serão apresentados os principais recursos desta ferramenta, como: requisições, temporizador, extrator de expressão regular, asserções, utilização de variáveis, configuração e execução do teste e análise dos resultados. Veremos como e quando utilizar cada um desses recursos.

JMeterQuando falamos em teste de performance, sempre a primeira

ferramenta que nos vem à cabeça é o JMeter, isso porque é um software que está há um tempo no mercado e tem vários 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 código aberto, podemos desenvolver melhorias para atender melhor o projeto que iremos utilizá-la, como plug-ins para gerar outros relatórios além dos que a ferramenta já oferece.

A instalação do JMeter é bem simples. Seu download pode ser efetuado no site da Apache (ver seção 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 gestão dos scripts de teste e no controle de cenários aplicados, facilitando a manutenção dos mesmos;

• para configurações de ambientes de testes para execução em servidores e vários terminais;• para auxiliar nas avaliações das respostas recebidas para as requisições enviadas aos servidores.

Estes são os principais recursos da ferramenta e serão abor-dados de forma mais detalhada nos tópicos a seguir. Outros recursos que serão apresentados são:• os controles de gravação que são importantes no momento da gravação dos scripts, ajudando a economizar tempo no projeto;• o extrator de expressão regular que auxilia a coleta de da-dos dos resultados retornados para o JMeter, podendo assim realizar validações durante o teste;• como utilizar variáveis no script de teste para deixar o teste o mais próximo do cenário real do sistema e do seu dia a dia.

Neste artigo iremos falar do JMeter para teste de performance, porém, também é possível criar e executar testes funcionais e em banco de dados, embora existam outras ferramentas no mercado com melhores recursos para executar estes tipos de avaliação.

Criando o script de testeAssim como em outros tipos de teste, é importante decidir o

que deve ser testado e como proceder essas avaliações. Não é interessante avaliar todas as funcionalidades do sistema uma vez que o esforço seria muito alto, então devemos avaliar quais devem ser priorizadas. No caso do teste de performance, de-vemos considerar dois pontos: funcionalidades que têm muito acesso simultâneo (por exemplo, em um e-commerce, o cenário de compra é o mais importante e o que devemos garantir que tenha performance excelente para que o cliente não passe a comprar em outro local motivado por um desempenho ruim enquanto realizava sua compra) e funcionalidades em que a requisição possa ser mais lenta, como upload e download de arquivo.

Após definir quais funcionalidades serão testadas, devemos dividi-las em casos de testes, que poderão ser organizados por grupos de usuários. Então teremos o plano de teste para agrupar os casos de testes. Todos os casos de testes poderão 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 cenários de avaliação definidos foram “Realizar Login”, “Cadastrar Usuário” e “Realizar e Concluir uma Compra”. Nestes cenários podemos definir que o “Login” terá uma carga de 40 usuários simultâneos, o “Cadastrar Usuário” 10 usuários simultâneos e o “Realizar e Concluir uma Compra�, 50 usuários simultâneos. Desta forma, cada caso de teste pode ser adequado ao cenário real que temos em produção. Veremos mais sobre configurações de execução no tópico “Configura-ções e Execução do Teste”. Depois de definidos todos os casos de testes, iremos criar um script de teste para automatizar sua execução.


dESENvoLviMENTo


O JMeter possui uma estrutura muito fácil 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 responsável por controlar a execução de todos os grupos de usuários. Nele que iremos agrupar todos os componentes. Além disso, também iremos definir algumas configurações das execuções, como se os grupos de usuários devem ser executados simultaneamente ou con-secutivamente; ativar o modo de teste funcional para o JMeter salvar dados das respostas do sistema, e; podemos definir variáveis globais que serão utilizadas na execução do teste. Falaremos mais sobre a utilização de variáveis no tópico “Utilizando Variáveis”.

No plano de teste, podemos inserir inúmeros grupos de usuários. Cada um executará um teste diferente podendo ser este executado simultaneamente ou não.

O grupo de usuários é o componente que controla a execução dos cenários. Nele definimos quantos usuários devem interagir com o sistema simultaneamen-te, qual o tempo de duração e qual ação o JMeter deve tomar quando ocorrer um erro com um usuário.

Para criar o teste devemos adicionar, no grupo de usuários, as requisições necessárias para simular o teste. Re-lembrando que devemos adicionar um grupo de usuário para cada caso de teste do plano.

Além das requisições, é importante adicionar Asserções para garantir que o teste execute de forma correta. Por exem-plo, após realizar um login na aplicação, é interessante inserir uma asserção para garantir que o login foi feito com sucesso antes de realizar o próximo passo. Neste cenário, se a aplicação travar no login, será fácil identificar no relatório final onde está o gargalo.

Devemos também adicionar o tem-porizador para que o tempo de cada requisição simule o tempo real que o usuário leva para realizar cada iteração com o sistema e o extractor de expressão regular caso a aplicação necessite passar dados de uma resposta para a próxima requisição enviada ao servidor. Por fim,

Figura 1. Árvore de componentes do JMeter

devemos adicionar os componentes ouvintes para realizar a análise após a execução do teste. Nos próximos tópicos, falaremos destes componentes e qual sua importância no teste.

Controlador de gravaçãoNo grupo de usuários, devemos adi-

cionar as requisições que representam cada passo do caso de teste. As requi-sições podem ser adicionadas uma a uma manualmente ou podemos utilizar um componente que o JMeter oferece chamado controlador de gravação. Este componente faz parte do grupo de con-troladores lógicos. Ele nos permite gravar a execução de um cenário, com isso todas as requisições são geradas dessa forma sem a necessidade de inserção manual, sendo basicamente um record/play.

Porém, é necessário realizar ajustes nas requisições para a execução ocorrer com

sucesso, como trocar os valores fixos por variáveis e ajustar algumas configura-ções. Por exemplo, em um cenário de download e upload, as configurações da requisição devem ser diferentes de como o controlador de gravação se comporta em cenários comuns de interação com o usuário.

RequisiçõesPara enviarmos requisições aos servi-

dores, devemos utilizar os componentes do sampler. Nele temos disponíveis várias opções de requisições, como FTP, SOAP/XML-RCP, Java, HTTP, entre outros.

Na Figura 2 temos um exemplo de uma requisição HTTP para realizar um login. O endereço acessado é o 127.0.0.1, já o ca-minho foi definido para “/Login”. Estamos enviando os parâmetros para realizar o login e o método definido é POST.

Figura 2. Componente Requisição HTTP


Temos várias opções de métodos para definir na requisição, porém os mais utilizados são GET e POST. O GET envia uma requisição ao servidor e ela é somente de leitura ou consulta. Já o POST também envia uma requisição ao servidor, porém ela pode enviar dados para inclusão ou edição de registros.

Nos parâmetros enviados, podemos ver a variável ${USUARIO}declarada. Neste caso, cada usuário enviará a re-quisição com um dado diferente, porém simultaneamente. Falaremos mais sobre configuração de variáveis no tópico “Utilizando Variáveis”.

TemporizadorPara simular a ação real do usuário

na aplicação, devemos emular o Thiking time, ou seja, o tempo que o usuário pensa entre as ações que ele realiza no sistema. O JMeter disponibiliza alguns componentes, como o “temporizador constante” e o “temporizador aleatório uniforme” para simularmos esta ação.

Extrator de expressão regular Sempre que optamos por rea-

lizar teste de performance em um siste-ma, devemos conhecer a sua estrutura para sabermos que recursos teremos que utilizar para que a avaliação seja executada corretamente. Por exemplo, se a aplicação foi desenvolvida em ASP.NET, teremos que extrair e repassar a VIEWSTATE em todas requisições.

VIEWSTATE é uma solução ASP.NET que armazena as informações e o estado dos controles e objetos da página para se manterem quando um Postback ocorrer na página.

Quando gravamos o teste pela primeira vez com o JMeter, ele arma-zena a VIEWSTATE atual da gravação. Sendo assim, quando executamos o

Figura 3. Componente Extractor de Expressão Regular

teste novamente, ele enviará na requi-sição uma VIEWSTATE inválida. Para solucionarmos isso, deveremos extrair a VIEWSTATE das respostas que rece-bemos utilizando o componente extrator de expressão regular e repassá-la na próxima requisição.

Na Figura 3 podemos ver uma confi-guração de expressão regular. Nele está definido que a extração deve ser feita no corpo da resposta (Campo da Resposta a ser verificado), mas poderíamos extrair a expressão de outras partes da resposta, como da URL ou cabeçalho.

No campo Nome de Referência deve-mos definir o nome da variável onde o JMeter salvará a que será extraída. No caso da Figura 1, a variável foi nomeada para VIEWSTATE. Depois devemos utili-zar esta variável como “${VIEWSTATE}” onde for necessário usar a expressão extraída.

No campo Expressão Regular devemos inserir a fórmula para extrair a expres-são que queremos. No caso da Figura 3, a expressão é “id=”__VIEWSTATE” value=”(.+?)””. Neste caso, o JMeter irá extrair da resposta da requisição o valor onde está o código “(.+?)” e armazená-lo na variável “${VIEWSTATE}”.

Existem várias formas de extrair um dado. É interessante estudar o compo-nente Extração de Expressão Regular para utilizá-lo de forma eficiente em cenários onde a extração é complexa, por exemplo, em casos em que o resultado contenha mais de uma resposta para a expressão simples.

No campo Modelo devemos apontar a quantidade de variáveis que esta-mos extraindo neste componente. No exemplo da Figura 1, estamos indi-cando que apenas uma variável será extraída. Se fossem duas variáveis, deveríamos inserir “$1$$2$” no campo.

E no momento de utilizar os dados, de-clararíamos “${VIEWSTATE_g1}” para acessar o dado da primeira variável e “${VIEWSTATE_2}” para acessar o dado da segunda variável.

Por fim, no campo Valor Padrão, defini-mos o valor que o JMeter utilizará quan-do não encontrar a expressão regular na resposta da requisição.

Uma forma de avaliar se a expressão regular está correta é conferir a resposta da requisição utilizando o componente ouvinte. Falaremos mais sobre os com-ponentes ouvintes no tópico “Avaliação e relatório da Execução do Teste”.

AsserçõesPara garantir que o script de teste esteja

executando com sucesso, que o sistema não deu timeout durante a execução, de-vemos utilizar asserções para verificar o resultado da resposta da requisição que enviamos.

Para validar conteúdo das respostas das requisições, podemos utilizar Extra-ção de Expressão Regular e XPath. Outra asserção que podemos usar é a asserção de duração que é onde definimos o tempo máximo que a aplicação tem para responder a requisição enviada.

Para visualizar o resultado das asser-ções, devemos utilizar o componente ouvinte. Com o resultado das asserções, podemos inserir condições para o JMe-ter realizar, por exemplo, quando uma asserção falhar para a execução do teste com aquele usuário.

Utilizando variáveis Para o teste de performance simular uma situação real, é importante que cada usuário utilize variáveis diferente dos outros usuários simultâneos. No cenário de login, por exemplo, podemos conectar ao sistema utilizando usuários com perfis de acesso diferentes.

Caso a variável utilizada seja a mesma para todos os usuários, é uma boa prática declará-la como variável global no com-ponente plano de teste. Assim, quando quisermos alterá-la, será necessário rea-lizar a alteração em apenas um local.

Para configurar as variáveis por usu-ário, devemos utilizar o componente Configuração dos dados CSV.


dESENvoLviMENTo


Na Figura 4 podemos ver um exemplo de configuração de variáveis com CSV.

Na configuração apresentada, pode-mos ver que no “Nome do arquivo” é inserido o caminho onde o arquivo CSV está salvo. As variáveis são definidas no campo “Nomes das variáveis”. Estas devem estar na mesma sequência do CSV. Também podemos definir quais usuários utilizarão o CSV na execução. No exemplo temos “Todos os usuários virtuais”. Para declarar as variáveis na requisição devemos utilizar “${}”.

Configurações e execução do testeApós termos todos os scripts de teste

criados, é necessário realizar algumas configurações. Em cada grupo de usuário devemos definir quantos de-les executarão aquele teste, tempo de inicialização e tempo de execução. Mas antes, devemos avaliar qual o objetivo do teste para definir como deve ser a configuração realizada. Os objetivos podem ser:• Avaliar como o sistema se comporta com a carga atual;• Avaliar qual a carga máxima que o sistema suporta;• Descobrir os pontos de gargalo;• Tempo má x i mo esperado nas requisições.

Na Figura 5 podemos observar um teste configurado para executar 100 usuários (número de usuários virtuais). Ele irá aguardar 10 segundos para ini-cializar o teste (tempo de inicialização) e irá executar o teste durante uma hora (tempo de início e tempo de término).

Uma outra forma de configurar a quantidade de execuções dos usuários é colocando quantidade no contador de iteração e desabilitar o modo infinito. Desta maneira, o JMeter irá executar o teste com 100 usuários a quantidade de vezes definida neste campo.

No teste da Figura 5 também foi defini-do que quando ocorrer um erro no teste do usuário, o JMeter deve começar a pró-xima avaliação a partir deste usuário.

Para garantir o sucesso da execução do teste e que os resultados sejam ver-dadeiros, o ambiente deve estar bem configurado. Deve-se avaliar a carga que

Figura 4. Componente Configurador dos dados CSV

o teste irá executar para definir qual será o tamanho do seu ambiente. A execução pode ser feita na nuvem ou pode ser dis-tribuído em IPs físicos ou virtuais.

Na Figura 6 temos uma representação de uma configuração de ambiente onde o JMeter cliente gerencia todo o teste e, ao iniciar a execução, ele distribui todos os usuários nos quatro IPs que são os JMeter Servers, que por sua vez enviam requisições acessando o alvo de teste.

Avaliação e relatório da execução do teste

A análise dos resultados é a parte mais importante do teste, afinal se passarmos resultados falsos para o cliente ou su-pervisores, o sistema apresentará erros em produção e teremos retrabalho para a equipe do projeto.

Para monitorar os testes, o JMeter dis-ponibiliza vários componentes que são chamados de ouvintes que podemos adi-cionar ao plano de teste, em cada grupo

Figura 5. Configurador do componente Grupo de Usuários

de usuário ou em cada requisição. Lem-brando que quanto mais ouvintes inse-rirmos, mais memória consumiremos da máquina na hora da execução e isto pode afetar a execução da avaliação.

A seguir serão apresentados três dos ouvintes mais utilizados para monitorar o teste.

Ouvinte árvore de resultadosO ouvinte árvore de resultados, re-

presentado na Figura 7, captura muitas informações de cada requisição feita por cada usuário durante o teste. Por exem-plo, quais parâmetros foram enviados na requisição e qual o tempo de resposta do servidor, e exibe o conteúdo da resposta da requisição na aba dados da resposta. Nele também conseguimos visualizar quais variáveis aquela requisição enviou como parâmetro. É possível selecionar várias opções de exibição dos dados da resposta, como: texto, HTML, JSON e JavaScript.


Podemos também selecionar as opções XPath Tester e RegExp Tester para testar as fórmulas utilizadas nas extrações de expressões regulares e asserções.

Ouvinte resultado de asserçãoEste ouvinte não influencia na geração

do relatório, mas é importante para sabermos quais asserções passaram e quais falharam.

Ouvinte relatório de sumárioEsse ouvinte é apresentado na Figura 8,

que nada mais é do que uma planilha que o JMeter gera com as principais informações da execução do teste, como: quantidade de usuários (amostras) que executaram cada requisição (rótulo), tempo médio em milissegundos (média), tempo mínimo em milissegundos (mín) e tempo máximo em milissegundos (máx), entre outras. Esses tempos são calculados considerando todas as exe-cuções simultâneas.

Além destes ouvintes, o JMeter tem muitos outros que geram gráficos e for-necem muitas informações importantes. Por exemplo, é interessante também mo-nitorarmos o banco de dados e o servidor da aplicação. Assim, é possível avaliar em que momento do teste a aplicação caiu, se teve picos elevados e qual a carga máxima que a aplicação suportará.

A execução do teste deve ser feita enquanto o sistema não tem nenhum outro acesso, apenas a nossa avaliação rodando para evitar interferência nos resultados.

O teste de performance deve ser traba-lhado como um projeto de teste, para o qual precisa ser feito um planejamento completo, estimar o tempo de criação dos scripts, o tempo de execução, tempo de análise e da geração do relatório final.

Este tipo de teste tem o momento certo para ser executado: a aplicação deve es-tar estável, já deve ter passado por teste funcional, estar sem bugs e não deve ter nenhuma melhoria para ser aplicada durante sua execução. Por exemplo, não é interessante criar um script de teste para uma funcionalidade que ainda so-frerá alterações antes da execução, pois o script terá que ser atualizado, assim gerando retrabalho.

Figura 7. Ouvinte Árvore de Resultados

Figura 8. Ouvinte Relatório de Sumário

Figura 6. Representação do ambiente de execução do JMeter


dESENvoLviMENTo


O ideal é realizar este teste na versão que será liberada para ou já está em produção, tomando o cuidado com o horário da execução e configurações para não afetar os dados reais de produção.

Neste artigo, a ferramenta utilizada para demonstração foi o JMeter, mas antes de iniciar o projeto de teste de performance em sua organização, é interessante avaliar todas ferramentas no mercado e avaliar qual delas melhor atende aos requisitos de seu projeto.

Referências 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. “Introdução ao teste de software”. Instituto de Ciências Matemáticas e de Computação - ICMC/USP, Nota Didática, 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 – User’s Manualhttp://jmeter.apache.org/usermanual/index.html

[2] Manual de Utilização da Ferramenta JMeterhttp://www.freetest.net.br/downloads/Ferramentas/JMeter/Manual_JMeter.pdf

[3] Performance Testing Guidance for Web Applicationshttps://msdn.microsoft.com/en-us/library/bb924375.aspx





C

M

Y

CM

MY

CY

CMY

K

Porta80_AnINst.pdf 1 18/09/2011 14:58:37

engenharia software 85 gestao de configuração

Documents