Estórias do usuário - Parte 3
•
3 gostaram•930 visualizações
O documento fornece dicas para escrever histórias de usuário eficazes, incluindo levar em conta o tamanho e complexidade das tarefas, separar tarefas difíceis de estimar, não omitir tarefas, e considerar o valor da tarefa para o todo.
Recomendados
Mais conteúdo relacionado
Mais de Ismael
Mais de Ismael (20)
Último
Último (20)
Estórias do usuário - Parte 3
- 1. Parte 3
- 11. O que meu o cliente quer?
- 20. •Leve em conta o tamanho das tarefas •Separe as tarefas difíceis de estimar •Não economize tarefas •Leve em consideração o valor da tarefa para o todo
- 21. Obrigado! Ismael Soares & Luiz Ferreira
- 22. 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.
- 23. Imagens • http://www.flickr.com/photos/jmmpereda/25867 55467/in/photostrea • http://www.flickr.com/photos/tribodosincas/191 965516/ • http://www.flickr.com/photos/kj- an/2611734503/ • http://www.flickr.com/photos/eivisso/515665460 2/ • http://www.flickr.com/photos/serye/3117461948 /
Notas do Editor
- Os detalhes da Estória estão presentes nas conversas. Entretanto, se estes não forem suficientes para o entendimento das solicitações, ou até mesmo para se fazer a estimativa da estória, pode-se criar um nível maior de detalhamento através de Sub-Estórias.
- Neste exemplo temos três cartões, sendo uma Estória principal e duas Sub-Estórias. As Sub-Estórias foram criadas porque as informações existentes na Estória principal não fornecem todos os detalhes necessários para desenvolvimento da funcionalidade. Mesmo sendo quebrada em Sub-Estórias, a idéia não é criar uma dependência de estórias, mas fornecer um detalhamento mais rico de informações, com intuito de entregar a funcionalidade da estória principal.
- Estórias do Usuário muito relacionadas dificultarem a entrega de uma funcionalidade em uma única iteração Mais de uma equipe de desenvolvimento trabalhando num único software
- Se as estórias não estiverem organizadas, poderá haver problemas de comunicação, conflitos de código e retrabalhos
- Para resolver estes tipos de problemas, é recomendável separar as estórias por tema.
- Embora elas sejam diferentes, estão relacionadas ao mesmo tema: pagamentos
- A separação por tema ajuda a entender a necessidade do cliente, proporcionando assim, uma visão ampla do que deve ser desenvolvido.
- Por causa do seu grande conteúdo são difíceis de implementá-las em uma única iteração, dificultando sua estimativa e seu planejamento.
- Note que a descrição da estória parece ser pequena e de fácil entendimento, porém ao analisar a funcionalidade em questão, pode-se concluir que há uma grande complexidade envolvida, pois levaria muito tempo para desenvolvê-la. Nesta situação, é recomendável quebrá-la, criando estórias de menor porte.
- A Figura exemplifica a divisão de uma estória de grande porte em estórias menores. Neste exemplo, foi criada uma estória para cada idioma, e com isso, estimá-las, planejá-las e implementá-las separadamente, sem comprometer a funcionalidade inicialmente solicitada, além de agilizar a entrega de parte do software para que o cliente possa trabalhar.
- Estória pode ser quebrada em tarefas, com intuito de facilitar o processo de estimativa e melhorar a divisão do trabalho entre os desenvolvedores, agilizando a entrega do software.
- As tarefas representam apenas uma parte da estória, portanto não tem valor para cliente.
- Não existe uma fórmula mágica a ser aplicada para garantir que a desagregação seja exata e concisa.
- 1 - é recomendável que cada tarefa não ultrapasse cinco dias ou uma iteração para ser desenvolvida e testada; 2 - se uma determinada tarefa é difícil de estimar por causa da sua complexidade ou até mesmo por causa de dependência externa, separe-a das demais. Isto fará com que a estória não seja impedida por completo; 3 - se uma tarefa pode ser desenvolvida por mais de um desenvolvedor, divida-a em mais tarefas. Dessa forma, mais pessoas irão participar do desenvolvimento e ela será concluída mais rapidamente; 4 - suponha que será desenvolvido um relatório de vendas e este possuirá duas formas de visualização: analítica e sintética. No entanto, será desenvolvida apenas uma consulta SQL que atenderá as duas visualizações. Ao invés de criar duas tarefas, uma para cada tela e atrelar a consulta a uma delas, agregaria mais valor ao todo se esta consulta estivesse em uma tarefa separada. Isto porque, caso uma das duas tarefas atrasem, uma não impediria a outra.