Esse é o nosso quinto e último texto falando sobre a estória do usuário, e hoje vamos falar das Tasks na User Story. E para complementar o conhecimento entregue nesse arquivo, recomendo a leitura dos textos anteriores.
Continuando...
A Tasks na User Story
Depois de ler os artigos anteriores, nós já sabemos que quando o assunto é Scrum, existem princípios envolvidos. E que para falar da User Story, também é preciso falar de princípios, o principal deles é o de que um produto pode ser totalmente representado pela necessidade do usuário.
Nós também já sabemos que a User Story nada mais é, que, a descrição concisa da necessidade do usuário de um produto ou funcionalidade. Por se tratar da estória do usuário, falar de User Story é falar da busca por descrever a necessidade do usuário de forma simples e leve.
Já entrando na composição da User Story, temos os Critérios de Aceite e as Regras de Negócio que são composições de uma User Stories. Ou seja, para uma User Stories estar completa, ela precisa ser composta por ambos.
Normalmente os critérios de aceite são representados em forma de lista de itens de negócio que apresentam as formas de usar as funcionalidades implementadas na estória do usuário. Chama-se critério de aceite, porque através dessa lista é possível descobrir se a User Story foi implementada de acordo com o que o PO (Product Owner) solicitou. Lembra disso?
E, agora, de forma sintetizada vamos recapitular o conceito de DOR e DOD:
DOR: Definition of Ready, que na tradução literal quer dizer ‘definição de preparado’, existe para dar apoio ao Refinamento.
O conceito da Definition of Ready (DOR) é, basicamente, ser uma lista onde constam todos os requisitos necessários para que uma história possa ser validada no backlog da Sprint. Ou seja, o DOR compõe a relação do que uma estória precisa ter para começar; e entre outras coisas ela precisa: ter anexos, ser bem detalhada, ter saída de negócio, critérios de aceite, requisitos e acessos (banco de dados, servidor…).
DOD: Definition of Done, tradução literal: Definição de feito. O conceito do DOD é ajudar o time a listar os requisitos necessários para que a tarefa seja dada como concluída.
Na prática, no dia a dia do desenvolvimento de um projeto, a DOD, é como a DOR. Isso porque, assim como no DOR, ela tem como estratégia montar uma lista para verificar as etapas do desenvolvimento da tarefa. E assim como na DOR, na DOD a tarefa só pode ser considerada concluída, quando ela atender aos requisitos especificados na DOD.
Esse resumo é importante para que possamos entender o contexto em que a Task surge.
Conhecendo melhor as Tasks na User Story
Como já falamos no artigo sobre a Sprint Planning, após a Sprint Planning, o Time Scrum concentra seus esforços em quebrar a User Story em unidades menores de trabalho, e essas unidades menores são conhecidas como Tasks na User Story O detalhe importante para ressaltar, é que não é o PO que quebra as estórias, transformando-as em Tasks.
É o Time Scrum que faz isso. Entendido?
Resumindo, as Tasks na User Story são partes da User Story, que são quebradas em tarefas, e são, geralmente, técnicas.
Sabendo disso, a dúvida é: como se quebram as estórias em tarefas? Para tentar responder essas perguntas, vou tentar listar algumas dicas ou instruções de como quebrar as tarefas. Separei algumas dicas para ajudar com isso.
Sempre crie tarefas que possam ser feitas em um dia de trabalho (a tarefa não precisa durar o dia inteiro, só não deve ultrapassar um dia. Se a quebra resultar em uma tarefa de mais um dia, a recomendação é quebrar ainda mais). Mas por que um dia e não mais? O objetivo é facilitar o gerenciamento das tarefas e proporcionar uma melhor visualização do desenvolvimento.
Granularidade fina: Fazer uma análise detalhada da User Story e transformar cada detalhe em uma Task. Assim as tarefas tornam-se uma espécie de guia para o desenvolvimento.
Refinamento Contínuo: A Sprint é a base para o desenvolvimento do produto. Por isso essa dica é: sempre adeque a quebra de tarefas à realidade do Time.
Tasks na User Story: as Tarefas Smart
O acrônimo SMART é o mais famoso dentro e fora do ambiente tecnológico, é usado para definir o detalhamento das tarefas
Specific (específica): Ter uma única responsabilidade, ser coesa.
Mensurável: Precisa ser medida. Se não se pode medir, como pode saber como entregar?
Alcançável: Somente o Time de desenvolvimento tem autonomia para fazer essa classificação.
Relevante: Precisa agregar ao todo da história.
Temporal: Deve ter um tempo definido para sua realização.
Legal, não é?
Depois de entender o SMART no universo ágil, terminamos mais esse assunto, mas eu te espero no próximo artigo para falarmos sobre PRIORIZAÇÃO. Até lá!
Se você se interessa pelo tema e quer saber como aplicar o SCRUM, transformar sua carreira, aumentar o valor de mercado da sua empresa e ser um profissional que entrega resultados de alto valor e performance, clique aqui Scrum Training e saiba mais sobre esse framework que é tendência mundial.
Comentarios