Bem-vindo ao Livro de Padrões InnerSource.

Este livro contém as melhores práticas InnerSource codificadas em um formato específico para facilitar a compreensão, avaliação e aplicação delas em seu contexto. Chamamos esse formato de padrão.

A InnerSource Commons coletou esses padrões ao longo de muitos anos, publicando os padrões mais maduros neste livro, onde membros da comunidade revisam cada padrão, com pelo menos uma instância conhecida de uso do padrão.

Nesta introdução, explicamos o que é InnerSource, o que é um padrão e Como você pode usar Padrões InnerSource? em sua organização.

Se você já está usando InnerSource em sua empresa e deseja contribuir com suas experiências para este livro, adoraríamos receber suas contribuições!

O que é InnerSource?

Definimos InnerSource como:

O uso de princípios e práticas de código aberto para o desenvolvimento de software dentro dos limites de uma organização.

O InnerSource aproveita as lições aprendidas com o desenvolvimento de software de código aberto e as aplica à forma como as empresas desenvolvem software internamente. À medida que os desenvolvedores se acostumaram a trabalhar em software de código aberto de alta qualidade, surge um forte desejo de trazer essas práticas de volta para dentro da empresa e aplicá-las ao software que as empresas podem relutar em lançar.

Para empresas que constroem principalmente software de código fechado, o InnerSource pode ser uma ótima ferramenta para quebrar barreiras, incentivar e ampliar a colaboração interna, acelerar a integração de novos engenheiros e identificar oportunidades de contribuir com software para o mundo de código aberto.

O que são Padrões InnerSource?

Padrões são uma forma de descrever uma solução repetível e comprovada para um problema dentro de um contexto. Os padrões seguem uma forma simples que auxilia durante a implementação de uma solução para entender as restrições do problema, compreender as forças que você precisa equilibrar e o contexto resultante - a situação criada pela aplicação da solução.

Os padrões podem fornecer uma maneira para os participantes da InnerSource Commons compartilharem informações de forma concisa, melhorando a prática do InnerSource. Os padrões são divididos em Título, Declaração do Problema, Contexto, Forças e Soluções como suas principais seções.

• O que são padrões? Vídeos no Youtube - Assista a uma série de vídeos no Youtube de 2-5 minutos explicando Padrões InnerSource.

• Webinar de Discussão de Padrões - Realizamos um webinar em 16 de março de 2017 para discutir ao vivo um donut pattern (vá para 24:30 para a discussão). Isso ilustra o processo de revisão que seguimos. Veja também o Webinar O'Reilly de 1 de junho de 2017 sobre Padrões InnerSource.

• Modelo de Padrão - Veja um padrão InnerSource esqueleto para ter uma ideia do que é necessário para criar um novo padrão!

• Introdução aos Padrões InnerSource (apresentação do Fall Summit 2016) - Tim Yao e Padma Sudarsan (PDF). Fundo e exemplos detalhados de padrões - Entenda detalhadamente por que e como interagir com nossos padrões. Veja também a Introdução aos Padrões InnerSource (Fall Summit 2017) Tim Yao e Bob Hanmer (PDF).

Como você pode usar Padrões InnerSource?

Os padrões devem ser usados com cuidado. Eles não podem ser aplicados indiscriminadamente. Na maioria dos casos, você precisará adaptar a solução fornecida à sua situação; mas as informações dadas no padrão, definindo o contexto (restrições imutáveis) e as forças (restrições que podem ser alteradas e equilibradas entre si), devem ajudá-lo a fazer isso. Note que você também precisará determinar se existem restrições adicionais (contexto da empresa e forças da empresa) que se aplicam à sua empresa/organização específica e que devem ser adicionadas ao padrão (como um tipo de filtro). Essas restrições adicionais podem exigir etapas de solução adicionais a serem aplicadas.

A forma do padrão é útil para descrever soluções comprovadas, mas também pode ser usada para brainstorming de novas soluções onde os padrões ainda não estão estabelecidos. Isso ocorre porque a anatomia de um padrão fornece um framework para pensar em um problema de maneira estruturada. Você também pode criar um donut pattern (preenchendo os campos de problema, contexto, forças e contexto resultante, mas deixando a solução em branco) como uma maneira de pedir ajuda à comunidade da InnerSource Commons (para encontrar uma solução comprovada ou para gerar ideias para tentar).

Como Contribuir?

Por favor, consulte: Contribuir para este livro

Créditos

Este livro é o resultado de muitos anos de trabalho de inúmeros Contribuidores de Código Aberto de todo o mundo. Sua disposição em compartilhar abertamente os desafios que enfrentaram em suas empresas e como o InnerSource os ajudou a enfrentar esses desafios torna este livro um recurso valioso para outros em sua jornada InnerSource.

