Microsoft

DevOps Dojo InnerSource Estudo de caso

Resumo

Quando feito corretamente, InnerSource é uma das formas mais eficazes de liberar valor preso na empresa. InnerSource não é apenas para código fonte, pode ser usado para qualquer conteúdo, incluindo vendas, pré-vendas, marketing, solução, entrega ou educação em sua organização.

Microsoft vem praticando InnerSource dentro dos grupos de produtos para desenvolver código por mais de 5 anos com bolsões iniciais de colaboração entre equipes em código alcançando muitos mais anos. Na sequência dos esforços de colaboração, o DevOps Dojo dentro do Microsoft Professional Services é um dos grupos mais recentes para usar InnerSource, desta vez, para criar conteúdo colaborativamente.

Leia para aprender como Microsoft DevOps Dojo usou InnerSource para ajudá-los:

• Resolva o problema. de ter muitas cópias divergentes de conteúdo voltado para o cliente, em vez de criar uma “fonte única de verdade” para os recursos usados na entrega de suas masterclasses DevOps
• Empoderar uma comunidade global de profissionais DevOps e consultores Microsoft para se envolver na co-criação dos ativos, assíncrona, auxiliar ao seu trabalho diário
• Habilitar membros da equipe para Incorpore o feedback do cliente para melhorar o conteúdo ao vivo com os clientes e ter propagado rapidamente para toda a organização
• Crescer habilidades Em comunicação, documentação e construção comunitária que levou à realização pessoal, sucesso profissional, e promoções
• Construir profundo e duradouro pessoal conexões em todo o mundo.

Contexto

A engenharia Microsoft sofreu uma enorme transformação nos últimos anos, desde um ano até o lançamento de um software embalado em 2014, até a implantação para produção 82.000 vezes por dia em 2019, e hoje 5,6M vezes por mês. Os clientes naturalmente perguntavam: “Como isso aconteceu?” e “Qual é o molho secreto nos bastidores?” Um grupo dentro do Microsoft Professional Services (agora chamado Microsoft Industry Solution) decidiu enfrentar este desafio e compartilhar os aprendizados da Microsoft de praticar InnerSource com conteúdo diretamente entregue aos clientes. A iniciativa DevOps Dojo começou no início de 2019. DevOps Dojo é uma comunidade de prática em Microsoft. Começou com um pequeno grupo de voluntários da organização de serviços, depois expandiu para o sucesso do cliente, consultoria digital, grupos de produtos e outras organizações. Toda participação é voluntária e acontece ao lado de suas prioridades de trabalho. É uma comunidade onde equipes interfuncionais praticam princípios ágeis, contínuos de colaboração e automação da DevOps para encontrar o melhor caminho para entregar software de ideia para produção com qualidade. Ele inclui um conjunto diversificado de participantes através de papéis, níveis de experiência e geografias, todos trabalhando para aprender juntos e compartilhar esses aprendizados com os clientes da Microsoft.

Problemas a serem resolvidos

Quando DevOps Dojo começou o IP interfuncional era fonte fechada. Isso era um problema. As equipes estavam trabalhando com tecnologias que tinham acabado de sair, com ferramentas que ainda estavam em beta. O conteúdo central estava sendo atualizado pelos Grupos de Produtos em uma base contínua. Links para recursos e relatórios tinham que ser atualizados regularmente.

Cada membro do Dojo muitas vezes criava sua própria cópia local para personalizar ou atualizar para clientes. Havia uma proliferação de versões do conteúdo, cada uma ligeiramente diferente uma da outra: não havia uma “fonte única de verdade”. Atualizações globais não poderiam ser facilmente emitidas, e o feedback do cliente ficou com o membro do Dojo mais próximo do cliente.

Michael Watson, arquiteto da Microsoft, elaborou sobre a questão: “DevOps Dojo é uma colaboração de mais do que apenas pessoal Microsoft. Estávamos reunindo pessoas para falar sobre esse assunto. Mesmo que tivéssemos um ponto de vista, muitas das pessoas com quem nos engajamos tinham anos de experiência. Queríamos aprender um com o outro e manter-nos atualizados com o que estava acontecendo na indústria.”

