Entendendo a relação entre histórias (User Story) e tarefas
No meu artigo anterior falei sobre o planejamento das equipes ágeis o que nos levou a User Story (histórias) e consequentemente a tarefas, neste artigo vamos mais a fundo na relação entre User Story e tarefas.
Cada história é uma coleção de tarefas, onde a história descreve a necessidade do usuário e a tarefa descreve como a funcionalidade será implementada, como a tarefa representa o trabalho real teremos um nível de granularidade muito maior.
A definição das tarefas para cada história, ocorre quando alocamos a história na iteração atual e isso é muito bom, pois teremos maior feedback e detalhes para assim melhor elaborar as tarefas a serem executadas para aquela história.
As tarefas são estimas em horas, é recomendado estimar o tamanho das tarefas entre 2-12 horas, para tarefas que requerem mais que 12 horas quebre estas em várias tarefas de menos de 12 horas.
Quando uma história está PRONTA (DONE)?
Em SCRUM utilizamos o termo DONE para indicar que uma história já teve seu desenvolvimento finalizado e está pronta para ser avaliada pelo Produtct Owner. A própria equipe cria sua definição de DONE, que pode ser um único critério ou um conjunto, abaixo um exemplo:
- Todas as tarefas completadas (desenvolvimento, testes, documentação)
- Executar e passar em todos os testes de aceitação
- Nenhum defeito aberto
- Aceitação do product owner
- Pode ser enviado ao usuário
Com isso a equipe se compromete a entregar todas as histórias com base na definição estabelecida.
Critérios de Aceitação
Assim como a equipe define o DONE para cada história, o product owner ou cliente são responsáveis por descrever seus critérios para aceitarem a história, estes critérios podem descrever a funcionalidade, comportamento e desempenho que eles esperam para tal recurso.
O papel dos critérios de aceitação é definir o que DONE é exatamente, isso irá ajudar ao desenvolvimento saber quando eles completaram a história. Se existem partes da história que você não quer deixar para o desenvolvimento definir, escreva um critério de aceitação. Por exemplo, se você acha que deve definir as mensagens de erros e como elas serão apresentadas, você pode fornecer um documento de design para explicar o formato e texto das mensagens de erro ou você pode escrever critérios de aceitação para cada história que venha a gerar uma mensagem de erro.
Para finalizar, história, critérios de aceitação e tarefas para implementar a história representa um requisito em ágil.
No próximo artigo vamos falar sobre Daily Standup.
Artigos relacionados
Como equipes ágeis planejam seu trabalho
Video: Como escrever seus requisitos (User Stories) no formato Ágil
SCRUM – Reuniões diárias (Daily Standup Meeting)
Os diferentes papéis em uma Equipe Ágil – SCRUM
TDBXJsonTools copiar/converter dados entre TDataSet – TJSONObject – DBXReader
DataSnap – Compartilhando conexão com o banco entre diferentes Server Classes a partir do mesmo cliente (Session)
Bom dia Andreano,
Os Critérios de Aceitação é um documento formal? Ele especifica a aceitação de uma única história ou define a aceitação de todas as histórias? Caso a história precise de testes para receber o status DONE, os requisitos a serem testados estão todos contidos no critério de aceitação? Em que momento são levantados estes critérios junto ao cliente? Existe um sprint específico para isso?
Fico no aguardo!
Atenciosamente.
Bom dia Andreano, tudo bem? espero que sim
Você teria algum software que gerencie SCRUM para sugerir?
Atualmente utilizo TRAC + AGILO devido ao mesmo integrar ao SUBVERSION, porém, a versão que tenho deixa a desejar em alguns aspectos.
Agradecido desde já,
Um abraço,
Parabéns.
Muito bom..simples e direto nas definições de um processos agil.