Documente seus Princípios Orientadores

Title

Documente seus Princípios Orientadores

Patlet

A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.

Problema

A organiza√ß√£o est√° tentando implementar o InnerSource em uma escala maior. A iniciativa come√ßou entre entusiastas de c√≥digo aberto. O objetivo agora √© obter a ades√£o de pessoas que n√£o possuem experi√™ncia em c√≥digo aberto. Para esse p√ļblico, o slogan t√≠pico de "aplicar as melhores pr√°ticas de c√≥digo aberto" n√£o √© mais suficiente para transmitir a mensagem do que √© o InnerSource, quais problemas ele resolve e quais ferramentas ele usa para solucionar esses problemas. Como resultado, a ado√ß√£o do InnerSource na organiza√ß√£o diminui. As equipes desenvolvem ideias divergentes sobre os objetivos do InnerSource e como implement√°-lo da melhor maneira, o que leva a confus√£o quando os contribuidores come√ßam a cruzar as fronteiras das equipes

História

Experimentos iniciais em uma organização mostraram que as melhores práticas de colaboração em código aberto podem ser benéficas. O próximo passo agora é levar a iniciativa para equipes e indivíduos que não possuem um amplo conhecimento em código aberto.

A meta agora é comunicar claramente os objetivos da iniciativa InnerSource, bem como um caminho claro para alcançar os mesmos.

Contexto

  • A terminologia InnerSource est√° circulando entre os funcion√°rios.

  • A iniciativa come√ßou entre entusiastas do c√≥digo aberto.

Forças

  • As equipes t√™m dificuldade em comunicar exatamente quais s√£o os aspectos importantes do InnerSource.

  • As pessoas que n√£o possuem experi√™ncia em c√≥digo aberto falham em entender o que significa trazer as melhores pr√°ticas do c√≥digo aberto para dentro da organiza√ß√£o.

  • No dia a dia, as equipes que tentam seguir as melhores pr√°ticas do InnerSource t√™m dificuldade em decidir se o que est√£o fazendo est√° alinhado com os valores gerais do InnerSource.

Solução

Aqueles que lideram a iniciativa InnerSource na organização precisam ajudar as equipes e indivíduos que têm pouco conhecimento em código aberto e, portanto, têm menos compreensão intuitiva do InnerSource.

A clareza deve ser fornecida às equipes e indivíduos por meio da documentação dessas duas áreas:

  1. Propósito - Por que a organização deseja adotar o InnerSource?

  2. Princípios - Quais são os princípios do InnerSource que ajudarão a enfrentar esses desafios?

As seguintes se√ß√Ķes fornecem mais detalhes sobre ambos, destinados a servir como poss√≠veis pontos de partida para document√°-los em sua organiza√ß√£o.

Por que a organização quer adotar o InnerSource?

No passado, o InnerSource provou ser bem-sucedido em resolver v√°rias quest√Ķes comumente encontradas em organiza√ß√Ķes.

Porém, quais desafios organizacionais a sua organização espera melhorar usando o InnerSource?

Em vez de fazer generaliza√ß√Ķes, tente identificar exatamente as solu√ß√Ķes que correspondam aos desafios da sua organiza√ß√£o - de prefer√™ncia com aqueles afetados pela mudan√ßa que voc√™ deseja ver.

Alguns desafios que outras organiza√ß√Ķes abordaram seguindo as melhores pr√°ticas do InnerSource:

  • Reduzir silos de desenvolvimento causados por uma cultura excessiva de propriedade.

  • Aumentar a velocidade de inova√ß√£o, reduzindo o tempo gasto resolvendo problemas semelhantes, promovendo um c√≥digo saud√°vel para reutiliza√ß√£o.

  • Aumentar a velocidade de desenvolvimento atrav√©s de uma melhor colabora√ß√£o entre equipes.

  • Resolver depend√™ncias de projetos/equipes al√©m de "esperar" ou "construir solu√ß√Ķes alternativas", reduzindo gargalos de engenharia.

  • Aumentar a qualidade.

  • Aumentar a satisfa√ß√£o dos funcion√°rios.

  • Aumentar o sucesso de novas contrata√ß√Ķes.

  • Construir documenta√ß√£o acion√°vel.

Quais princípios do InnerSource ajudarão a abordar esses desafios?

Uma vez que as equipes compreendem quais problemas o InnerSource irá ajudá-las a resolver, o próximo passo é explicar quais princípios ajudam a enfrentar esses desafios.

Com base nos princípios básicos de desenvolvimento de código aberto, as seguintes diretrizes têm se mostrado bem-sucedidas:

(1) O código deve ser hospedado de forma transparente dentro da organização.

O código-fonte, documentação e dados relevantes para o desenvolvimento do projeto devem estar disponíveis e serem facilmente encontrados por qualquer pessoa na organização.

(2) Contribui√ß√Ķes em vez de pedidos de funcionalidade.

