Conceitualmente refere-se ao mundo das ideias e do pensamento humano. Pode ser definido como o conjunto de todas as mentes humanas interconectadas, tendo sua origem do grego `νους (nous, "mente")` em um sentido semelhante à atmosfera e biosfera.

Os seres humanos têm um impulso inato para competir por status social; ele está conectado por nossa história evolutiva. A maioria das formas que os humanos têm de se organizar são adaptações à escassez e à carência.

Nossa sociedade é predominantemente uma economia de troca. O status social é determinado não pelo que você controla, mas pelo que você dá.

Como se pode maximizar a qualidade se não há uma métrica para qualidade? Você pode não trabalhar para obter reputação, mas a reputação é um pagamento real com consequências se você fizer bem o trabalho.

Sociologia¶

Em 1991, aos primeiros experimentos de Linus Torvalds, William e Lynne Jolitz, na construção do Linux, a característica mais importante do Linux, no entanto, não era técnica, mas sociológica, todos acreditavam que qualquer software tão complexo quanto um sistema operacional tinha que ser desenvolvido de forma cuidadosamente coordenada por um grupo relativamente pequeno e unido de pessoas,a qualidade era mantida não por padrões rígidos ou autocracia, mas pela estratégia ingenuamente simples de lançar toda semana e obter feedback de centenas de usuários em poucos dias, criando uma espécie de seleção darwiniana rápida nas mutações introduzidas pelos desenvolvedores.

• Linus Torvalds
  • Libere cedo e frequentemente, delegue tudo o que puder, esteja aberto ao ponto da promiscuidade — foi uma surpresa;
  • Release early. Release often. And listen to your customers;
  • Linus estava mantendo seus hackers/usuários constantemente estimulados e recompensados — estimulados pela perspectiva de ter uma parte da ação que satisfizesse o ego, recompensados pela visão de melhoria constante (mesmo diária) em seu trabalho.
  • Eric S. Raymond, CUNHOU a lei de Linus: "Dada uma base grande o suficiente de beta-testers e co-desenvolvedores , quase todos os problemas serão caracterizados rapidamente e a correção óbvia para alguém." - "given enough eyeballs, all bugs are shallow".
• Restrições legais de várias licenças, segredos comerciais e interesses comerciais.
  • O desenvolvedor que usa apenas seu próprio cérebro em um projeto fechado vai ficar para trás do desenvolvedor que sabe como criar um contexto aberto e evolucionário no qual o feedback explorando o espaço de design, contribuições de código, detecção de bugs e outras melhorias vêm de centenas (talvez milhares) de pessoas.
• Linux foi o primeiro projeto para o qual foi feito um esforço consciente e bem sucedido para usar o mundo inteiro como seu pool de talentos.
• Conjunto de costumes cooperativos que pudessem permitir que os desenvolvedores atraíssem codesenvolvedores e obtivessem o máximo aproveitamento do meio.
• Memórias de um revolucionário Pyotr Alexeyvich Kropotkin: "Entre agir com base no princípio de comando e disciplina e agir com base no princípio do entendimento comum.";
• Mutual Aid: An Illuminated Factor of Evolution, "Contra a competição, pela cooperação.", pois derrubou dogma crucial ao liberalismo e demonstrou a centralidade da cooperação – nas sociedades e na própria evolução das espécies.

DevRel (Developer Relations) e Innersource¶

Ter uma definição clara dentro da mesma organização é vital para adotar uma cultura InnerSource dentro da sua organização.

Sem um entendimento claro e direção correta, é fácil para os membros da equipe se perderem em sua própria direção de onde ir.

A pergunta que façoe é: Qual é a parte mais desafiadora do desenvolvimento de software na sua organização?

• Sobrecarregado com a quantidade de código que precisa manter em sua organização?
• Equipes escreveram códigos que duplicam funcionalidades escritas por outra equipe?
• Equipes reescrevem o código que herdaram porque não o entendem ou acham que não é bom, apenas para encontrar problemas encontrados antes?
• Você conhece algum código em execução em produção que você não se sentiria confortável em mostrar a outra pessoa?
• Você conhece equipes que lutam para se comunicar e colaborar efetivamente apesar das fronteiras temporais, geográficas e culturais?
• Você reconhece oportunidades para aumentar os níveis de abertura, transparência e participação dentro da sua organização?

Por que?¶

• A "abertura" do projeto se estende a muitas equipes dentro da organização;
• A reutilização de código em toda a organização cresce imensamente;
• A colaboração entre equipes se torna relativamente sem atrito;
• O desenvolvimento se torna mais rápido;
• A documentação de qualidade é detectável;
• Permanece sob a visão e o controle de uma única organização.

Quais os Benefícios¶

• Quais benefícios do InnerSource seriam mais impactantes para sua equipe?
• Quais benefícios seriam mais imediatos?
• Quais benefícios são mais necessários?
• Como cada um dos membros da sua equipe responderia a essas perguntas?
• Como vocês, como membros da equipe, quebram os silos?
• Onde estão os pontos problemáticos ou gargalos dentro da sua equipe ou organização?

Defina as estratégias¶

• Quais são alguns objetivos comuns pelos quais a organização pode trabalhar?
• Quais são alguns critérios de sucesso iniciais que promoveriam o compartilhamento do progresso em direção a essas metas?
• Quais comportamentos você atualmente incentiva e motiva os funcionários a adotar?
• Como os métodos existentes poderiam ser utilizados para esta iniciativa?
• Quais projetos internos vêm à mente quando você pensa em colaboração (não precisa ser focado no desenvolvedor)?
• O que você acha que faz com que esses projetos sejam bem-sucedidos?
• O que você pode usar nesses projetos para essa iniciativa?
• O que você gostaria de medir para identificar o sucesso da iniciativa?

• A transparência melhora a colaboração e permite que qualquer pessoa na empresa veja quando um projeto está saindo dos trilhos e ajude a corrigi-lo.

O que precisa MUDAR?¶

Como Implantar?¶

• Cultura: Quão receptiva é sua organização, culturalmente, à maneira de trabalhar da InnerSource?
• Capacitação do Desenvolvedor: Se você perguntasse a um grupo aleatório de desenvolvedores em sua organização o quanto eles se sentem capacitados para trabalhar com outras equipes, o que você acha que eles diriam?
• Governança: A comunidade de desenvolvedores dentro da sua organização recebe o suporte necessário?

Disfunções¶

• Ausência de confiança: Sem confiança, você não pode ter debates e conflitos saudáveis, porque as pessoas têm medo de serem honestas umas com as outras.
• Medo de conflito: Para construir conflito produtivo você precisa primeiro construir confiança, desenvolver segurança psicológica, para que as pessoas se sintam livres para serem honestas umas com as outras.
• Falta de comprometimento
• Evitar a responsabilização: As ideias são avaliadas apenas por seus méritos.
• Desatenção aos resultados

Ingredientes culturais¶

• Transparência: tanto em termos de processo como de participação;
• Engajamento: os colaboradores estão altamente engajados, há conflito produtivo;
• Assíncrona: a comunicação é assíncrona, permitindo a participação de toda a organização

Regras da Casa¶

Uma diretriz de contribuição fornece documentação CLARA, sobre como um colaborador pode contribuir, bem como formaliza as responsabilidades dos desenvolvedores que aceitam alterações de código em seu projeto.

Essas diretrizes não devem ser padronizadas em toda a organização, mas os itens abaixo são recomendados:

Committer Confiável (TC)¶

O papel dele é ajudar a orientar os contribuidores e a mover as mudanças de código adiante. Algumas de suas outras responsabilidades incluem:

O esperado¶

Governança¶

Como uma organização, você pode ter certeza de que qualquer código não público permanecerá seguro dentro do seu ambiente — e somente desenvolvedores com permissões apropriadas poderão contribuir?

• Forneça os fluxos de trabalho que as equipes possam usar para criar um modelo;
• Forneça um repositório de TEMPLATES com exemplos:
  • README(s);
  • Modelos de problemas e solicitações de pull;
  • Arquivos CONTRIBUTING;
  • LICENÇA;
  • CODEOWNER;
  • Arquivos gitignore, etc.
• Crie uma equipe innersource DAR orientação quando ACIONADA;

Medições¶

Quais problemas o InnerSource resolve?¶

A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa. Imagine duas equipes na mesma empresa entregando softwares separados, com o software de uma equipe dependendo do da outra.

Em organizações tradicionais, somente a equipe anfitriã pode alterar seu código. Outras equipes devem enviar solicitações e esperar até que sua importância seja reconhecida. Com a InnerSource, uma equipe externa que precisa urgentemente de uma mudança pode codificá-la ela mesma, com a orientação da equipe anfitriã.

O InnerSource se aplica ao mesmo tipo de situação em que uma equipe consumidora 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 wait it out, workaround e escalar sem as desvantagens associadas.

