Esta cultura tem tornado cada vez menos rígida a fronteira entre o desenvolvimento e as operações de TI necessárias para manter os sistemas no ar.

Diante dos muitos benefícios trazidos pela adoção das práticas de DevOps, principalmente em times ágeis, quais seriam as razões para que esta cultura tenha ganhado força somente num passado recente? Que fatores motivam as práticas de DevOps? Que fatores permitiram que o DevOps se tornasse uma realidade?

No post de hoje vamos elicitar 3 grandes motivadores da cultura DevOps na atualidade.

O conflito histórico entre equipe de infra e equipe de desenvolvimento parece estar com os dias contados. As práticas de DevOps vem com o objetivo de facilitar a integração entre atividades de desenvolvimento, como criar novas features, resolver bugs, etc, e as operações de infra para manter o sistema no ar como manutenção dos servidores, sincronização e deploy do código, etc.

Realizar estes dois tipos de tarefas de forma coordenada pode trazer diversos benefícios através da colaboração entre os profissionais que criam e testam as aplicações e as equipes que mantém todo o ambiente de produção no ar. Para mais informações sobre DevOps, leio o post "Já Ouviu Falar em DevOps?".

Como falei no início do post, os processos de DevOps começaram a marcar presença mais fortemente nos times de TI somente nos últimos anos. Principalmente pela constante necessidade de mudanças e, consequentemente, pela maior necessidade de agilidade nas entregas, o cenário que encontrado em muitos times de desenvolvimento praticamente "pedia" a aplicação dos processos de DevOps.

Entender os motivos que levaram a ascensão destas práticas pode ajudar na aplicação das mesmas de forma a extrair o máximo dos benefícios trazidos com as técnicas de DevOps. Abaixo, enumeramos 3 grandes fatores que ajudam a entender o porquê da adoção e valorização das práticas de DevOps atualmente:

1. Cultura Ágil

Dentre tantas melhorias, como os avanços nos meios nos setores de telecomunicação e tecnologia da informação tornaram a realidade das organizações cada vez mais dinâmicas.

Com ambientes mais dinâmicos surge a necessidade de maior flexibilidade e respostas mais rápidas às mudanças. Mais especificamente na área de TI, é preciso que os sistemas sejam desenvolvidos e mantidos de maneira que mudanças possam ser aplicadas com agilidade.

É necessário estar continuamente entregando valor. Para que isso seja possível é preciso que, uma vez desenvolvido, um sistema possa ir para produção rapidamente e com qualidade. Um gargalo que pode ser comumente encontrado é na burocracia muitas vezes imposta pelas equipes que mantém os sistemas no ar. Para estas equipes, a priori, mudanças não são bem vindas e estão sempre associadas a riscos. Porém, para o negócio as mudanças tem se tornado cada vez mais necessárias.

O tempo entre o desenvolvimento de um recurso e o deploy em produção pode ser um fator determinante para o sucesso ou fracasso de uma iniciativa de uma organização. Diante deste cenário é possível notar os processos de DevOps surgem como uma prática interessante na medida em que permitem que as mudanças sejam levadas rapidamente para produção de forma coordenada e com qualidade, reduzindo o time to market.

As práticas de DevOps tratam de tornar mais eficientes e, quando possível, automatizar todas as operações necessárias para que um código saia do desenvolvimento e chegue em produção com rapidez e qualidade, que é o que se pretende dentro da cultura ágil.

2. Tecnologia

Operações como realizar deploy de forma bem controlada, gerar de pacotes, executar testes, automatizar scripts para sincronização de pacotes, dentre outras operações não são desejos recentes na TI.

Antes mesmo do crescimento da cultura ágil e da necessidade de entregas contínuas, a automatização de operações de TI já era um desejo em muitos times. Podemos nos perguntar: Então por que estas operações ganharam maior atenção agora com as práticas de DevOps?

O primeiro ponto que me vem em mente é o fator financeiro. Antigamente, responder rápido a mudanças era algo não tão "lucrativo" quanto hoje. Primeiro porque o custo para automatizar estas operações era mais alto.

Segundo, por que a necessidade por respostas rápidas a mudanças não era tão grande quanto hoje.