Enquanto contemplava o problema, um dos membros do Dojo, Alvaro Guadamillas, lembrou: “Eu vi tanto conteúdo incrível criado pela comunidade DevOps Dojo que desde o primeiro dia eu senti a necessidade de tornar esse conteúdo tão aberto a todos quanto possível. Depois de dois meses na comunidade Dojo, senti confiança suficiente para compartilhar uma ideia: por que não tornar o conteúdo do DevOps Dojo InnerSource? Por que não aplicamos o Pull Requests à criação do conteúdo e colaboramos em escala para ter o mais recente e maior conteúdo disponível para todos na Microsoft? Por que não evitamos ter várias cópias da mesma apresentação distribuídas em todos os lugares e ter uma única fonte de verdade em vez disso?” Em um evento masterclass do Dojo em Xangai, Álvaro encontrou-se com alguns dos outros membros da equipe principal e sugeriu a abordagem. Olhando para como ele enfrentou seus desafios e reconhecendo que havia uma comunidade global InnerSource que já existia para ajudá-los em sua jornada, foi acordado que eles iriam experimentar com uma abordagem InnerSource. Considerando o impacto cultural de InnerSource, a equipe decidiu pilotar InnerSource primeiro em um subconjunto da solução DevOps Dojo. Com o apoio da comunidade Dojo, incluindo a equipe de engenharia Azure DevOps, e a experiência da GitHub, eles criaram o primeiro piloto InnerSource em Serviços Profissionais Microsoft.

Fundações e Implementação

Um dos primeiros passos que a equipe deu foi obter alguns conselhos especializados para ajudá-los em sua jornada. Eles chamaram Natalie Bradley da GitHub que tinha experiência significativa em trabalhar com organizações para ajudá-los em sua jornada InnerSource. Com a ajuda de Natalie, a equipe começou a conseguir todas as políticas e processos apropriados para ajudar a equipe. Todo o conteúdo foi armazenado como arquivos de marcação em GitHub e o Dojo comunicou dia a dia através dos canais da Comunidade em Microsoft Teams.

Figura 1: InnerSource no Dojo DevOps em Microsoft

A equipe se focou em oferecer uma experiência perfeita para os contribuintes. Eles também cuidaram de fornecer clareza de governança, incluindo nomear quem era responsável por cada área, e como resolveriam quaisquer disputas que possam surgir.

Desde o primeiro dia, a equipe sabia que seria essencial ser capaz de rastrear e celebrar ambas as contribuições e o uso de sua produção. Portanto, a configuração inicial também incluiu métricas em torno de downloads, bem como rastreamento do número e fonte de pedidos de pull.

Ao projetar o DevOps Dojo, a equipe não pensou no Dojo simplesmente como um programa de curto prazo. Eles acreditavam que o Dojo era um programa de transformação tanto para o campo interno Microsoft quanto para os clientes do Microsoft. Eles adotaram um modelo centrado em produtos através de um processo e abordagem de produto “lean”. Você pode descobrir mais detalhes sobre a abordagem do produto magro noDevOps Dojo blog.

Uma única fonte da verdade – Entregue

Em alguns meses, a equipe inicial tinha um produto viável mínimo (MVP) funcionando. O conteúdo das masterclasses estava sendo entregue à comunidade de uma forma que estava constantemente atualizada. Os laboratórios e as instruções para a entrega do laboratório foram criados e atualizados da mesma forma.

Como Harleen Kaur, consultor técnico da Microsoft, descreveu: “Como treinador, eu me prepararia para cada sessão, e se eu visse um link ou referência que precisava ser mudado, meu primeiro instinto era fazer isso no site, então todos se beneficiariam com a mudança. Eu pude fazer isso no momento. Se eu não pudesse, poderia ter esquecido de voltar mais tarde para fazê-lo.”

A equipe central começou então a realizar sessões regulares para ajudar a espalhar a notícia. Eles mostraram o conteúdo que estava disponível, e como a equipe poderia usá-lo, ou ainda melhor, contribuir para isso. Eles fizeram role-play ao vivo para demonstrar como os vários papéis InnerSource funcionaram, e até mesmo ao vivo edições para o conteúdo em chamadas para que as pessoas pudessem ver como o processo de revisão e aprovação funcionou e como foi fácil. Através desse processo eles também estavam identificando diferentes desafios e experiências para incorporar.

Participação e contribuições logo se espalharam pelo mundo. O Dojo atualmente tem várias unidades de negócios trabalhando juntas em 36 países para entregar o mais recente e preciso conteúdo aos clientes da Microsoft.

Deep Mehta, Consultora de Tecnologia da Microsoft compartilhou: “Reuso IP é algo que sempre quisemos fornecer, mas no passado, foi um desafio. InnerSource nos ajudou a entregar isso. Além disso, encorajamos aqueles que reutilizam o conteúdo para ajudar contribuindo de volta. InnerSource também ajuda a rede com pessoas ao redor da organização. Você conhece os contribuintes, aprende com eles. Esse é um grande ponto positivo.”

Dave McKinstry, Microsoft do DevOps FastTrack Manager, acrescentou: “O que eu notei de uma perspectiva de engenharia, é que quando você abre seu código fonte, a qualidade inerentemente sobe. As pessoas querem melhorar as coisas.”

Inovação Ativada

À medida que o uso do conteúdo DevOps Dojo aumentava, a equipe percebeu que ferramentas adicionais poderiam ajudar os usuários a conhecer o conteúdo. Eles foram inspirados a implementar um Chatbot QnA para melhorar a experiência para os usuários do conteúdo.

O chatbot permite que a comunidade do Dojo pergunte qualquer coisa em seu canal comunitário de Equipes apoiado por AI bots e QnA Maker (um serviço cognitivo Azure). Além de fornecer respostas em tempo real com suporte de linguagem, a solução organicamente melhora as perguntas e respostas da comunidade. Integrada com poderosas capacidades de IA, a solução foi projetada para ajudar Dojos a obter respostas relacionadas ao conteúdo, prontidão, ofertas e entrega do Dojo rapidamente em um estilo conversacional em equipes Microsoft.

Uma vez definidos os requisitos e a equipe tinha uma boa compreensão da arquitetura de integração, eles começaram a implementação através do InnerSource. O QnA Bot foi a público na Microsoft como planejado. Todas as melhorias e contribuições acontecem através de um processo InnerSource e podem rapidamente fazer efeito através de tubulações de automação.

Yue Sheng, que trabalhou na IA Chatbot fora de suas principais responsabilidades de trabalho, compartilhou: “Você tem mentores, professores e amigos aqui. Tudo é um processo bidirecional. Estamos sempre tentando novas inovações. Recebo novas coisas interessantes através do processo.”

Como observou Kan Tang, um dos líderes do DevOps Dojo: “Na Microsoft, cada um de nós tem seu foco de trabalho. Às vezes você vê algo que quer tentar fora de suas responsabilidades. As pessoas vêm para DevOps Dojo, e têm autonomia para experimentar e inovar. “

Aprendendo através de InnerSource

Através de sua prática do InnerSource, a comunidade Dojo também notou que publicar seu conteúdo através do InnerSource criou uma maravilhosa oportunidade de aprendizagem. InnerSource requer que uma equipe capture e documente tudo para que a equipe possa colaborar assíncrona e não confiar em estar perto um do outro. Como a equipe observou: escrever te faz pensar, pensar te faz refletir, refletir te faz deliberar, deliberar te faz aprender mais profundamente.

“Em nossa escrita, constantemente desafiamos uns aos outros, aprendemos uns com os outros, e iteramos coletivamente”, comentou Kitty Chiu, Arquiteta DevOps na GitHub.

