Modelo de Maturidade

Title

Modelo de Maturidade

Patlet

As equipes come√ßaram a adotar o InnerSource. A pr√°tica est√° se espalhando para v√°rios departamentos. No entanto, a compreens√£o do que constitui um projeto InnerSource varia. A solu√ß√£o √© fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavalia√ß√£o e descubram padr√Ķes e pr√°ticas das quais ainda n√£o t√™m conhecimento.

Problema

Quando a ado√ß√£o do InnerSource em uma empresa come√ßa a aumentar, o acompanhamento individual de cada projeto por meio de um evangelista se torna invi√°vel. Al√©m disso, cada vez mais pessoas est√£o adquirindo pelo menos uma compreens√£o b√°sica do que significa trabalhar em um projeto InnerSource. No entanto, ao observar todos os projetos InnerSource, a profundidade de compreens√£o do conceito divergir√°. As equipes podem n√£o estar cientes de padr√Ķes comprovados que as ajudariam a avan√ßar para o pr√≥ximo n√≠vel e a resolver problemas e pontos de dor com os quais est√£o lidando.

Contexto

Diversas equipes começaram a adotar práticas de InnerSource. O nível exato de compreensão da prática varia entre as equipes. Os problemas específicos com os quais as equipes se deparam divergem dependendo do contexto e ambiente de trabalho de cada equipe. Como resultado, a definição do que são práticas recomendadas importantes em um projeto InnerSource difere conforme cada equipe.

Forças

As equipes que compartilham aprendizados sobre InnerSource enfrentam mal-entendidos, pois não têm consciência do nível respectivo de adoção do InnerSource.

As equipes acreditam que "tudo se resume a migrar para um ambiente de desenvolvimento de software compartilhado forge" (GitLab, GitHub ou Bitbucket s√£o exemplos bem conhecidos dessas forjas).

As equipes não têm conhecimento das melhores práticas que as ajudariam a resolver problemas com os quais se deparam em suas atividades diárias.

Solução

Solicite às equipes que façam uma autoavaliação com base no modelo de maturidade proposto.

Transparência

Planos e Produtos

Os projetos InnerSource se beneficiam do planejamento transparente em toda a organiza√ß√£o, permitindo que as partes interessadas compreendam melhor as decis√Ķes e as influenciem de maneira que possa ser seguida por outros.

  • PP-0: Indiv√≠duos e equipes n√£o divulgam regularmente seus planos ou produtos para m√ļltiplas partes interessadas. N√£o existem a√ß√Ķes formais na organiza√ß√£o.

  • PP-1: Indiv√≠duos e equipes d√£o visibilidade aos seus planos ou produtos para m√ļltiplas partes interessadas antes de inici√°-los. Roadmap compartilhado.

  • PP-2: J√° existem roadmaps compartilhados com diretrizes claras e regras de contribui√ß√£o onde as partes interessadas podem fornecer feedback. No entanto, isso n√£o √© padronizado em toda a organiza√ß√£o e nem todos os projetos fornecem essas informa√ß√Ķes.

  • PP-3: Os roadmaps s√£o compartilhados por padr√£o e h√° um processo padr√£o e maneira homog√™nea de fazer isso em toda a organiza√ß√£o no n√≠vel de cada projeto InnerSource. Isso cont√©m regras claras para contribuir e influenciar no roadmap.

Processo e Ferramentas de Desenvolvimento