Outro ponto é a tecnologia. Atualmente com a virtualização e computação na nuvem, além da alta capacidade de processamento das máquinas, ficou facilitada a construção de ferramentas voltadas para o apoio às operações de TI, como automatização de testes e gerência de configuração,por exemplo. Além disso, os crescentes investimentos em aplicativos para dispositivos móveis tem impulsionado criações e atualizações que precisam ser lançados frequentemente com agilidade e qualidade.

3. Infra estrutura mais complexa

Manter os sistemas de uma organização no ar tem se tornado uma tarefa cada vez mais complexa. Atualmente, muitas são as formas de disponibilizar as aplicações no ar. A manutenção, que antes era feita somente sobre as máquinas físicas, hoje é feita sobre máquinas físicas, máquinas virtuais, além da nuvem.

Estes novos recursos permitem que as equipes responsáveis por manter os sistemas no ar tenham maior previsibilidade, garantias e SLA bem definidos na manutenção de seus sistemas.

Por outro lado, a complexidade decorrente destes serviços requer que as operações de TI estejam bem definidas e automatizadas na medida do possível, para garantir que os benefícios alcançados com estes serviços sejam alcançados.

A partir destes 3 grandes fatores fica fácil perceber a necessidade e os benefícios que o DevOps pode trazer às organizações atuais.

Para o desenvolvimento ágil é importante que as operações sejam feitas com a colaboração de todo o time, conferindo mais rapidez nas entregas, e economizando nas burocracias.

Métricas importantes como o Time to market são afetadas diretamente com a implantação das práticas de DevOps, que pode reduzir significativamente o tempo necessário para que um produto seja disponibilizado no mercado.

The post 3 Motivadores para a Cultura DevOps appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Quando falamos em testes automatizados, o que vem primeiro à cabeça? Testes que simulam o usuário utilizando uma aplicação, através da UI (User Interface)? Testes de unidade (ou unitários)? Neste post, vamos mostrar os níveis de testes automatizados dentro do Agile e como melhorar a estratégia de automação de testes da sua empresa.

Em empresas que estão começando a trabalhar com testes automatizados, é comum vermos o uso de ferramentas do tipo record-playback, como o Selenium IDE, para criar scripts de testes validando cenários de ponta-a-ponta em uma aplicação, através da UI. Esses testes também são chamados de Testes de Aceitação. Ferramentas como essas facilitaram bastante a criação desses testes, permitindo até que um usuário possa gravar um teste, sem requerer skills de programação. Soluções pagas, como as da IBM, HP e Microsoft, também oferecem ferramentas desse tipo.

Infelizmente, também é comum cair na "tentação": gravar centenas de testes que navegam pela UI, só percebendo que algo está errado quando um novo campo é incluído em uma tela, ou quando o identificador de um elemento é alterado, por exemplo. A médio/longo prazo surgem os problemas: o custo de manutenção se torna alto, os testes demoram muito para rodar (aumentando tempo de build) e dar feedback sobre o sistema, muitos testes falham devido a falsos negativos, etc.. Com isso, o time acaba perdendo a confiança nos testes e, muitas vezes, deixando de rodá-los.

Essa preocupação com o tempo de build e de feedback dos testes não vem dos dias de hoje. No XP (Extreme Programming), na parte sobre Integração Contínua [1], já se falava da importância do "10-minute build". James Shore, no livro The Art of Agile Development, cita o "10 or 15-minute build", que seria o tempo máximo razoável para obter feedback do seu build. Em suas próprias palavras, "That's about the right amount of time to stretch my legs, get some coffee, and talk over our work with my pairing partner". O assunto é tão relevante, que Dan Bodart, em sua palestra Crazy Fast Build Times – Or when 10 seconds starts do make you nervous, mostra maneiras de reduzir em até dez vezes o tempo de build de uma aplicação.

Em empresas que possuem times ágeis, testes de unidade (e também o TDD) já nos ajudam muito nessa situação. Quando temos uma boa quantidade de testes de unidade para um sistema, se faz menos necessário automatizar testes tão exaustivos pela UI. Testes de unidade são fáceis de manter, são muito efetivos para testar valores limite ou possíveis combinações de desvios dentro do código e rodam extremamente rápido, nos dando um bom feedback sobre nosso sistema em pouco tempo. Porém, por definição, estamos testando comportamentos de componentes isolados, de forma que uma hora ou outra deveríamos testar a integração entre eles, certo? Logo, criamos então um teste que navegue pela UI para validar isso? Não!

Pirâmide de Automação de Testes

