Medir o impacto do GitHub Copilot
O Copilot ajuda os desenvolvedores a escrever códigos melhores, mais rápido e com mais entusiasmo. Estamos aprendendo continuamente, junto com nossos clientes e parceiros, como medir esse impacto. Por exemplo, tanto o GitHub quanto pesquisadores externos observaram o impacto positivo em experimentos controlados e estudos de campo onde o Copilot conferiu:
Conclusão de tarefa 55% mais rápida usando o texto preditivo.
Melhorias de qualidade em 8 dimensões (por exemplo, legibilidade, livre de erros, capacidade de manutenção).
Muitas empresas fazem uma pergunta bastante razoável: “Como posso saber se o Copilot está conferindo esses benefícios à minha equipe?”. Para responder a essa pergunta, nós vamos detalhar a seguir uma estrutura para avaliar o impacto em quatro fases.
Neste guia, você aprenderá:
Como avaliar o impacto do Copilot em quatro fases, da adoção inicial à eficiência sustentada.
Como usar as pesquisas com desenvolvedores e dados de telemetria como indicadores principais do impacto do Copilot nas medições em nível de sistema.
Como planejar e medir as melhorias no nível do sistema que podem resultar do GitHub Copilot.
Fases de adoção do GitHub Copilot
As duas primeiras fases, Avaliação e Adoção, concentram-se nos indicadores principais que estão mais próximos possíveis da atividade de codificação. Elas contam com uma combinação de dados autorrelatados por desenvolvedores e telemetria existente do GitHub. A utilização desta estratégia permite (a) prever de maneira confiável o impacto futuro e (b) realizar uma avaliação com relativamente pouco investimento adicional em observabilidade.
É difícil, se não impossível, medir objetivamente a produtividade do desenvolvedor. Descobrimos que muitas vezes é melhor simplesmente perguntar a eles como gastam seu tempo, quais são seus obstáculos e quais ferramentas são úteis. A grande maioria dos desenvolvedores que usam o GitHub Copilot afirmam que é uma ferramenta valiosa que eles usam pelo menos uma vez por semana, o que com certeza é suficiente para justificar nosso investimento.
À medida que entramos na terceira e quarta fases, Otimização e Eficiência Sustentada, pedimos que os líderes de engenharia integrem seus objetivos organizacionais específicos aos critérios de avaliação. Durante essas fases, o foco deve mudar para o aumento da eficiência (por exemplo, através de medições de custo/esforço, tempo de colocação no mercado e risco) e intencionalidade (por exemplo, através de medições de valor entregue).
Em todas as fases, recomendamos a medição no nível da organização ou da equipe, de preferência ao longo dos limites de um grupo de trabalho que faz commit de código para o mesmo serviço ou aplicação. Isso permite que as equipes avaliem o impacto para os desenvolvedores que realizam trabalhos semelhantes.
Agora, vamos percorrer cada uma das quatro fases, explorando os objetivos específicos, a metodologia, as métricas relevantes e os critérios para passar para a próxima fase de medição.
Avaliação
Objetivo: criar um caso técnico e de negócios para adotar/rejeitar o GitHub Copilot em grande escala.
Metodologia: avaliar os principais indicadores de impacto (próximos à atividade de codificação) por meio de pesquisas com desenvolvedores e medições de envolvimento dos usuários.
Métricas relevantes (consulte o glossário): Satisfaction using Copilot
, Benefits of using Copilot
, Challenges of using Copilot,
Enablement provided
, Average daily active users per month - completions
, Average daily active users - chat
, Average daily active users - total
, Suggestions delivered - completions
, Number of acceptances - completions
, Lines of code accepted - completions
, Total acceptance rate - completions
Critério de saída: >40% dos participantes ativos do teste ficariam “muito decepcionados” se perdessem o acesso ao Copilot (veja a pesquisa).
Durante a avaliação, a maioria das organizações deseja simplesmente determinar: o GitHub Copilot vale uma implantação em escala?
Em última análise, a maioria das equipes deseja apenas fornecer um bom software com rapidez e segurança. Porém, coisas como tempo de colocação no mercado, custo de entrega, postura de segurança e retenção de talentos são indicadores atrasados que levam tempo para serem avaliados. Além disso, estes indicadores de atraso também podem ser influenciados por fatores externos, como mudanças na equipe, prioridades de negócios, desafios técnicos etc.
Portanto, recomendamos considerar os indicadores principais antes de adicionar novas métricas ao seu ROI e scorecards de engenharia. Esses indicadores principais devem incluir uma combinação de dados autorrelatados de pesquisas de engenharia e telemetria existentes do GitHub.
Ferramentas e recursos
Pesquisas de desenvolvedores: há uma ampla pesquisa mostrando que os desenvolvedores são especialistas no domínio, capazes de avaliar a relação entre ajuda e danos em seu próprio toolchain. Confiamos nos desenvolvedores para avaliar de forma crítica o impacto do GitHub Copilot em seu próprio trabalho. Felizmente, as pesquisas são relativamente fáceis de realizar, uma vez que também servem como um precursor rápido e confiável do impacto futuro. As perguntas em nossa Pesquisa para Desenvolvedores do GitHub Copilot fornecem insights sobre como o Copilot ajudou, quais são as suas deficiências e para que é usado.
Dados de envolvimento do usuário: além das respostas da pesquisa, a API Copilot Metrics e a API Copilot User Management fornecem medições relacionadas de como seus desenvolvedores estão usando o Copilot. Medições como
Average Daily Active Users
eTotal Acceptance Rate
podem ajudar a identificar onde é necessária maior capacitação de sua equipe.
Adoção
Objetivo: as equipes alvo estão habilitadas e usando ativamente o GitHub Copilot.
Metodologia: continuar focando em indicadores principais e indicadores de capacitação. Pode haver sinais precoces de impactos mais amplos no sistema.
Métricas relevantes (consulte o glossário): todas as medições da fase de Avaliação, mais New seats added in billing cycle
, Dormant users
, Total completed pull requests
, Pull requests per developer
, Time to merge
, PR lead time
, Average code review time in hours
, Pull request merge rate
, Total successful builds
, Change failure rate
, CI success rate
, Open security vulnerabilities
Critério de saída: >80% das licenças comprometidas são atribuídas e estão ativas com impacto neutro ou melhor nas métricas no nível do sistema.
À medida que você expande o uso do Copilot em sua organização, além de observar as medições usadas durante a avaliação, considere usar o Billing and Plans Dashboard (Painel de cobrança e planos do Copilot) para entender onde pode ser necessária capacitação adicional.
Insight: a pesquisa da Microsoft descobriu que pode levar 11 semanas para que os usuários percebam totalmente a satisfação e os ganhos de produtividade com o uso de ferramentas de IA.
No estudo controlado randomizado (RCT) do Microsoft Copilot Impact 2022-2023, o grupo de tratamento (desenvolvedores com acesso ao Copilot) experimentou um aumento bruto de adoção de 26,4% em duas semanas, quando receberam e-mails de lembrete de habilitação.
Ferramentas e recursos
As seguintes ferramentas e recursos oferecem suporte para a capacitação durante a fase de Adoção e capacitam os engenheiros de teste durante a fase de Avaliação:
Microsoft Learn: GitHub Copilot : cursos gratuitos sobre como usar o GitHub Copilot.
Introdução ao GitHub Copilot: tutoriais em vídeo para começar a usar o VS Code.
Discussões sobre o Copilot na comunidade GitHub: ótimo recurso para administradores e desenvolvedores campeões, com muitas informações e dicas valiosas.
Documento do GitHub Copilot: documentos que abrangem tudo, da introdução até a solução de problemas e melhorias de recursos.
Se você não observar altos níveis de adequação do produto em suas respostas de pesquisa e medições de API, recomendamos o uso de entrevistas de acompanhamento para entender quaisquer desafios que os engenheiros possam enfrentar e para oferecer mais capacitação.
Executar suas próprias pesquisas com desenvolvedores ajudará você a aprender e melhorar seus esforços de engenharia, mas primeiro você deve considerar sua motivação. Por exemplo, temos três objetivos principais: avaliar a satisfação geral com as ferramentas do desenvolvedor, priorizar quais pontos problemáticos devem ser abordados e registrar nossa eficácia ao lidar com eles. Essas metas orientam as perguntas que fazemos.
Da mesma forma, é melhor envolver uma variedade de partes interessadas em suas perguntas. Trabalhamos com cientistas de dados da equipe de insights e pesquisa de talentos da Shopify, diretores e vice-presidentes de diferentes departamentos e vários especialistas no assunto para criar e refinar nossas perguntas.
A fadiga das pesquisas pode ser um problema real, por isso tentamos manter nossas pesquisas breves. Nossas grandes pesquisas semestrais com desenvolvedores levam de 15 a 20 minutos para serem concluídas e, mesmo assim, só as enviamos para metade da empresa de uma vez, para que eles não precisem respondê-las novamente. Também tentamos manter as pesquisas relativamente simples, muitas vezes contando com o método de concordância com 5 pontos, em que os participantes avaliam uma afirmação em uma escala de 1 a 5.
A maioria das organizações busca continuamente melhorar a produtividade e a eficácia de seus desenvolvedores. É possível observar melhorias nas medições que já fazem parte do scorecard de engenharia da sua equipe (por exemplo, prazo de entrega de relações públicas, pontos da história, taxa de falha de mudança), mas elas não devem ser o foco desta fase. Em vez disso, concentre-se em gerenciar mudanças à medida que sua equipe integra uma nova ferramenta em sua prática diária, neste caso, o GitHub Copilot. Se você observar uma regressão em qualquer uma das medições do scorecard de engenharia durante a implantação do Copilot, faça uma pausa para examinar a causa raiz. Se o Copilot for um fator contribuinte, ajuste sua estratégia de capacitação ou implantação conforme necessário. Garanta que seus desenvolvedores recebam treinamento adequado e tenham acesso a recursos quando precisarem de ajuda. Depois de integrar totalmente o Copilot à prática diária de engenharia de sua equipe, você poderá voltar sua atenção para a realização de melhorias no nível do sistema, específicas para os objetivos da sua organização (por exemplo, redução do tempo de colocação no mercado, custo de entrega, risco etc.).
Otimização
Objetivo: impactos positivos nos objetivos específicos da organização.
Metodologia: obter e canalizar ganhos de eficiência para resultados de negócios positivos, como tempo de colocação no mercado mais rápido ou menor custo de entrega.
Métricas relevantes (consulte o glossário): todas as medições das fases de Adoção e Avaliação, além de medições adaptadas aos objetivos da sua organização.
Critério de saída: >80% das licenças comprometidas são atribuídas e estão ativas, com impactos positivos documentados nas medições de nível de sistema alvo da organização.
Depois que sua equipe adotar o GitHub Copilot, você poderá começar a se concentrar nas melhorias no nível do sistema mais importantes para sua organização. Cada organização é única. Algumas organizações podem estar atingindo suas metas de qualidade, mas desejam aumentar a velocidade. Para outras, códigos maliciosos e dívida técnica podem ser um problema.
Recomendamos um processo abrangente de três etapas para otimizar e sustentar o impacto do Copilot no longo prazo:
1. Defina suas metas no nível do sistema
Decida as metas no nível do sistema que são mais importantes para sua organização. Recomendamos uma perspectiva holística que considere múltiplas medições e adote uma abordagem sustentável para melhorias. Monitore as medições de qualidade e velocidade, mesmo que uma seja o foco principal, para que você perceba quaisquer consequências indesejadas o mais cedo possível. Continue a focar os principais indicadores de satisfação e envolvimento dos desenvolvedores, pois eles respaldarão as melhorias no nível do sistema. Para justificar e maximizar o valor, algumas organizações podem escolher uma lente de Engenharia de Valor de Negócio para ajudar nessa decisão.
À medida que você mede o progresso em direção às suas metas no nível de sistema (veja a etapa 3 abaixo), pode ser necessário ajustar suas metas ou fornecer capacitação além da implementação do Copilot.
Dica: seus planos táticos devem estar alinhados com as metas que você definiu. Depois que uma grande quantidade de sua equipe tiver adotado o Copilot (normalmente, mais de 80%), é razoável esperar um impacto visível nas medições posteriores de engenharia, mas apenas se os líderes de engenharia direcionarem a capacidade excedente para metas significativas. Se os desenvolvedores não tiverem uma orientação adequada, a capacidade excedente poderá se dissipar entre as atividades e ficar menos visível.
Se a sua organização oferece autonomia significativa às equipes, pode ser necessário registrar (a) quanto e (b) para onde a capacidade excedente é direcionada, o que maximizará a sua capacidade de medir o impacto no nível de sistema.
2. Ferramentas de configuração/acesso que permitem a medição do objetivo
Para algumas organizações, o sistema de engenharia vai além da plataforma do GitHub. Considere se você precisa aproveitar fontes de dados adicionais para viabilizar a medição de seus objetivos no nível de sistema. A estrutura SPACE fornece exemplos de indicadores no nível de sistema que podem ser úteis para medir o progresso em direção ao seu objetivo.
3. Monitorar medições
Decida a frequência do monitoramento das medições no nível do sistema. Muitas vezes, isso pode estar alinhado com a sua cadência de engenharia; recomendamos não mais do que semanalmente ou a cada duas semanas. Muitas equipes optam por examinar seus scorecards de engenharia durante uma reunião mensal de revisão de “Fundamentos de Engenharia”. Ao mesmo tempo, continue a observar as medições quantitativas relacionadas ao engajamento com o Copilot (da API Copilot Metrics e do Painel de Cobrança e Planos). Recomendamos também continuar a usar a pesquisa do Copilot semestralmente, no mínimo, para fornecer indicadores iniciais de quaisquer possíveis preocupações relacionadas ao uso. Como alternativa, incorpore perguntas relacionadas ao GitHub Copilot nas pesquisas dos desenvolvedores de sua organização ou forneça oportunidades de feedback síncrono para verificar a experiência do Copilot.
Dica: muitos líderes desejam quantificar o retorno do investimento (ROI) do Copilot. Qualquer impacto além da codificação é indireto e as possibilidades posteriores são infinitas. Assim, devemos ter cuidado ao procurar causalidade em medições de nível de sistema, como cobertura de código, pontos da história entregues, tempo de ciclo etc. É provável que o Copilot tenha impacto em várias medições no nível do sistema, mas vários fatores, como mudança de prioridades, mudanças de pessoal, interrupções do site ao vivo e fase de desenvolvimento podem afetar as medições a nível do sistema. Quando a dinâmica situacional é poderosa, é mais provável que o Copilot seja um fator atenuante do que uma força motriz.
Eficiência sustentada
Objetivo: avaliação e melhoria contínua.
Metodologia: à medida que a composição da equipe e os objetivos de negócios mudam, adaptar e manter o impacto do GitHub Copilot.
Métricas relevantes (consulte o glossário): todas as medições das fases de Adoção e Avaliação, além de medições adaptadas aos objetivos da sua organização.
As organizações mudam com o tempo. Empregue medições da fase de Otimização como forma de feedback sobre onde as mudanças podem ser necessárias em seu sistema de engenharia. Esteja atento a fatores de negócios que possam exigir que você mude as prioridades e suas metas e considere medições alternativas em nível de sistema. Mesmo enquanto você usa o Copilot, continue analisando as pesquisas e as medições quantitativas de engajamento para garantir que todos os desenvolvedores possam usufruir do impacto do Copilot. Aborde qualquer barreira identificada e forneça a capacitação adicional necessária.
Como aprender mais
A nossa abordagem para medir o impacto do Copilot foi desenvolvida com base nos muitos estudos de investigação que realizamos:
Pesquisa: Quantifying GitHub Copilot’s impact on code quality (Como quantificar o impacto do GitHub Copilot na qualidade do código)
The economic impact of the AI-powered developer lifecycle and lessons from GitHub Copilot (O impacto econômico do ciclo de vida do desenvolvedor que usa tecnologia de IA e as lições do GitHub Copilot)
Survey reveals AI’s impact on the developer experience (Pesquisa revela o impacto da IA na experiência do desenvolvedor)
Pesquisa: Quantifying GitHub Copilot’s impact on developer productivity and happiness (Como quantificar o impacto do GitHub Copilot na produtividade e satisfação do desenvolvedor)
Pesquisa: How GitHub Copilot helps improve developer productivity (Como o GitHub Copilot ajuda a melhorar a produtividade do desenvolvedor)
Temos observado a necessidade sistemática de nos concentrarmos na capacitação do Copilot, e que os impactos a nível do sistema podem ser diversos e dependem altamente do contexto. É por isso que recomendamos selecionar objetivos no nível do sistema apenas quando os engenheiros estiverem satisfeitos e usando o Copilot com eficiência. Também recomendamos clareza e constância ao comunicar às equipes de engenharia sobre para onde os ganhos de produtividade do Copilot devem ser direcionados.
Estamos comprometidos em aprender com nossos clientes e parceiros sobre como podemos usar a IA como parte de sistemas de engenharia sustentáveis, seguros e produtivos. Continuaremos compartilhando nossos insights.
A seguir, abordaremos maneiras de moldar sua política e governança interna de IA para promover o uso apropriado e eficaz.
A seguir: Capacitar os desenvolvedores com políticas e governança de IAComece a usar o GitHub Copilot