Area Paths
| Aspecto | Azure DevOps | Jira |
|---|---|---|
| Conceito | Categorização hierárquica (Project\Backend\API\Auth) | Sem equivalente direto |
| Hierarquia | Estrutura em árvore com profundidade ilimitada | Plano — Components e Labels não têm hierarquia |
| Escopo de team | Area paths delimitam trabalho para teams | Board filters ou escopo baseado em component |
| Herança | Area paths filhos herdam do pai | N/A |
| Profundidade típica | 3-5 níveis | N/A |
Alternativas no Jira
| Funcionalidade Area Path (ADO) | Alternativa Jira | Fidelidade |
|---|---|---|
| Categorização | Components (por projeto, com maintainer e default assignee) | Média — plano, sem hierarquia |
| Tagging | Labels (tags de texto livre) | Baixa — sem estrutura, propenso a erros de digitação |
| Hierarquia | Custom field (cascading select) | Média — configuração manual por nível |
| Escopo de team | Board filter (JQL com component = X) | Média — alcançável mas não nativo |
Gap crítico
Gap de migração
Este é um dos gaps mais críticos na migração. Area paths multi-nível (ex.: Backend\API\Auth) não podem ser representados diretamente no Jira.
Workarounds comuns
- Achatar para Components:
Backend,Backend-API,Backend-Auth(perde semântica hierárquica) - Cascading Select Custom Field: Simula hierarquia mas requer manutenção manual
- Jira Premium Hierarchy: Hierarquia custom de issues pode compensar parcialmente
- Múltiplos Labels:
area:backend,area:api,area:auth(baseado em convenção)