Em seu livro Succeeding with Agile, Mike Cohn descreve o conceito da Pirâmide de Automação de Testes (Test Automation Pyramid).

Segundo Cohn, uma estratégia eficiente de testes automatizados deve contemplar testes em três níveis: Unidade, Serviço (Integração) e UI. Na base da pirâmide, temos uma grande quantidade testes de unidade, que devem ser a base de uma boa estratégia de testes automatizados. No topo, uma quantidade pequena de testes de UI, justamente para evitar os problemas que comentamos anteriormente. No meio, temos uma quantidade razoável de testes de serviço, que também podem ser chamados de testes de integração, API Tests, etc.. Cohn, no artigo The Forgotten Layer of the Test Automation Pyramid, comenta sobre a importância desse nível de teste e seu papel em preencher o gap entre unidade e UI.

Testes na camada de serviço testam, basicamente, os serviços da aplicação, “abaixo” da UI. Essa abordagem evita com que todo teste, além do teste de unidade, seja executado diretamente navegando pela interface do usuário. Com isso, em vez de executarmos testes exaustivos validando todas as regras de negócio pela interface, podemos fazer testes abaixo da UI. Esse tipo de teste tem sido muito importante, visto que muitas aplicações hoje em dia possuem interfaces Web e Mobile (smartphone, tablet), sendo necessário separar a interface da lógica da aplicação. Martin Fowler se refere a esses testes com o nome de Subcutaneous Tests.

Dentro do Agile, podemos fazer esses testes para validar os critérios de aceite das histórias, por exemplo. Uma boa abordagem é o uso de BDD (Behaviour-Driven Development) [2]. Para aplicações Java, existe o Arquillian, que tem diversos recursos para criação desses testes, além de extensões que ajudam na criação de testes com Selenium WebDriver e Page Objects.

Testes na UI

Com testes na camada de serviço, não precisamos validar todas as regras de negócio de um sistema pela UI. Podemos focar esses testes em funcionalidades críticas (Smoke Tests), em testes que validem aspectos da interface, ou em testes com diversos browsers (xBrowser Testing). Smoke Tests formam o subconjunto dos testes mais importantes, que garantem que a aplicação está realmente OK. O ISTQB (International Software Testing Qualifications Board) os define como:

                "Subconjunto de todos os casos de testes definidos/planejados que cobre as principais funcionalidades de um componente ou sistema, para averiguar as principais funções de um programa em funcionamento sem se preocupar com maiores detalhes."         

Quando concentramos os testes automatizados para a camada de UI, como descrevemos no início do post, em vez de termos uma pirâmide, temos o chamado "Ice-cream Cone", vide figura abaixo:

Como evitar os problemas de testes na UI?

1. Uso do pattern Page Objects

Padrão preconizado pelo próprio Selenium, que propõe separar os testes da complexidade da UI, melhorando a legibilidade, manutenibilidade e reusabilidade do código.

Importante: Tratar código de teste como código de produção!

2. Uso de Headless Browsers

Headless Browsers funcionam da mesma forma que browsers comuns, com a diferença de não ter uma interface gráfica. São mais rápidos para testes e são muito bons para usar com Integração Contínua. Hoje em dia, o mais popular é o PhantomJS, que utiliza a engine gráfica WebKit, a mesma usada pelo Google Chrome. Há também o SlimerJS e o HtmlUnit.

Frameworks e headless browsers suportados:

• Selenium WebDriver

   

  • HtmlUnit, através do HtmlUnitDriver
  • PhantomJS, através do GhostDriver
• Capybara

   

  • HtmlUnit, através do Celerity
  • PhantomJS, através do Poltergeist
• CasperJS

   

  • Suporta o PhantomJS (engine WebKit) e o SlimerJS (engine Gecko)

 3. Uso de BDD

Existem diversos frameworks para ajudar na adoção de BDD, como:

• JBehave (Java)
• Cucumber (Ruby, Java, etc.)
• SpecFlow (plataforma .NET)
• easyb (Groovy)

 4. Paralelizar testes

É possível rodar testes em paralelo, diminuindo bastante o tempo de execução. Pode-se usar TestNG, Maven e Selenium Grid para tal.

Finalizando, recomendo a leitura do artigo Eradicating Non-Determinism in Tests, do Martin Fowler e da palestra Lições do Futuro: O que eu queria saber há alguns anos atrás sobre como manter uma suíte de testes, do Eder Ignatowicz e Fabio Santos, apresentada nas edições 2012 e 2013 do TDC. Compartilhem suas dúvidas nos comentários!