Queremos mencionar especificamente o Grupo de Trabalho InnerSource Patterns. Eles têm nutrido a qualidade dos Padrões InnerSource e ajudaram outros a contribuir. Por último, eles também compilaram uma seleção de padrões disponíveis neste livro.

A imagem de capa deste livro foi criada por Sebastian Spier e adaptada a partir de uma imagem de Tony Hisgett - Alhambra 6, disponível sob CC BY 2.0.

Obrigado a todos os contribuidores! E feliz Dia InnerSource :)

Licenciamento

InnerSourcePatterns por InnerSourceCommons.org está licenciado sob uma Licença Internacional Creative Commons Attribution-ShareAlike 4.0.

Title

Avaliação de Projeto entre Equipes

Patlet

É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.

Contexto

• Você é responsável por uma equipe cross que serve como plataforma para outros na empresa.

• O projeto entre equipes não proporciona nenhum valor direto para a receita da empresa.

Problema

Projetos entre equipes podem ter um impacto muito grande na empresa, mas são difíceis de representar de maneira baseada em dados. Como resultado, é fácil e comum tanto buscar projetos que não fornecem valor real quanto subfinanciar o que, de outra forma, produziria grande valor.

Forças

• Os projetos precisam demonstrar valor (objetivo ou subjetivo) à liderança da empresa para serem financiados.

• O valor do projeto entre equipes é disperso em várias unidades de negócios finais.

• Devido a essa dispersão, o valor do projeto entre equipes é difícil de medir diretamente.

Solução

Estabeleça um padrão e modelo de como valorizar projetos entre equipes.

Tais modelos nos fornecem a ferramenta necessária para nos concentrarmos e ampliar a colaboração de alto valor para a empresa.

O core de todo o valor do projeto entre equipes é a ideia de que podemos realizar mais juntos do que separados. Atribuir valor a um esforço entre equipes é um exercício em quantificar quanto mais está sendo feito juntos. O delta exato na produtividade variará de acordo com o domínio e o projeto. Existe um processo comum pelo qual você pode criar um modelo para calculá-lo.

Explicação

Monte uma pequena equipe de especialistas em seu domínio. Usando essa equipe de especialistas, estime 4 coisas sobre cada consumidor de sua saída de projeto:

• Quanto tempo leva para que eles consumam a saída do seu projeto?

• Quanto tempo levaria para que eles criassem o valor da saída do seu projeto para si mesmos?

• Qual a porcentagem da saída do seu projeto é realmente útil para eles?

• Quanto tempo eles gastariam em manutenção da solução criada por eles mesmos, em base contínua (idealmente por uso)?

Ao fazer essas estimativas, é impossível saber com alta precisão exatamente quanto tempo cada atividade leva. Isso não é o seu objetivo. Em vez de exatidão, você deve se esforçar para estabelecer um limite mínimo nessas estimativas. A ideia é que o grupo de especialistas seja capaz de dizer uns aos outros: "Não sabemos exatamente quanto tempo levaria, mas todos concordamos que é pelo menos isso." Especificamente, você deve estimar um tempo máximo razoável para consumir a saída do seu projeto e tempos mínimos razoáveis para os consumidores, caso contrário, criar, usar e manter suas próprias soluções.

Uma observação sobre o custo de "criar sua própria solução" (home-roll). O custo de criar uma solução por conta própria NÃO é necessariamente o mesmo (muito improvável, na verdade) do custo de criar uma solução compartilhada. Muitas vezes, para a mesma funcionalidade, a modularidade e qualidade envolvidas na construção de uma solução compartilhada entre equipes tornam o investimento significativamente maior do que uma implementação rápida e codificada usada apenas uma vez.

Fórmula

Depois de estimar os limites piores casos, você pode calcular o valor da saída do seu projeto de equipe cross durante um determinado período de tempo usando a fórmula simples:

[Tempo Economizado] - [Tempo Investido]

([Número de novas implementações] * [Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] + [Número de usos] * [Custo de manutenção por uso]) - ([Número de novas implementações] * [Custo de implementação])

[Número de novas implementações] * ([Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] - [Custo de implementação]) + [Número de usos] * [Custo de manutenção por uso]

Comentário

Apesar das aparências de rigor, esse processo não produz uma forma exata de medir a saída de projetos entre equipes. Na prática, entretanto, ele oferece um modelo através do qual você pode tomar uma decisão adequada de como financiar esse trabalho. Depois de ter dados bons e razoáveis conforme explicado acima, você deve financiar horas de desenvolvimento dedicadas para executar o projeto em, pelo menos um dos três níveis abaixo:

1. O número de horas poupadas pela fórmula acima. Como todos temos certeza de que a fórmula produzirá um número abaixo do verdadeiro número de horas salvas, você pode ter a confiança de que financiar o projeto até esse ponto é uma vitória certa para você.

2. A quantidade de tempo que leva para dar suporte a contribuições internas para projetos entre equipes. Como o colaborador provavelmente teria feito o trabalho de qualquer maneira de forma única, vale a pena financiar o tempo que leva para facilitar o trabalho dele ser compartilhado.

3. Qualquer quantia que pareça boa para você. Um efeito colateral intencional de ter uma fórmula de valoração é que ela naturalmente força a medição dos pontos-chave de uso que fornecem valor aos consumidores.

Essas medidas podem ser compreendidas e utilizadas em sua forma bruta para lhe fornecer uma ideia intuitiva de quão valioso é o projeto.

Algumas pessoas podem se preocupar com a falta de precisão nessa abordagem de valoração. Mas tudo bem se esse processo não fornecer uma medição exata. Ele só precisa ser preciso o suficiente para cumprir dois objetivos:

1. Dar um meio de representar o valor do que está acontecendo para aqueles que estão organizando e financiando esforços entre equipes.

2. Ajudar aqueles envolvidos a saber quais áreas de esforço entre equipes são prioritárias com base em seu valor.

Na prática, desde que essas valorações estejam dentro de uma ordem de grandeza da realidade e uma da outra, elas são suficientemente precisas para cumprir esses propósitos. Elas fornecerão uma melhoria significativa nos resultados em relação às valorações ad hoc (e aos efeitos resultantes) descritas na seção Problema no início deste documento.

Contexto Resultante

• Meios baseados em dados para discutir o valor e financiamento do projeto de equipe cross com a liderança.

• Métricas-chave em torno do projeto de equipe cross instrumentalizadas em forma bruta.

• Definir como o projeto de equipe cross fornece valor tende a levar a ele produzir maior valor para a empresa.

• Projeto geralmente bem-sucedido e "buzz" em torno dele.

Instâncias Conhecidas

• Nike

Estado

• Structured

• Proven in multiple domains.

Autores

• Russ Rutledge

Reconhecimento

• Jeremiah Wright por me ensinar a pensar em projetos entre equipes como um negócio interno que opera na moeda do tempo dos desenvolvedores.

Histórico de Tradução

• 2023-04-27 - Tradução Eneri Junior

• 2023-04-27 - Tradução Humberto Zilio

Padrões

Apêndice

• Extras

Recursos

Cada vez mais padrões estão sendo contribuídos para este livro pela comunidade InnerSource Commons. Isso é incrível!

Agora, como tornar mais fácil para os leitores descobrirem os padrões que podem ajudá-los em sua situação específica?

Para esse propósito, fornecemos este mapa mental. Ele classifica os padrões com base nas diferentes fases de um Programa InnerSource e nos desafios que podem surgir nas respectivas fases.

Melhore este Mapa Mental

Referências

Deseja tornar este livro melhor? Isso é incrível!

O livro Padrões InnerSource em si é um e acolhe qualquer forma de contribuição. Nada é insignificante!

Não importa se deseja nos auxiliar a corrigir erros de gramática/ortografia, melhorar o design ou contribuir com padrões inteiramente novos baseados nas experiências InnerSource que teve em seu local de trabalho. Amamos todas essas contribuições! :)

Se nunca contribuiu para um projeto de código aberto anteriormente, saiba que a comunidade Padrões InnerSource é formada por pessoas amigáveis e é um ambiente seguro para experimentar.

Antes de Começar

As fontes dos Padrões InnerSource e deste livro estão mantidas em um repositório no GitHub. Portanto, será necessário ter uma conta de usuário no GitHub para fazer edições e sugestões neste livro. Caso não possua uma ainda, visite e crie uma conta gratuitamente.

Diferentes Formas de Contribuir

Aqui estão algumas maneiras pelas quais pode contribuir:

1. Corrigir erros de ortografia, formatação ou outras falhas que notar neste livro.

2. Melhorar o conteúdo de um padrão existente (por exemplo, adicionando uma breve descrição de como está usando um padrão como uma Instância Conhecida).

3. Contribuir com um novo padrão, descrevendo como superou desafios relacionados ao InnerSource em sua organização.

Para (1) e (2) acima, pode simplesmente clicar no link Editar no GitHub que vê no topo de cada página deste livro. Isso o levará diretamente ao arquivo correspondente em nosso repositório GitHub, onde pode sugerir suas alterações.

Para (3), será necessário clonar o repositório e adicionar um novo arquivo com o padrão que está sugerindo. Ao fazer contribuições maiores para este livro, revise nosso e também nosso .

Licença das Contribuições