Para mim, o que me fez entrar na equipe foi o conceito de compartilhar conteúdo e aprender de diferentes partes do mundo e papéis diferentes. Sempre compartilhamos ideias e pontos de vista diferentes. É um verdadeiro enriquecimento, uma conversa que trouxe muito valor”, compartilhou Giulia Cupani, Gerente do Programa Azure.

Conexões mundiais

A equipe DevOps Dojo é distribuída pelo mundo. Isso apresenta muitos desafios, como restrições de fuso horário, não permitindo que toda a equipe se encontre. Kitty Chiu, baseada na Austrália, descreveu como o processo InnerSource e foco na criação de conteúdo permitiu que eles se engajassem perfeitamente no processo: “Antes da pandemia, a cultura Microsoft geralmente envolvia reuniões presenciais. Isso foi um desafio se você estiver trabalhando em um fuso horário diferente. Muitas vezes tínhamos que voar para Seattle para colaborar em projetos como este. Quando a pandemia Covid-19 atingiu, a noção de comunicação assíncrona tornou-se a norma. InnerSource foi onde as conversas começaram. Margarita Sanz, DevOps e Cloud Consultant na Microsoft, também compartilharam como InnerSource permitiu que a equipe desenvolvesse um propósito comum em toda a equipe global: “Nunca vi pessoas mais comprometidas com um objetivo do que essa equipe. A equipe foi da China para Madri, passando pela Índia e Suíça, para vários fusos horários nos EUA, etc. Diferentes fusos horários, línguas diferentes, e origens diferentes, mas o mesmo objetivo, e acima de tudo, a mesma CULTURA.”

Cliente Primeiro

Microsoft muitas vezes fala sobre uma cultura “primeiro cliente”. Neste caso, a equipe DevOps Dojo demonstrou como tomar uma abordagem InnerSource para a criação de seu conteúdo não só garantiu que seu cliente recebesse o mais recente e atualizado conteúdo, mas também permitiu que o cliente se envolvesse no processo de atualização.

As equipes entregam suas masterclasses diretamente aos clientes. Paul Fijnvandraat, consultor principal da Microsoft, compartilhou que se um cliente tivesse feedback ou uma pergunta a ser respondida (em pré-vendas ou entrega), ele criou um pedido de pull para ter a pergunta e resposta adicionadas ao conteúdo do Dojo DevOps. Dessa forma, o feedback do cliente se propagava para toda a organização quase imediatamente.

Impacto para a equipe

O DevOps Dojo oferece valor significativo para Microsoft e seus clientes. No entanto, ao falar com a equipe DevOps Dojo, um benefício adicional é o incrível impacto sobre os participantes individuais.

Muitos membros do Dojo foram formalmente recompensados e promovidos por causa de seu enorme sucesso, mas parece que a maior recompensa de todas foi ainda mais pessoal. Aqueles no Dojo relataram que eles tinham forjado relacionamentos próximos entre regiões e níveis de experiência, que eles construíram novas habilidades e tiveram experiências de aprendizagem incríveis. Margarita Sanz descreveu:

“Eu sei que encontrar uma equipe onde você se sinta apoiado, e valorizado não é fácil, e mesmo que o caminho nem sempre tenha sido suave, eu andaria novamente sem dúvida. Não éramos uma equipe, éramos amigos, éramos família trabalhando lado a lado apoiando um ao outro. No dia em que me juntei ao Dojo, senti que estava me juntando a uma nova família. Hoje eu me desenvolvo, aprendo, e fico de mãos dadas com todos eles, e eu não poderia estar mais orgulhoso e animado com o futuro que está por vir.”Conforme descrito por Kan Tang:O que ganhamos com essa experiência? Tremendo aprendizado e crescimento, novas oportunidades, felicidade, autoconfiança e amizades ao longo da vida!

Planos futuros

