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:
Propósito - Por que a organização deseja adotar o InnerSource?
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:
Isso não substitui a documentação estruturada. No entanto, pode servir como ponto de partida para coletar documentação estruturada.
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
2023-04-29 - Tradução Eneri Junior
2023-04-29 - Tradução Humberto Zilio
Last updated
