Casa do Código
esses itens no backlog, sem detalhar exatamente o que deverá ser feito, e então, somente quando a prioridade do épico for aumentando e a hora de trazê-lo para o
planejamento estiver se aproximando, será o momento certo para dividi-lo em his-
tórias de usuário.
Para melhor ilustrar imagine um sistema de gestão empresarial. O sistema pode
ter temas como Comercial, Financeiro e Contábil, por exemplo.
O tema Financeiro pode ser derivado em Épicos como Cobranças e Pagamentos,
já o Épico Pagamentos pode ser derivado em funcionalidades como Pagamento por
Boletos e Pagamentos por Depósitos.
A Funcionalidade Pagamento por Boleto, poderia ser derivada em diversas his-
tórias, como, por exemplo, Pagamento de Boletos Vencidos, Pagamento de Boletos
com Juros etc.
Dividindo Histórias
É comum que algumas histórias de usuários sejam grandes demais para serem
implementas em uma única iteração. Nesses casos, é interessante dividi-las em vá-
rias histórias menores. É importante, porém, manter o aspecto INVEST. Você pode
dividir histórias por variações nas regras de negócio, por variações nos dados, por diferentes cenários de uso etc.
Quebrando Histórias em Tarefas
De um modo geral, histórias requerem certo esforço para serem implementadas.
Por isso elas são dividas em tarefas, que representam os passos necessários para que a funcionalidade da história seja desenvolvida e entregue em funcionamento ao cliente. É recomendado que as histórias sejam quebradas em tarefas que não precisem
de mais de um dia de trabalho para serem desenvolvidas. Posteriormente veremos
como isso acontece e como as atividades técnicas são gerenciadas.
Apenas depois de ouvir o PO e compreender a história, a equipe a quebra em
partes menores, chamadas simplesmente de tarefas. Neste momento a presença do
PO é menos importante, porque as tarefas têm um âmbito mais técnico, e geralmente
terão descrições como: criar as tabelas no banco de dados, criar objetos de negócio, realizar integração através de web services etc.
Não é preciso entrar em detalhes minuciosos sobre cada tarefa e neste mo-
mento pode-se tomar algumas decisões de design que a equipe considerar
importante, como linguagens, frameworks, bibliotecas e padrões a serem
50
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
utilizados, além de questões que envolvam performance e escalabilidade. Decisões
que a equipe considerar menos importantes podem ser tomadas mais tarde, apenas
no momento da implementação.
3.7
Mapeando histórias de usuários
Mapeamento de histórias é uma técnica que consiste basicamente em decompor ati-
vidades de usuário de alto nível em um workflow que pode ser decomposto posteriormente em um conjunto de histórias de usuário. A técnica, que foi popularizada
por Jeff Patton, é centrada na perspectiva do usuário [53].
Primeiramente, temos os épicos representando requisitos de alto nível, depois
temos as funcionalidades, e finalmente as histórias 3.5:
Figura 3.5: Mapa de histórias
Dependendo da abordagem os nomes dos níveis de requisitos podem mudar. Na
abordagem original de mapeamentos de histórias, Patton usa Atividades, Tarefas e
Subtarefas em vez de épicos e funcionalidades e histórias. Outras fontes entendem
51
3.7. Mapeando histórias de usuários
Casa do Código
que épicos são maiores que temas, por exemplo, mas isso não importa muito: uma
vez compreendida a essência da prática, você pode escolher a semântica que for mais adequada
ao seu contexto.
Note que tudo está priorizado em dois eixos, tanto da esquerda para a direita, que
representa a prioridade entre diferentes épicos, e diferentes funcionalidades, quanto de baixo para cima que representa a prioridade entre diferentes histórias de usuário.
Depois de pronto e priorizado, você pode utilizar o mapa para definir releases
em camadas, ou seja releases que contêm um pouco de cada funcionalidade (veja na
figura 3.6.
Figura 3.6: Releases no Mapa de Histórias
Para ilustrar, imagine, por exemplo, um site de comércio eletrônico que será
composto por funcionalidades de carrinho de compra, vitrine eletrônica e Consulta
de Pedidos. Em vez de entregar uma funcionalidade completa com todas as histórias
envolvidas, é possível entregar algumas histórias de cada funcionalidade por release.
Dessa forma, o produto poderia ser lançado com o básico de cada funcionalidade
e já poderia ser utilizado. À medida que os outros releases forem entrando no ar, as funcionalidades seriam aprimoradas com a entrega de outras histórias.
52
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
Recomendações
Desenvolva o mapa de histórias colaborativamente, convide o PO,
analistas de negócio, desenvolvedores etc.
Mantenha o mapa sempre visível para que o time possa discutir
frente a ele, e tomar decisões mais facilmente uma vez que o mapa
dá uma visão melhor do todo e sobre como as diferentes funci-
onalidades e histórias de usuário estão conectadas a objetivos de
negócio [43].