Hoje, o conteúdo DevOps Dojo é continuamente melhorado pela comunidade, eles têm uma única fonte de verdade com o mais recente e maior conteúdo, e a equipe pode colaborar em uma escala, a qualquer momento e em qualquer lugar do mundo. Eles viram a adoção do conteúdo DevOps Dojo crescer mês após mês e começaram a ver contribuições começarem de outras regiões do mundo. O grupo está ansioso para estender as práticas DevOps Dojo e InnerSource dentro do Microsoft e talvez até começar o processo de fornecimento aberto do conteúdo DevOps Dojo para o mundo!“Temos mais de 80 mil engenheiros trabalhando em código na Microsoft, e estamos constantemente avaliando o que seria interessante para compartilhar abertamente com nossos clientes. InnerSource nos permitiu desbloquear esse potencial, reduzir a redundância e colaborar de forma mais eficaz.”Arno Mihm, Diretor do Programa InnerSource @ Microsoft.

Agradecimentos

Este estudo de caso foi escrito por Clare Dillon, Diretor Executivo da InnerSource Commons, Daniel Izquierdo, CEO Bitergia & Diretor da InnerSource Commons, e Dr. Klaas-Jan Stol, diretor da InnerSource Commons, após uma série de entrevistas com as equipes DevOps Dojo na Microsoft.

Clare observa: “Compartilhar histórias sobre nossas jornadas InnerSource é uma parte importante da comunidade InnerSource Commons. Gostaríamos de enviar um enorme obrigado a todas as pessoas maravilhosas em Microsoft e GitHub que tiveram tempo para compartilhar suas experiências e nos ajudar a gravar este estudo de caso:

• Deep Mehta – Consultor de Tecnologia, Azure Cloud & AI, Microsoft Índia
• Margarita Sanz – DevOps e consultor de nuvem, Microsoft Espanha
• Álvaro Guadamillas – Gerente de Programa de Negócios, Azure Cloud & AI, Microsoft Espanha
• Michael Watson – Arquiteto, Microsoft Austrália
• Yue Sheng – Consultor, Azure Cloud & AI, Microsoft China
• Kitty Chiu – Arquiteto sênior DevOps, GitHub, Austrália
• Harleen Kaur – Entrega Técnica – Segurança da Informação & DevOps, Microsoft Índia
• Dave Burnison, advogado técnico sênior, GitHub, EUA
• Karl Pitteira – Diretor do Grupo PM, Microsoft, EUA
• Jeff Wilcox, diretor da PM, Microsoft, EUA
• Natalie Bradley – Diretora, Arquitetos de Sucesso de Clientes, GitHub, EUA
• Dave McKinstry – Gerente, DevOps Programa FastTrack, GitHub, EUA
• Paul Fijnvandraat – Consultor Principal, Microsoft Holanda
• Chris Witte, consultor sênior, Microsoft US
• Jihee Choi – Consultor, Microsoft US
• Nicolas Mays, consultor da ASSC, Microsoft US
• Geoff Sexton, consultor sênior, EUA.
• Giulia Cupani – Gerente de Programa Azure, Microsoft Suíça
• Aakanksha Lnu – Consultoria Gerente de Produto, Microsoft, Reino Unido
• Beste Altinay – Arquiteto ASSC, Microsoft Holanda
• Rui Melo – Arquiteto, Microsoft, PORTUGAL
• Nithyanathan R – Arquiteto ASSC, Microsoft Índia
• Charlie Gu – Arquiteto, Microsoft, China
• Harry Chen – Arquiteto, Microsoft, EUA
• Bahram Rushenas – Arquiteto, Microsoft, EUA
• Garry Trinder, advogado sênior da nuvem, Microsoft, Reino Unido
• Kan Tang – Gerente de Arquiteto, Linha de Serviço de Mercadorias de Varejo e Consumidores, EUA
• Arno Mihm – Gerente de Programa Principal, InnerSource @Microsoft, EUA

Para mais informações ou para obter mais detalhes, junte-se à comunidade InnerSource Commons Slack para iniciar uma conversa. Você também pode verificar oDevOps posts do Dojo(Todos criados pela equipe usando Markdown através de um processo InnerSource)

Se você gostaria de compartilhar sua história InnerSource, por favor, entre em contato conosco noinfo@innersourcecommons.org.