Referências:

http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

http://martinfowler.com/bliki/TestPyramid.html

[1] https://blog.myscrumhalf.com/2012/06/a-integracao-continua-utilizada-no-dia-a-dia-do-desenvolvimento-agil/

[2] https://blog.myscrumhalf.com/2011/10/bdd-%E2%80%93-foco-no-comportamento-do-sistema/

The post Melhorando sua Estratégia de Testes Automatizados appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá Pessoal, no post de hoje irei falar sobre o Agilte Tester, o testador ágil. Esse termo é utilizado no livro Agile Testing: A Practical Guide for Testers and Agile Team para identificar o testador que está alinhado com os princípios e valores ágeis.

Em projetos de software, testes sempre são um motivo para discussão. Em projetos tradicionais, normalmente há uma gerência (Gerência de Qualidade) e uma equipe (Equipe de Garantia de Qualidade) que são responsáveis por especificar e realizar os testes. A Equipe de Garantia de Qualidade busca encontrar erros, sejam erros de não conformidades com normas técnicas ou não atendimento de requisitos do software. Por outro lado, em projetos ágeis, essa burocracia pode atrapalhar bastante o andamento do projeto. Atualmente, técnicas como o TDD indicam que os testes deve ser escritos e executados pelos próprios programadores, quebrando um pouco a prática tradicional.

Agile Testing é mais do que isso, é uma forma de utilizar os valores ágeis para auxiliar o testador, o chamado Agile Tester, o ajudando a fazer melhor seu trabalho, a ajudar seu time a entregar um maior valor de negócio para o projeto a cada iteração. Logo, não basta escrever um teste automatizado em um projeto ágil para falar que no projeto se faz Agile Testing e que a pessoa é um Agile Tester, alguns princípios devem ser seguidos para reforçar os valores da agilidade.

No livro são discutidos um conjunto de 10 mandamentos do Agile Tester, que irei apresentar abaixo.

1. Forneça Feedback Contínuo

Como a ideia é utilizar esses conceitos em projetos ágeis, o conceito de feedback contínuo não é nenhuma novidade. Uma das principais funções do testador é apoiar o Product Owner e o Cliente à escrever os requisitos de cada user story, na forma de exemplos e testes.

2. Entregue valor para o cliente

Desenvolvimento ágil é entregar valor em ciclos curtos para o Cliente. Nesse caso, o testador deve ficar atento às mesmas, se estão exatamente de acordo com o que o Cliente priorizou recentemente. Agile Testers sempre estão focados no projeto como um todo, i.e., as funcionalidades mais importantes de cada release devem estar prontas para serem entregues, mesmo que com isso, outras funcionalidades devam ficam em segundo plano.

3. Buscar a comunicação olho no olho

​Nenhum time funciona bem sem uma boa comunicação. Como hoje em dia existem times distribuídos, em diferentes continentes, trabalhando no mesmo projeto, o Agile Tester deve buscar uma forma única para facilitar a comunicação com todos da equipe.

4. Tenha coragem

​Coragem é um valor importante em projetos ágeis, práticas como testes automatizados e integração contínua permitem ao time praticar esse valor. O time deve ter coragem de realizar mudanças, mas, sem uma suite de testes de regressão automatizados, essa mudança pode ser muito insegura. O Agile Tester deve ter coragem para encontrar os erros de outros e ajudá-los a não cometerem o mesmo erro. Deve ter coragem de pedir ajuda, mesmo quando quem pode ajudá-lo for uma pessoa de difícil acesso.

5. Mantenha a simplicidade

​Agile Testers e seus times não devem apenas produzir o sofware mais simples possível que atenda aos requisitos do cliente, mas também devem encontrar a forma mais simples de medir se o software atende a esses requisitos. Logo, medições são importantes, mas, não devem ser uma barreira para a condução do projeto.

6. Pratique a melhoria contínua

​O Agile Tester sempre deve estar em busca de novas ferramentas, técnicas, habilidades ou práticas que auxiliem em seu trabalho de garantir que os desejos do cliente serão atendidos da forma mais simples possível.

7. Responda a mudanças