Todos os envolvidos em um projeto agem como potenciais colaboradores e s√£o tratados e apoiados como tal. As contribui√ß√Ķes permanecem como sugest√Ķes em vez de requisitos. A coordena√ß√£o antes de uma contribui√ß√£o ajuda a evitar esfor√ßo desperdi√ßado. Os projetos fornecem diretrizes de contribui√ß√£o para evitar fric√ß√£o.

(3) Erros s√£o oportunidades de aprendizado.

Com o trabalho visível em toda a organização, qualquer erro é visível para todos. Como resultado, deve ser estabelecida uma cultura em que os erros sejam oportunidades de aprendizado em vez de falhas que devem ser evitadas a todo custo.

(4) Escrita acima de comunicação verbal.

Para projetos que envolvem v√°rias equipes, potencialmente em hor√°rios de reuni√£o divergentes, √© necess√°rio colaborar de forma ass√≠ncrona. O objetivo dos projetos InnerSource √© recrutar novos colaboradores. Para isso, futuros colaboradores potenciais precisam ser capazes de acompanhar o progresso do projeto de forma aut√īnoma com uma barreira muito baixa para entrada. Se a comunica√ß√£o relevante do projeto acontecer por meio de comunica√ß√£o s√≠ncrona, os argumentos discutidos precisam ser registrados no canal escrito - as decis√Ķes devem ser finalizadas apenas l√°. Como efeito colateral, isso leva a uma documenta√ß√£o b√°sica passiva que √© muito valiosa para qualquer rec√©m-chegado ao projeto.

(5) Permitir que conselhos escritos acumulem em um arquivo persistente e pesquis√°vel.

Toda a comunica√ß√£o do projeto, em particular as decis√Ķes tomadas e as discuss√Ķes que levaram a essas decis√Ķes, precisam ser arquivadas. Deve ser poss√≠vel referenciar a comunica√ß√£o por meio de URLs est√°veis. A comunica√ß√£o anterior precisa ser armazenada de forma que possa ser facilmente pesquisada.

Dois avisos, no entanto:

  1. Isso não substitui a documentação estruturada. No entanto, pode servir como ponto de partida para coletar documentação estruturada.

  2. H√° exce√ß√Ķes √† regra de que tudo deve ser escrito e acess√≠vel a toda a organiza√ß√£o: discuss√Ķes relacionadas a pessoas e discuss√Ķes relacionadas √† seguran√ßa s√£o sens√≠veis e n√£o devem ser realizadas publicamente.

(6) Recompensar Trusted Committership

Todas as contribui√ß√Ķes (por exemplo, c√≥digo fonte, documenta√ß√£o, relat√≥rios de bugs, participa√ß√£o em discuss√Ķes, suporte ao usu√°rio, marketing) s√£o bem-vindas e s√£o recompensadas. Aqueles que demonstram apoio ao projeto s√£o convidados como Trusted Committers. Todos os Trusted Committers de um projeto s√£o publicados.

Contexto Resultante

  • Membros da organiza√ß√£o entendem quais desafios podem ser enfrentados aplicando as melhores pr√°ticas de InnerSource.

  • Membros da organiza√ß√£o sem experi√™ncia pr√©via em c√≥digo aberto entendem os valores e princ√≠pios b√°sicos dos projetos InnerSource.

  • Membros da organiza√ß√£o sem experi√™ncia pr√©via em c√≥digo aberto conseguem verificar suas atividades di√°rias em rela√ß√£o a um conjunto de valores comuns estabelecidos.

  • As pr√°ticas de desenvolvimento da organiza√ß√£o se tornam mais semelhantes aos projetos de c√≥digo aberto, tornando mais f√°cil para os membros da organiza√ß√£o participar de projetos de c√≥digo aberto.

Inst√Ęncias Conhecidas

Europace AG

Os princípios de InnerSource listados na Solução acima são em sua maioria baseados na experiência da Europace. Para mais detalhes, consulte Europace InnerSource Prinzipien (em alemão).

GitHub

Objetivo

Muitas vezes, na GitHub, trabalhamos em um modelo em que equipes contribuem com recursos para √°reas fora de sua responsabilidade. Exemplos comuns incluem engenharia de vendas contribuindo com recursos para desbloquear uma venda, projetos especiais contribuindo com recursos urgentemente necess√°rios e de alto impacto em todo o produto e uma equipe trabalhando em v√°rias √°reas para entregar uma funcionalidade.

Princípios

No geral, os princípios descritos neste documento visam evitar o aumento da dívida técnica e da carga de suporte para a equipe responsável. Muitas vezes, ajuda é oferecida a uma equipe porque eles estão atrasados devido aos custos de suporte e manutenção em sua área de responsabilidade e não têm capacidade para contribuir para o recurso. Qualquer novo recurso realizado por outra equipe que aumente essa carga de suporte ou dívida técnica significa ainda menos tempo para a equipe responsável trabalhar em novos recursos, portanto, queremos garantir que sejam feitos corretamente.

