Práticas e artefatos comumente utilizados com Scrum

Práticas comuns que não estão no Guia do Scrum

Apesar de não estarem descritas no Guia do Scrum, algumas práticas e artefatos são utilizados pela grande maioria dos times Scrum. Normalmente, sua utilização ocorre de maneira a complementar algo que está descrito no guia como uma prática a ser adotada, mas sem uma especificação clara de como fazer.

A seguir alguns exemplos:

Quadro de tarefas

Ao se pensar em Scrum, e em metodologias ágeis no geral, a primeira imagem que vem a mente das pessoas é um quadro com diversos post-its.

O quadro de tarefas (Figura 1) serve para aumentar a transparência do trabalho do time. Basicamente é um quadro branco, com algumas divisões verticais de acordo com a necessidade do time.

Cada divisão representa uma fase do trabalho e cada post-it representa uma tarefa. A medida que o trabalho em uma tarefa avança dentro da Sprint, o post-it correspondente a ela avança no quadro.

Isso dá uma visão clara para qualquer um das tarefas que estão sendo feitas, as que já estão prontas, as que ainda não foram iniciadas, etc.

Gráfico Burndown

Geralmente, em uma parte do quadro de tarefas encontramos o gráfico burndown. Ele é utilizado para que se possa acompanhar o desempenho do time ao longo da sprint.

No eixo X do gráfico encontra-se a quantidade de pontos restantes na sprint. No eixo Y do gráfico temos a quantidade de dias da sprint.

De acordo com o desempenho estimado do time, é traçada uma linha ideal, que representa a quantidade de trabalho restante estimada para cada dia da sprint.

Na reunião diária, de acordo com as tarefas finalizadas no dia anterior, o Time de Desenvolvimento atualiza a linha referente ao trabalho realizado, o que dá uma indicação dos pontos realmente restantes até aquele momento.

Dessa maneira, a cada vinte e quatro horas a posição do trabalho restante da sprint é atualizada, e sabe-se facilmente o quão longe do desempenho ideal o time está caminhando.

Além do gráfico e das tarefas, comumente no quadro também encontra-se a meta da sprint em destaque além de um espaço para que fiquem expostos os itens não planejados e impedimentos encontrados durante a sprint.

Note que cada time Scrum pode encontrar necessidades específicas quanto ao que deve ficar no quadro, desde as fases das tarefas como os demais itens.

Alguns times podem considerar importante, por exemplo, colocar em um espaço do quadro quais os membros do Time de Desenvolvimento durante aquela sprint.

Figura 1: Exemplo de quadro de tarefas

Histórias de Usuário

Embora o Scrum não defina um padrão para escrita de requisitos, comumente eles são coletados em forma de histórias de usuário, que nada mais são do que um parágrafo que descreve uma necessidade de um usuário do sistema, como por exemplo: “Eu como autor necessito saber a quantidade de livros de minha autoria que foram vendidos para que eu possa cobrar minha comissão junto à editora”.

Na frase acima temos três coisas bem definidas:

• Um papel ou ator: o autor.
• Uma necessidade ou caso de uso: saber a quantidade de livros vendidos.
• Um motivo: cobrar a comissão junto à editora.

As histórias de usuário são escritas e mantidas pelo Product Owner e é muito comum que sejam mantidas em cartões de papel.

Dessa maneira, o Product Owner mantém na frente a descrição da história e no verso alguns testes de aceitação, que nada mais são do que os critérios que indicam que essa história foi implementada corretamente ou não.

Para a história de usuário acima, alguns testes de aceitação possíveis seriam:

• Existência de um totalizador de unidades vendidas por título;
• Existência de um totalizador de unidades vendidas no geral;
• Possibilidade de realizar uma pesquisa de vendas por período;

As histórias de usuário coletadas compõem o Product Backlog e são refinadas à medida em que se movimentam em direção ao seu topo.

Uma boa história de usuário está escrita no padrão INVEST, um acrônimo para: Independente, Negociável, Valiosa para o cliente ou usuário, Estimável, Pequena (Small em inglês) e Testável.

