Embora muitas pessoas pensem que histórias do Usuário se resumem em simples anotações em cartões, existem alguns conceitos a serem considerados para uma aplicação eficaz desta metodologia. Dentre elas, podem-se destacar os três “C”s e INVEST.

Três C’s

Em Histórias do Usuário os três “C”s são:

  • Cards (cartão): O Product Owner (representante do cliente na equipe de desenvolvimento) descreve em linguagem de negócio algumas frases que direcionarão o desenvolvimento de uma funcionalidade no sistema. No cartão pode conter notas, estimativas, observações e até comentários úteis para facilitar a estimativa;
  • Conversation (conversas): Mesmo as informações mais relevantes estejam descritas no cartão, as conversas entre o cliente e o Product Owner são essenciais, posto que, são nelas que surgem os detalhes que muitas vezes ficam implícitos nas Histórias;
  • Confirmation (confirmação): Para ter certeza que o software desenvolvido está de acordo com as necessidades do cliente, é preciso executar os testes de aceitação descritos no cartão. Por isso, os testes merecem tanta atenção quanto o desenvolvimento.

INVEST

Em 2003, Bill Wake, autor do livro Extreme Programming ExploredRefactoring Workbook, criou um conjunto de seis atributos que definem a eficácia de uma história. Ele chamou esse conjunto de INVEST:

  • Independent (independente): as Histórias do Usuário precisam ser o mais independente possível. Isto porque, a dependência entre as Histórias dificultam as estimativas e ainda atrasam a entrega do software. Por exemplo, suponha que em um sistema de vendas tenha várias formas de pagamento: dinheiro, cheque, cartão, etc. Se colocarmos todas elas numa só história, o cliente não poderá iniciar as vendas até que todo o módulo esteja pronto. O correto, neste caso, seria criar uma história para cada forma de pagamento. Assim, o cliente poderia priorizar as mais importantes e iniciar as vendas com as formas que estiverem disponíveis;
  • Negotiable (negociável): uma história do Usuário não é um contrato. Muito menos uma especificação cheia de detalhes. É apenas uma introdução às funcionalidades para que a equipe possa compreender as necessidades do seu cliente. Por isso, ela deve ser reflexível e negociável, tendo em vista que mudanças sempre irão acontecer durante o desenvolvimento. Além do mais, nem todas as funcionalidades serão desenvolvidas ao mesmo tempo. O cliente precisa ter liberdade para escolher aquilo que mais agrega valor ao seu negócio;
  • Valuable (valiosa): uma História do Usuário é valiosa quando é escrita em linguagem de negócio, ou seja, quando tem algum valor para o cliente. Imagine uma história onde a descrição seja: “O sistema deve suportar até 100 conexões simultâneas”. Veja como seria difícil para um cliente definir a prioridade desta história. Preocupadas com isto, algumas empresas preferem apenas apoiar o cliente, deixando-o escrever as Histórias. Mesmo sendo um investimento que terá retorno certo, é algo difícil de fazer, devido o pouco conhecimento do cliente sobre o assunto;
  • Estimatable (estimável): uma história é estimável quando ela provê as informações necessárias para que a equipe de desenvolvimento a compreenda. Isso não significa que ela deva ser recheada de detalhes, mas sim, clara e objetiva;
  • Small (pequena): considere uma história com a seguinte descrição: “Como usuário, eu quero fazer pedidos via web para minha maior comodidade”. A primeira vista, parece algo simples e claro, entretanto, analisando com um pouco mais de cautela, pode-se perceber que esta é uma história gigantesca. O conceito de “pequena”, não se refere à descrição da história, mas sim a sua complexidade;
  • Testable (testável): todo cartão de história do Usuário precisa conter no verso os testes de aceitação. Além disso, esses testes devem ser escritos pela mesma pessoa que escreveu a história. Dessa forma, se evita problemas de comunicação e entendimento do que deve ser feito.

E ai, gostou?
Deixe seu comentário, dúvida, ou crítica mais abaixo.
Até a próxima!

Autor

Ismael Soares é Gerente de Engenharia de Software na Bluesoft em São Paulo. É formado em banco de dados pela Faculdade Impacta de Tecnologia e possui mais de 14 anos com experiências em análise e desenvolvimento de sistemas. Já trabalhou com diversas tecnologias, entre elas: VB6, ASP, PHP, C#.NET, VB.NET, ASP.NET, PL/SQL, T-SQL, Groovy, Ruby e Java. Já participou de diversos projetos com banco de dados entre eles: Oracle, MSSQL Server, MySQL e Postgree.

2 Comentários

  1. Muito bom. Só para complementar, a qualidade small, segundo alguns autores, também reflete a capacidade de uma User Story caber em uma iteração.

Deixe aqui o seu comentário