Gestão do Backlog
Tipos (Epic, User Story, Task, Bug)
Epic
No jira qualquer ação de trabalho tem o nome de issue. O epic é um issue que reflete o foco de negócio para o produto, de forma mais abrangente. Corresponde a uma iniciativa do negócio que se pretende ver concretizada no produto a desenvolver.
Os user stories e as tasks ficam associados ao épico.
User Story
O user story corresponde a requisito ou funcionalidade a que o produto deverá dar resposta (User Story / Job Story) e que trás valor para o utilizador.
Como [perfil], quando [situação], quero [motivação e como], para que [resultado esperado].
Task
Uma user story dá origem a uma ou mais tarefas, tantas quanto as necessárias para a concretização da story no produto final. As tarefas podem corresponder a tarefas do processo de reseach e design thinking (empatia, definição, ideação, protótipo e testes), análise, desenvolvimento, testes, passagens e outros tipos de trabalho a realizar. Deve estimar-se o esforço de cada tarefa em story points para ser possível planear o trabalho que se faz em cada sprint e medir a velocidade da equipa.
Bug
Quando é encontrado um problema no produto desenvolvido, após o requisito ou funcionalidade ter sido dado por concluído, é reportada uma correção (erro / bug).
Hierarquia
A figura seguinte ilustra a hierarquia existente entre os vários tipos de issues do Backlog:
No Jira, a única hierarquia que se estabelece diretamente é entre o Épico e a User Story. As restantes relações de hierarquia são manuais e estabelecidas por recurso à funcionalidade de Link issues (associar outros issues).
Campos a preencher
Consoante o tipo de issue, há campos que deverão ser preenchidos.
[1] As tarefas são estimadas em unidades de valor abstratas, tais como story points, com base na utilização de um modelo de pesos relativos. O significado dos story points é determinado pela Equipa (ex. níveis de complexidade de implementação).
Algumas notas transversais sobre o preenchimento dos seguintes campos:
Description – incluir User Story / Job Story, critérios de aceitação, link para protótipo e para qualquer outro documento relevante;
Priority – selecionar entre Highest, High, Medium, Low, Lowest;
Business Unit Value – auxiliar à ordenação em hierarquia dos issues nas pesquisas, deverá ser preenchido unicamente pelo Product Owner;
Status – de acordo com o ciclo de vida (Ciclo de vida);
Sprint – preenchido apenas quando o issue for incluído no Sprint Backlog.
Epic
Issue Type = Epic;
Components = Epic.
No caso de existir um Epic dividido num conjunto de Epics, deverá ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).
Story
Issue Type = Story;
Components = Story.
No caso de existirem relações ou dependências com outras Story, deverá ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).
Task
Issue Type = Task;
Description – incluir descrição completa que permita identificar exatamente o âmbito da tarefa;
Linked issues – garantir a relação com a respetiva Story e outras tarefas com as quais existem relações de dependência (Linkar outros issues);
Components – selecionar entre Backend, Data Analytics, Deployment, Development, Frontend, Functional Analysis, Segurança, UX/UI.
É fundamental compreender o contexto do produto no qual a tarefa se insere, a fim de garantir que a sua execução corresponde a um incremento funcional do produto final. Para tal, é essencial identificar com que story esta tarefa está relacionada, devendo ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).
Bug
Issue Type = Bug;
Description – incluir descrição completa que permita identificar exatamente qual o problema e como replicar o mesmo;
Linked issues – garantir a relação com a respetiva Story e outras tarefas com as quais existem relações de dependência (Linkar outros issues);
Components – selecionar entre Backend, Data Analytics, Deployment, Development, Frontend, Functional Analysis, Segurança, UX/UI;
Environment – informação adicional que permita replicar o problema;
Fix versions – Release onde vai ser corrigido o erro;
Affects versions – Release onde ocorre o erro.
Associar outros issues
No Jira, a única hierarquia que se estabelece diretamente é entre o Epic e a Story. As restantes relações de hierarquia (Hierarquia) são manuais e estabelecidas por recurso à funcionalidade de Link issues.
Assim, é fundamental criar as seguintes relações através da criação de links com outros issues:
Relação de hierarquia Story – Task (importante para garantir o contexto de negócio da task a realizar);
Relação de hierarquia Story – Bug (importante para garantir o contexto de negócio do bug a corrigir);
Relação entre Task – Task (se são ambas essenciais para a concretização de um incremento ao produto, por exemplo, tarefa de UX – tarefa de FE – tarefa de BE);
Relação entre Task – Bug (se aplicável);
Relação entre quaisquer issues (representativa das dependências entre si).
Associar checklists
O Jira permite definir uma checklist com um conjunto de tópicos a confirmar ou executar, para reutilização em vários issues. Tem a vantagem de ser definida uma única vez e permitir fazer referência a esta sempre que for necessário, enriquecendo a informação que consta do issue.
Um conceito essencial ao agile, a Definition of Done, corresponde a um exemplo prático da utilização de uma checklist. Mas até uma característica ou comportamento repetitivo do produto pode ser identificado como uma checklist. O importante é não esquecer de selecionar a checklist em todos os issues onde esta deverá ser aplicável.
As figuras seguintes ilustram alguns exemplos de checklist:
Ciclo de vida
Estados de issues (Scrum)
To Do - A tarefa aguarda o início da sua execução. Este é o estado de todos os issues que estão no Backlog. Quando selecionada para o Sprint Backlog a tarefa continua neste estado até que alguém comece a trabalhar sobre ela durante o Sprint;
In Progress - A tarefa está a ser correntemente trabalhada por alguém;
Blocked - Existem dependências internas / externas que têm de ser desbloqueadas / concluídas para que a tarefa deste issue possa continuar;
Peer Review - Passo intermédio antes de colocar o issue em review que faz com o que os trabalhos sejam revistos por colegas (pares);
Review - O desenvolvimento da tarefa terminou, mas o código desenvolvido está à espera de revisão por parte do Product Owner;
Closed - Todo o desenvolvimento está concluído, e o conteúdo realizado nesta tarefa pode passar para o ciclo de CI/CD normal, se aprovado pelo Product Owner.
Nota importante: A tarefa só é colocada “In Progress” aquando da sua execução, pois este estado refere-se ao ciclo de vida da tarefa. Quando está a ser realizada a validação pelo par deve manter-se em “Peer Review”. Quando está a ser realizada a validação pelo product owner deve manter-se em “Review”.
Last updated