Como a Microsoft faz planejamentos com o DevOps

A Microsoft é uma das maiores empresas do mundo que utiliza metodologias Agile. Ao longo de anos de experiência, a Microsoft desenvolveu um processo de planejamento de DevOps que se expande desde os menores projetos até grandes operações como o Windows. Este artigo descreve muitas das lições aprendidas e práticas que a Microsoft implementa ao planejar projetos de software em toda a empresa.

Mudanças importantes

As seguintes alterações importantes ajudam a tornar os ciclos de desenvolvimento e envio mais saudáveis e eficientes:

• Promova o alinhamento cultural e a autonomia.
• Mude o foco de indivíduos para equipes.
• Crie novas estratégias de planejamento e aprendizagem.
• Implemente um modelo multiequipe.
• Melhore as práticas de integridade do código.
• Promova a transparência e responsabilidade.

Promova o alinhamento cultural e a autonomia

Peter Drucker disse: "A cultura come estratégia no café da manhã". Autonomia, domínio e propósito são as principais motivações humanas. A Microsoft tenta fornecer essas motivações para PMs, desenvolvedores e designers para que eles se sintam capacitados para criar produtos de sucesso.

Dois importantes contribuintes para essa abordagem são o alinhamento e a autonomia.

• O alinhamento vem de cima para baixo, para garantir que indivíduos e equipes entendam como suas responsabilidades se alinham com objetivos de negócios mais amplos.
• A autonomia acontece de baixo para cima, para garantir que indivíduos e equipes tenham impacto nas atividades e decisões do dia a dia.

Há um equilíbrio delicado entre alinhamento e autonomia. Muito alinhamento pode criar uma cultura negativa em que as pessoas desempenham apenas como o que lhes é pedido. O excesso de autonomia pode causar falta de estrutura ou direção, tomada de decisão ineficiente e planejamento ruim.

Mude o foco de indivíduos para equipes

A Microsoft organiza pessoas e equipes em três grupos: PM, design e engenharia.

• O PM define o que a Microsoft cria e por quê.
• O design é responsável por projetar o que a Microsoft cria.
• A engenharia cria os produtos e garante sua qualidade.

As equipes da Microsoft têm as seguintes principais características:

• Interdisciplinar
• 10 a 12 pessoas
• Autogerenciado
• Carta clara e metas para 12-18 meses
• Salas de equipe físicas
• Implantação de recursos próprios
• Recursos próprios em produção

Buscar equipes verticais

As equipes da Microsoft costumavam ser horizontais, cobrindo toda a interface do usuário, todos os dados ou todas as APIs. Agora, a Microsoft busca equipes verticais. As equipes são donas de suas áreas do produto do início ao fim. Diretrizes rígidas em determinados níveis garantem uniformidade entre as equipes em todo o produto.

O diagrama a seguir explica a diferença entre equipes horizontais e verticais:

Permita a autosseleção de equipes

A cada 18 meses, a Microsoft executa um "exercício amarelo pegajoso", onde os desenvolvedores podem escolher em quais áreas do produto desejam trabalhar nos próximos períodos de planejamento. Esse exercício proporciona a autonomia, pois as equipes podem escolher em quê trabalhar, e o alinhamento organizacional, pois promove o equilíbrio entre as equipes. Cerca de 80% das pessoas neste exercício permanecem em suas equipes atuais, mas se sentem empoderadas porque tiveram escolha.

Crie novas estratégias de planejamento e aprendizagem

Dwight Eisenhower disse: "Planos não valem nada, mas planejamento é tudo". O planejamento da Microsoft é dividido na seguinte estrutura:

• Sprints (3 semanas)
• Planos (3 sprints)
• Temporadas (6 meses)
• Estratégias (12 meses)

Engenheiros e equipes são os principais responsáveis pelos sprints e planos. A liderança é a principal responsável pelas temporadas e estratégias.

O diagrama a seguir ilustra a estratégia de planejamento da Microsoft:

Essa estrutura de planejamento também ajuda a maximizar o aprendizado durante o planejamento. As equipes são capazes de obter feedback, descobrir o que os clientes querem e implementar as solicitações dos clientes de forma rápida e eficiente.

Implemente um modelo multiequipe

Os métodos anteriores fomentaram uma "cultura de interrupção" de bugs e incidentes ao vivo no local. As equipes da Microsoft criaram sua própria maneira de aumentar o foco e evitar distrações. As equipes se auto-organizam para cada sprint em duas equipes distintas: Recursos (equipe F) e Cliente (equipe C).

A equipe F trabalha em recursos comprometidos, e a equipe C lida com problemas e interrupções ao vivo no local. A equipe estabelece uma cadência rotativa que permite que os membros planejem as atividades com mais facilidade. Para obter mais informações sobre o modelo de várias equipes, consulte Criar equipes produtivas e focadas no cliente.

Melhore as práticas de integridade do código

Antes de mudar para metodologias Agile, as equipes costumavam permitir que os bugs de código se acumulassem até que o código fosse concluído no final da fase de desenvolvimento. Depois disso, as equipes descobriram bugs e trabalharam para corrigi-los. Essa prática criou uma montanha-russa de bugs, que afetou o moral e a produtividade da equipe quando as equipes tiveram que trabalhar em correções de bugs em vez de implementar novos recursos.

