Trilha de aprendizagem: líder do projeto

Esta seção cobre como InnerSource se encaixa com outros aspectos da liderança do projeto, incluindo ágil, código aberto, planejamento de capacidade, e muito mais.

InnerSource para Líderes de Projetos

Depois de completar este segmento, você terá uma melhor compreensão de como InnerSource acelera o desenvolvimento do produto. Também cobriremos como se relaciona com as melhores práticas de desenvolvimento ágil.

Para alcançar agilidade, as organizações se esforçam por equipes autônomas. No entanto, em um mundo complexo e interligado, algumas dependências não podem ser evitadas. InnerSource fornece uma alternativa Equipes que precisam de modificações em suas dependências podem ajudar. InnerSource facilita a colaboração entre equipes. Através de seu foco na comunicação escrita, é bem adequado mesmo para o primeiro modo remoto.

Nesta seção, você aprenderá onde o desenvolvimento ágil e InnerSource usam terminologia similar e até tecnologia – mas diferem substancialmente nos detalhes. Em vez de encontrar mal-entendidos comuns, você se beneficiará de conhecer as diferenças na cultura, mas também com o propósito de ferramentas usadas.

Você entenderá o impacto do InnerSource no planejamento de capacidade. Também com InnerSource não há almoço grátis. Equipes de acolhimento precisam de tempo para mentores. Também veremos as possibilidades de negociação adicionais que a InnerSource traz, mantendo o equilíbrio de dar e receber.

Mas vamos começar com um breve exemplo. Imagine que está construindo um novo aplicativo de música. Para entender como seus usuários estão interagindo com o aplicativo você começa a coletar alguns registros de interação. Com o tempo, você procura mais fundo ao analisar isso, alimentando seus aprendizados de volta ao desenvolvimento. Agora, imagine que outra equipe trazendo conteúdo para sua aplicação também tem algumas necessidades – eles podem querer recompensar criadores de conteúdo com base em quantos usuários alcançaram. Então eles, também começam a usar seus registros coletados. Mas eles precisam de alguns passos adicionais de análise que você não tinha pensado no início. Eles estão agora confrontados com um desafio: construir uma solução, ou passar por seu backlog para ter seu pedido priorizado. Com InnerSource eles terão uma terceira opção: fazer as mudanças com sua ajuda. Claro, isso pode ser mais lento do que se você tivesse feito as mudanças. Mas ainda será mais rápido do que esperar você fazer as modificações.

Em uma organização InnerSource ideal, você pode aumentar isso ainda mais, lembra da última vez que teve que fazer modificações de corte cruzado em toda sua plataforma? Quando vamos “colocá-lo no atraso de cada equipe” isso muitas vezes parece que está se arrastando para sempre. Por outro lado, acelera as coisas substancialmente para fornecer a essas equipes um remendo que implementa a modificação. A complexidade das modificações nessa abordagem depende da maturidade da organização e da manutenção/modularidade do código produzido.

InnerSource e Ágil

Você quer melhorar seu produto e entregar mais rápido aos clientes. Você quer fazer as partes interessadas felizes. InnerSource ajuda sua equipe a oferecer valor e manter autonomia em um mundo altamente interligado.

Organizações tentam entregar valor aos clientes rapidamente. Uma causa comum para atrasos são dependências no processo de entrega. Como resultado, as organizações preferem equipes interfuncionais cobrindo comunicação com o cliente, design, implementação, testes e operações, eliminando a entrega de custos. Para alcançar alto desempenho, as equipes eliminam resíduos e reutilizam componentes existentes. De uma perspectiva de equipe, cada componente reutilizado adiciona outra dependência fora do controle dessa equipe. O lado negativo desta otimização é claro: a equipe depende de outra equipe se precisar de mudanças no componente usado. Para ser capaz de implementar essas discussões muitas vezes longas estão programadas, às vezes levando à necessidade de otimizar prioridades detalhadas globalmente. Em situações complexas, tanto quanto em grandes organizações, isso leva a um aumento no tempo necessário para se ajustar às mudanças nas necessidades dos negócios. Para componentes centrais muito populares muitas vezes há tantos pedidos vindo em que uma equipe de componentes centrais fica sem capacidade para implementar todas as mudanças solicitadas.

Nas organizações tradicionais só existem Duas maneiras de fazer mudanças nas dependências.:

Envie um pedido de recurso/relatório de bugs e aguarde a outra equipe priorizar essa mudança e implementá-la.
Construir uma solução para evitar o bug ou localmente fornecer a funcionalidade necessária.

Se nenhuma dessas opções é bem sucedida normalmente o problema está sendo intensificado e decidido em um nível de hierarquia superior.

Nenhuma solução é particularmente satisfatória. Olhando para o Open Source, embora haja uma solução óbvia, uma equipe dependendo de um componente torna-se uma equipe contribuinte e fornece uma ajuda para a equipe anfitriã.

