Azure Boards - Work items

Este é o oitavo post da série a respeito do Azure Boards e senti que já estava na hora de mostrar pelo menos um work item no detalhe, antes de seguir com outros assuntos.

No primeiro post, eu já havia falado sobre os tipos de work items existentes, qual é a hierarquia entre eles e quais são as diferentes formas de visualizá-los dentro da ferramenta. O segundo post mostra os processos que definem quais tipos de work items existirão no projeto e quais são os status dentro do processo Agile, o escolhido como exemplo para essa série. E no quarto post mostrei como criar work items, dentro da visualização “Boards – Backlog”.

Então, se você vem acompanhando a série desde o início, acredito que você já tenha alguma noção a respeito dos work items e o post de hoje vai te mostrar alguns detalhes.

Relembrando, os work items são a representação dos itens de trabalho do projeto e é através deles que podemos acompanhar a evolução do desenvolvimento. Dentro do processo Agile, temos os seguintes tipos disponíveis:

Cada item difere entre si pelo tipo, posição na hierarquia e campos disponíveis para incluir informações dentro da ferramenta.

Epic

Maior nível hierárquico, representa um objetivo do negócio, que será entregue através da conclusão das Features.

Exemplos: aplicativo para Android, aumento na conversão, melhorar experiência do usuário.

Feature

O conjunto de Features entrega um Epic. Features representam recursos, que serão implementados através de User Stories.

Exemplos: disponibilizar dados para o aplicativo, permitir compra com 1 click, atualizar layout da página de produto.

User Stories

Cada Feature é composta de diversas User Stories (histórias de usuário). Cada User Story representa um item no Product Backlog e descreve o valor que deve ser entregue para o cliente e o trabalho que deve ser executado.

Exemplos: tela de login, cadastro de cartão de crédito, alteração no esquema de cores.

Task

As Tasks representam o trabalho necessário para implementar a User Story e é através delas que podemos estimar o trabalho de membros da equipe de forma individual.

Exemplos: criar view de login no aplicativo, criar formulário de cadastro no HTML, ajustar o CSS da página de produto.

Bug

Os Bugs são utilizados para acompanhar a correção de defeitos encontrados e solução de dívida técnica.

Exemplos: erro recorrente ao logar, formulário não está aceitando texto no campo “Nome”, botão na página de produto não está de acordo com o novo layout.

Issue

As Issues indicam problemas que podem impedir o trabalho que está sendo feito no momento. Elas geralmente são vinculadas aos outros work items, através do link de tipo “Relacionado”.

Exemplo: aplicativo está com erro no download na Play Store.

Para criar uma Issue, siga o caminho “+ – New work item – Issue” no menu lateral:

Campos do work item

Note que a cada work item, o conjunto de campos disponíveis apresenta algumas diferenças. Porém, todos os work items possuem a mesma estrutura geral:

1. Link direto para acessar o work item;
2. ID e título;
3. Pessoa da equipe responsável;
4. Tags;
5. Opção de “Salvar” ou “Salvar & fechar”;
6. Opção de seguir o work item;
7. Estado atual;
8. Motivo do estado atual;
9. Representa o time ou produto do work item (depende da configuração feita na criação do projeto);
10. Sprint;
11. Campos que diferem de acordo com o tipo de work item (exceto pelo “Discussion”);
12. Abas com mais opções que por default incluem:
    • Histórico;
    • Links;
    • Anexos.
13. Work items relacionados.

Acompanhando work items

Ao clicar em “Follow” (opção 6 da imagem anterior), é possível acompanhar o work item. Quando o work item está sendo acompanhado, é feito o envio de um email a cada alteração.

Independentemente de estar acompanhando o work item, também é feita a notificação para a pessoa da equipe em que o nome está atribuído e para todas as pessoas marcadas no campo “Discussion”.

Adicionando comentários

Dentro do campo “Discussion” é possível incluir comentários no work item. Para notificar outras pessoas, use a notação com um @ e para incluir outros work items, use a notação com uma #:

Na prática, todos os work items simbolizam a mesma coisa e a diferença entre eles está nas informações que vamos incluir para acompanhar o trabalho. Acredito que vendo dessa forma é bem mais fácil de entender todas as opções existentes, porque, além desses work items apresentados, existem outros tipos dentro dos outros processos. Então tudo depende da forma como você vai trabalhar a gestão do seu produto.

Esse foi um overview a respeito dos work items disponíveis no Azure Boards. Como sempre, a caixa de comentários está sempre aberta.

Até a próxima!

Copiar link