Como todos sabem, o Product Backlog é o artefato do Scrum que representa o que deve ser desenvolvido no projeto, ou seja, ele possui todo o trabalho a ser realizado. Por outro lado, como também sabemos, em um projeto Scrum, a mudança no rumo é esperada, logo, o conjunto inicial de funcionalidades para atender ao produto pode ir variando de prioridade conforme o tempo passa, e, com isso, manter o Product Backlog priorizado e atualizado é de suma importância para o sucesso do projeto. Nesse post irei listar 10 dicas para auxiliar à priorização do Product Backlog. 

1. Mantenha o Product Backlog atualizado

Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Product Backlog. Quanto menor for o conjunto de histórias que devem ser priorizadas, mais simples será a tarefa. Por mais que seja dificil "desapegar" de uma história pensada e, até certo ponto, especificada, é importante que isso seja feito, pois ela estando no Product Backlog, mesmo que com uma prioridade baixa, pode influenciar na priorização das demais histórias e alterar o rumo do produto.

2. Dê importância a DoR (Definition of Ready – Definição de Preparado)

A definição de história preparada é outro fator que pode auxiliar bastante na priorização do Product Backlog. Sem ela, a equipe de desenvolvimento pode não saber estimar corretamente uma história, passando uma falsa noção de tamanho da história para o PO, que irá tomar decisões sobre priorização com base em uma informação pouco confiável.

3. Qual o conhecimento, incerteza e risco sobre uma história?

Como esses fatores influenciam diretamente o sucesso do produto, histórias com baixo grau de conhecimento e alto grau de incerteza e risco devem ter uma prioridade alta, pois quanto antes forem desenvolvidas, antes pode-se perceber o melhor caminho a se seguir, caso contrário pode não haver o tempo necessário para desenvolver a história e colher os frutos do apredizado do desenvolvimento da mesma.

4. Qual a influência da história na próxima release?

Histórias que permitam um lançamento mais rápido do produto tambem devem estar no topo do Product Backlog. Por exemplo, em um software de geração de nota fiscal, a geração da nota em si é muito mais importante que o cadastro dos produtos, logo, ela deve possuir uma maior prioridade.

5. Atenção ao tamanho das histórias

Lembre-se, a história deve ser pequena suficiente (s de small do INVEST) para ser independente e agregar valor para o software e para o cliente, dessa forma, busque uma uniformidade no tamanho das histórias, de modo que o Product Backlog, principalmente em seu topo, possua apenas histórias na menor unidade possível, e, a medida que avançamos no Product Backlog, podemos encontrar histórias maiores. Assim, evitamos que a equipe estime histórias muito grandes, que possuem maior risco de apresentar surpresas em seu desenvolvimento e que possuem estimativas mais suscetíveis a erros.

6. Atenção à dependência entre as histórias

Apesar da definição de que as histórias devem ser independentes (i de independent do INVEST), muitas vezes não conseguimos evitar a dependência entre as histórias. Nesse caso a melhor opção é deixar visivel essa dependência, com uma anotação, uma cor diferente, qualquer coisa que chame a atenção para isso. Se a história A depende da história B, não agrega valor para o negócio fazer a A antes da B e isso deve estar visível para todos os envolvidos no Projeto.

7. Ouça todos os interessados no Projeto

A decisão sobre a prioridade do Product Backlog é única e exclusiva do Product Owner, entretanto, ele deve ouvir todos os interessados (stakeholders) no Projeto para auxiliar o seu processo de tomada de decisão. Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao PO, mas sim à todos os envolvidos no Projeto, principalmente interessados e clientes.

8. Utilize Técnicas de Priorização

Novamente, apesar da decisão sobre a prioridade do Product Backlog ser única e exclusiva do Product Owner, a utilização de técnicas, como a técnica de KANO pode ser bastante útil quando existe dúvida na prioridade de um pequeno conjunto de histórias. Uitlize as técnicas de priorização como sua aliada para ajudar a resolver esses pequenos conflitos.

9. Considere a priorização por temas