Agora você pode se perguntar: “Isso não leva ao caos completo onde as pessoas escrevem aleatoriamente em repositórios de códigos de equipes que não são membros?” InnerSource vem com um conjunto de papéis e processos que trazem clareza para o que de outra forma levaria ao caos:

Cada projeto InnerSource tem um conjunto de Trusted Committers com contas claras que vão além de simplesmente revisar código. Trusted Committers estabeleceu as regras para as contribuições.
Contribuições acontecem de forma estruturada:
- A intenção da contribuição é compartilhada cedo para garantir que a contribuição se encaixa na visão e escopo dos projetos.
- O progresso é compartilhado cedo então a equipe anfitriã tem a chance de orientar o contribuinte e guiá-los no caminho para um design e arquitetura desejados. Dessa forma, a frustração devido a ter que recusar uma contribuição tardia no processo é evitada.
- Decisões e comunicação vital acontecem de forma assíncrona para ser capaz de trabalhar em torno de diferentes horários de reuniões de pessoas em diferentes equipes. Como resultado, equipes que contribuem ganham autonomia para consertar artefatos a montante sem sacrificar a qualidade do componente que está sendo contribuído.

Como efeito colateral InnerSource fornece às equipes melhores práticas que facilitam o trabalho em uma primeira cultura remota.

Em vez de trabalhar em silos InnerSource promove a colaboração entre equipes. Em vez de construir cada componente localmente InnerSource promove a reutilização. Reduz o custo de reutilização, fornecendo um caminho claro para apoiar a equipe upstream com o trabalho de consertar bugs e implementar recursos.

Como em Open Source InnerSource promove um pensamento de forças combinadas: componentes que todas as unidades de negócios e equipes de produtos precisam como uma fundação podem ser construídas juntas. Como resultado, todos os barcos estão crescendo juntos, a inovação criada em uma parte da organização pode criar benefícios em toda a corporação. Com equipes que estão familiarizados com InnerSource a carga para mover este tipo de inovação para frente pode ser compartilhada por todas as equipes que se beneficiam e dependem dos componentes e serviços resultantes.

InnerSource dá a sua equipe a iniciativa e ferramentas para corrigir problemas que bloqueiam os recursos de transporte para os clientes. Quando feita a manutenção correta de componentes e serviços centrais pode ser compartilhada de uma forma bem estruturada por uma “equipe virtual InnerSource” que é maior do que qualquer equipe específica de produtos.

Em configurações avançadas, os envolvidos entendem o valor dos contribuintes trabalhando em características mais simples que podem não beneficiar diretamente seus clientes sob a condição de que liberte a equipe anfitriã para trabalhar em mudanças mais complexas que os contribuintes têm uma necessidade de negócios.

Resposta curta: não, de jeito nenhum. Em vez disso, os dois se complementam:

Código bem fatorado e bem testado é um objetivo de qualquer equipe ágil. Em um InnerSource definir os tempos de rampa para os membros da equipe, mas também para colaboradores externos da equipe ficam mais curtos.

Equipes familiarizadas com a colaboração que evitam tarefas estão em boa posição para lidar com contribuições externas de forma flexível. Eles também trazem uma mentalidade e um estilo de comunicação que funciona bem para motivar os contribuintes sobre cuja prioridade eles não têm influência direta. Trabalhar com motivação intrínseca ao invés de dirigir o trabalho significa que as equipes de acolhimento têm as ferramentas para colaborar com os colaboradores.

Equipes emparelhadas para trabalhar em problemas já estão confortáveis em compartilhar progresso mais cedo. Há dois desafios mudando-se para InnerSource de uma cultura única emparelhada: a equipe anfitriã precisa ter tempo para apoiar os contribuintes e agendar isso em seu trabalho planejado. Além disso, quando cruzamos os limites da equipe, muitas vezes é difícil encontrar espaço de tempo para o emparelhamento, nesses casos, deve ser complementado com colaboração assíncrona. Para evitar interrupções frequentes, os membros da equipe geralmente precisam planejar seu dia intencionalmente com mais rigor nas configurações InnerSource. Muitas vezes é mais simples reservar certas horas no dia ou um dia por semana para orientar contribuições. Tornar isso explícito no nível da equipe requer muita pressão dos engenheiros tentando cumprir seus próprios objetivos, mas também ajudando contribuintes. Outro desafio com o emparelhamento é que permite que os pares se movam muito rapidamente juntos, muitas vezes à custa de escrever informações importantes para o resto da equipe. Em uma configuração InnerSource é preciso treinamento para lembrar de trazer todas as decisões relevantes de volta aos canais de comunicação compartilhados para ambos, equipe anfitriã e colaboradores. De uma perspectiva de produto que traz muito mais transparência ao processo de desenvolvimento. Também significa que as decisões que de outra forma poderiam ter sido tomadas no nível de engenharia só agora são visíveis para todos os envolvidos.

Lembra da última vez que insistiu que seu produto fosse bem testado, de preferência com testes automatizados para que implantações possam acontecer com frequência e sem intervenção humana? Este objetivo agora ajuda com InnerSource também: contribuições são muito mais fáceis se os contribuintes puderem verificar localmente se suas mudanças são seguras. Testes também garantem que o time do anfitrião lembre-se de manter a funcionalidade se eles forem lembrados da razão por um teste falhando.

Lembra da última vez que insistiu em sua equipe para seguir o objetivo de “deixar o código em melhor forma do que achou”? Essa mentalidade ajuda no modelo InnerSource, que garante que a qualidade e coesão do código permaneça alta mesmo quando há múltiplas contribuições de diferentes fontes.

InnerSource e Agile usam algumas das mesmas ferramentas para fins diferentes.

Em equipes ágeis, histórias de usuários são uma conversa com o cliente. Muitas vezes são colocadas como notas pegajosas em um quadro branco. Mas também são armazenados em um rastreador de problemas. Como resultado, rastreadores são vistos como ferramentas de planejamento, essencialmente um substituto para notas pegajosas em um quadro branco. Em InnerSource, rastreadores de problemas servem para uma conversa com o cliente, mas também para comunicação entre membros de uma equipe de committers confiáveis e colaboradores trabalhando em um componente comum do InnerSource. Questões em InnerSource se tornam muito mais longas e faladas do que em sua organização média. Eles também rastreiam o histórico de implementação e decisões detalhadas para uma mudança.

Resenhas de código: em organizações tradicionais, revisões de código geralmente servem para fins de auditoria.

Eles são feitos quando o desenvolvimento está terminado. Em InnerSource mudanças de código são compartilhadas muito cedo no processo, às vezes quando nada mais que um esboço é feito. O objetivo é buscar feedback e orientação precoces. Isso é particularmente útil para equipes que estão em horários diversos e não conseguem encontrar tempo para programação de pares. Muitas vezes as equipes têm a aspiração de que ninguém anda sozinho – na realidade, embora isso muitas vezes não é muito mais do que uma aspiração nunca alcançada. Em particular, onde as contribuições cruzam os limites da equipe.

Ferramentas usadas no InnerSource podem formalizar isso pedindo que mais de um ser humano esteja envolvido em qualquer mudança.

O objetivo com InnerSource é que o projeto seja transparente o suficiente para que os desenvolvedores que não fazem parte da equipe possam entender as decisões do projeto e seguir o processo de criação de software. Como resultado, toda a comunicação precisa estar em um lugar que todos os interessados na conversa podem seguir: escrita, pública, pesquisável e conectável. O objetivo não é reduzir as distrações aos outros. O objetivo é tornar todas as conversas do projeto transparentes.

Como resultado, mensagens e e-mails diretos devem ser evitados. Para facilitar o acompanhamento das conversas por todos, as mensagens relacionadas a um projeto InnerSource devem ser reunidas em um canal de comunicação separado: o objetivo não é alcançar cada pessoa da equipe do projeto InnerSource. O objetivo é encontrar uma sala comum compartilhada para todos envolvidos com o projeto onde possam ter discussões focadas no projeto InnerSource.

Focar na comunicação escrita não significa que a comunicação verbal seja proibida. Ainda precisa haver tempo para uma xícara de café compartilhada. Também resolver problemas juntos, emparelhar-se com outros ou em pessoa hackathons são valiosos para encontrar soluções rapidamente. A equipe precisa ter certeza de que todas as decisões relevantes do projeto são mantidas em canais aos quais todos têm acesso. Isso também pode significar adiar decisões importantes do projeto até que todos voltem de férias ou esperem por mais um dia ou dois se aqueles que trabalham em outro país estiverem de férias. Isso não só é relevante para decisões de codificação, mas também se refere à missão geral do projeto, roteiro e direção. Sem essa informação, os contribuintes terão dificuldade em entender quais contribuições terão boas chances de serem aceitas.

Todas as discussões em projetos InnerSource são visíveis para todos na empresa. Culpar as pessoas por seus erros, ridicularizá-las por seus erros, falar pelas costas sobre o que fizeram de errado é uma maneira segura de matar essa confiança e levar ao fracasso do projeto InnerSource. Isso é particularmente importante para qualquer um em uma posição de liderança ou modelo.

InnerSource e Planejamento

O planejamento desempenha um papel em InnerSource em duas situações importantes:

Equipes contribuintes precisam entender que trabalhar em código upstream normalmente precisa de mais tempo do que fazer mudanças comparáveis em sua própria base de código que eles estão bem familiarizados. Eles precisam estar cientes do fato de que mesmo que a equipe anfitriã não precise implementar a mudança que eles ainda precisam estar disponíveis para orientação e revisão. O tempo necessário para isso aumenta com o tamanho da mudança necessária. Como resultado, a comunicação precoce com a equipe anfitriã é importante em particular em casos de mudanças maiores.

Equipes também precisam estar cientes do tempo necessário para orientar e revisar. Simplesmente dizendo às equipes contribuintes que elas podem enviar mudanças como patches não reduz o tempo para fazer a mudança para zero para a equipe anfitriã. Além disso, equipes hospedeiras podem se encontrar na rara situação onde são inundadas com pedidos de retirada. Para esse evento, precisa haver uma compreensão clara das prioridades de negócios dos projetos que enviam esses pedidos. Quando sobrecarregado com remendos, é hora de pensar em compartilhar a propriedade do componente. Em particular, os contribuintes que estão voltando regularmente e ganharam confiança da equipe anfitriã são bons candidatos para receber o título Trusted Committer.

Alguns atritos devido a uma cultura de trabalho ligeiramente diferente não podem ser evitados. Para estes casos é importante definir explicitamente expectativas.

Imagine a seguinte situação: como contribuinte você finalmente fez a mudança necessária – provavelmente com uma pequena ajuda da equipe anfitriã. Você orgulhosamente submete o pedido de retirada. Então… nada acontece. Um dia depois – ainda sem reação. Você começa a se perguntar se a equipe anfitriã viu o seu patch. Você quer saber onde melhor chamar a equipe sobre uma atualização. Este silêncio é muito frustrante em particular para os contribuintes da primeira vez. Existem vários remédios para esta situação – remédios que não precisam de conhecimento de codificação, mas requerem pelo menos algumas habilidades básicas de comunicação:

Faça momentos de reação que podem ser esperados da equipe anfitriã explicitar – por exemplo, na documentação contribuinte.
Assim que um pedido for recebido, comunique o tempo esperado para receber um retorno substancial ao invés de deixar os contribuintes esperarem.
Comunique-se com os contribuintes para entrar em contato com a equipe anfitriã e assistir comunicação lá.

Nenhuma dessas tarefas precisa de habilidades de escrita de código. Isso reforça a necessidade de pessoas além daqueles que têm conhecimento de programação. É uma boa prática considerar as pessoas cobrindo essas tarefas como comprometidas com o projeto InnerSource e incluí-las como Trusted Committers também.

Pequenas mudanças e remendos são fáceis de manusear – eles são rápidos de rever e muitas vezes não carregam muito risco quando fundido. Uma maneira de ajudar equipes anfitriãs é ter tempo para dividir mudanças em pedaços menores. Certifique-se de comunicar o contexto mais amplo a que essas mudanças pertencem.

Muitas vezes, fazer mudanças maiores requer comunicar intenção e propósito cedo. Também pode ser benéfico garantir que equipe contribuinte e equipe anfitriã tenham tempo suficiente para trabalhar na mudança juntos. Isso significa que as pessoas que definem as prioridades da equipe precisam pensar além de sua própria equipe quando priorizam mudanças. No entanto, coordenação ainda pode acontecer de forma independente, como normalmente apenas o par de colaboradores e equipe anfitriã estão envolvidos.

Raramente equipes hospedeiras correm para o desafio de receber muitos patches de equipes contribuintes. Nesse caso, ajuda a pensar em mover contribuidores confiáveis para o papel Trusted Committer. Além de simplesmente ajudar com críticas, o novo Trusted Committers pode ajudar na triagem de problemas, mentorando novos contribuintes e coisas assim.

Quando confrontado com um grande interesse em contribuições um fator adicional a considerar quando priorizar a ajuda de mentores para contribuidores pode ser o interesse dos contribuintes em uma relação de longo prazo com a equipe anfitriã. Quanto mais tempo for necessário para ser mentor, mais provável deve ser para os contribuintes ficarem por mais tempo.

Na prática, compartilhar a propriedade do componente com contribuidores muito ativos provou manter o recém-criado Trusted Committers envolvido com o projeto por um período mais longo de tempo. Normalmente eles ajudam a manter o componente atualizado e orientar novos contribuintes muito depois que a motivação inicial para a contribuição foi abordada.

InnerSource e habilidades de negociação

Codificação e negociação? Você pode se perguntar como esses dois vão juntos. Em particular para as equipes anfitriãs InnerSource ajuda a ter alguns obstáculos em mente quando se trata de mudar a negociação.

Como discutido no último segmento de treinamento, mudanças de código menores tendem a ser aceitas mais rápido. Para a equipe anfitriã as vantagens são claras e devem ser comunicadas às equipes contribuintes:

São mais fáceis de rever.
Eles têm menos impacto – ambos, positivo e negativo.
Eles são mais rápidos para integrar.

Como resultado, fazer pequenas mudanças na moda ad hoc normalmente causa pouco ou nenhum atrito. Eles são um bom ponto para contribuições e muitas vezes podem ser tratados sem muito apoio de coordenação. Normalmente é assim que começam as contribuições InnerSource: engenheiros em equipes começam a colaborar em mudanças menores e acham que funcionam muito fácil e leve. Mudanças menores também são mudanças que tendem a passar sem necessidade de escalada.

Isso pode fazer com que as equipes adotem uma mentalidade onde InnerSource é apenas para os engenheiros de software. No entanto, este modelo de trabalho ad hoc se rompe assim que o alcance das contribuições aumenta. Se mantido puramente para engenheiros de software, no pior dos casos, mesmo com empurrar para trás de outros papéis nas equipes isso significa que as escaladas vão acontecer muito mais frequentemente. Para modificações com um escopo maior outros papéis na contribuição e na equipe anfitriã precisa estar ciente do trabalho InnerSource e precisa trazer suas habilidades para a mesa:

Juntos, as duas equipes precisam descobrir um bom momento para trabalhar na contribuição. Se a equipe anfitriã não tem tempo para orientar a equipe contribuinte é mais provável que fique frustrada por falta de apoio. Eles também podem ser mais propensos a desenvolver uma solução que é provável que precise de um monte de retrabalho causando frustração para todos envolvidos. Se a equipe contribuinte não tiver tempo para se concentrar nos ciclos de refinamento da contribuição para as mudanças pode se tornar muito longa e interrupções muito altas.
Antes de qualquer código fonte ser escrito, o contribuinte e a equipe anfitriã precisam descobrir se as mudanças se encaixam na visão do projeto InnerSource. Idealmente isso também significa que tecnologia e nível de negócios precisam se unir, de preferência no mesmo canal de comunicação onde todos podem participar. Muitas vezes isso resulta em negociações sobre se as mudanças devem ser feitas no projeto InnerSource – com manutenção posteriormente coberta pela equipe anfitriã. Pode significar que os envolvidos precisam esclarecer qual é o valor para todos os envolvidos, mas também se e como a equipe contribuinte pode ajudar a equipe anfitriã a diminuir a carga de manutenção.

“Apenas escreva o código e nos envie seu patch” – parece fácil. Exceto que na realidade isso só é verdade para as mudanças mais triviais. Em particular, mudanças maiores precisam de coordenação para que todos os envolvidos tenham tempo de participar. Caso contrário, espera-se mais tempo de espera. Cruzar os limites da equipe também significa mudanças sutis na cultura da comunicação. Pessoas que são fortes comunicadores podem ajudar a cruzar essas lacunas traduzindo entre equipes em caso de mal-entendidos.

Em contraste com equipes trabalhando apenas no código local, as equipes de acolhimento InnerSource precisam ter certeza de que seu roteiro e visão são comunicados com todos os potenciais contribuintes. Além disso, a equipe anfitriã precisa ter certeza de que os requisitos de design, arquitetura e desempenho são explícitos e claros para todos trabalhando na base de códigos, incluindo contribuintes ocasionais. Esta transição é particularmente difícil para as equipes costumavam trabalhar em ambientes locais muito coesos. Essencialmente, tudo que em uma equipe local é claro implicitamente precisa ser transparente e explícito. A curto prazo, isso custa tempo. A longo prazo, ajuda os contribuintes a se atualizarem mais rápido, exigindo menos apoio da equipe anfitriã. Uma coisa que foi provada como bem sucedida na Open Source é facilitar para os contribuintes seguirem o caminho certo. Isso inclui verificações automáticas de qualidade que falham na construção. Enquanto demora para escrever e manter aqueles tirar o trabalho dos ombros da equipe anfitriã como questões óbvias são destacadas automaticamente.

Uma diferença com InnerSource para negociações regulares entre equipes são oportunidades de pensar fora da caixa: imagine um contribuinte Bob que precisa de uma mudança muito complexa no projeto InnerSource mantido por Alice. Bob está começando a entender a base de códigos e teria dificuldade em entender sozinho. Além disso, orientá-lo através do processo levaria Alice muito tempo. No entanto Alice tem várias prioridades, mas fácil de implementar características em seu backlog. E se Bob tirou algum desses problemas do histórico dela e os implementou em troca Alice tem tempo para trabalhar na mudança que Bob precisa? Por uma questão de transparência, esses acordos devem ser explicados para ambos, a equipe anfitriã e a equipe contribuinte. Caso contrário, eles terão dificuldade em entender por que Bob e Alice não estão trabalhando nas mudanças que cada um de seus clientes precisa.

