3 formas de fatiar histórias de usuário

3 formas de fatiar histórias de usuário

Hoje em dia, quando eu vejo uma história de usuário há muito tempo em desenvolvimento, eu já fico inquieto e minha mão já começa a coçar. Eu sinto que tenho que fazer alguma coisa pra ela ir logo pro PRONTO.

E eu fico assim, porque em geral, histórias grandes carregam muita incerteza dentro delas. É muito requisito de uma vez só e o desenvolvedor acaba se perdendo e fazendo mais do que devia fazer. Pura perda de tempo e dinheiro…

Neste post, eu falei da diferença entre FATIAR e QUEBRAR uma história de usuário.

E se é importante ter histórias menores, hoje vou te contar 3 formas de fatiar as histórias de usuário. Não é para você ficar preocupado em padronizar as histórias, não é preciso que fiquem todas do mesmo tamanho. A gente só quer evitar histórias grandes demais e também as pequenas demais. Como o pessoal do Kanban diz:

Evite os ratos e elefantes. Tudo entre coelhos e cavalos está valendo.  

Vamos lá!?

FATIAR POR FUNCIONALIDADE

Imagina uma história de usuário com várias funcionalidades dentro dela. Pode ser uma como “Enviar um pedido de compra”.

Mas investigando um pouco mais, descobrimos que o cliente queria dizer na verdade é que o usuário dele vai poder criar um pedido, incluir itens no pedido, alterar as quantidades dos itens, excluir um item e fechar o pedido.

Esse é um bom momento para quebrar essa história de usuário em uma para cada FUNCIONALIDADE que a gente listou.

Mesmo que seja o mesmo desenvolvedor que irá desenvolver tudo, ele ainda ganha. Ela vai pensar em cada história por vez. Vai entender parte por parte. E os envolvidos no projeto vão conseguir visualizar que o projeto está andando.

Isso pode parecer pouco, mas esse progresso contínuo gera confiança no time de desenvolvimento. O cliente começa a ver que o time consegue entregar em um ritmo com pouca variação. E ganhar a confiança de todos os envolvidos no projeto vai facilitar demais a sequência do desenvolvimento.
Essa foi a primeira, Fatiar por Funcionalidades.

FATIAR POR DADOS

Vamos para a segunda forma… Imagina agora que ao invés de muitas funcionalidades, a sua história de usuário tem muito dados. Pode ser: “Incluir um empregado” em um sistema de RH.

Dentro dessa história tem dados pessoais, endereços, documentos, dependentes, etc.

Você já deve ter percebido aonde eu quero chegar… E é isso mesmo… Cada parte desses dados pode virar uma história de usuário separada e menor: Incluir dados pessoas do empregado, Incluir endereço do empregado, Incluir documentos e assim por diante.

O efeito disso, de novo, são histórias de usuário menores e mais fáceis de desenvolver. Eu chamo isso de Fatiar pelos Dados.

E eu acho que deixei o melhor por último…

SPIKES

Imagina uma história complexa. Você não sabe se é possível desenvolver essa história. Ela tem um grande valor para o seu cliente. Mas se você e seu time começarem a desenvolver, vocês não tem nem ideia de quando isso pode terminar, se é que é possível terminar.

Antes de começar a implementar essa história, muitos times criam uma história menor. É uma história para fazer uma pesquisa, uma investigação. A ideia dessa história não é implementar uma funcionalidade nova. O objetivo dela é eliminar ou reduzir o risco do time se comprometer com uma história que você não sabe quando vai terminar.

Esse tipo de história é conhecida como Spike. Você pode até implementar alguma coisa num spike. Mas objetivo aqui não é ter um código que será usado no seu produto final. O objetivo é testar a viabilidade de alguma coisa. É validar alguma coisa da qual o time não está muito certo.

Quando mais simples esse teste, melhor. Mais rápido você válida (ou inválida) uma hipótese.

Existem outras formas de você fatiar uma história de usuário. O que vimos hoje foi: Fatiar por Funcionalidade, Fatiar por Dados e Criar um Spike.

VEJA TAMBÉM

%d blogueiros gostam disto: