Europace

Adotando práticas de código aberto na Europace

Estudo de caso extraído de um capítulo/artigo de Isabel Drost-Fromm em ‘Adopting Inner Source’ (julho de 2018)

Introdução

A Europace é uma fintech de médio porte sediada em Berlim, na Alemanha. A organização iniciou formalmente seu programa InnerSource em 2017 e compartilhou os aprendizados no artigo um ano depois. 

Nesse primeiro ano, a Europace relatou que, onde os processos e práticas InnerSource foram aplicados, houve uma melhora perceptível nos prazos de desenvolvimento, código de maior qualidade e maior colaboração entre equipes. Os novos processos também aumentaram a responsabilidade dos desenvolvedores pelos projetos e fortaleceram uma cultura de mentoria entre equipes.

Objetivos do InnerSource

Em 2015, a Europace começou a explorar modelos alternativos de organização e governança. O objetivo era desenvolver uma nova estrutura para toda a empresa que criasse uma cultura de ‘auto-organização descentralizada’ (posso colocar um link aqui…). Nessa nova estrutura, a responsabilidade e a tomada de decisões passariam para as pessoas com maior conhecimento especializado. 

Essa missão se baseava na ‘… convicção fundamental… de que os funcionários da Europace são especialistas em suas áreas e plenamente capazes de tomar as decisões certas’. 

(devo incluir uma referência?  Página 88 do artigo)

Nesse contexto, o InnerSource oferecia tanto um modelo abrangente quanto diretrizes úteis para desenvolver essa visão. 

Ao reproduzir boas práticas do código aberto, o InnerSource também oferecia a possibilidade de resolver desafios da empresa em crescimento, como:

• O aumento dos silos de desenvolvimento entre as equipes. 
• A interdependência tecnológica e os desafios associados à priorização do desenvolvimento.
• As lacunas de informação e a perda da ‘memória dos projetos’ devido à documentação limitada. 
• A necessidade de migrar para comunicação e tomada de decisões assíncronas para facilitar o trabalho remoto.

InnerSource: o primeiro ano na Europace

Obtendo apoio e engajamento dos funcionários

• Criando uma função dedicada ao InnerSource

Primeiro, foi criada uma função específica para coordenar as iniciativas InnerSource. A experiência do novo coordenador com código aberto e com a Apache Software Foundation foi inestimável para compreender, comunicar, implementar e resolver problemas ao longo da jornada InnerSource da Europace.

• A importância estratégica de construir relacionamentos

O passo seguinte foi envolver diferentes partes interessadas na Europace e iniciar conversas sobre os benefícios da participação. A abordagem adotada foi convidar pessoas para almoços informais individuais. Essas conversas foram especialmente úteis para identificar preocupações e possíveis obstáculos. 

Após identificar desafios comuns, foram organizados almoços informais em grupo para que os interessados compartilhassem aprendizados. Isso evoluiu para encontros mensais de discussão durante o almoço, voltados à troca de informações e à solução de problemas.

• O papel de Trusted Committer no ‘metanível’

Nessa fase inicial, entusiastas do InnerSource ajudaram seus colegas a adotar novos processos de comunicação e registro de decisões. Outros também orientaram equipes, responderam a perguntas e divulgaram o InnerSource entre os colegas.  Esse grupo central foi convidado a atuar como Trusted Committers do programa InnerSource.

A atribuição do status de Trusted Committer reconheceu publicamente os esforços dos defensores e mentores do InnerSource. Também tornou visível quem impulsionava o programa dentro da empresa. 

Novos processos, novas ferramentas

• Aumentando a transparência na comunicação e na tomada de decisões

Rastrear as decisões de desenvolvimento e produto havia se tornado um desafio na Europace.  Foi identificada a necessidade de registrar as comunicações e decisões por escrito. 

Os defensores do InnerSource incentivaram ativamente os colegas e deram o exemplo para substituir a dependência de decisões verbais pelo uso do Slack, de discussões no GitHub ou de outros meios com registros arquivados. 

• Melhorando a transparência das tarefas para facilitar a colaboração

Até então, o planejamento ocorria principalmente em quadros do Trello ou no JIRA. Porém, as equipes frequentemente restringiam o acesso de leitura e escrita às suas próprias unidades. Isso criava obstáculos à colaboração entre equipes.

Como o GitHub disponibiliza informações por padrão, a migração facilitou que todas as equipes pesquisassem ‘… nas issues, nas conversas sobre pull requests e no código’.

• O repositório InnerSource: liderando pelo exemplo e tornando seguro errar

O programa InnerSource precisava dar o exemplo de transparência, oferecer um espaço para fazer perguntas à comunidade e acompanhar a documentação relevante reunida.

O programa seguiu uma abordagem InnerSource ‘baseada em infraestrutura’ (precisa de nota de rodapé). 

Os processos de comunicação foram criados para refletir os princípios InnerSource descritos acima e, de acordo com essa abordagem, foram reutilizadas ferramentas já disponíveis na organização. 

