05 Mar 2021 | 3 minutos • Ferramentas
Azure Boards - Processos
Definição do modelo de trabalho

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

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!
O link do post foi copiado com sucesso!Mais conteúdos de Ingrid Machado

28 Nov 2022 • Ferramentas
Sistema de gestão de conteúdo - Construção - Parte 2
Este post é a terceira parte da explicação sobre como criei o meu projeto para o Coda Doctorate. Para entender o processo por completo, recomendo que inicie a leitura pelo post com a primeira pa...
5 minutos

14 Nov 2022 • Ferramentas
Sistema de gestão de conteúdo - Construção - Parte 1
Este post é a segunda parte da explicação sobre como criei o meu projeto para o Coda Doctorate. Para entender o processo por completo, recomendo que leia primeiro o post com a ideação. Recapit...
4 minutos

31 Out 2022 • Ferramentas
Sistema de gestão de conteúdo - Ideação
Depois do Coda Bootcamp, fiz a minha inscrição para o Coda Doctorate, que é a fase com conteúdo mais avançado sobre o Coda. Mas, a melhor parte, é que ele é muito focado em resolução de problemas. ...
6 minutos