​Apesar de esse ser um dos valores mais importantes para times ágeis, é um dos mais difícies conceitos para Agile Testers. Pois com a estabilidade, o testador pode dizer que, após ele testar algo, aquilo está pronto. Entretanto, a adaptação a mudança é necessária, logo, a utilização de ferramentas automatizadas para testes pode auxiliar um Agile Tester a responder a mudanças com maior rapidez e segurança.

8. Seja auto-organizado

​O Agile Tester é parte do time auto-organizado do projeto. Logo, ele deve buscar apoio de todos do time para atingir seus objetivos.

9. Foque nas pessoas

​Projetos de sucesso são aqueles onde boas pessoas conseguem fazer seu melhor trabalho. Como o tester encontra erros, ele deve fazê-lo sempre respeitando a todos da equipe, nunca focando na pessoa que cometeu algum erro, mas sim no erro que foi cometido, para evitar algum mal estar entre os membros da equipe e ajudar a todos a não cometerem os mesmos erros.

10. Aproveite

​Trabalhe em um time onde se sinta confortável, ninguém consegue realizar um bom trabalho em um ambiente ruim.

Finalizando, pode-se perceber que o Agile Tester deve estar alinhado com os princípios e valores ágeis, todos os 10 mandamentos são baseados neles. E você, se considera um Agile Tester??

Deixe seu comentário e vamos continuar esse bate papo…

Referência:

• Agile Testing: A Practical Guide for Testers and Agile Team

The post 10 Mandamentos de um Agile Tester appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

A revisão da Sprint já foi tratada aqui no blog em alguns posts, como em O que é Reunião de Revisão? – FAQ Scrum, Boas Práticas da Reunião de Revisão e Como tornar a revisão da sprint um sucesso?. Também não é para menos. Apesar de às vezes a reunião de Revisão ser vista como uma cerimônia não tão necessária quanto outras, ela é na verdade uns dos pontos de inspeção e adaptação mais importantes do ciclo Scrum, principalmente do ponto de vista do produto.

Uma das razões para a reunião de Revisão ser menos valorizada é porque, em alguns casos, a visão que se tem é de que sua utilidade é apenas fazer uma homologação da versão entregue e, na verdade, isso pode ser feito apenas pelos testadores do produto, sem a presença de stakeholders, PO e time desenvolvedor. No entanto, o erro está em crer que a reunião de Revisão serve para homologar a entrega. E é justamente para desmistificar essa cerimônia do Scrum que veremos porque ela é tão importante assim.

#1: É a hora de olhar e ver se o que foi feito te atende e te agrada!

O principal objetivo da reunião de Revisão é mostrar ao PO e aos demais envolvidos no projeto o que foi realizado durante a Sprint, não realizar uma homologação inicial do produto. Quando um item de backlog é incluído no Sprint Backlog, cria-se uma expectativa de que ao final do ciclo de desenvolvimento aquele problema será resolvido e de acordo com o nível de qualidade desejado. É por isso que durante a Revisão o PO tem o poder de aprovar ou reprovar os itens do Sprint Backlog. Ele precisa avaliar se o valor esperado com a execução de um determinado item foi realmente entregue. Se foi, ele aprova o item. Se não, reprova.

#2: Ok. Atendeu e agradou. Mas é esse o caminho que você quer mesmo seguir?

A reunião de Revisão também é o momento que você consegue reunir PO, equipe e stakeholders para que todos possam ver a situação atual do produto e discutir se ele está no caminho certo. O planejamento da Sprint seguinte será realizado em outro momento, mas é na reunião de Revisão que surgem sugestões de novos itens de Backlog e é bom mesmo que surja. Isso demonstra que todos estão envolvidos com o projeto, buscando o sucesso do produto e conversando sobre o melhor direcionamento para ele.

#3: Nhé… agradou não. Temos que mudar alguma coisa aí.

Já dizia a sabedoria popular que “Nem tudo são flores”. Em alguns momentos itens do Sprint Backlog serão reprovados, mas não porque não foram finalizados ou porque tem bugs, por exemplo. Eles serão reprovados simplesmente porque não foram aceitos pelo PO. E é importante que isso seja realizado presencialmente durante a reunião de Revisão para que a equipe entenda porque aquele item não foi aprovado e o que precisa mudar para as próximas Sprints para que isso não volte a acontecer.

#4: Está bem… também é o momento de uma homologação inicial da versão.