• A equipe convidada ou colaborador solicita um recurso da equipe anfitriã.
• O proprietário do produto garante que as histórias de usuário que representam a solicitação de recurso sejam criadas, seja por membros da equipe convidada ou da equipe anfitriã. (Sprint - Jake Knapp)
• Essas histórias devem descrever o recurso solicitado em termos aceitáveis ​​para a equipe convidada.
• Elas também listam quaisquer detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito.

A InnerSource também fornece uma melhoria geral à cultura de ENGENHARIA pois os DEVs têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas.

O InnerSource dá a uma empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem, sem o fardo de manutenção a longo prazo. A empresa como um todo ganha, pois o tempo das equipes convidadas é colocado em código que outros podem usar.

Seu cerne, estão quatro princípios que formam a base de qualquer instância bem-sucedida da InnerSource. Esses princípios têm inspiração em projetos de código aberto bem-sucedidos e são necessários para que a InnerSource alcance os benefícios descritos anteriormente.

Os princípios são:

• Abertura: Os projetos devem ser detectáveis ​​e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório.
• Transparência: Equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente . Isso significa que as equipes convidadas devem ser capazes de ter uma compreensão de:
  • O projeto/repositório e sua direção
  • Requisitos de recursos pendentes
  • Progresso nos requisitos de recursos
  • Tomada de decisão da equipe anfitriã
• Mentoria Priorizada: Os colaboradores nas equipes convidadas são promovidos para que entendam o suficiente sobre o projeto/repositório da equipe anfitriã para alterá-lo com sucesso.
• Contribuição Voluntária ao Código: A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente.

A InnerSource dá a esses gerentes uma chance de se envolverem mais em discussões que cruzam os limites organizacionais, e seu rastro de registros preserva evidências de suas contribuições.

Como o InnerSource requer contribuições de muitas equipes diferentes, os planos devem ser publicados e compartilhados. Isso não só permite a coordenação, mas destaca as contribuições que um gerente e sua equipe fazem para a organização maior.

A InnerSource pede documentação e transparência tanto no código quanto nas diretrizes. Se um desenvolvedor-chave sair ou estiver ocupado, o conhecimento estará disponível para outros.

Padrões corporativos:¶

Padrões, processos e documentação são elementos importantes de colaboração que permitem que várias equipes produzam código para um projeto compartilhado. Compartilhar padrões, processos e documentação junto com o próprio código os torna explícitos, bem como fáceis de consumir e manter.

Controle de versão, painéis de mensagens e outras ferramentas preservam um registro do que aconteceu e de quem contribuiu. A transparência e o acesso aberto que eles criam garantem visibilidade e, portanto, permitem o devido crédito por realizações em projetos da InnerSource.

Colaboradores, committers confiáveis ​​e donos de produtos mantêm mais discussões sobre projetos para colaborar na busca de soluções.

A contribuição de outros donos de produtos incorpora conhecimento valioso sobre seus usuários, o histórico de seus projetos, obstáculos a serem observados e outras coisas. Isso faz com que a comunicação extra valha a pena.

A equipe técnica geralmente sai da faculdade ou de outros programas de treinamento com habilidades em programação e, talvez, engenharia e gerenciamento de projetos.

As pessoas não podem participar de uma meta compartilhada se não tiverem as mesmas visões de metas-chave e maneiras de prosseguir.

Pessoas de fora geralmente trazem perspectivas importantes, tanto sobre as necessidades do usuário quanto sobre métodos robustos para atender a essas necessidades.

Elas podem revisar os padrões da sua equipe e até mesmo contribuir para eles. Tanto os donos do produto quanto os responsáveis ​​confiáveis ​​devem solicitar contribuições para os padrões.

Os projetos da InnerSource que desejam atingir altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos durante todo o ciclo de vida do software.

A publicação de documentos internos Requests for Comments (RFCs) permite discussões no início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.

Open Source ou InnerSource¶

Adotar a abordagem Innersource dentro de uma organização pode trazer diversas vantagens, especialmente em termos de eficiência interna, colaboração e inovação. Para que não haja dúvidas sobre as diferenças de innersource e Open Source, elaboramos o quadro abaixo:

Assim, InnerSource é um desenvolvimento histórico baseado no movimento Open Source junto com outras tendências em software.

O InnerSource difere do código aberto clássico por permanecer dentro da visão e do controle de uma única organização.

A "abertura" do projeto se estende por muitas equipes dentro da organização.

O software InnerSource continua sendo proprietário da empresa, mas dentro dele é aberto para qualquer um usá-lo e contribuir com ele.

O desenvolvimento se torna mais rápido à medida que os programadores aprendem a usar testes unitários, cobertura de código e integração contínua para remover bugs em um estágio inicial do desenvolvimento.

Os comentários escritos trocados entre os membros da equipe, embora ocupem algum tempo, mais do que se pagam ajudando novos programadores a aprender o sistema mais rápido.

Os programadores aprendem a documentar melhor seu código, tanto formalmente (como comentários e documentação no código) quanto informalmente (em listas de discussão).

Permite que desenvolvedores de software contribuam para os esforços de outras equipes, promovendo transparência e abertura para contribuições de outros.

Qualquer um pode usar, modificar e compartilhar livremente softwares desenvolvidos de forma institucional, para qualquer propósito com a ideia de que compartilhar código leva a um software melhor e mais confiável.

Para tal observa-se duas práticas atuais no mundo de desenvolvimento: Innersource e Boilerplate code.

• InnerSource em sua equipe é estabelecer metas, marcos e, em seguida, criar uma lista de verificação de itens que precisam ser realizados em sua equipe para atingir essas metas.
• Boilerplate code refere-se a trechos de código que se repetem e que frequentemente aparecem em muitos projetos ou partes do código. Esses trechos geralmente não contêm lógica específica, mas são necessários para a estrutura do programa, temdo como uma ideia a reutilização esse código para economizar tempo e evitar erros ao reescrever o mesmo código repetidamente.

O código padronizado é um texto em linguagem computacional que você pode reutilizar com pouca ou nenhuma alteração em diversos contextos diferentes.

Coisas que um não programador pode fazer¶

Comece a ouvir : Tudo em código envolve outras pessoas. Você está procurando se juntar a uma equipe, e isso significa entende-la e como ela funciona.

Participe de uma lista de discussão : Para muitos projetos, a lista de discussão é o principal canal de comunicação sobre o desenvolvimento do projeto.

Siga um Blog : Blogs mantidos por desenvolvedores geralmente dão informações sobre o que está por vir em lançamentos futuros e o que é preciso para chegar lá.

Trabalhe com Tickets/Issues : O código é o coração de qualquer projeto de código, mas não pense que escrever código é a única maneira de contribuir. A maioria dos projetos tem um sistema de tickets de problemas publicamente visível, vinculado à página inicial do site do projeto e incluído na documentação. É o principal canal de comunicação entre os usuários e os desenvolvedores. Mantê-lo atualizado é uma ótima maneira de ajudar o projeto.

Diagnosticar um bug : Bugs são frequentemente mal reportados. Diagnosticar e triar um bug pode ajudar a economizar tempo dos desenvolvedores com o trabalho braçal de descobrir as especificidades do problema.

• Se um usuário relatou, "O software não funciona quando eu faço X", gaste algum tempo para descobrir as especificidades do que acontece nesse problema.
• É repetível? Você pode criar um conjunto de etapas para causar o problema repetidamente?
• Você pode restringir o problema, como acontecer apenas em um navegador, mas não em outro, ou em uma distribuição, mas não em outra? Mesmo que você não saiba o que causa o problema, o esforço que você coloca em restringir as circunstâncias torna mais fácil para outra pessoa consertá-lo.
• O que quer que você descubra, adicione ao ticket no sistema de bugs para que todos vejam.

Fechar bugs corrigidos : Frequentemente, os bugs são corrigidos na base de código, mas os tickets relatados sobre eles não são atualizados no sistema de tickets. Limpar esse lixo pode ser demorado, mas é valioso para todo o projeto. Comece consultando o sistema de tickets para tickets mais antigos que um ano e veja se o bug ainda existe. Verifique o log de alterações de lançamento do projeto para ver se o bug foi corrigido e pode ser fechado. Se for conhecido que foi corrigido, anote o número da versão no ticket e feche-o.

Teste um beta ou candidato a lançamento : Qualquer projeto que seja projetado para rodar em múltiplas plataformas pode ter todos os tipos de problemas de portabilidade. Quando um lançamento se aproxima e um beta ou candidato a lançamento é publicado, o líder do projeto espera que ele seja testado por muitas pessoas diferentes em muitas plataformas diferentes. Você pode ser uma dessas pessoas e ajudar a garantir que o pacote funcione na sua plataforma.