As equipes agora implementam um limite de bugs, calculado pela fórmula # of engineers x 5 = bug cap. Se a contagem de bugs de uma equipe exceder o limite de bugs no final de um sprint, eles devem parar de trabalhar em novos recursos e corrigir bugs até que estejam abaixo do limite. Agora, as equipes pagam dívidas de bugs à medida que avançam.

Promova a transparência e responsabilidade

No final de cada sprint, cada equipe envia um email relatando o que realizaram no sprint anterior e o que planejam fazer no próximo sprint.

Objetivos e resultados principais (OKRs)

As equipes são mais eficazes quando têm clareza sobre os objetivos que a organização está tentando alcançar. A Microsoft fornece clareza às equipes por meio de objetivos e resultados-chave (OKRs).

• Os objetivos definem as metas a serem alcançadas. Os objetivos são significativos, concretos, baseados em ação e, idealmente, declarações de intenção inspiradoras. Os objetivos representam grandes ideias, não números reais.
• Os resultados-chave definem etapas para atingir os objetivos. Os resultados-chave são resultados quantificáveis que avaliam o progresso e indicam o sucesso em relação aos objetivos em um intervalo de tempo específico.

Os OKRs refletem os melhores resultados possíveis, não apenas os resultados mais prováveis. Líderes tentam ser ambiciosos e não cautelosos. Forçar as equipes a buscar resultados-chave desafiadores impulsiona a aceleração em relação aos objetivos e prioriza o trabalho que se move em direção a metas maiores.

A adoção de uma estrutura de OKR pode ajudar as equipes a terem um desempenho melhor pelos seguintes motivos:

• Toda equipe está alinhada no plano.
• As equipes se concentram em alcançar resultados em vez de concluir atividades.
• Toda equipe é responsável pelos esforços regularmente.

Os OKRs podem existir em diferentes níveis de um produto. Por exemplo, pode haver OKRs de produto de nível superior, OKRs de nível de componente e OKRs de nível de equipe. Manter os OKRs alinhados é relativamente fácil, principalmente se os objetivos forem definidos de cima para baixo. Quaisquer conflitos que surjam são indicadores iniciais valiosos de desalinhamento organizacional.

Exemplo de OKR

Objetivo: cultivar uma base de clientes forte e feliz.

Resultados-chave:

• Aumentar o Net Promoter Score (NPS) externo de 21 para 35.
• Aumentar a satisfação dos docs de 55 para 65.
• O novo fluxo de tubulação tem uma pontuação Apdex de 0,9.
• O tempo de fila para trabalhos é de 5 segundos ou menos.

Para obter mais informações sobre OKRs, consulte Medir resultados de negócios usando objetivos e resultados-chave.

Selecione as métricas certas

Os resultados-chave são tão úteis quanto as métricas em que se baseiam. A Microsoft usa os principais indicadores que se concentram na mudança. Ao longo do tempo, essas métricas constroem uma imagem funcional da aceleração ou desaceleração do produto. A Microsoft geralmente usa as seguintes métricas:

• Variação na taxa de crescimento mensal da adoção
• Mudança de desempenho
• Mudança no tempo necessário para aprender
• Mudança na frequência de incidentes

As equipes evitam métricas que não agregam valor em relação aos objetivos. Embora possam ter determinados usos, as métricas a seguir não são úteis para acompanhar o progresso em relação aos objetivos:

• Precisão das estimativas originais
• Horas concluídas
• Linhas de código
• Capacidade da equipe
• Burndown da equipe
• Velocidade da equipe
• Número de bugs encontrados
• Cobertura de código

Antes do Agile e depois do Agile

A tabela a seguir resume as alterações feitas pelas equipes de desenvolvimento da Microsoft ao adotarem práticas Agile.

Antes	Após
Marcos de 4 a 6 meses	Sprints de 3 semanas
Equipes horizontais	Equipes verticais
Escritórios pessoais	Salas de equipe e trabalho remoto
Longos ciclos de planejamento	Planejamento e aprendizagem contínuos
PM, Desenvolvimento e Teste	PM, Design e Engenharia
Participação anual do cliente	Participação contínua do cliente
Branches de recursos	Todos trabalham na unidade principal
Equipes de mais de 20 pessoas	Equipes de 8 a 12 pessoas
Roteiro secreto	Roteiro compartilhado publicamente
Dívida de bug	Sem dívidas
Documentos de especificação de 100 páginas	Especificações do PowerPoint
Repositórios privados	Código fonte aberto ou InnerSource
Hierarquia profunda da organização	Hierarquia organizacional nivelada
Os números de instalação definem o sucesso	A satisfação do usuário define o sucesso
Os recursos são enviados uma vez por ano	Recursos enviados a cada sprint

Principais aspectos a serem lembrados

• Leve a ciência Agile a sério, mas não seja prescritivo em excesso. O Agile pode se tornar muito rigoroso. Deixe a mentalidade e a cultura Agile crescerem.
• Comemore resultados, não atividades. A implantação da funcionalidade supera as linhas de código.
• Envie a cada sprint para estabelecer um ritmo e cadência e enxergar todo o trabalho que precisa ser feito.
• Crie a cultura que você quer para obter o comportamento que você está procurando.