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.
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.
Aprenda com a equipe da Web do Space Game como usar os Painéis do Azure para implementar práticas de software Agile, juntamente com transparência e colaboração de DevOps.
Esta certificação mede sua capacidade de realizar as seguintes tarefas técnicas: projetar e implementar processos e comunicações, projetar e implementar uma estratégia de controle de origem, projetar e implementar pipelines de construção e liberação, desenvolver um plano de segurança e conformidade e implementar uma estratégia de instrumentação.
Saiba como o Scrum implementa os princípios Agile como um conjunto de artefatos, práticas e funções. As equipes podem usar o Scrum para gerenciar seu trabalho.
Saiba mais sobre os princípios de eficiência do fluxo de trabalho Kanban e como as equipes de software podem usar o acompanhamento Kanban e os quadros para aumentar o fluxo e a taxa de transferência.
