No quadro da figura 3.3, o limite do desenvolvimento está estourado, e os desen-
volvedores não podem puxar mais histórias, nem os testadores que estão no limite.
Nessa situação a equipe toda precisa focar em entregar as histórias que estão mais
próximas do final do processo antes de poder começar a trabalhar em novas histó-
rias.
Sem limite de trabalho em progresso, mais trabalho seria começado, e poderia
correr o risco de na data de release a equipe não ter terminado ainda uma série de
histórias e defeitos que mesmo estando em andamento não estariam prontos para
serem entregues ao cliente.
Quando uma história ficar pronta no estágio em que se encontra e, esperando
para ser puxada para o próximo estágio, está em uma fila. As filas devem ser tão
pequenas quanto possível. Recomenda-se considerar a criação de pequenas filas para
que absorvam a variação do processo e permitam que fluxo não seja interrompido.
Muitos processos, se não possuírem filas, poderão fazer com que as pessoas fi-
quem desocupadas, gerando tempo ocioso, devido a variações no tempo que cada
item
leva para ficar pronto. Novamente, é importante observar seu processo e, em-
piricamente, optar pela solução que permitir melhor fluidez.
3.6
Escrevendo Histórias de Usuário
Histórias de usuário são descrições simples e curtas de funcionalidades que deverão ser implementadas no software. As Histórias são, geralmente, escritas pelo próprio
Product Owner, com suas próprias palavras e, então, são registradas em cartões que
posteriormente são anexadas ao quadro da equipe.
As histórias contêm apenas uma breve descrição que representa uma necessi-
dade do cliente, porém, apesar da simplicidade da história, o cliente deve possuir
o conhecimento necessário para disponibilizar informações de negócio para que a
equipe possa transformar sua necessidade em software. Por exemplo, imagine uma
história cuja funcionalidade seja desenvolver um relatório de balanço contábil; será necessário que o cliente possua o conhecimento de negócio necessário, isso é, saiba o que é um balanço contábil e quais são suas características, para que assim ele possa explicar à equipe o que precisa ser feito.
45
3.6. Escrevendo Histórias de Usuário
Casa do Código
Toda história de usuário deve possuir um critério de aceitação, também defi-
nido pelo cliente, que permite à equipe identificar quando ela está implementada
por completo e com sucesso. Ao escrever uma história o cliente assume responsabi-
lidade sobre ela.
As histórias de usuário têm caráter de negócio, por isso, instalar o servidor de
integração contínua ou atualizar a versão da biblioteca de injeção de dependências, geralmente, não são exemplos válidos. Podem até ser exemplos de tarefas, mas não
de histórias de usuários. Veremos a diferença entre histórias e tarefas mais adiante.
Alguns exemplos de história de usuários válidas em um projeto de desenvolvi-
mento de um site de relacionamentos podem ser:
Um usuário pode publicar suas fotos em seu perfil;
Usuários podem criar e participar de comunidades;
Comunidades devem possuir moderadores.
Mike Cohn propôs um formato interessante que é amplamente conhecido e uti-
lizado no mercado:
Eu, como um (papel) quero (funcionalidade) para que (valor de negócio).
Se aplicarmos o modelo proposto nas histórias citadas anteriormente, elas fica-
riam da seguinte forma:
Eu como um forista quero publicar minha foto em meu perfil para que os
outros participantes possam me identificar mais facilmente.
Eu como um usuário gostaria de criar uma comunidade para que eu possa
reunir pessoas com interesses semelhantes aos meus.
Eu como um moderador gostaria aprovar ou rejeitar respostas a tópicos do
forum para evitar postagens inadequadas.
Investindo em Boas Histórias
Segundo Mike Cohn, autor do livro: User Stories Applied, boas histórias devem
conter as seis características seguintes:
1. Histórias devem ser independentes para evitar problemas de planejamento e
estimativa. Se duas histórias possuírem dependência entre elas, e uma tiver priori-
dade alta e a outra baixa, provavelmente a história dependente de prioridade baixa
46
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
precisará ser desenvolvida antes das outras tarefas, assim que chegar a hora da his-tória de prioridade alta ser desenvolvida. Nesses casos, pode ser interessante unir ambas em uma única história;
2. Histórias devem ser negociáveis, não devem ser vistas como requisitos que de-
verão ser implementados a qualquer preço. Lembre-se, histórias são apenas curtas
descrições de funcionalidades que deverão ser analisadas e discutidas com o cliente no momento em que sua prioridade for atingida, ou seja, no momento em que a história fizer parte de uma iteração. É importante que a história seja detalhada apenas quando o momento de seu desenvolvimento estiver próximo, isto é, quando chegar
o momento de a história entrar na iteração corrente. Quanto mais cedo ela for ana-
lisada e detalhada, maiores serão as chances de haver retrabalho e até mesmo perda