É muito comum existirem Histórias do Usuário que estejam tão relacionadas, a ponto de dificultarem a entrega de uma funcionalidade em uma única iteração. Além disso, algumas empresas trabalham com mais de uma equipe desenvolvendo o mesmo software. Com isto, se as Histó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 Histórias por tema.
organização de Histórias do Usuário
No exemplo ilustrado na figura acima é possível observar três estórias: “Como cliente, eu quero consultar os pagamentos realizados no portal…”, “Como cliente, eu quero imprimir a segunda via de pagamento do boleto…” e “Como cliente, eu quero imprimir o comprovante de pagamento…”. Embora elas sejam diferentes, estão relacionadas ao mesmo tema: pagamentos. Suponha que estas Histórias sejam desenvolvidas por duas ou três equipes, sendo que elas não sabem da existência das outras estórias. A probabilidade de desenvolverem funções parecidas é muito grande. Sem contar que, uma história poderá ser finalizada antes das outras, mas não será entregue por causa desta dependência.
A separação por tema ajuda a entender a necessidade do cliente, proporcionando assim, uma visão ampla do que deve ser desenvolvido.
De uma forma geral, algumas empresas que utilizam esta metodologia confundem a organização por tema com junção de estórias. Este erro gera outro problema descrito neste artigo: Histórias muito grandes que são difíceis de planejar.

Quebrando Histórias do Usuário em Tarefas

Conforme comentado neste artigo, uma História do Usuário representa uma funcionalidade solicitada pelo cliente, contudo esta 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 Histórias do Usuário são descrições de funcionalidades que têm valor para o cliente, não é uma lista de tarefas. O ato de dividir uma história em tarefas ajuda a torna – lá compreensiva aos desenvolvedores.
Quebrando uma história
No exemplo ilustrado na figura acima, o cliente precisa que os usuários que navegam pelo seu site possam consultar e reservar os apartamentos. Para desenvolver esta funcionalidade, a equipe de desenvolvimento decidiu dividir a história nas seguintes tarefas: “Fazer interface do usuário”, “Criar Componentes de validação” e “Integrar com Sistema de Reserva”. E para garantir que estas tarefas irão atender a descrição da estória, criaram testes unitários e de aceitação, baseados no que o Product Owner escreveu no verso do cartão.
A história tem valor agregado para o cliente porque representa a funcionalidade em questão. Por outro lado, as tarefas representam apenas uma parte do todo e não tem o mesmo valor. Em outras palavras, a entrega parcial destas tarefas não satisfaz a necessidade do cliente. Este ponto precisa ser levado em consideração no momento da divisão da estória.
Não existe uma fórmula mágica a ser aplicada para garantir que a desagregação seja exata e concisa. Para isso, devem ser consideradas as recomendações a seguir:

  • Leve em conta o tamanho das tarefas – é recomendável que cada tarefa não ultrapasse cinco dias ou uma iteração para ser desenvolvida e testada;
  • Separe as tarefas difíceis de estimar – 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 história não seja impedida por completo;
  • Não economize tarefas – 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;
  • Leve em consideração o valor da tarefa para o todo – 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.

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.

Deixe aqui o seu comentário