Corrigir um bug : Geralmente é aqui que os colaboradores que querem começar a trabalhar no código começam. É simples: encontre um bug que pareça interessante no sistema de tickets e tente corrigi-lo no código. Documente a correção no código, se for apropriado. É uma boa ideia adicionar um teste ao conjunto de testes para testar o ponto do código que você corrigiu; alguns projetos exigem que as correções de bugs incluam testes. Mantenha notas enquanto você vasculha essa base de código desconhecida. Mesmo que você não consiga corrigir o bug, documente no ticket o que você descobriu como parte da tentativa de correção. O que você encontrar ajuda aqueles que vêm depois de você.

Escreva um Teste : A maioria dos projetos tem um conjunto de testes que testa o código, mas é difícil imaginar um conjunto de testes que não pudesse ter mais testes adicionados a ele. Se você encontrar um bug, tente escrever um teste que o reproduza. Se você não puder reproduzir o bug, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe. Se você não puder escrever um teste que passe, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe. Se você não puder escrever um teste que passe, escreva um teste que falhe. Se você não puder escrever um teste que falhe, escreva um teste que passe.

Adicione um comentário : Ao vasculhar o código, você pode encontrar alguns pontos que são confusos. Provavelmente, se você ficou confuso, outros também ficarão. Documente-os no código e envie um patch. Trabalhe com documentação A documentação é normalmente a parte de um projeto que recebe pouca atenção. Ela também pode sofrer por ter sido escrita do ponto de vista daqueles que estão familiarizados com o projeto, em vez dos olhos de alguém que está começando a entender.

Trabalhe com a Comunidade : O código aberto é apenas parcialmente sobre código. A comunidade faz o código aberto funcionar. Aqui estão algumas maneiras de ajudar a construí-lo.

Responda a uma pergunta : A melhor maneira de ajudar a construir a comunidade é ajudando os outros. Responder a uma pergunta, especialmente de alguém que está apenas começando, é crucial para ajudar o projeto a crescer e prosperar. O tempo que você leva para ajudar um iniciante, mesmo que ele esteja fazendo uma pergunta em que você poderia facilmente dar um rápido "RTFM", compensa no futuro, pois consegue outro membro ativo da comunidade. Todo mundo começa em algum lugar, e os projetos precisam de um fluxo constante de pessoas para que continuem vitais.

Escreva uma postagem de blog/wiki : Se você tem um blog, escreva sobre suas experiências com o projeto que está usando. Conte sobre um problema que você enfrentou usando o software e o que você fez para resolvê-lo. Você estará ajudando de duas maneiras, tanto ajudando a manter o projeto na mente de outras pessoas ao seu redor, quanto criando um registro para qualquer outra pessoa que tenha seu problema no futuro e pesquise na web pela resposta. (Um blog de suas aventuras técnicas também é uma excelente maneira de mostrar experiência no mundo real com o software em questão na próxima vez que você for procurar um emprego usando-o.)

Melhore um site : Se você tem habilidades em web design e pode ajudar a melhorar o site, e assim a imagem pública do projeto, esse é um tempo bem gasto. Talvez o projeto pudesse usar uma reformulação gráfica, ou um logotipo para identificar o projeto. Essas podem ser habilidades que faltam na comunidade. Eu sei que adoraria se pudesse obter alguma ajuda de design gráfico nos sites dos meus projetos.

Escreva Documentação técnica : Se você consegue escrever sobre como um aplicativo ou software funciona, você pode escrever documentação técnica sobre ele. Especialmente projetos de código aberto que buscam atualizar, renovar, expandir ou criar documentos técnicos para o público em geral ler. Quanto mais você escrever em inglês simples, melhor. A melhor parte é que você não precisa ser um programador para escrever documentos técnicos.

Ensine e ajude os outros : A melhor maneira de aprender mais sobre um tópico é tentar ensiná-lo. O melhor professor é aquele que consegue explicar coisas complexas com exemplos simples. Então você precisa tentar ser o melhor professor para ser o melhor aprendiz e o melhor no seu mundo de programação. Ensinar os outros fará você se sentir melhor consigo mesmo e ajudará você a obter melhores habilidades e conhecimento em sua profissão. Quando você receber ajuda de alguém, não guarde para si mesmo, compartilhe com os outros. Faça do mundo um lugar melhor para se viver.

Consumerização¶