Um repositório GitHub (‘ep-innersource’) acompanhava todos os trabalhos e decisões do programa InnerSource. Um canal dedicado no Slack foi criado para discussões gerais sobre o programa.

O repositório GitHub também servia como espaço para experimentar processos e tecnologia em um ambiente seguro, sem risco de interromper os sistemas de produção.

• A transição para pull requests

Embora alguns funcionários da Europace já conhecessem o GitHub, as equipes passaram a ser incentivadas a usar pull requests para lidar com a interdependência tecnológica.

Colaboradores de qualquer equipe que quisessem fazer alterações tinham permissão para baixar o código por meio de uma pull request no GitHub. Podiam adicionar ou modificar uma funcionalidade e enviá-la ao Trusted Committer da equipe anfitriã para aprovação. O código era então integrado à base principal, ou o colaborador era solicitado a fazer novas revisões. 

Em poucas semanas, as pull requests passaram a ser adotadas mais amplamente como modelo de colaboração.

• Promovendo a responsabilidade nos projetos InnerSource: o Trusted Committer

O papel de Trusted Committer (link para a trilha de aprendizagem da ISC aqui) foi introduzido para facilitar a colaboração entre equipes, preservar a memória dos projetos e promover a responsabilidade pelo projeto ao longo do tempo. 

Os Trusted Committers garantiam a qualidade do produto enquanto reduziam as barreiras às contribuições. Também eram responsáveis por orientar os desenvolvedores que desejavam contribuir com código ou correções.

Quando conquistavam a confiança dos mantenedores, os colaboradores recebiam acesso de escrita ao repositório.

Desenvolvendo uma compreensão interna comum do InnerSource

Inicialmente, o InnerSource foi definido como uma forma de aplicar os princípios do código aberto aos projetos da empresa. 

Com a evolução do programa, tornou-se importante desenvolver a compreensão dos funcionários não apenas sobre ‘como’ praticar InnerSource, mas também sobre os princípios e boas práticas que sustentavam sua adoção bem-sucedida na Europace.

O programa InnerSource desenvolveu a conscientização e o conhecimento das equipes ao facilitar um trabalho colaborativo para: 

• Documentar os aprendizados de InnerSource no blog técnico da empresa.
• Enviar um padrão InnerSource para o InnerSource Commons.
• Criar um conjunto de princípios InnerSource para a Europace.

Como em todos os programas InnerSource, os pedidos de contribuição e revisão eram divulgados no canal do Slack. As iniciativas também eram publicadas no GitHub e, quando necessário, o líder de InnerSource procurava pessoas-chave para solicitar revisões.

Resultados do InnerSource

Em um ano, os projetos InnerSource implantados na Europace demonstraram os benefícios desse modelo de colaboração:

• A migração para o GitHub e o incentivo em toda a empresa para documentar decisões nas principais plataformas aumentaram a transparência dos projetos e reduziram a fragmentação das informações.
• Como decisões, discussões de arquitetura, documentação e código ficaram mais próximos no GitHub, tornou-se mais fácil acompanhar e compreender as mudanças. Isso reduziu a necessidade de muitos requisitos formais de documentação prévia e, consequentemente, aumentou o interesse dos gerentes de projeto e designers de UX pelos projetos.
• A tomada de decisões assíncrona pelo Slack e pelo GitHub facilitou a participação de funcionários que não estavam inicialmente envolvidos nos projetos. Sem depender de trabalhar no mesmo local ou de reuniões presenciais, as pessoas podiam compartilhar conhecimento além das fronteiras de equipes, horários e localização geográfica.
• O papel de Trusted Committer aumentou a responsabilidade dos desenvolvedores. Como a mentoria fazia parte desse processo, passou a ser reconhecida como uma contribuição valiosa dos funcionários.
• O uso de pull requests permitiu que membros experientes oferecessem ideias e apoio a projetos fora de suas responsabilidades. A proteção oferecida pelas pull requests e revisões de código também deu aos novos desenvolvedores a oportunidade de realizar contribuições valiosas.
• O uso de pull requests também possibilitou ‘… uma aceleração do desenvolvimento’

• Tanto a qualidade do código quanto a das revisões de código melhoraram substancialmente.

Conclusão

A promoção de práticas InnerSource na empresa e em vários projetos demonstrou seu valor para desenvolver código de maior qualidade, incentivar a reutilização e resolver problemas existentes, como a perda da memória dos projetos e a fragmentação das informações. O uso do InnerSource em projetos selecionados confirmou os benefícios da colaboração entre equipes tanto para os projetos quanto para os funcionários. Novos desenvolvedores tiveram a oportunidade de desenvolver suas habilidades, enquanto os mais experientes foram reconhecidos como Trusted Committers e mentores.

A segunda fase do programa InnerSource da Europace se concentraria nos novos desafios relacionados à ampliação e à expansão do programa.

Ainda assim, na perspectiva da Europace, a fase inicial de adoção foi considerada muito bem-sucedida.