Ok, realmente é possível fazer uma homologação inicial da versão durante a reunião de Revisão, mas é importante saber que esse não é o objetivo da reunião e que, na realidade, o que será realizado é uma validação do requisito implementado. O teste do funcionamento será apenas de maneira superficial.

Se dermos uma olhada no livro Agile Testing, veremos que esta validação se enquadra justamente do quadrante 3 do Agile Testing Quadrants, como podemos ver abaixo.

Esses quadrantes tem por objetivo representar as maneiras de se testar um sistema de forma ágil. No caso dos testes que fazemos na reunião de Revisão, nosso objetivo é crititar o produto do ponto de vista do negócio. Sendo assim, nossos testes durante a reunião criticarão os cenários, a usabilidade, a aceitação do usuário, validando o produto e o negócio e não o funcionamento do requisito.

#5: E também um momento de aprendizagem…

Outra vantagem da reunião de Revisão é que ela também é uma oportunidade de mostrar ao PO e stakeholders como é o funcionamento do que foi desenvolvido e explicar o passo a passo necessário para executar a ação esperada. Esta prática evita ruídos e falsos alarmes de erros, além de acabar avaliando também a usabilidade do que foi realizado. Se não houver dúvida de como proceder, sabe-se que a usabilidade está ok e será de fácil entendimento. Se surgir alguma dúvida, vale considerar se não é uma boa ideia fazer alguma alteração na solução implementada.

#6: Pelo fim das surpresas, desapontamentos e frustrações!

Por fim, a reunião de Revisão evita que lá na frente os mais interessados no projeto acabem tendo surpresas desagradáveis com o rumo que o produto levou. Se o acompanhamento do projeto for realizado toda Sprint, durante 1 ou 2 horas, ao final do projeto o produto estará da maneira desejada, entregando o valor esperado e evitaremos aqueles casos em que após anos de desenvolvimento o produto acaba por ficar encostado, porque não atendeu a necessidade para o qual ele foi criado. É na reunião de Revisão que alinhamos as expectativas com o produto e o direcionamos para alcançar o objetivo estabelecido.

E nos projetos de vocês? Como a equipe vê a Revisão da Sprint? Compartilhe com a gente as suas experiências!

Referências:

• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Using the Agile Testing Quadrants

The post 6 motivos por que a Revisão da Sprint é importante appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Outro problema relacionado a medição é o famoso “medir por medir” que ocorre quando sabe-se que medir é importante, mas as medições são feitas sem planejamento ou sem um objetivo claro. Vale lembrar que por mais que o custo de se realizar uma certa medição seja baixo, caso esta não seja utilizada para nenhum fim, no final das contas ela se torna cara, pois significou um esforço da equipe que não serviu para nada.

Para solucionar estes problema, foi criado o GQM (Goal Question Metric). Ele é um método simples para planejar medições de forma que estas sejam baseadas em objetivos específicos de medição. A utilização do GQM com o SCRUM será mostrada a seguir.

Como uma das funções do Scrum Master é zelar pelo processo, a medição deve ser um aliado importante para seu trabalho. Uma boa prática seria analisar os pontos negativos e positivos levantados nas retrospectivas (principalmente os recorrentes) e identificar pontos falhos no processo. Por exemplo, um ponto negativo recorrente nas restrospectivas pode ser que muitos bugs estão sendo encontrados na versão de homologação, mostrando que a atividade de testes automatizados do processo de trabalho está falha.

A partir desta identificação, é possível aplicar o GQM para planejar o processo de medição, isto ocorre definindo:

• O objetivo da medição (GOAL). Ex: Melhorar a eficiência dos testes automatizados.
• A questão a ser respondida (QUESTION). Ex: Qual a eficiência dos testes automatizados?
• As métricas que respondem a questão respondida (METRIC). Ex: Intervalo entre falhas, Número de bugs encontrados em homologação etc.

Com o planejamento definido, é possível dar início ao programa de medição que será seguido pela equipe. É importante também que o Scrum Master agende reuniões periódicas de análise de dados, onde os dados medidos serão exibidos de forma que seja possível tirar conclusões para ações corretivas  (ex: gráficos, tabelas etc).

O GQM é apenas um dos muitos métodos que podem ser utilizados para se planejar medições. Outros podem ser encontardos em guias como o MPS.BR, CMMI e algumas ISOs. A conclusão importante deste post é: Medições devem ser planejadas.

The post Uso de medições com GQM (Goal Question Metric) no SCRUM appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.