/ FERRAMENTAS

Azure Boards - Processos

Foto de Jannis Lucas, via Unsplash

No primeiro post da série, falei sobre o que é o Azure Boards, os tipos de work items da ferramenta e as telas disponíveis para gerenciar estes work items. No post de hoje, vou falar sobre os processos, que também são importantes no momento de fazer a gestão dos times.

O processo é o que vai determinar quais são os tipos de work item e o fluxo de status que serão disponibilizados no projeto dentro da ferramenta. Dentre os processos disponíveis por padrão no Azure Boards, encontram-se:

  • Basic;
  • Agile;
  • Scrum;
  • CMMI.

É possível escolher um dos processos ou criar uma customização. Para os textos desta série, vou seguir com exemplos do processo Agile, sem nenhuma customização. A escolha é baseada na nomenclatura dos work items e nos status disponíveis.

Processo Agile

Como o nome já diz, ao utilizar o processo Agile é possível trabalhar com metodologias ágeis. As atividades de desenvolvimento e teste podem ser acompanhadas em separado, onde pode-se usar um quadro Kanban para acompanhar User Stories e bugs e/ou um taskboard para acompanhar tarefas e bugs. Além disso, os work items possuem campos para acompanhar a estimativa, o trabalho restante e o trabalho concluído.

Quadro Kanban com uma User Story em New

Quadro Kanban exibindo o nível de User Story

Taskboard com uma Task em New

Taskboard de uma Sprint

Tipos de work items

Os tipos de work items disponíveis no processo Agile são os seguintes:

Tipos de work item do processo Agile: Epic, Feature, User Story, Task, Bug e Issue

Os 6 tipos de work items disponíveis são separados em 3 níveis (Portfolio Backlog, Backlog e Issue & bug tracking) e respeitam a hierarquia indicada pelas setas.

Estados dos work items

Em relação ao fluxo de trabalho, temos os seguintes estados possíveis:

  • New: estado de quando o work item é criado ou retorna para o Backlog;
  • Removed: estado de um work item que foi removido do Backlog;
  • Active: estado do work item que está em desenvolvimento;
  • Resolved: todos os work items filhos já foram desenvolvidos e passaram nos testes unitários;
  • Closed: o work item passou nos testes de aceite.

Imagem com caixas exibindo o fluxo de estados de uma User Story

Fluxo de estados de uma User Story no Processo Agile

Imagem com caixas exibindo o fluxo de estados de uma User Story

Fluxo de estados de uma Feature no Processo Agile

Imagem com caixas exibindo o fluxo de estados de uma User Story

Fluxo de estados de um Epic no Processo Agile

Note como a hierarquia dos work items influencia a passagem do estado “Active” para “Resolved” no fluxo do processo Agile. A User Story pode ser movida para “Resolved” quando todas as tarefas de implementação forem concluídas, por exemplo.

O fluxo de estados dos bugs considera o fluxo de testes e o das tasks considera o fluxo de desenvolvimento. Sendo que ambos diferem consideravelmente do fluxo dos work items anteriores:

Imagem com caixas exibindo o fluxo de estados de uma User Story

Fluxo de estados de um Bug no Processo Agile

Imagem com caixas exibindo o fluxo de estados de uma User Story

Fluxo de estados de uma Task no Processo Agile

Quando um work item está em “Closed” ou “Done”, ele aparece somente na página com o Sprint Backlog, no quadro Kanban e no taskboard. Quando um work item está em “Removed”, ele não é exibido em nenhum backlog ou quadro do projeto.


É importante entender como o processo escolhido influencia na forma de trabalho dentro do Azure Boards. Escolher um processo que não está de acordo com o fluxo de trabalho real pode gerar confusão e até mesmo prejudicar o rendimento do time.

Agora que já conhecemos as telas disponíveis e o processo Agile com seus work items e fluxo de trabalho, vamos ver como criar um projeto no próximo post da série.

Até a próxima!



ingridmachado

Ingrid Machado

Engenheira de computação, especialista em engenharia de software.
Autora deste querido blog.

Mais posts