Como a Microsoft planeja com o DevOps

A Microsoft é uma das maiores empresas do mundo a usar metodologias agile. Ao longo de anos de experiência, a Microsoft desenvolveu um processo de planejamento de DevOps que é dimensionado dos menores projetos 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.

Alterações instrumentais

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

• Promover o alinhamento cultural e a autonomia.
• Altere o foco de indivíduos para equipes.
• Crie novas estratégias de planejamento e aprendizado.
• Implemente um modelo de várias equipes.
• Aprimore as práticas de saúde do código.
• Promover transparência e responsabilidade.

Promover o alinhamento cultural e a autonomia

Peter Drucker disse: "A cultura come estratégia no café da manhã." Autonomia, domínio e finalidade são motivações humanas fundamentais. A Microsoft tenta fornecer esses motivadores a PMs, desenvolvedores e designers para que eles se sintam capacitados a criar produtos bem-sucedidos.

Dois colaboradores importantes 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 metas de negócios mais amplas.
• A autonomia ocorre de baixo para cima, para garantir que indivíduos e equipes tenham um impacto nas atividades e decisões diárias.

Há um equilíbrio delicado entre alinhamento e autonomia. Muito alinhamento pode criar uma cultura negativa onde as pessoas atuam apenas como lhes é dito. Muita autonomia pode causar falta de estrutura ou direção, tomada de decisão ineficiente e mau planejamento.

Alterar 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 características principais:

• Multidisciplinar
• 10-12 pessoas
• Autogerenciamento
• Carta clara e metas para 12-18 meses
• Salas de equipe físicas
• Implantação de funcionalidades próprias
• Funcionalidades próprias em produção

Esforce-se para formar equipes verticais

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

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

Permitir equipes de seleção autônoma

A cada dezoito meses, a Microsoft realiza um "exercício de planejamento com post-its", em que os desenvolvedores podem escolher as áreas do produto nas quais desejam trabalhar nos próximos dois períodos de planejamento. Este exercício fornece autonomia, pois as equipes podem escolher no que trabalhar e 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.

Criar novas estratégias de planejamento e aprendizagem

Dwight Eisenhower disse: "Os planos são inúteis, mas planejar é tudo." O planejamento da Microsoft se divide na seguinte estrutura:

• Sprints (3 semanas)
• Planos (3 sprints – períodos de trabalho ágil)
• Estações (6 meses)
• Estratégias (12 meses)

Engenheiros e equipes são responsáveis principalmente por sprints e planos. A liderança é responsável principalmente pelos tempos 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 podem obter comentários, descobrir o que os clientes querem e implementar solicitações de clientes de forma rápida e eficiente.

Implementar um modelo de várias equipes

Os métodos anteriores promoveram uma "cultura de interrupção" de bugs e incidentes em tempo real. As equipes da Microsoft criaram sua própria maneira de fornecer foco e evitar distrações. As equipes se organizam automaticamente para cada sprint em duas equipes distintas: Recursos (equipe F) e Cliente (equipe C).

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

Aprimorar as práticas de saúde do código

Antes de mudar para as 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. Em seguida, o Teams descobriu bugs e trabalhou para corrigi-los. Essa prática criou uma montanha-russa de bugs, que afetava a moral e a produtividade da equipe quando as equipes tinham que trabalhar em correções de bugs em vez de implementar novos recursos.

O Teams agora implementa um limite de bug, 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, ela deverá parar de trabalhar em novos recursos e corrigir bugs até que eles estejam sob seu limite. As equipes agora pagam dívidas de bugs conforme avançam.

Promover transparência e responsabilidade

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

Objetivos e principais resultados (OKRs)

As equipes são mais eficazes quando estão claras sobre as metas que a organização está tentando alcançar. A Microsoft fornece clareza para as equipes por meio de objetivos e principais resultados (OKRs).

• Os objetivos definem as metas a serem alcançadas. Os objetivos são significativos, concretos, orientados à ação e instruções de intenção idealmente inspiradoras. Os objetivos representam grandes ideias, não números reais.
• Os principais resultados definem etapas para alcançar os objetivos. Os principais resultados são resultados quantificáveis que avaliam o progresso e indicam êxito 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. Pressionar as equipes para buscar resultados importantes 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 ter um desempenho melhor pelos seguintes motivos:

• Todas as equipes estão alinhadas ao plano.
• As equipes se concentram em alcançar resultados em vez de concluir atividades.
• Cada equipe é regularmente responsável por seus esforç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 OKRs alinhados é relativamente fácil, especialmente se os objetivos forem definidos de cima para baixo. Todos os conflitos que surgem são indicadores iniciais valiosos de desalinhamento organizacional.

Exemplo de OKR

Objetivo: aumentar uma base de clientes forte e feliz.

Principais resultados:

• Aumentar a pontuação de promotor de rede externo (NPS) de 21 para 35.
• Aumente a satisfação dos documentos de 55 para 65.
• O novo fluxo de pipeline 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 os resultados dos negócios usando objetivos e resultados importantes.

Selecione as métricas corretas

Os principais resultados são tão úteis quanto as métricas em que se baseiam. A Microsoft usa indicadores principais que se concentram na alteração. Com o tempo, essas métricas criam um quadro geral de aceleração ou desaceleração do produto. A Microsoft geralmente usa as seguintes métricas:

• Alteração na taxa de crescimento mensal da adoção
• Alteração no desempenho
• Alteração no tempo de aprendizado
• Alteração na frequência de incidentes

As equipes evitam métricas que não geram valor para os objetivos. Embora possam ter determinados usos, as seguintes métricas não são úteis para acompanhar o progresso em direçã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.

Principais conclusões

• Leve a ciência agile a sério, mas não seja excessivamente prescritivo. Agile pode se tornar muito rigoroso. Permita que a mentalidade e a cultura agile cresçam.
• Celebre os resultados, não a atividade. A implantação da funcionalidade supera as linhas de código.
• Envie em cada sprint para estabelecer um ritmo e cadência e encontrar todo o trabalho que precisa ser feito.
• Crie a cultura desejada para obter o comportamento que você procura.