• Independente: significa que essa história não possui dependência com nenhuma outra, podendo ser implementada individualmente;
• Negociável: a história deve ser escrita de maneira a permitir um nível de negociação, onde os envolvidos chegam a um consenso de quão “profunda” será sua implementação;
• Valiosa para o cliente ou usuário: uma história deve representar um item que agregue algum valor ao produto, e esse valor deve ser perceptível para o cliente ou usuário. É importante lembrar que o foco é desenvolver sempre o que possui mais valor para o cliente, pois afinal ele é quem é o principal interessado no produto (e quem vai pagar a conta);
• Estimável: uma história deve ser escrita com um nível de detalhe tal que permita ao Time de Desenvolvimento realizar uma estimativa quanto ao tempo necessário para sua implementação. Na história de exemplo, de nada adiantaria que a história fosse escrita da seguinte maneira “Eu como autor necessito de um relatório para saber o valor de minha comissão.”. Perceba como existem detalhes ausentes, até mesmo em relação à base sobre a qual a comissão será calculada.
• Pequena (Small em inglês): uma história deve ser pequena ao ponto de poder ser realizada em uma sprint. Histórias grandes geralmente carregam um alto grau de incerteza. Geralmente o Time de Desenvolvimento ajuda o Product Owner a decompor uma história muito grande em histórias menores;
• Testável: deve ser claro para todos os envolvidos como aquela história deve ser testada, de forma a garantir o seu funcionamento. Os testes de aceitação, escritos no verso do cartão, por exemplo, costumam garantir essa propriedade das histórias.

Estimativas

O Scrum não define uma maneira como os requisitos devem ser escritos e, consequentemente, uma maneira como os requisitos devem ser estimados.

A maioria dos times Scrum usa histórias de usuário, e as estimam utilizando a técnica de Pontos de História.

Um ponto de história nada mais é do que uma unidade de tamanho, que faz sentido para o time Scrum e indica se a história é grande ou pequena.

Por exemplo: uma história muito simples de ser implementada, para o time, poderá ter o tamanho 1. Consequentemente, uma história com o dobro de complexidade da primeira terá o tamanho 2.

Dessa forma, o Time de Desenvolvimento realiza as estimativas baseando-se no tamanho relativo das histórias, e não no tempo para sua implementação.

Essa abordagem simplifica o processo de estimativa, pois fazer uma comparação se torna muito mais simples do que “cravar” uma quantidade de horas para implementar uma funcionalidade.

Um exemplo: ao comparar um frasco com capacidade 300 ml com um frasco com capacidade 1000 ml, sem saber dessas medidas, pouquíssimas pessoas serão capazes de acertar exatamente a quantidade de líquido que cabe em cada frasco. No entanto, é praticamente certo que todas as pessoas saberão identificar que um frasco é maior do que o outro. E a grande maioria, através da comparação, saberá que o frasco de 1000 ml é pouco mais de três vezes maior do que o frasco de 300 ml.

Planning Poker

Para estimar os requisitos com pontos de história, muitos times adotam o Planning Poker (Figura 2).

Figura 2: Exemplo de baralho de Planning Poker

Como funciona:

Cada integrante do Time de Desenvolvimento possui um baralho, com cartas numeradas representando os pontos.

Após o Product Owner explicar o requisito, cada um vira a carta com a quantidade de pontos que considera representar o tamanho do requisito. É importante que todos mostrem os pontos ao mesmo tempo, pois dessa forma cada um indica o tamanho que acredita ser o correto para o requisito, sem ser influenciado pela estimativa dos demais componentes do Time de Desenvolvimento.

Após a rodada, normalmente, o integrante que colocou o menor valor e o que colocou o maior valor explicam seus motivos e o requisito é discutido por todos os integrantes do Time de Desenvolvimento. Feito isso, há uma nova rodada. O processo se repete até que todos entrem em um consenso quanto à estimativa para o requisito.

Normalmente os times Scrum adotam intervalos não sequencias em suas cartas de baralho de Planning Poker. Os baralhos mais comuns começam com a sequência Fibonacci, tendo a seguinte sequência de pontos: 0,1,2,3,5,8,13,20,40,100.

Histórias com pontuação 0 são consideradas já implementadas.

Essa escala de pontos visa forçar que as histórias sejam divididas em histórias menores. Perceba, por exemplo, que entre 20 e 40 temos uma variação muito grande e ainda maior entre 40 e 100 pontos.

Existem times que limitam a quantidade máxima de pontos que uma história pode ter, obrigando histórias com pontuação maiores a serem divididas.

É isso pessoal. Este artigo visou se aprofundar um pouco mais nas práticas e artefatos mais comuns do Scrum. Um abraço a todos e até a próxima.