Azure Boards - Processos

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.

Tipos de work items

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

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.

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:

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!

Copiar link