Os projetos InnerSource prosperam quando os contribuidores se tornam ativos e participam. Como resultado, tornar a contribuição mais fácil deve ser equilibrado com objetivos técnicos puros.

  • DP-0: Cada equipe segue seu pr√≥prio processo de desenvolvimento e ferramentas. Eles n√£o s√£o definidos para compartilhar conhecimento e artefatos fora da equipe de desenvolvimento. Equipes de desenvolvimento isoladas.

  • DP-1: As equipes de desenvolvimento usam reposit√≥rios de c√≥digo compartilhados internamente. Algumas equipes desenvolvem seu pr√≥prio processo de Integra√ß√£o Cont√≠nua (CI), usando ferramentas de CI n√£o corporativas ou padr√£o. N√£o h√° um processo de revis√£o de c√≥digo definido, embora algumas equipes de projetos o fa√ßam internamente.

  • DP-2: A organiza√ß√£o patrocina e promove um reposit√≥rio compartilhado para o conhecimento coletivo. Algumas equipes desenvolvem seu pr√≥prio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revis√£o de c√≥digo definido e usado por alguns projetos. √Äs vezes, a revis√£o de c√≥digo √© feita por membros externos da equipe.

  • DP-3: A maioria das equipes desenvolve seu pr√≥prio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revis√£o de c√≥digo definido e usado. A revis√£o de c√≥digo √© feita por membros tanto internos quanto externos √† equipe.

Decis√Ķes

Com o intuito de motivar os colegas a contribuir para trabalhos fora de suas equipes principais, eles precisam ter visibilidade no processo de tomada de decisão do projeto anfitrião - mas também sentir que suas vozes estão sendo ouvidas e valorizadas.

  • DC-0: Os tomadores de decis√£o frequentemente ret√™m intencionalmente ou por acidente dados e recursos relacionados √†s decis√Ķes do projeto.

  • DC-1: Materiais que fazem parte das pr√°ticas de tomada de decis√£o se tornam dispon√≠veis para revis√£o ap√≥s as decis√Ķes serem finalizadas.

  • DC-2: As pessoas sentem que sabem sobre - e est√£o contribuindo para moldar - a maioria (mas n√£o todas) das decis√Ķes importantes √† medida que essas decis√Ķes est√£o sendo tomadas. Materiais que fazem parte das pr√°ticas de tomada de decis√£o est√£o dispon√≠veis em marcos definidos do projeto.

  • DC-3: As pessoas sentem que fazem parte de um processo compartilhado e padronizado para tomada de decis√Ķes coletivas, endossado pela organiza√ß√£o. Materiais que fazem parte das pr√°ticas de tomada de decis√£o s√£o continuamente acess√≠veis durante os processos de trabalho.

Recursos √öteis

Para atrair contribuidores, materiais de suporte √ļteis precisam estar facilmente acess√≠veis.

  • RS-0: Indiv√≠duos e equipes nem contribuem para, nem acessam um reposit√≥rio compartilhado de conhecimento.

  • RS-1: Indiv√≠duos e equipes disponibilizam materiais do projeto para revis√£o interna ap√≥s terem conclu√≠do o trabalho. Indiv√≠duos e equipes compartilham recursos, mas em sistemas ou reposit√≥rios desconexos, fragmentados ou individualizados/isolados. Indiv√≠duos e equipes compartilham recursos, mas n√£o h√° uma compreens√£o comum ou compartilhada dos crit√©rios usados para determinar se as informa√ß√Ķes s√£o sens√≠veis ou n√£o. N√£o "compartilham pensamentos com outros".

  • RS-2: Indiv√≠duos e equipes tornam os materiais relacionados ao projeto acess√≠veis a alguns membros das equipes de projeto de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indiv√≠duos e equipes ret√™m dados e recursos sens√≠veis, fornecendo detalhes, contexto e escopo limitados.

  • RS-3: Indiv√≠duos e equipes tornam os materiais relacionados ao projeto amplamente acess√≠veis √† organiza√ß√£o - e possivelmente tamb√©m fora da organiza√ß√£o - de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indiv√≠duos e equipes que devem reter dados e recursos sens√≠veis t√™m clareza sobre o que n√£o est√£o compartilhando, e outros entendem por que esses materiais n√£o est√£o dispon√≠veis para eles.

Histórias