Por outro exemplo, imagine uma equipe anfitriã que está trabalhando em um projeto InnerSource muito popular. Provavelmente é central para os negócios da empresa. Com o tempo, cada vez mais contribuidores são capazes de fazer as mudanças que precisam transformando a equipe anfitriã em um gargalo de revisão. Para lidar com essa questão, uma perspectiva clara sobre as prioridades gerais de negócios e importância das equipes contribuintes ajuda a entender quais os patches para priorizar e impedir os membros da equipe anfitriã de mudar de foco constantemente. Como próximo passo, a equipe anfitriã precisa pensar em expandir o número de Trusted Committers trabalhando no projeto InnerSource. Como mencionado anteriormente, uma opção poderia ser convidar pessoas comprometidas com o projeto que se reportam a uma linha de negócios diferente.

Em particular, quando confrontados com um monte de contribuições que são bastante complexas, equipes anfitriãs precisam entender onde o tempo investir para mentores contribuintes é um investimento digno. Quanto mais tempo for necessário para ser mentor, mais provável será que esses contribuintes tenham tempo para ficar por mais tempo.

Opções para propriedade compartilhada

Organizações tradicionais preferem ter um único ponto de contato em caso de problemas. Por outro lado, permitir que simplesmente todos façam mudanças certamente resultará em uma bagunça que não pode mais ser mantida.

Baseado nessa observação, cada projeto InnerSource tem uma equipe dedicada de Trusted Committers. O interesse em manter um projeto InnerSource muitas vezes é motivado pelo interesse próprio esclarecido: uma equipe entendendo que eles mesmos precisam do projeto InnerSource para satisfazer as necessidades de seus clientes e entendendo que abrir o projeto para contribuições pode espalhar a carga de trabalho para avançar o projeto. Abrir um projeto para contribuições não significa que Trusted Committers tenha que aceitar todas as submissões. É a equipe do Trusted Committers que define a missão e objetivos para o projeto. Eles estão em posição de definir a direção e decidir a aceitação da mudança de acordo.

“Compromissores confiáveis são responsáveis por um projeto InnerSource. Eles revisam submissões e colaboradores.”

Este é um resumo muito simplista do papel de um Trusted Committer. Na realidade, uma das primeiras perguntas muitas vezes gira em torno da necessidade de aceitar cada contribuição. Em particular, onde os contribuintes já investiram muito tempo nas contribuições pode ficar frustrado ao ouvir que seu trabalho foi em vão. Habilidades de comunicação são importantes para garantir que os contribuintes saibam como é o roteiro do projeto InnerSource. Eles também são necessários para garantir que os contribuintes saibam compartilhar intenção e progresso muito cedo para evitar gastar muito trabalho sem resultados. Por último, mas não menos importante, rejeitar contribuições precisa de boas habilidades de comunicação. Resumindo, mesmo que não esteja escrevendo o código fonte, seu apoio é necessário para comunicar claramente a visão do projeto InnerSource, para ajudar quando as contribuições precisam ser rejeitadas. Outro aspecto que se torna mais importante à medida que o projeto InnerSource se torna mais popular: revisão e orientação tornam-se mais intensivas e ao longo do tempo precisam ser programadas para o dia explicitamente. Isso tem impacto no planejamento geral de capacidade e não deve acontecer “sob o radar”.

Por outro lado, para os contribuidores, é importante que a revisão de código não seja uma última etapa. Em vez disso, é uma maneira de orientar continuamente os contribuintes através do processo de desenvolvimento de código idealmente levando a melhores resultados mais rápido. Para que isso funcione na prática, precisa haver tempo e espaço para a formação de equipes, mas além dos limites tradicionais da equipe. Ter pelo menos uma vaga compreensão das diferentes culturas em equipes torna mal-entendidos muito menos prováveis e o processo de contribuição muito mais suave.

Em particular, quando as equipes anfitriãs são inundadas de contribuições líderes de projetos que de outra forma se concentram apenas em sua equipe local precisa ter uma perspectiva mais global: * Ajude a equipe a entender diferentes prioridades para as contribuições recebidas dependendo da estratégia geral da empresa. Muitas vezes nem todas as contribuições são igualmente urgentes. Você pode ajudar sua equipe comunicando com os contribuintes se a integração da mudança demorar um pouco mais. Muitas vezes isso ainda é muito mais rápido do que sua equipe fazendo todo o trabalho por conta própria. Em particular, os contribuintes da primeira vez podem precisar de ajuda, em particular para mudanças maiores. Coordenar o momento em torno dessa orientação pode ser uma grande ajuda para sua equipe.

“Mas nós poderíamos simplesmente gargarejar permanentemente” … um equívoco onde potenciais equipes de convidados acreditam que simplesmente copiar o código seria mais rápido.

