O documento discute conceitos para aplicação eficaz de Estórias de Usuário, incluindo os atributos INVEST (Independente, Negociável, Valiosa, Estimável, Pequena, Testável) e os Três C's (Conversas, Cartões, Confirmação).
5. Estórias do Usuário – Conceito: INVEST
Em 2003, Bill Wake, autor do livro Extreme
Programming Explored and Refactoring Workbook,
criou um conjunto de seis atributos que definem a
eficácia de uma estória.
19. Referências
www.slideshare.net/Ridlo/escrevendo-estrias-do-
usurio-eficazes
Cohn, Mike (2004). User Stories Applied: For Agile
Software Development. New York: Addison Wesley
Professional. ISBN: 0-321-20568-5.
Ambler, Scott W. Agile Modeling: Effective Practices
for eXtreme Programming and the Unified Process.
ISBN: 978-0-471-27190-1.
21. Próxima apresentação: Como Gerenciar as
Estórias do Usuário
Criando Sub-Estórias;
Criando um Tema;
Épicos;
Criando Tarefas;
Notas del editor
CHINA:
Fazer uma breve introdução: Falar a respeito da ultima apresentação...
CHINA:
Vamos falar sobre alguns conceitos para uma aplicação Eficaz...
ISMAEL:
Embora muitas pessoas pensem que Estó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.
ISMAEL:
ISMAEL:
CHINA:
De acordo com BILL Wake, estes são os seis atributos que definem uma boa Estória do Usuário.
SEGUNDO Ele, PARA QUE UMA ESTÓRIA SEJA EFICAZ ELA PRECISA SER INDEPENDENTE...
VAMOS FALAR AGORA UM POUCO SOUBRE CADA UM DESSES ATRIBUTOS.
CHINA:
As Estórias precisam ser o mais independente possível.
PORQUE A dependência entre as estórias dificultam as estimativas e ainda atrasam a entrega do software.
Suponha que um sistema de vendas tenha várias formas de pagamento: Dinheiro, Cheque, Cartão, etc.
Se colocarmos todas elas numa só estória, o cliente não poderá iniciar as vendas até que todo o módulo esteja pronto. O correto, neste caso, seria criar uma estó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.
ISMAEL:
Uma Estó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.
CHINA:
Uma Estória DEVE ser valiosa para o cliente. E só possui valor quando é escrita em linguagem de negócio.
Imagine uma Estória onde a descrição seja: “O sistema deve suportar até 100 conexões simultâneas”.
Seria difícil para um cliente definir a prioridade desta estória. Preocupadas com isto, algumas empresas preferem apenas apoiar o cliente, deixando-o escrever as estórias.
ISMAEL:
Uma estó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.
CHINA:
Considere uma estó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 estória gigantesca, complexa.
O conceito de “pequena”, não se refere à descrição da estória, mas sim a sua complexidade;
ISMAEL:
Todo cartão de Estó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 estória.
Dessa forma, se evita problemas de comunicação e entendimento do que deve ser feito.
CHINA:
CHINA:
A Estória é Descrita em linguagem de negócio, são 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;
ISMAEL:
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 estórias;
CHINA:
Teste de aceitaçã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.
ISMAEL:
CHINA:
Na nossa próxima apresentação, iremos falar sobre COMO GERENCIAR...