Ao mesmo tempo, buscamos ser uma empresa na qual os engenheiros trabalhem livremente em diferentes áreas e prioridades de negócios frequentemente exigem que contribuamos para áreas fora de nossas áreas principais de responsabilidade.

Um bom resumo dos princípios é deixar a área em tão bom estado quanto ou em melhor estado do que você a encontrou.

Com isso em mente, aqui estão os princípios em que concordamos:

  • Evite produtos minimamente vi√°veis ‚Äč‚Äč(MVPs) que acumulam d√≠vida de recursos. Est√° tudo bem lan√ßar um MVP para obter feedback do cliente, mas a equipe que contribui deve estar comprometida em concluir o conjunto de recursos. Exemplos incluem:

    • Compromisso em ir al√©m do MVP para uma solu√ß√£o que ir√° satisfazer a maioria dos clientes.

    • Suporte completo para administra√ß√£o de novos recursos (por exemplo, suporte na interface do usu√°rio de configura√ß√Ķes, em vez de apenas executar uma linha de comando).

    • Disponibiliza√ß√£o de recursos tanto na interface do usu√°rio quanto na API, em vez de fornecer apenas uma API (ou vice-versa).

    • Garantir que os recursos funcionem em ambientes de servidor local e em nuvem.

  • Apoiar o trabalho de cria√ß√£o de novas funcionalidades desde o in√≠cio at√© depois da sua implementa√ß√£o em produ√ß√£o

    • Coordenar o lan√ßamento incremental

    • Lidar com os tickets de suporte

    • Planejar tempo para lidar com o feedback dos clientes (funcionalidades e bugs)

  • Construir recursos da maneira correta (n√£o acumular d√≠vidas t√©cnicas)

    • Concordar com requisitos e solu√ß√£o com as equipes de Produto e Engenharia

    • Arquitetura e design adequados

    • Certificar-se de que os dados sejam armazenados adequadamente para evitar migra√ß√Ķes de dados posteriormente.

    • Telemetria adequada est√° em vigor

    • Cobertura de testes adequada est√° em vigor

    • Suportado em ambientes de produ√ß√£o na nuvem e local (incluindo configura√ß√£o, backup/restaura√ß√£o, migra√ß√Ķes, etc.)

    • Corre√ß√£o de bugs

    • Documenta√ß√£o atualizada

Compromisso

Usamos um modelo de engajamento porque gostamos de definir quais medidas concretas podem ser tomadas por uma equipe ao contribuir com recursos para √°reas fora de sua √°rea de responsabilidade.

Um modelo de envolvimento típico no GitHub é parecido com este:

  • Obter a aprova√ß√£o do conjunto de recursos e do plano de implementa√ß√£o do propriet√°rio do produto.

  • Obtenha a aprova√ß√£o do projeto de engenharia, incluindo a abordagem dos requisitos n√£o funcionais (telemetria, cobertura de testes, testes em v√°rios ambientes e suporte) do propriet√°rio da engenharia (geralmente o gerente e o diretor de engenharia).

  • Fa√ßa revis√Ķes de c√≥digo ao longo do processo, juntamente com a revis√£o de quaisquer requisitos novos ou alterados.

Robert Bosch GmbH

Objetivo

Promover a colaboração, o aprendizado e a inovação é o foco principal da iniciativa Bosch InnerSource (BIOS).

Princípios

Para isso, a Bosch aplicou os seguintes princípios:

  • Abertura: Reduzimos as barreiras de entrada nas comunidades de BIOS o m√°ximo que podemos.

  • Transpar√™ncia**: Somos radicalmente transparentes e compartilhamos nossos produtos de trabalho, nossa comunica√ß√£o e nossa tomada de decis√Ķes com todos os associados da empresa.

  • Voluntariedade**: A decis√£o de participar e contribuir com a comunidade da BIOS fica a cargo de cada associado. Os funcion√°rios devem trabalhar na BIOS porque est√£o intrinsecamente motivados, e n√£o porque o gerente lhes disse isso.

  • Autodetermina√ß√£o**: As comunidades da BIOS s√£o livres para escolher no que trabalhar, quando trabalhar e quais ferramentas e processos usar para trabalhar.

  • Meritocracia**: O poder √© investido nos membros do projeto BIOS com base em seus m√©ritos, ou seja, com base na qualidade e na quantidade de suas contribui√ß√Ķes.

Os princ√≠pios Abertura, Transpar√™ncia e Voluntariedade ajudaram a desenvolver diversas comunidades de associados intrinsecamente motivados. A Meritocracia provou ser uma motiva√ß√£o eficaz para fazer grandes contribui√ß√Ķes. A Autodetermina√ß√£o permitiu que as comunidades usassem seu tempo limitado para contribui√ß√Ķes da maneira mais eficaz e eficiente.

Estado

Structured

Autores

  • Isabel Drost-Fromm

  • Georg Gr√ľtter

Reconhecimento

  • Zack Koppert - for sharing GitHub's approach in the Known Instances

Alias

Explicit InnerSource Principles

Histórico de Tradução

Last updated