Os softwares ERPs, acumulam, tecnologias e funcionalidades para atender uma grandiosidade empresarial (indo contra os cenários atuais com os processos ágeis – Lean IT, SCRUM e etc.), que por muitas vezes não aplicáveis a instituição e/ou adotam tecnologias, que foram abandonadas pelo mercado ou não amigáveis ou com raros profissionais, por exemplo o FORMS, OAF, PEOPLECODE e etc.

Esta claro com esta pesquisa, que a diferença entre software **corporativo** e **consumidor** necessita diminuir e que os **consumidores**, usam softwares mais envolventes e intuitivos: iFOOD, UBER, LinkedIn, WhatsApp e etc., sendo óbvio, as perguntas:

• Como diminuir este hiato entre estas camadas ou diminuir esta sensação?
• Como aumentar a satisfação do cliente, sem tornar o Aplicativo corporativo apenas um repositório?
• Como medir o processo se por um lado, o fornecedor do software, nos monetiza, por Aplicativo em alguns casos e em outros pelo conjunto da obra?
• Como diminuir a sensação, sem aumentar o número de sistemas - FRONT END?

Modelo de Desenvolvimento - Ideia¶

• Década de 90 – Paul R. Timm - 50 Poderosas Ideias Para Voce Manter Seus Cilentes - Será que a frase não foi distorcida? Satisfazer x Submissão?
• Século 21 – Roger Fisher/William Ury/Bruce Patton - Como chegar ao Sim - A negociação de acordos sem CONCESSÃO
  • É preciso respeitar os direitos do cliente, mas também os princípios que regem a organização;
  • Atender os anseios do cliente a qualquer custo nunca será um bom negócio;
  • Política do Ganha a Ganha;
• Para que não haja confusão:

Necessidade Básica¶

Temos que enviar produtos com mais rapidez para acompanhar as crescentes necessidades dos clientes, sobreviver à concorrência e impulsionar a redução de custo, para tal, espera-se que o time seja dividido em duas partes:

Pilares da Codificação/Tenha em Mente¶

Métricas¶

Automatização¶

A automação também realiza a documentação de cada processo, auxiliando na padronização dos passos, sendo extremamente vantajosa para a empresa não só pela redução dos erros humanos, mas também porque o trabalho manual custa tempo e dinheiro.

Lean¶

• GEMBA é "lugar real", ou seja, onde a ação da empresa acontece.
• OBEYA é "lugar físico" ou virtual onde a geração de conhecimento acontece.
• HEIJUNKA é um método Lean para a redução de desigualdade no processo de produção e minimização da chance de sobrecarga, ou seja, NIVELAMENTO.
  • Reduzir continuamente o lead time;
  • Produzir em lote cada vez menor;
  • Questionar sempre e não concordar com estoque;
  • Ajustar e controlar a capacidade com produção mix;
  • Atribuir aos processos anteriores uma carga balanceada
• ANDON Ele cria alertas visuais por meio de luzes que destacam onde é necessário agir. Corda de Andon.

Anti-padrões da Cultura Devops¶

Cultura da Culpa¶

Silos¶

Implantação Manual¶

Cultura DeVOPS¶

Cultura¶

Construir uma cultura de responsabilidade compartilhada, com transparência e feedback mais rápido é a base de toda equipe de DevOps que deseja ter um alto desempenho.

Foco¶

Mudança de Percepção¶

Desorganização <> Bagunça¶

• Qual é a diferença entre desorganização e bagunça?
  • A desorganização é quando você não tem um lugar define para as coisas.
  • A bagunça é quando você tem o lugar mas não coloca.

As coisas lá o nível de bagunça estão associados com a distância entre o lugar onde a coisa deveria estar e o lugar onde ele está de fato.

O arquiteto de muitas formas ajuda o time a definir uma organização ou seja qual é o lugar certo de cada coisa e e depois de definir o lugar certo de cada coisa tentar ajudar o time a colocar as coisas.

Os principais bloqueadores associados ao InnerSource foram a cultura organizacional (pensamento em silos), falta de tempo para contribuir, falta de conscientização geral e falta de adesão da gestão intermediária.

O dono de um projeto de software é a pessoa que tem o direito exclusivo, reconhecido pela comunidade em geral, de distribuir versões modificadas.

• Criar um projeto: um mantenedor desde seu início e o mantenedor ainda está ativo;
• Propriedade do projeto passada a você pelo proprietário anterior (isso às vezes é conhecido como "passar o bastão").
• Adquirir propriedade de um projeto é observar que ele precisa de trabalho e que o proprietário desapareceu ou perdeu o interesse.