BT

Novidades O InfoQ vem desenvolvendo uma série de novas funcionalidades para melhorar sua experiência com o site. Confira!

De Use Cases para User Stories: dicas e desafios na transição

| por Augusto Colombelli Alessio em 08 dez 2016. Tempo estimado de leitura: 5 minutos |

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.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Parabéns by Hugo Estevam Longo

Belo artigo! Muito legal essa visão prática da transição.
Há um tempo atrás escrevi sobre essa transição para requisitos ágeis:
incubadora.periodicos.ufsc.br/index.php/IJKEM/a...

Re: Parabéns by Augusto Colombelli Alessio

Olá Hugo, obrigado. Muito bom seu artigo, bem completo e com diversas boas referências, parabéns.

Dúvida - regra de negócio x regra de sistema by Cláudio Antônio Silva

Olá Augusto.

Fiquei com algumas dúvidas no trecho abaixo:
'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.


O que você quer dizer com "bloqueamos a solução"?
Por que uma regra de tela tira a flexibilidade para mudanças?

Ficarei grato se puder detalhar um pouco mais estes pontos.

Um abraço e parabéns,
Cláudio.

Parabéns by Mozart Alves Junior

Muito bom o artigo. Estou nesse processo de transição.

Parabens! by Domingos Teruel

Excelente artigo! Me ajudou um bocado.

Re: Dúvida - regra de negócio x regra de sistema by Augusto Colombelli Alessio

Olá Cláudio,

No processo de transição, aproveitamos para discutir alguns outros pontos de nossa especificação. A parte escrita de nossas regras de negócio estava muito detalhada, tornando assim a solução proposta engessada e com baixa flexibilidade para mudança.

Optamos por tornar as regras de negócio mais enxutas (focadas em negócio e não em sistema) e explorar mais as conversas entre o time. Com isso conseguimos reduzir bastante o tempo de escrita e manutenção das regras de negócio.

Por exemplo, ao invés de escrever na especificação a necessidade de incluir um combobox, optamos por decidir isso durante a Sprint Planning ou até mesmo durante a Sprint através de uma conversa.

Abraços,

Augusto

Re: Parabéns by Augusto Colombelli Alessio

Obrigado Mozart. Se precisar de alguma ajuda ou opinião me avise, podemos trocar algumas figurinhas.

Abraços

Re: Parabens! by Augusto Colombelli Alessio

Obrigado Domingos. Abraços.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

8 Dê sua opinião

Sponsored Content

Conteúdo educacional

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT