Recentemente participei do processo de transição do modelo de especificação requisitos na minha empresa, passando a utilizar histórias de usuário ao invés de casos de uso. Por se tratar de um assunto novo na empresa, muitas dúvidas surgiram durante a transição.
Neste pequeno artigo, apresento um pouco da minha percepção sobre essa mudança e alguns desafios que enfrentamos, além de dicas de como proceder. Muitas das ideias aqui são inspiradas no clássico livro 'User Stories Applied', de Mike Cohn.
Escreva menos, converse mais
Trabalhar com histórias de usuário vai além da escrita. Nos casos de uso investimos grande parte do tempo escrevendo cenários, atores e passos. Nas histórias de usuário não precisamos detalhar tudo isso - pelo contrário, escrevemos o mínimo necessário e trabalhamos a comunicação cara a cara.
O que isso significa? Escreva menos e esteja perto de seu time para explicar, discutir e negociar a implementação. Não perca tempo escrevendo textos enormes que não serão aproveitados futuramente; invista esse tempo em entender os objetivos de negócio do cliente e trabalhar mais perto das equipes.
Regras de negócio mais que regras de sistema
As regras de negócio devem vir primeiro. Mas qual a diferença entre regras de negócio e regras de sistema? Considere este exemplo:
Valor unitário = Preço x Quantidade + Frete + Outras despesas + Seguro - Desconto
Esta é uma regra de negócio. Independente de haver um software para automatizar o cálculo, essa regra deve ser respeitada. Além disso, podemos referenciar a regra em outras partes do software; e ela será alterada somente quando o processo da empresa for alterado. Agora considere o exemplo abaixo:
Se o nome da empresa não tiver sido informada, o campo filial deve ficar indisponível para ser informado.
Nesse exemplo, 'bloqueamos' a solução para que seja controlada por uma regra de tela. Esse tipo de regra tira a flexibilidade para mudanças e pode gerar altos custos de manutenção.
Em resumo, prefira documentar somente regras de negócio. Sobre as regras de sistema, converse com a equipe!
Faça com o time
A história de usuário será utilizada pelo time, então busque envolver todos no processo de criação. Um exemplo é que nem sempre o Product Owner é a melhor pessoa para definir se a história é estimável ou independente das demais - porém ele é a melhor pessoa para dizer se a história tem alto ou baixo valor para o cliente.
As diferentes percepções dos membros do time ajudam as histórias a serem bem elaboradas e disseminam antecipadamente o conhecimento para toda a equipe.
Otimize a velocidade da entrega de valor ao cliente
Quanto menor a história, menos tempo ela irá demorar para estar pronta e mais rápida conseguiremos tornar a entrega de valor ao cliente. Parece simples, não?
Considero que esse é um dos maiores desafios para se trabalhar com histórias de usuário. As histórias têm de ser pequenas, desde que entreguem valor e sejam independentes. Isso é possível? Depende.
Em alguns cenários, histórias muito pequenas podem não entregar valor algum ao cliente, porém agilizam o fluxo de trabalho do time. Em outros cenários, histórias muito pequenas podem ser dependentes entre elas e travar o fluxo de trabalho.
Trabalhe com o time para chegar ao tamanho ideal das histórias. Experimente e esteja aberto a receber feedback durante e após a iteração.
Critérios de aceitação devem ser flexíveis
O objetivo dos critérios de aceitação é fornecer as informações necessárias para que o time saiba quando a história está pronta. Durante o desenvolvimento, podemos nos deparar com situações em que novos critérios devem fazer parte da história.
Nesses momentos lembre-se que devemos responder a mudanças mais do que seguir um plano. Inclua, remova e edite sempre que necessário, e procure divulgar as alterações para todos os envolvidos.
Em algumas situações é necessário alinhar as mudanças com o cliente. Não adie isso! Quanto antes uma mudança é resolvida, menor será o seu custo.
Entregue valor e não telas de cadastro
Um dos pontos mais críticos na transição de Use Cases para User Stories é chegar a um acordo sobre o que é valor. É muito comum que as primeira histórias sejam quebradas por camada técnica e não por valor. Por exemplo, priorizar no backlog as histórias para as telas de cadastros.
Pergunte-se: quanto tempo o usuário levará para conseguir obter benefícios com o produto? Ao invés de criar histórias para telas de cadastro, busque saber em que funcionalidade esses cadastros serão utilizados. Inicie o desenvolvimento por essa funcionalidade. Lembre-se que criar a tela de cadastro é uma consequência; o que importa é onde esse cadastro será utilizado.
Inspeção e adaptação: bases para boas histórias
Mudar os artefatos da especificação requer aprendizado do time. Mais de uma iteração é necessária para se chegar a um bom amadurecimento. Utilize as reuniões de retrospectiva e planejamento para identificar os pontos de melhoria das histórias. Lembre-se, todos estão aprendendo então esteja aberto a receber feedbacks.
Indo além
Os livros de Mike Cohn são as referências ideias para conhecer mais sobre User Stories e podem servir de base para esclarecer muitas dúvidas durante o processo de transição - ou de adoção das histórias de usuários desde o início. Outras referências são os livros de Lisa Crispin e Roman Pichler:
- User Stories Applied, Mike Cohn
- Agile Testing, Lisa Crispin e Janet Gregory
- Agile Estimating and Planning, Mike Cohn
- Agile Product Management with Scrum, Roman Pichler
Há também vários sites que podem ser ótimas fontes para conhecer mais sobre User Stories e as melhores técnicas de adoção e transição. O próprio site de Mike Cohn é uma boa fonte para começar; uma boa definição resumida é esta no site oficial de XP. E um artigo mais longo no site Agile Modeling mostra diagramas e outros detalhes.
[Uma versão deste artigo foi publicada previamente no Medium do autor.]
Sobre o autor
Augusto Colombelli Alessio é Scrum Master na Softplan Planejamento de Sistemas, em Florianópolis. Trabalha com desenvolvimento de software desde 2010. Tem as certificações CSM e PSM, além de MBA em Gerenciamento de Projetos na FGV e especialização em desenvolvimento de projetos para ambiente internet na UTFPR.