Olá Pessoal, essa semana irei falar sobre priorização do Product Backlog, irei passar algumas dicas que podem ser bastante úteis na priorização do mesmo.

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 (Português) 10 dicas para melhorar a priorização do Product Backlog appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 (Português) 10 Mandamentos de um Agile Tester appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) Otimizando o tempo gasto ao estimar histórias appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Esse tema não é novo em nosso blog, visto que eu já o abordei em um post meu de Maio de 2012. Como eu disse anteriormente, o ato de medir é fundamental para sabermos algo sobre alguma coisa, segundo Pressman, se não realizamos medições sobre alguma coisa, não sabemos nada sobre isso. A ideia da palestra do Mauricio é apresentar algumas métricas de código e sua utilidade em identificar possíveis pontos de falha. Logo, como em agilidade, principalmente em Scrum, buscamos a inspeção e adaptação, como poderemos melhorar nosso desenvolvimento sem métricas que indiquem que o mesmo está falho em algum lugar.

The post (Português) Métricas de Código, sem medição não sabemos nada… appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Olá pessoal, baseado no último post da Paula, falarei hoje sobre como podemos utilizar o Project Model Canvas na fase de prégame do projeto, como uma forma de sumarizar todas as informações essenciais ao início do projeto. Em um post anterior meu, comentei sobre a importância da fase de prégame para a definição de aspectos técnicos do software. Hoje, focarei mais no outro lado, no lado do negócio.

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 How to Use Project Model Canvas on the Project Pre-Game appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.