Como falei na dica #6, a dependência entre histórias muitas vezes é inevitável. Dessa forma, agrupar as histórias dependentes em um tema e priorizar o tema também pode ajudá-lo, assim a priorização pode ser dividida em 2 passos, primeiro se prioriza os temas e, em sequência, as históias dentro de cada tema, evitando assim que histórias de um mesmo tema fiquem espalhadas por todo o Product Backlog.

10. Se mantenha atualizado!!!

Como sempre, nunca pare de estudar e se atualizar. A cada dia novas técnicas aparecem, e, estarmos de cabeça aberta para absorver novos conhecimentos é sempre importante para nos ajudar a melhorar nosso trabalho.

Gostaram das dicas? Deixe seu comentário e vamos continuar discutindo sobre priorização, até a próxima!!!

The post 10 dicas para melhorar a priorização do Product Backlog 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.

“Gastamos muito tempo estimando e, principalmente, discutindo sobre o entendimento das histórias e a pontuação das mesmas”

Perantes esse sentimento, nossa primeira atitude foi descobrir o tempo médio gasto na discussão de uma história. Após algumas sprints, conseguimos chegar a um valor de 15 minutos, ainda, percebemos que as maiores discussões são em histórias pequenas, de no máximo 5 pontos. Assim que constatamos isso, nos perguntamos: 

“Como que isso aconteceu?”

Afinal, a sequência de Fibonacci alterada existe exatamente para evitar grandes discussões. Apesar disso, acabamos percebendo que ela é muito útil no início do Projeto, ou seja, ela é muito boa para ajudar na saída da estimativa em horas, visto que o espectro de valores é muito menor. Por outro lado, ainda existem 11 valores para serem escolhidos e, desses 11 valores, 7 estão muito próximos na escala (0 ao 8). 

Após essa constatação, resolvemos medir se a discussão se uma história vale 2 ou 3 pontos influencia no andamento do projeto. Para isso, durante algumas sprints, ao final de cada uma, todas as histórias que entraram na sprint eram reestimadas, de forma a termos, após o desenvolvimento da história, a pontuação que julgamos a correta.

Com isso, percebemos que, primeiro, esse “erro” de estimativa indesejado pela equipe não ocorria, visto que a velocidade média se mantinha e, chegamos a outra conclusão, que normalmente histórias que julgamos como 0 ou 8 dificilmente considerávamos errada, entretanto, ocorriam muitos “erros” entre 0.5 e 5. Com base nessas conclusões, resolvemos alterar nosso conjunto de pontos possíveis, agora, iríamos utilizar apenas o 0, 2, 5, 13 e 100. 

Estamos trabalhando com a nova escala a 2 sprints, por conta disso, ainda não temos muitos resultados decorrentes dessa mudança. Entretanto, já podemos perceber que o tempo gasto na discussão e pontuação das histórias caiu pela metade, sem perda de qualidade, ou seja, agora, discutimos apenas dúvidas da história, mas nada tão profundo que justifique uma mudança de complexidade de 2 para 3 pontos.

Por fim, vale lembrar que a mudança na escala gera problemas, como a perda do referencial da velocidade média. Devido a isso, certifique-se que essa mudança é necessária, i.e., realize medições que justifiquem essa mudança. Caso a resposta seja sim, mude, lembre que o Scrum é um framework que deve ser adpatado para o ambiente de cada Projeto.

E vocês, qual escala utilizam para estimar? Deixe seu comentário e vamos continuar com esse bate papo. Até a próxima!

The post Otimizando o tempo gasto ao estimar histórias appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Inicialmente, vale lembrar que esse tema não é novo em nosso blog. Em Maio de 2012 escrevi um post que fala sobre o assunto, entretanto, na época, não abordei métricas de código, apenas métricas relacionadas ao projeto.

Ainda, segundo Pressman, se não realizamos medições sobre alguma coisa, não sabemos nada sobre isso. Logo, se buscamos a melhoria contínua, precisamos medir não apenas nosso processo, mas também encontrar métricas que indiquem a qualidade de nosso código, que é um dos principais artefatos gerados durante o desenvolvimento.

Assim como temos o Business Intelligence, que analisa métricas do négócio, devemos criar o Software Intelligence, com o objetivo de encontrar, através dos números, potenciais problemas em nosso código. Dessa forma, podemos prever a ocorrência de um problema ou até mesmo evitar a ocorrência do mesmo. Por exemplo, podemos descobrir que X% das classes que importam o pacote xyz devem ser corrigidas posteriormente, dessa forma, sabemos que, ao utilizar determinados pacotes, devemos ter atenção, pois normalmente erros são gerados.

Em sua palestra, Mauricio Aniche indicou algumas métricas para avaliar o andamento do desenvolvimento do software:

• Linhas de código por método
• Quantidade de métodos por classe
• Cobertura de código
• Artefatos modificados
• Bugs por dia de semana
• etc…

​Ainda, vale lembrar que, apesar de existirem boas práticas para algumas métricas citadas (linhas de código por método, por exemplo) a medição é importante para sabermos quando, em nossa organização, esse número passa a ser crítico e a ser um grande indício de bugs. Além disso, podemos cruzar essas informações, de forma a termos novas interpretações sobre nosso código.

Como realizar essas medições não é uma tarefa simples, existem diversas ferramentas para apoio nesse momento, como o Eclipse Metrics, JaCoCO – Java Code Coverage dentre outros.

Finalizando, fica cada vez mais claro para mim a importância de medirmos nosso trabalho, sem um número não temos como saber se estamos melhorando ou piorando o mesmo. E vocês, praticam medições no código? Quais métricas utilizam? Vamos continuar esse bate papo…

The post Métricas de Código, sem medição não sabemos nada… appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Como sabemos, no Scrum, a visão do projeto é fixa, o prazo também, sendo, nesse caso, o escopo para atingir a visão variável. Logo, uma das partes mais importantes dessa fase é a elaboração da visão do projeto. Essa visão pode ser elaborada e refinada através da utilização de técnicas como Elevator Statement e Product Vision Box. Com a visão pronta, podemos traçar um roadmap para o produto para, então, começar a criar nossas histórias. Seguindo essa linha, teremos no final da fase de prégame alguns artefatos gerados e o Product Backlog inicial do projeto criado. Ainda, esses artefatos podem ser todos sumarizados em outro artefato chamado Project Data Sheet. 

Por outro lado, apesar dos artefatos gerados pelo Elevator Statement, Product Vision Box  e Product Roadmap serem bastante ilustrativos, o Project Data Sheet é um documento basicamente textual que, apesar de ser pequeno e dever caber em uma folha, não apresenta as informações em um formato ilustrativo, é apenas o resumo completo da fase de prégame do Projeto. É exatamente para preencher essa lacuna que podemos utilizar o Project Model Canvas.

Como citado anteriormente pelo Igor e pela Paula, a utilização de Canvas para realizar um planejamento é bastante útil e torna a visualização do problema mais simples e intuitiva. Analisando o Project Model Canvas podemos perceber que todos os pontos presentes em um estão lá:

• Representando a visão temos a Justificativa, Objetivos, Benefícios e o Produto;
• Representando o Product Roadmap temos a Linha do Tempo e o Grupo de Entregas; e
• Representando o Product Backlog temos a lista inicial de Requisitos.

Ainda, com esse formato, podemos ver de forma clara e rápida qual a equipe, interessados, riscos, restrições e custos do projeto. E, como sabemos, todas essas características são bastante importantes para um projeto de software.

Por fim, vale lembrar dos benefícios adquiridos ao se utilizar um Canvas para planejar e comunicar o planejamento para todos os interessados. Com a utilização do mesmo o planejamento fica simples de ser entendido e bastante ilustrativo. Além disso, o mesmo pode ser impresso em uma grande superfície, facilitando assim o entendimento do planejamento por todos e a discussão em torno do mesmo. Como a fase de prégame é muito importante, um artefato que facilite a compreensão do projeto por todos e fomente a discussão e análise é de grande valia.

Achei bem interessante a utilização desse novo artefato na fase de prégame de um Projeto, pretendo adotá-lo nos Projetos da GPE.

E você, o que achou? Pretende adotá-lo também? Já o utiliza? Nos envie seu comentário e vamos continuar esse bate papo.

The post Utilizando o Project Model Canvas no Pré-Game appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.