A curto prazo isso é verdade. A longo prazo, significa manutenção adicional. Como líder de projeto, você pode ajudar sua equipe a entender por que contribuir com mudanças no projeto que você depende é do melhor interesse do negócio, menos trabalho em geral. Manutenção a longo prazo é assumida pela equipe anfitriã.

“Estamos usando pedidos para desenvolver nosso componente, então estamos usando InnerSource diariamente”. Ao usar requisições e avaliações é um componente crucial, é apenas a linha de base para projetos InnerSource. Só porque dois projetos dependem do uso de pedidos diários não significa que a abertura deles para contribuições externas seja a mesma.

InnerSource vem com diferentes melhores práticas. Para evitar confusão e frustração para os contribuintes, é importante que as equipes de acolhimento definam para seu projeto InnerSource qual modelo de governança eles querem adotar. Como em Open Source, esses níveis de governança podem ser substancialmente diferentes.

No InnerSource Commons fornecemos um padrão InnerSource que define pelo menos três níveis de governança: Por fora, isso pode parecer o seu projeto InnerSource diário. Fazer a recusa de ser mentor e aceitar contribuições explícitas evita confusão de colegas tentando interagir com o projeto através de meios InnerSource. Em vez disso, isso se comunica com aqueles que dependem do projeto que só os pedidos de recursos e relatórios de bugs podem ser tratados pela equipe. Essencialmente, isso significa voltar a um projeto tradicional de desenvolvimento de software. * O código-fonte é visível para todos, e a equipe de Trusted Committers reservou tempo para orientar os colaboradores. Para esses projetos, remendos e pedidos são bem-vindos. A equipe do Trusted Committers garante que a comunicação relevante do projeto aconteça em um canal escrito, arquivado, pesquisável e conectável. A equipe também garante que as decisões relevantes do projeto sejam tomadas onde os contribuintes possam vê-las e segui-las. A decisão final, porém, cabe à equipe de Trusted Committers, e tornar-se Trusted Committer do projeto está vinculado a trabalhar na equipe inicial. * Como acima, mas a equipe de Trusted Committers está aberta à ideia de compartilhar o acesso de escrita. Essa abordagem requer um processo para construir confiança suficiente com contribuidores para a equipe do Trusted Committers compartilhar acesso de escrita. Isso é particularmente útil quando há uma relação de longo prazo com contribuintes. No estágio final, a equipe do Trusted Committers também está pronta para compartilhar controle sobre quem tem acesso de escrita, bem como visão de projeto e missão. Embora isso muitas vezes resulte no mais alto nível de comprometimento dos contribuintes, também requer um alto nível de coordenação cruzando os limites da equipe. Também requer o mais alto nível de transparência ao tomar decisões sobre o projeto.

Para resumir cada nível de governança precisa de uma abordagem diferente de colaboração e coordenação.

O que está implicitamente claro para os membros da equipe é melhor explicitado e documentado se o projeto gostaria de incentivar contribuições. Tópicos como * Tempos de resposta para esperar ao enviar alterações, * canais de comunicação para usar ao entrar em contato com a equipe de Trusted Committers, * canais de comunicação para usar ao tentar seguir o projeto como um contribuinte * níveis de governança para esperar do projeto são todos os tópicos que a equipe anfitriã inteira tem que concordar e se comunicar com os contribuintes.

O aumento do compartilhamento de responsabilidades para projetos InnerSource também tem impacto em avaliações de desempenho. Em contextos hierárquicos, muitas vezes consideram contribuições locais para a equipe. Contribuidores InnerSource no entanto estão começando a ter um impacto fora de suas próprias equipes. InnerSource Trusted Committers tem um impacto em equipes que podem estar fora do alcance de sua própria equipe. Isso significa que gerentes de linha direta estão perdendo um certo nível de controle. Eles também estão perdendo a supervisão direta. Como resultado, o feedback de desempenho de equipes potencialmente remotas deve ser levado em conta.

Uma boa prática para equipes interfuncionais é construir e executar. Com contribuições potencialmente vindas de usuários a jusante esta melhor prática parece quebrar. Existem várias maneiras de usar InnerSource nesse contexto também:

A opção número um é mover-se para uma maior modularização e colaborar apenas nas partes que são as mesmas entre as equipes e manter as operações locais.
Alternativamente, trabalhe com testes de contrato para evitar quebras na API.
Trabalhar com acordos internos de nível de serviço, fazer contribuintes se inscreverem em períodos de garantia para remover o medo da equipe anfitriã de que as contribuições quebram os sistemas de produção.

Relação com o Código Aberto

InnerSource é a aplicação das melhores práticas de colaboração Open Source dentro dos limites das corporações. Isso torna a compreensão de dois aspectos da Open Source mais fácil para equipes através de paralelos com InnerSource:

Assim como em InnerSource, projetos Open Source têm diferentes níveis de governança. Nem todos os projetos Open Source são criados iguais, enquanto alguns grupos só publicam o código fonte, esperando que nenhuma interação, outros querem que usuários a jusante se tornem ativos e enviem patches. Outros projetos têm processos configurados para permitir o impacto no projeto Open Source. Entender esses níveis de governança significa que decidir qual projeto de código aberto usar em casa também levará em consideração a governança de código aberto. Um usuário a jusante de um projeto InnerSource terá aprendido a avaliar corretamente o equilíbrio entre mover-se rápido, mas ser incapaz de influenciar um projeto vs. mover-se em um ritmo mais lento, mas ser capaz de influenciar um projeto juntos.

Trabalhar em projetos InnerSource ajuda as equipes a praticar o que significa compartilhar o custo e o esforço para construir plataformas juntas. Compartilhar o trabalho entre as equipes ajuda a inovar mais rápido no geral: equipes de produtos com diferentes áreas de foco podem unir forças para desenvolver uma plataforma base necessária mais rápido e compartilhar a carga de manutenção resultante.

A mesma dinâmica impulsiona vários projetos Open Source também. Entender isso significa que a participação nesses projetos é natural para qualquer equipe que tenha experiência com InnerSource. Saber que dinâmica da experiência prática também torna mais fácil para as equipes reconhecerem quais projetos de código aberto estão sendo desenvolvidos de acordo com esses princípios. Tipicamente, este entendimento também tem um impacto no qual as equipes de projetos Open Source decidem usar internamente.

Recursos que muitas equipes precisam podem ser criados colaborando em vez de reimplementá-los localmente várias vezes. Isso torna mais fácil entender o conceito de como compartilhar esforços pode ajudar a tornar a torta maior para todos e como pode ajudar a impulsionar os padrões da indústria se feita de forma aberta, em vez de apenas internamente.

Em termos de mecânica ambas as práticas são muito semelhantes. A maior diferença é a visibilidade dos projetos, para InnerSource que é limitado à corporação, para Open Source eles são públicos.

Parece que uma pequena diferença no papel é uma grande diferença na prática. Ir ao Código Aberto significa que cada mensagem é visível publicamente e potencialmente arquivada para sempre. Esta implicação pode ser muito desconfortável em particular para funcionários não acostumados a esse modo de trabalhar. Além disso, todas as ações sendo públicas significa que elas também estão disponíveis para o escrutínio público – não podem mais ser examinadas por especialistas em comunicação corporativa. Artefatos produzidos da mesma forma estão disponíveis para o escrutínio público no que diz respeito à conformidade de licenças, segurança e afins – por exemplo, para concorrentes, para potenciais novos contratos futuros, para clientes.

Por outro lado, também abre a porta para a colaboração com outros fora dos muros de uma corporação – levado ao extremo que pode resultar em co-opição onde concorrentes unem forças para construir uma plataforma técnica comum, inovando e competindo uns contra os outros em cima disso.

Ir de código aberto também reduz as implicações fiscais de colaborar através dos limites das pessoas jurídicas. Enquanto a transferência é um tópico quente para muitos esforços InnerSource é irrelevante para qualquer projeto Open Source.

Enquanto “e sobre publicar projetos como Open Source” é o primeiro pensamento quando se fala em se tornar ativo no espaço Open Source. Quando experiente com InnerSource fica claro que publicar projetos inteiros é apenas uma forma de ser ativo no espaço aberto.

Em vez disso, é muito mais natural adotar um ponto de vista iluminado de interesse próprio: * Onde as equipes usam certas dependências de Código Aberto em partes vitais de seus componentes, é importante garantir que estejam envolvidas a montante – mesmo que o único objetivo seja entender o futuro roteiro do projeto. * Onde as equipes têm necessidade de mudanças em projetos de código aberto de que dependem, a experiência com InnerSource torna óbvias as vantagens de participar a montante: Claramente não se trata apenas de uma mentalidade de “partilhamento é cuidar” – mas tem benefícios econômicos claros onde equipes contribuintes têm uma sobrecarga de manutenção altamente reduzida se suas mudanças forem integradas a montante.

Dando mais um passo para trás, até mesmo a decisão de qual projeto Open Source adotar e usar internamente será influenciada pela experiência InnerSource de uma equipe: * InnerSource treina equipes para entender o que procurar em termos de colaboração e comunicação – de experiência pessoal eles entenderão por que é importante para o projeto ter canais de comunicação claros, arquivados e pesquisáveis. Eles também entenderão por que é importante que toda decisão relevante sobre o projeto seja tomada nesses canais de comunicação. * Ao compreender os diferentes níveis de governança em InnerSource, as equipes estarão bem preparadas para entender as implicações de projetos de código aberto que operam com diferentes níveis de abertura.