Governança AZ2

Módulo de maturidade do Órbita e matriz de permissões do Azure DevOps. Acesso restrito à equipe de governança.

Governança AZ2

Duas iniciativas independentes no mesmo lugar. As telas de Configuração e Simulador tratam do módulo de maturidade do Órbita. A Matriz de permissões trata do modelo de segurança do Azure DevOps. Tudo que você editar fica salvo neste navegador.

Este navegador não está permitindo salvar dados locais. As alterações valem só até fechar a aba.

Modelo de pontuação

O peso da dimensão define quanto ela vale no score geral. O ponto por criticidade define como esse peso se distribui entre os indicadores ativos dentro da dimensão. Dimensão sem nenhum indicador ativo sai do cálculo e seu peso é redistribuído entre as demais.

Peso por dimensão

Digite qualquer valor. Se a soma não fechar 100, a página normaliza e mostra o peso efetivo ao lado.

soma digitada:100

Ponto por criticidade

Quanto um indicador pesa dentro da própria dimensão. Aumentar o ponto de bloqueante concentra o score nos desvios graves; igualar os três trata todo indicador da mesma forma.

Faixas do score

Aplicadas ao score geral e a cada nota de dimensão, e usadas pela trava de confiabilidade no simulador.

Verde a partir de
Amarelo a partir de
Vermelho abaixo disso
Ver

Regra de cálculo

A mesma fórmula vale para qualquer configuração montada acima e é a que o simulador executa.

taxa(i) = itens em desconformidade / itens elegíveis

nota(dimensão) = 10 × ( 1 − Σ(ponto·taxa) / Σ(ponto) )  só indicadores ativos

score geral = Σ ( nota(dimensão) × peso efetivo(dimensão) )

Indicador sem base elegível no período (zero itens no denominador) sai do cálculo: não penaliza nem premia. Mantém-se o corte de 01/01/2026 já usado hoje pelo Órbita. Trava de confiabilidade: quando a nota de Conformidade de Campos ou de Fluxo cai abaixo do limite vermelho, as abas Performance e Visão 360 daquele time exibem aviso de dado não confiável.

usando a configuração atual
Score de maturidade
0,0 / 10
verde
0510
Preencher

Matriz de permissões do Azure DevOps

Quem pode fazer o quê, por cargo. Clique em qualquer célula para percorrer os quatro estados que a tela de segurança do Azure DevOps oferece de verdade. O modelo assume grupos de segurança por squad, adicionados a todos os projetos daquele squad, e licença Basic para todos os perfis.

Estados Permitir Negar Herdado Não definido

Clique avança o estado. Segure Shift e clique para voltar. Negar vence herança no Azure DevOps: é o único estado que bloqueia mesmo quando o usuário está em outro grupo que permite.

Decisões já fechadas

Exclusão só do Coordenador para cima. Coordenador e Gerente mandam item para a lixeira. A exclusão permanente fica só com o administrador da organização.

Diretor e CTO são leitura. Enxergam tudo, não operam o board. Quem opera é Gerente, Coordenador e Squad Leader.

Acesso entre projetos por exceção. Reader concedido sob solicitação aprovada pelos coordenadores, não por padrão.

Licença Basic para todos. Stakeholder não entra no modelo.

Como funciona a criação por tipo

São duas camadas, não uma. A permissão Edit work items in this node (linha WI-02) é a porta de entrada: sem ela a pessoa não cria nem edita nada, e ela não distingue tipo nenhum. O bloco de criação por tipo age em cima de quem já passou por essa porta, e só controla criação. Tirar o WI-02 da matriz deixaria a edição sem dono: é ele que impede o Diretor e o CTO de mexerem em item de trabalho.

O bloqueio por tipo é feito por regra do process template: uma regra que restringe a transição para a categoria de estado Proposed, condicionada a Current user is a member of group, desabilita a criação daquele tipo para aquele grupo. É o caminho documentado pela Microsoft e é o que sustenta o bloco de criação por tipo desta matriz.

Consequência prática: essas linhas são configuradas em Organization Settings › Process, uma regra por tipo, não em Project Settings › Permissions. Valem para toda a organização, não por projeto.

A linha Ignorar regras do processo ao salvar anula tudo isso: quem tem essa permissão fura o template inteiro sem deixar rastro na tela de segurança.

Fora do escopo desta matriz

Repos e Pipelines não entram. Quem gerencia repositório, branch policy, pipeline, ambiente e service connection é o time de infraestrutura. Esta matriz cobre apenas o que a governança administra: estrutura do projeto, itens de trabalho, criação por tipo, área e iteração.

Onde cada bloco se configura. Projeto e organização: Project Settings › Permissions e Organization Settings. Itens de trabalho: Project Settings › Project configuration › Areas, aba Security de cada nó. Criação por tipo: Organization Settings › Process, uma regra por tipo. Área e iteração: Project Settings › Project configuration.

A linha em rosa abaixo de cada permissão traz o nome exato em inglês, do jeito que aparece na tela do Azure DevOps.

Configuração atualizada em outra aba