Como a Microsoft planeja o DevOps

A Microsoft é uma das maiores empresas do mundo a utilizar metodologias ágeis. Ao longo de anos de experiência, a Microsoft desenvolveu um processo de planejamento de DevOps que pode ser dimensionado desde os projetos menores até esforços maciços 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 instrumentais

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

• Promover o alinhamento cultural e a autonomia.
• Mude o foco dos indivíduos para as equipas.
• Crie novas estratégias de planeamento e aprendizagem.
• Implementar um modelo com várias equipas.
• Melhorar as práticas de integridade do código.
• Promover a transparência e a responsabilização.

Promover 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 motivações humanas fundamentais. A Microsoft tenta fornecer esses motivadores para PMs, desenvolvedores e designers para que eles se sintam capacitados a criar produtos de sucesso.

Dois fatores importantes que contribuem para esta 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 os indivíduos e as equipas têm impacto nas atividades e decisões do dia-a-dia.

Existe um equilíbrio delicado entre alinhamento e autonomia. O excesso de alinhamento pode criar uma cultura negativa em que as pessoas se comportam apenas como lhes é dito. O excesso de autonomia pode causar falta de estrutura ou direção, tomada de decisão ineficiente e planejamento deficiente.

Mude o foco dos indivíduos para as equipas

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

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

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

• Interdisciplinar
• 10-12 pessoas
• Autogestão
• Carta clara e metas para 12-18 meses
• Salas físicas de equipa
• Implantação de funcionalidades próprias
• Características próprias em produção

Lute por equipes verticais

As equipes da Microsoft costumavam ser horizontais, cobrindo toda a interface do usuário, todos os dados ou todas as APIs. Agora, Microsoft esforça-se por equipes verticais. As equipas são responsáveis pelas suas áreas do produto de ponta a ponta. Diretrizes rígidas em determinados níveis garantem a uniformidade entre as equipes em todo o produto.

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

Permitir a autoseleção de equipas

A cada 18 meses, a Microsoft realiza um "exercício adesivo amarelo", na qual os desenvolvedores podem escolher em quais áreas do produto desejam trabalhar nos próximos períodos de planeamento. Este exercício proporciona autonomia, pois as equipas podem escolher no que trabalhar, e alinhamento organizacional, uma vez que promove o equilíbrio entre as equipas. Cerca de 80% das pessoas neste exercício permanecem em suas equipes atuais, mas se sentem empoderadas porque tiveram uma escolha.

Criar novas estratégias de planeamento e aprendizagem

Dwight Eisenhower disse: "Os planos não valem nada, mas o planeamento é tudo." O planejamento da Microsoft se divide na seguinte estrutura:

• Sprints (3 semanas)
• Planos (3 sprints)
• Estações (6 meses)
• Estratégias (12 meses)

Engenheiros e equipes são os principais responsáveis por sprints e planos. A liderança é a principal responsável pelas estações 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.

Implementar um modelo multi-tripulação

Os métodos anteriores fomentavam uma "cultura de interrupção" de bugs e incidentes em sites ao vivo. As equipes da Microsoft criaram sua própria maneira de fornecer foco e evitar distrações. As equipas auto-organizam-se para cada sprint em duas equipas distintas: Características (F-crew) e Cliente (C-crew).

A equipe F-crew trabalha em funcionalidades comprometidas, e a equipe C-crew lida com problemas em sites ativos e interrupções. 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 tripulações, consulte Crie equipes produtivas e focadas no cliente.

Melhorar as práticas de integridade do código

Antes de mudar para metodologias ágeis, as equipes costumavam deixar que bugs de código se acumulassem até que o código fosse concluído no final da fase de desenvolvimento. As equipes então 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 equipa exceder o limite de bugs no final de um sprint, devem parar de trabalhar em novas funcionalidades e resolver bugs até que estejam abaixo do limite. As equipes agora pagam dívidas de bugs à medida que avançam.

Promover a transparência e a responsabilização

No final de cada sprint, cada equipe envia um e-mail relatando o que realizou no sprint anterior e o que planeja fazer no próximo sprint.

Objetivos e principais resultados (OKRs)

As equipas são mais eficazes quando têm clareza dos objetivos que a organização está a tentar alcançar. A Microsoft fornece clareza para as equipes por meio de objetivos e resultados-chave (OKRs).

• Os objetivos definem as metas a atingir. Os objetivos são significativos, concretos, orientados para a ação e, idealmente, declarações de intenções inspiradoras. Os objetivos representam grandes ideias, não números reais.
• Os resultados-chave definem as etapas para alcançar 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 período de tempo específico.

Os OKRs refletem os melhores resultados possíveis, não apenas os resultados mais prováveis. Os líderes tentam ser ambiciosos e não cautelosos. Incentivar 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 OKR pode ajudar as equipes a terem um melhor desempenho pelos seguintes motivos:

• Todas as equipas estão alinhadas com o plano.
• As equipas concentram-se em alcançar resultados em vez de concluir atividades.
• Cada equipa é responsável pelos esforços numa base regular.

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, especialmente se os objetivos forem definidos de cima para baixo. Quaisquer conflitos que surjam são valiosos indicadores iniciais de desalinhamento organizacional.

Exemplo de OKR

Objetivo: Aumentar uma base de clientes forte e feliz.

Principais resultados:

• Aumentar a pontuação líquida de promotores (NPS) externa de 21 para 35.
• Aumente 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. Com o tempo, essas métricas criam 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
• Alteração no desempenho
• Mudança na hora de aprender
• Alteração da frequência dos incidentes

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

• Exatidão das estimativas originais
• Horas cumpridas
• Linhas de código
• Capacidade da equipa
• Burndown da equipe
• Velocidade da equipa
• 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 ágeis.

Principais conclusões

• Leve a ciência ágil a sério, mas não seja excessivamente prescritivo. Agile pode tornar-se demasiado rigoroso. Deixe a mentalidade e a cultura ágeis crescerem.
• Celebre os resultados, não a atividade. A implantação da funcionalidade supera as linhas de código.
• Envie entregas a cada sprint para estabelecer um ritmo consistente e uma cadência e identificar todo o trabalho necessário.
• Constrói a cultura que tu queres para alcançar o comportamento desejado.