Skip to content

Commit

Permalink
Update Learning Path articles
Browse files Browse the repository at this point in the history
  • Loading branch information
@github-actions
github-actions[bot] committed Aug 16, 2023
1 parent d6c7aca commit cc3838d
Show file tree
Hide file tree
Showing 12 changed files with 661 additions and 2 deletions.
27 changes: 27 additions & 0 deletions content/en/learn/learning-path/introduction/01.pt-br.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
title: Introdução
contributors:
- name: Fernando Correa
url: https://github.com/fer-correa
- name: Armando Guimarães
url: https://github.com/ArmandoGuimaraes
- name: rrrutledge
url: https://github.com/rrrutledge
image: https://img.youtube.com/vi/l93ohSHhr5U/mqdefault.jpg
featured: true
weight: 1
youtubeCode: l93ohSHhr5U
---
<div class="paragraph">
<p>Esta Trilha de Aprendizado fornece uma introdução ao InnerSource.
InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa.
O software InnerSource permanece proprietário da empresa, mas dentro dela está aberto para qualquer pessoa usá-lo e contribuir com ele.
Essa estratégia permite uma colaboração ampla e eficaz, produzindo software responsivo e ágil para as necessidades em constante mudança de seus muitos interessados internos.</p>
</div>
<div class="paragraph">
<p>Esta Trilha de Aprendizado ensina como reconhecer situações que são boas candidatas para o InnerSource.
Descreveremos em alto nível como o InnerSource pode ajudar nessas situações.
Você se familiarizará com os termos compartilhados usados ao discutir o InnerSource.
Também enumeraremos os princípios-chave nos quais o InnerSource se baseia e os benefícios vistos quando ele é aplicado de forma eficaz.</p>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
75 changes: 75 additions & 0 deletions content/en/learn/learning-path/introduction/02.pt-br.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
title: Quais problemas o InnerSource resolve?
contributors:
- name: Fernando Correa
url: https://github.com/fer-correa
- name: Armando Guimarães
url: https://github.com/ArmandoGuimaraes
- name: rrrutledge
url: https://github.com/rrrutledge
image: https://img.youtube.com/vi/v9fL-E3ZVdc/mqdefault.jpg
featured: false
weight: 2
youtubeCode: v9fL-E3ZVdc
---
<div class="paragraph">
<p>A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa.
Essa abordagem difere do que é visto em organizações tradicionais, onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos.
Vamos explorar uma situação que dá um exemplo dessa ideia.</p>
</div>
<div class="paragraph">
<p>Imagine duas equipes na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra.
Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição.
Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.</p>
</div>
<div class="paragraph">
<p>Quando as equipes de consumo precisam de muitos recursos, as equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir em quais recursos trabalharão.
Para solicitações de recursos críticos que não são priorizadas para trabalho imediato, a equipe de consumo geralmente pode escolher uma das três opções abaixo, cada uma com suas próprias desvantagens.</p>
</div>
<div class="olist arabic">
<ol class="arabic">
<li>
<p><strong>Espere</strong>. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada.
Esta opção requer a menor quantidade de trabalho do seu lado.
Dependendo do benefício da solicitação de recurso, esperar pode ser bom.
No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.</p>
</li>
<li>
<p><strong>Gambiarra</strong>. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado.
Este trabalho extra pode vir como mudança no projeto alvo.
Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto).
Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.</p>
<div class="olist loweralpha">
<ol class="loweralpha" type="a">
<li>
<p>Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.</p>
</li>
<li>
<p>A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.</p>
</li>
<li>
<p>A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.</p>
</li>
</ol>
</div>
</li>
<li>
<p><strong>Escalar</strong>. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho.
Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo.
No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia.
Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade.
A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.</p>
</li>
</ol>
</div>
<div class="paragraph">
<p>Esta discussão prepara o terreno para o InnerSource.
O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso.
O InnerSource fornece uma maneira para as equipes obterem os benefícios de <em>esperar</em>, <em>solução alternativa</em> e <em>escalar</em> sem as desvantagens associadas.</p>
</div>
<div class="paragraph">
<p>O InnerSource também oferece uma melhoria geral à cultura de engenharia, pois os engenheiros têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas.
Os desenvolvedores orientam e aprendem uns com os outros enquanto compartilham ideias e soluções em silos organizacionais.
Engenheiros e equipes podem reutilizar soluções internas para problemas de commodities, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.</p>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
81 changes: 81 additions & 0 deletions content/en/learn/learning-path/introduction/03.pt-br.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
---
title: Como funciona o InnerSource?
contributors:
- name: Fernando Correa
url: https://github.com/fer-correa
- name: Armando Guimarães
url: https://github.com/ArmandoGuimaraes
- name: rrrutledge
url: https://github.com/rrrutledge
image: https://img.youtube.com/vi/jPPwnaEBd8U/mqdefault.jpg
featured: false
weight: 3
youtubeCode: jPPwnaEBd8U
---
<div class="paragraph">
<p>Digamos que a equipe A use um software produzido pela equipe B.
A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A.
Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request.
Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código.
Integrantes da Equipe B para revisar e aceitar o código enviado.</p>
</div>
<div class="paragraph">
<p>Neste exemplo, chamamos a equipe A de equipe <em>Guest</em> e a equipe B de equipe <em>Host</em>.
Os termos <em>Guest</em> e <em>Host</em> sugerem uma situação análoga a receber um visitante em casa.
Nessa situação, a maioria das pessoas quer ser um bom anfitrião.
Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados.
Os visitantes são recebidos na porta e convidados a entrar.
Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa.
Pode haver algumas regras da casa que os hóspedes devem seguir.
Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião.
Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia.
Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados.
Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.</p>
</div>
<div class="paragraph">
<p>Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar.
Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões.
Primeiro, o <a href="https://innersourcecommons.org/learn/learning-path/product-owner"><em>Product Owner</em></a> determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição.
O <a href="https://innersourcecommons.org/learn/learning-path/contributor"><em>Contributor</em></a> é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã.
O <a href="https://innersourcecommons.org/learn/learning-path/trusted-committer"><em>Trusted Committer</em></a> representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request.
Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.</p>
</div>
<div class="paragraph">
<p>Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.</p>
</div>
<div class="ulist">
<ul>
<li>
<p>A equipe convidada ou c solicita um recurso da equipe anfitriã.</p>
</li>
<li>
<p>O Product Owner garante que as histórias do usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã.
Essas histórias devem descrever o recurso solicitado em termos aceitáveis para a equipe convidada.
Eles também listam todos os detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito.
Exemplos de tais detalhes incluem restrições de arquitetura, convenções de codificação, usos de dependência, contratos de dados, etc.</p>
</li>
<li>
<p>Apoiado pelo Trusted Committer, o Contributor envia o pull request para implementar o recurso solicitado.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.</p>
</div>
<div class="paragraph">
<p>Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução.
Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores.
Funciona para a empresa como um todo porque as soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente, onde qualquer um pode usá-los.
Mais tempo de engenharia permanece focado na produção de código que resolve os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.</p>
</div>
<div class="sect2">
<h3 id="_recursos_adicionais">Recursos Adicionais</h3>
<div class="ulist">
<ul>
<li>
<p>O padrão <a href="https://patterns.innersourcecommons.org/p/trusted-committer">Trusted Committer</a>.</p>
</li>
</ul>
</div>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
51 changes: 51 additions & 0 deletions content/en/learn/learning-path/introduction/04.pt-br.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
title: Quais são os benefícios do InnerSource?
contributors:
- name: Fernando Correa
url: https://github.com/fer-correa
- name: Armando Guimarães
url: https://github.com/ArmandoGuimaraes
- name: rrrutledge
url: https://github.com/rrrutledge
image: https://img.youtube.com/vi/PFLmOWCEpi4/mqdefault.jpg
featured: false
weight: 4
youtubeCode: PFLmOWCEpi4
---
<div class="paragraph">
<p>Há muitos benefícios em colaborar via InnerSource.
O InnerSource oferece à empresa uma estratégia escalável para <strong>equipes convidadas obterem solicitações de recursos quando precisarem</strong> sem o ônus de manutenção de longo prazo.
A empresa como um todo ganha à medida que o tempo das equipes convidadas é colocado em código que outras pessoas podem usar.</p>
</div>
<div class="paragraph">
<p>Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para as equipes anfitriãs que recebem contribuições regulares do InnerSource.
Lembre-se de que, como parte do processo InnerSource, o Product Owner na equipe anfitriã concorda desde o início que os recursos fornecidos são bons e desejáveis.
A InnerSource permite que a equipe anfitriã receba <strong>ajuda na criação de um produto melhor</strong> para seus consumidores!</p>
</div>
<div class="paragraph">
<p><strong>InnerSource fornece à equipe anfitriã uma estratégia escalável</strong> para atender a quantidades variadas de recursos solicitados por seus muitos consumidores.
Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exijam quantidades muito (ou mesmo irracionais) de trabalho a serem feitas nos produtos da equipe anfitriã.
Sem o InnerSource, essa situação leva facilmente a uma equipe estressada e sobrecarregada lidando com muitas solicitações de recursos encaminhadas a seus líderes.</p>
</div>
<div class="paragraph">
<p>No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir esses recursos aparecerão proporcionalmente à sua importância na forma de contribuidores convidados.
<strong>InnerSource torna-se um multiplicador de força</strong> que permite que a equipe anfitriã aja temporariamente maior do que seu tamanho real durante períodos de alta demanda.
Quando a demanda termina, o rendimento da equipe volta aos níveis normais, tudo sem qualquer microgerenciamento do número de funcionários ou itens de trabalho da equipe.
O InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa dele em um determinado momento.</p>
</div>
<div class="paragraph">
<p>Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, as contribuições regulares do InnerSource fornecem à equipe anfitriã <strong>melhores requisitos e alinhamento de priorização com todos os seus consumidores</strong>.
Uma equipe anfitriã pode fazer o melhor levantamento de requisitos sobre o trabalho que produz, mas quando o próprio consumidor é quem está enviando o trabalho, as chances são muito maiores de que a mudança resultante esteja alinhada exatamente com o que o consumidor precisa.
Embora possa ser apenas uma única equipe convidada enviando a alteração, essa equipe provavelmente representa muitos outros consumidores.</p>
</div>
<div class="paragraph">
<p>Além desse alinhamento, há também um treinamento geral e educação de <a href="https://innersourcecommons.org/learn/learning-path/contributor">contribuidores</a> enquanto eles trabalham e aprendem com <a href="https://innersourcecommons.org/learn/" class="bare">https://innersourcecommons.org/learn/</a> Learning-path/trusted-committer[trusted committers].
Essa interação ajuda os colaboradores a aprender e crescer em suas carreiras, resultando em <strong>maior satisfação no trabalho</strong>.
A documentação do projeto melhora para permitir essas contribuições em escala.
Os contribuidores sentem uma participação no projeto da equipe anfitriã.
É algo que eles recomendam a seus colegas ou novas equipes que eles ingressam.
Eles entendem melhor o projeto e são capazes de responder a perguntas sobre ele para outras pessoas, aliviando a equipe de acolhimento de um pouco desse fardo.
Mais pessoas contribuindo para um projeto naturalmente polinizam ideias de toda a empresa.
Esse aprendizado e alinhamento entre equipes ao longo do tempo serve para <strong>quebrar os silos tradicionais da empresa</strong>.</p>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
Loading

0 comments on commit cc3838d

Please sign in to comment.