Quando se trabalha em equipes anfitriãs, os erros serão automaticamente amplamente visíveis. Para manter os níveis de contribuição elevados, a cultura corporativa precisa celebrar o fracasso como uma oportunidade de crescimento e aprendizado.

  • ST-0: Indiv√≠duos e equipes n√£o compartilham sucessos nem falhas para que outros possam aprender.

  • ST-1: Indiv√≠duos e equipes se sentem √† vontade para compartilhar hist√≥rias sobre sucessos, mas n√£o sobre falhas.

  • ST-2: Indiv√≠duos e equipes se sentem √† vontade para compartilhar hist√≥rias de sucessos e falhas durante retrospectivas e revis√Ķes.

  • ST-3: Indiv√≠duos e equipes se sentem √† vontade para compartilhar hist√≥rias de sucessos e falhas, e aprendem com as falhas de acordo com protocolos formais.

Colaboração

Canais para Prover Feedback

Para reduzir silos, os colegas precisam se sentir à vontade para compartilhar feedback abertamente. Uma maneira fácil de apoiar isso é usar os mesmos princípios de comunicação em todas as hierarquias.

Idealmente, voc√™ acabar√° com canais de comunica√ß√£o adequados que sejam conhecidos por todos na organiza√ß√£o - com canais focados em diferentes objetivos (an√ļncios, suporte ao usu√°rio, canais de desenvolvimento, discuss√Ķes de infraestrutura, etc.). Algumas das melhores pr√°ticas que voc√™ estabelecer√° √† medida que seus projetos InnerSource amadurecem: Ado√ß√£o de diretrizes de netiqueta, abertura de um conjunto comprovado de canais padr√£o (que est√£o sendo arquivados, acess√≠veis publicamente, pesquis√°veis) para cada novo projeto InnerSource.

  • CF-0: N√£o existem processos nem canais estabelecidos. Alguns membros da organiza√ß√£o compartilham materiais por meio de canais ou discuss√Ķes privadas.

  • CF-1: A organiza√ß√£o est√° no processo de estabelecer diretrizes internas e canais para incentivar pontos de vista diversos sobre decis√Ķes da empresa/departamentais, para que qualquer pessoa pertencente √† organiza√ß√£o possa us√°-los. Alguns membros da organiza√ß√£o compartilham materiais de tomada de decis√£o informalmente usando plataformas n√£o oficiais. L√≠deres mant√™m pelo menos um canal claro e direto para que os membros da organiza√ß√£o compartilhem opini√Ķes construtivas sobre alguns assuntos relevantes para o trabalho.

  • CF-2: A organiza√ß√£o estabeleceu diretrizes e canais internos, e fornece recursos espec√≠ficos (programas de treinamento, acesso a conte√ļdo, etc.) para incentivar e solicitar pontos de vista diversos sobre decis√Ķes de equipe ou decis√Ķes em geral.

  • CF-3: Membros da organiza√ß√£o compartilham materiais de tomada de decis√£o em plataformas oficialmente sancionadas. Membros da organiza√ß√£o compartilham materiais abertamente por meio de m√ļltiplos canais e m√©todos para feedback. L√≠deres usam esses canais, encorajam abertamente outros a us√°-los e mant√™m registros voltados para a equipe ou p√ļblicos do feedback que receberam e/ou das a√ß√Ķes que tomaram para abordar esse feedback.

Liderança

Projetos InnerSource incentivam os funcionários a contribuírem para projetos fora da influência direta de seu gerente direto. Isso requer uma cultura de confiança.

  • LS-0: Cultura de comando e controle, dentro de uma organiza√ß√£o altamente hier√°rquica.

  • LS-1: Alguns l√≠deres est√£o abertos a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornec√™-lo.

  • LS-2: A maioria dos l√≠deres na organiza√ß√£o est√° aberta a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornec√™-lo. Os l√≠deres demonstram passividade em entender se todos os membros se sentem capacitados e habilitados a compartilhar. A organiza√ß√£o incentiva os l√≠deres a buscarem ativamente vozes n√£o presentes no di√°logo para inclus√£o.

  • LS-3: Os membros se sentem capacitados e habilitados a compartilhar opini√Ķes construtivas sobre qualquer assunto relevante para o trabalho ou sobre o qual sintam paix√£o.

Estrutura Organizacional e Funcional

Quando o InnerSource sai do nível de codificação pura e entra no nível de comunidade e grupo de trabalho, existe o potencial para reduzir silos, mesmo onde a colaboração direta de código não é possível.

  • OF-0: Grupos de trabalho tendem a ser est√°ticos em termos de membros e conjuntos de habilidades.

  • OF-1: Existem equipes multifuncionais, mas os pap√©is da equipe muitas vezes s√£o obscuros e as estruturas de governan√ßa s√£o vagas.

  • OF-2: Equipes multifuncionais s√£o comuns e as equipes publicam seus pap√©is e objetivos abertamente.

  • OF-3: Equipes multifuncionais s√£o comuns e tornam suas atividades amplamente conhecidas pela organiza√ß√£o; por sua vez, a organiza√ß√£o promove as melhores pr√°ticas para trabalhar juntos.

Contribuição

O objetivo ao projetar padr√Ķes de contribui√ß√£o precisa manter a colabora√ß√£o em mente, se a inten√ß√£o √© reduzir silos.

  • CB-0: Totalmente isolado, sem colabora√ß√£o fora das equipes. Alguma colabora√ß√£o ocorre devido a equipes multifuncionais.

  • CB-1: Membros da organiza√ß√£o e equipes colaboram, mas frequentemente afirmam que √© "muito dif√≠cil". Equipes revisitam raramente os resultados de suas colabora√ß√Ķes.

  • CB-2: Membros da organiza√ß√£o e equipes buscam ativamente oportunidades para colaborar. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esfor√ßos colaborativos e tornam esses resultados dispon√≠veis por padr√£o.

  • CB-3: Membros da organiza√ß√£o colaboram interna e externamente de maneiras que beneficiam a todos os envolvidos. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esfor√ßos colaborativos, compartilham suas aprendizagens fora da organiza√ß√£o e disponibilizam esses resultados externamente por padr√£o.

Comunidade

Políticas de Compartilhamento

Ter uma base de valores compartilhados facilita o trabalho entre as fronteiras das equipes. Cruzar essas fronteiras se torna mais f√°cil se um conjunto limitado de regras e diretrizes b√°sicas se aplicar em todos os lugares e puder ser facilmente referenciado.

  • SP-0: Nenhuma cultura de compartilhamento nem pol√≠ticas escritas.

  • SP-1: Alguns membros da organiza√ß√£o se unem para definir valores e princ√≠pios, mas n√£o recebem suporte claro ao fazerem isso.

  • SP-2: Membros da organiza√ß√£o documentam coletivamente vis√Ķes e acordos compartilhados, como declara√ß√Ķes de miss√£o e c√≥digos de conduta, tornam-nos facilmente acess√≠veis e os referenciam frequentemente. Materiais de integra√ß√£o e rituais de orienta√ß√£o fornecem contexto adequado para ajudar novos membros a entender como a organiza√ß√£o se beneficiar√° de suas contribui√ß√Ķes.

  • SP-3: Valores e princ√≠pios compartilhados orientam processos de tomada de decis√£o, resolu√ß√£o de conflitos e avalia√ß√£o entre os membros da organiza√ß√£o, que referenciam consistentemente esses valores e princ√≠pios em formatos verbais e escritos.

Sentir-se parte da organização

Uma das poss√≠veis raz√Ķes para introduzir o InnerSource nas organiza√ß√Ķes pode ser o aumento do engajamento. Este ponto acompanha como o engajamento est√° mudando ao adotar o InnerSource.

  • PA-0: Baixo engajamento, sem colabora√ß√£o, e as pessoas n√£o se sentem √† vontade para compartilhar com os outros.

  • PA-1: Membros da organiza√ß√£o se sentem √† vontade para compartilhar seus pensamentos e opini√Ķes sem medo de retalia√ß√£o, mas apenas em dom√≠nios familiares. As pessoas entendem que as melhores ideias vencem, e as responsabilidades de lideran√ßa se acumulam para as pessoas com hist√≥rico de contribui√ß√£o e comprometimento.

  • PA-2: Membros da organiza√ß√£o se sentem √† vontade para compartilhar seus pensamentos e opini√Ķes sem medo de retalia√ß√£o. L√≠deres demonstram dedica√ß√£o aos valores compartilhados da organiza√ß√£o.

  • PA-3: A organiza√ß√£o √© proativa em dizer aos membros que se beneficia de suas contribui√ß√Ķes; como tal, os membros demonstram consci√™ncia compartilhada e execu√ß√£o empoderada, e sentem um senso de responsabilidade para com a comunidade. L√≠deres entendem que crescem ao ajudar os outros a crescer, e eles mentoram membros juniores da organiza√ß√£o.

Governança

Prémios

Para impulsionar a adoção, motivadores extrínsecos podem ser usados para aumentar a colaboração entre equipes.

  • RW-0: Sem recompensas.

  • RW-1: L√≠deres s√£o incentivados a recompensar colabora√ß√Ķes excepcionais, mas n√£o h√° pol√≠ticas ou processos estabelecidos.

  • RW-2: Processos padr√£o s√£o estabelecidos para recompensar colabora√ß√Ķes fora das equipes de desenvolvimento. L√≠deres de equipe ou conselhos decidem quem deve ser recompensado.

  • RW-3: Recompensas n√£o s√£o apenas propostas pela organiza√ß√£o, mas as comunidades podem definir suas recompensas mais valiosas. A comunidade √© respons√°vel por decidir quem deve ser recompensado.

Políticas de Monitoramento

Projetos InnerSource precisam de um meio para autoavalia√ß√£o. M√©tricas podem ser um aspecto para facilitar essa avalia√ß√£o. Al√©m disso, em organiza√ß√Ķes com um n√≠vel de ado√ß√£o maduro do InnerSource, esperamos que a ado√ß√£o do m√©todo seja rastreada com base em m√©tricas claras e acordadas.

  • MP-0: N√£o existem pol√≠ticas de monitoramento existentes em nenhum n√≠vel da organiza√ß√£o.

  • MP-1: M√©tricas s√£o importantes para certas equipes, e elas come√ßam a us√°-las de maneira isolada.

  • MP-2: Existe uma estrat√©gia em n√≠vel organizacional em rela√ß√£o √†s m√©tricas que ajudam a validar pol√≠ticas espec√≠ficas em toda a organiza√ß√£o. Essa pol√≠tica de monitoramento existe em n√≠vel de alguns projetos InnerSource.

  • MP-3: Existem diretrizes claras, recomenda√ß√Ķes e treinamentos sobre o uso de m√©tricas com infraestrutura espec√≠fica fornecida pela organiza√ß√£o. Isso funciona em ambos os n√≠veis: programa InnerSource para entender a ado√ß√£o geral do InnerSource dentro da organiza√ß√£o e no n√≠vel dos projetos InnerSource.

Apoio e Manutenção

Não apenas o desenvolvimento de recursos deve ser de responsabilidade das equipes InnerSource - o suporte e a manutenção também fazem parte das tarefas principais das equipes.

  • SM-0: Suporte fornecido pela equipe principal de desenvolvimento ou equipe de suporte. Um contrato comercial garante o suporte. N√£o h√° conhecimento sobre o produto fora da equipe.

  • SM-1: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma equipe de suporte dedicada.

  • SM-2: O suporte para contribui√ß√Ķes InnerSource √© formalizado por meio de padr√Ķes InnerSource, como Garantia de 30 Dias ou Servi√ßo vs. Biblioteca.

  • SM-3: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma comunidade madura.

Cultura

Existem vários níveis em direção a uma cultura colaborativa.

  • CL-0: Silos - equipes trabalham independentemente, mas tamb√©m em isolamento.

  • CL-1: Reativo - equipes trabalham independentemente, mas sabem como reagir a falhas nas depend√™ncias.

  • CL-2: Contributivo - equipes ajudam ativamente a melhorar suas depend√™ncias contribuindo.

  • CL-3: Ativista - equipes buscam ativamente ajuda, orientam e recrutam novos contribuidores.

Papéis InnerSource

InnerSource traz consigo pap√©is expl√≠citos. Enquanto nas primeiras etapas alguns padr√Ķes podem ser utilizados sem adotar esses pap√©is, a comunica√ß√£o dentro dos projetos usando t√≠tulos de papel expl√≠citos se torna mais f√°cil.

  • RO-0: N√£o existem pap√©is espec√≠ficos que auxiliem a ado√ß√£o do InnerSource. Apenas pap√©is de desenvolvimento comuns est√£o presentes: desenvolvedor, analista, testador, etc.

  • RO-1: Ocasionalmente, alguns indiv√≠duos e equipes contribuem para outros projetos. Essas s√£o contribui√ß√Ķes t√©cnicas, onde o papel de usu√°rio/contribuidor √© reconhecido. Para algumas equipes, pode ser identificado pelo menos um membro que √© uma refer√™ncia t√©cnica, explicando o processo de desenvolvimento a outros membros da equipe de desenvolvimento. Essa pessoa poderia ser candidata a cobrir o papel de trusted committer.

  • RO-2: Um papel de Oficial de InnerSource √© respons√°vel pela governan√ßa e suporte, incluindo processos, etc. Identifica as necessidades de educa√ß√£o e garante que sejam providenciadas para a organiza√ß√£o. Lidera e orienta a organiza√ß√£o no envolvimento em projetos InnerSource. √Č o primeiro passo formal no caminho, definindo a vis√£o e o roteiro do InnerSource. A organiza√ß√£o definiu um papel de trusted committer, que √© um ponto de contato/refer√™ncia n√£o apenas para membros da equipe de desenvolvimento, mas tamb√©m para contribuidores externos. Existe um processo padr√£o que descreve como contribuir para a comunidade, o papel de contribuidor est√° presente. O papel de Cientista de Dados √© respons√°vel por gerenciar os rastros de atividade deixados pela iniciativa InnerSource, necess√°rios para medir a evolu√ß√£o do InnerSource. O papel de trusted committer evoluir√° para um perfil mais t√©cnico, e um Gerente de Comunidade ser√° respons√°vel por "energizar" a comunidade, sendo sua principal responsabilidade atrair e reter novos desenvolvedores/usu√°rios (contribuidores/membros da comunidade).

  • RO-3: Evangelistas est√£o se movimentando dentro da organiza√ß√£o, para informar os outros sobre o trabalho atual, o que o InnerSource faz e como faz√™-lo, e ajudar os outros a entenderem e se tornarem parte da iniciativa. Contribuidores n√£o t√©cnicos aparecem.

Contexto Resultante

Todos as equipes têm conhecimento das melhores práticas disponíveis.

As equipes compreendem seu nível de adoção do InnerSource.

Antes de adotar o InnerSource como um modelo de trabalho, as equipes têm ciência das práticas que se espera delas - tanto a curto prazo quanto a longo prazo.

Inst√Ęncias Conhecidas

  • Entelgy

  • Zylk

  • Bitergia

Autores

  • Daniel Izquierdo Cortazar

  • Isabel Drost-Fromm

  • Jorge

  • Nerea

Reconhecimento

  • Alexander Andrade (um agradecimento especial pela corre√ß√£o ortogr√°fica)

Alias

Modelo de Maturidade: Conheça as Melhores Práticas do InnerSource

Estado

  • Structured

  • Drafted in September 2019

Histórico de Tradução

Last updated