Encontro de primavera de 2018

Hoje, sabemos que InnerSource é uma ótima maneira de desenvolver software eficientemente, alavancando comunidades que transcendem os limites organizacionais e geográficos também conhecidos como silos. Nós também sabemos agora, que InnerSource é um excelente segway no verdadeiro desenvolvimento de código aberto para empresas sem um DNA de software. Quando Bosch começou com InnerSource, não havia experiência técnica, legal, de colaboração, social e comercial suficiente dentro de Bosch para iniciar o código aberto imediatamente. Fazer uma iniciativa InnerSource sair do chão em tal cenário é um desafio. Stefan voltará às origens da InnerSource em Bosch e compartilhará a história surpreendente de como ele conseguiu convencer a gerência superior a se envolver em InnerSource usando meios pouco convencionais. Isso incluía três elementos-chave:

1. Comece com InnerSource primeiro e não com código aberto imediatamente,
2. começar com ferramentas (aqui Eclipse IDE para automóvel) e não com os produtos Bosch e
3. Começar com “capturar a bandeira das nações” e não com slides Agora Stefan está orgulhoso que Bosch é ativo contribuindo para projetos da Internet das Coisas Eclipse.

Stefan está orgulhoso de Bosch estar contribuindo para projetos da Internet das Coisas.

Ao longo dos anos, todos vimos métodos de desenvolvimento de software ir e vir. Muitos de nós ficamos céticos com as promessas de novas abordagens como resultado. Danese, Jim e Georg, três praticantes de longa data da InnerSource, experimentaram em primeira mão como InnerSource se destaca e tem o potencial de realmente transformar o mundo do desenvolvimento de software corporativo. Nesta palestra, eles compartilharão três argumentos convincentes por que InnerSource importa.

“Fonte interna é uma ótima ideia! Você é o campeão dedicado para a fonte interna em sua empresa. O que você faz agora? Como você afeta realisticamente o comportamento de dezenas ou centenas de equipes ao ponto em que o fornecimento interno robusto e abrangente é uma parte normal da forma como a engenharia é feita?

Esta apresentação compartilha princípios, anedotas práticas, e exemplos relatáveis sobre esta situação extraídos da experiência na Nike. Embora não reclame todas as respostas, é um resumo perspicaz de mais de um ano de trabalho na área.

A empresa decidiu iniciar uma iniciativa InnerSource para promover a colaboração através das fronteiras organizacionais em todo o mundo. Entendemos que a adoção do paradigma de desenvolvimento de código aberto dentro da organização está se tornando muito popular e essencial para os negócios da empresa. Até onde sei, muitas empresas experimentaram esse modelo, mas até agora nem sempre é claro por onde começar. Então eu quero compartilhar nossa experiência da plataforma de borda InnerSource caso, com caso de uso, DevOps, ferramentas, desenvolvimento de produto, e infraestrutura de desenvolvimento e assim por diante e esperar que o público capture algumas insights. Mas mais discussões são necessárias para entender os vários modelos de InnerSource que as empresas estão adotando.

Em 2006, apresentei a fonte interna da SAP. Depois de ser professor, meu grupo ajudou outras empresas a introduzir a fonte interna. Usando três gerações de projetos, relatamos sobre nossas experiências e como as transformamos em um manual prático para governança de fontes internas.

Wayfair tem uma grande organização de engenharia. É composto por muitas pequenas equipes de sprint que podem trabalhar de forma eficiente e eficaz por conta própria. Esta estrutura, no entanto, torna difícil coordenar o trabalho que abrange grandes partes do departamento, como introduzir novos frameworks ou atualizar infraestrutura compartilhada. Nós introduzimos um conceito chamado grupos de trabalho, baseado em princípios InnerSource, que nos permitem executar esses tipos de projetos com a eficiência que esperamos de qualquer outra equipe. Durante esta sessão de cartazes, darei uma visão geral dos projetos que abordamos com grupos de trabalho, seus prós e contras, e como planejamos iterar sobre este padrão.

Innersource tem uma influência muito positiva na prototipagem e pré-desenvolvimento. Uma empresa com muitos produtos em diferentes domínios pode desencadear soluções de domínio cruzado através da publicação interna de APIs e bibliotecas. Compartilhar isso dentro da empresa tem permitido a reutilização em diferentes Unidades de Negócios, levando a sinergias surpreendentes em diferentes aplicações.

Enquanto há muitas palestras e postagens sobre APIs e a importância de um desenvolvedor de APIs eXperience, a maioria é sobre produtos de API públicos. E enquanto muitas das melhores práticas para produtos API também são aplicáveis a APIs privadas, há diferenças significativas nas circunstâncias e trocas que eles precisam fazer. A diferença mais importante é provavelmente em seus orçamentos: como potenciais centros de lucro, os produtos API podem se dar ao luxo de investir muito mais dinheiro em documentação e melhorias no portal de desenvolvedores movidos por UX. APIs internas raramente têm esse luxo. Nesta palestra explicarei as diferenças entre APIs públicas e privadas, introduzirei experiência de desenvolvedor a montante, e explicarei como pode melhorar o DX a jusante. Apresentar design de experiência (também conhecido como gamificação) e descrever como poderia ser usado em portais internos de desenvolvedores. Por fim, falarei sobre a importância dos SDKs e as diferentes estratégias que uma organização pode tomar para construí-los, incluindo uma estratégia de innersourcing que poderia ajudar a melhorar o DX de APIs no centro da iniciativa de transformação digital da sua organização.

FusionX foi a primeira comunidade interna de código aberto da Bosch e tem estado ativa nos últimos 9 anos. Nossa missão é capacitar colegas engenheiros Bosch a construir protótipos, ferramentas e novos produtos conectados aos nossos produtos muito mais rápido do que antes. Ao longo dos anos, vimos tudo isso acontecer e muito mais. Vou compartilhar exemplos e insights sobre como a comunidade funcionou, o que desenvolvemos e quais os fatores de sucesso e desafios que encontramos ao longo do caminho.

Fizemos o passo 1: temos uma plataforma, repositórios e um grupo de usuários iniciais. Agora estamos procurando o passo 2, envolver os desenvolvedores de grandes projetos de infraestrutura. Estão preocupados que não terão tempo para participar do InnerSource. Temos equipes, elas têm bons softwre e estão dispostas a compartilhá-lo, mas elas têm preocupações sobre a qualidade do código que os outros estarão contribuindo, e sua capacidade de orientar outros fora do grupo. Este é o nosso próximo obstáculo. Este cartaz é uma cabine de conselhos invertidos. Por favor, visite-nos e compartilhe suas ideias e conselhos.

        Another topic: we have a one hour meeting with the company president about InnerSource; what should we emphasize and try to get from him (in terms of support for the InnerSource Program).            

Nesta apresentação, apresentamos a abordagem de pesquisa e resultados preliminares de um projeto de pesquisa em andamento sobre as melhores práticas de mineração de origem interna. Como a fonte interna é o uso das melhores práticas de desenvolvimento de software de código aberto e o estabelecimento de uma cultura de código aberto dentro das organizações, precisamos entender as melhores práticas utilizadas e estabelecidas no mundo de código aberto para aprender com elas. Até agora coletamos informações de atividades de desenvolvimento de mais de 450.000 projetos de código aberto para quantificar seu desempenho e prever seu sucesso. Dos melhores projetos, planejamos minar o processo e as práticas usadas. Usando pesquisas de estudo de caso, aplicaremos essas práticas de código aberto em fonte interna e validaremos que podem pular o abismo de fonte aberta para fonte interna.

Nenhuma métrica é importante, mas está diretamente ligada aos objetivos estratégicos da sua empresa. O sucesso é medido quando os objetivos são alcançados.
Medir as coisas é ‘fácil’ se você souber onde extrair os dados, mas ter uma estratégia requer experiência de contexto, um método detalhado para formalizar o processo de medição e uma estratégia em relação à consciência, melhoria do processo, transparência e ações motivacionais entre outras áreas-chave.

Métricas não são a panaceia, mas ajudam a entender a estrutura e metodologia atuais seguidas por uma equipe de desenvolvimento de software. E quão longe isso é de outras organizações similares.

Os tópicos incluem:

• Objetivos usando métricas.
• Áreas de análise
• Uma abordagem formal como a Meta-Pergunta-Metrica.
• Estratégia ao usar métricas
• Alguns exemplos

Quebrar silos e promover a colaboração em várias unidades de negócios é um dos principais objetivos de qualquer InnerSource inicial. No entanto, como podemos saber se isso está realmente acontecendo? Esta palestra também vai se concentrar nas fontes de dados habituais disponíveis ao construir a infraestrutura necessária neste tipo de iniciativas e os vestígios deixados pelos membros da nova comunidade. Esses traços são os analisados, armazenados e curados para produzir métricas valiosas para a organização. Vou ver as fontes de dados habituais como GitHub, Jira ou Slack como alguns exemplos de como entender e medir a colaboração em toda a organização.

Fonte interna (IS) permite e requer que os desenvolvedores colaborem mais do que métodos SD tradicionais, como desenvolvimento ágil ou orientado por planos. Para entender melhor o IS, pesquisadores e profissionais precisam medir a colaboração do IS. No entanto, ainda não há um método estabelecido para isso. Nesta palestra, apresentamos um método para medir a colaboração da IS medindo o fluxo de retalhos dentro de uma organização. Fluxo de patch é o fluxo de contribuições de código através dos limites organizacionais, como projeto, unidade organizacional, ou centros de lucro. Demonstramos a capacidade do método de medição de fluxo de retalhos, aplicando-o em uma empresa de desenvolvimento de software. Nesta empresa, descobrimos que cerca de metade (47,9%) de todas as contribuições de código para projetos IS constituem fluxo de retalho entre unidades organizacionais, quase todos (42,2%) sendo entre unidades organizacionais trabalhando em diferentes produtos. Esse fluxo significativo indica alta relevância do fenômeno do fluxo. Nosso método de medição de fluxo de retalhos é o primeiro de seu tipo para medir e quantificar a colaboração IS. Pode servir de base para análises quantitativas da colaboração da IS.

Desacordos e mal-entendidos são comuns mesmo nas organizações mais eficientes. Felizmente, uma solução em potencial nos oferece um caminho à frente da vaga e confusão: design de relacionamento intencional. Tirado da profissão terapêutica, o IRD nos permite estabelecer clareza em nossas relações de trabalho logo para evitar conflitos depois. Nesta palestra, mostrarei como pode usá-la para estabelecer expectativas, estabelecer limites e descobrir preferências de comunicação para construir confiança e harmonia, especialmente quando suas equipes visam InnerSource.

Aplicando InnerSource com nossas equipes descobrimos como é a forma mais poderosa de desenvolver, aprender rápido, quebrar silos e escalar organizações. InnerSource permite estabelecer as melhores práticas de desenvolvimento de software de código aberto e cultura de código aberto para cada desenvolvimento interno. Você ainda pode desenvolver software proprietário, mas internamente abrir seu desenvolvimento. Nesta sessão, compartilho nossas experiências de como escalamos nossa organização usando InnerSource com papéis, métricas na minha organização anterior Intuit, e a cultura e práticas internas de código aberto na Microsoft.

Desenvolver uma plataforma tecnológica Cloud Native, que traz capacidades não funcionais para a empresa sempre foi um desafio para nós, como uma equipe de plataforma de fundações. Ao adotar uma mentalidade Open Source, olhamos como aumentar a agilidade e começar uma mudança cultural em nossa própria organização, para impulsionar uma mudança cultural nas unidades de negócios adotando nossa plataforma. Mudamos nossa organização para pensar como uma organização de código aberto (estrutura, práticas de engenharia e colaboração) e logo nos tornamos uma organização InnerSource para a empresa, liderando mais do que InnerSource – liderando uma mudança cultural. Vou descrever a transição que fizemos e como demos os primeiros passos como InnerSource na empresa.

Vamos discutir algumas formas seguras de fogo para garantir que você prepare sua jornada InnerSource para o fracasso. Seguindo essas dicas, você pode garantir que InnerSource nunca terá sucesso.

Aqueles de nós estabelecendo programas InnerSource encontram problemas semelhantes. Desenvolver padrões é uma forma de capturar soluções comprovadas para esses problemas. Vamos trabalhar juntos e fornecer soluções para a comunidade maior! Esta oficina fornecerá uma breve introdução dos padrões InnerSource, e os componentes padrão dos padrões. Então vamos entrar em grupos para criar padrões para problemas penetrantes. Se tiver um problema que queira que cubramos na oficina, avise-nos com antecedência! Email: erin.bank@ca.com

Linguagens padrão mostram como os padrões se encaixam para resolver classes de problemas em torno de uma área temática. Estamos criando padrões InnerSource no ISC desde 2016; este trabalho tem sido, talvez por necessidade, um pouco fragmentado. Descobrimos, por exemplo, que existem diferentes sabores de InnerSource e múltiplas dimensões ao longo das quais programas InnerSource podem ser descritos. Esta apresentação compartilha alguns insights sobre as linguagens padrão InnerSource, como eles podem ser, como eles podem ser usados e como eles podem ser criados.

Durante os últimos meses, um conjunto de empresas na Espanha tem trabalhado em um modelo de maturidade para dar uma estrutura geral para nível C e outras áreas de trabalho em InnerSource.
Esta palestra apresentará alguma discussão interna sobre o tema do modelo de maturidade e uma implementação potencial baseada nos principais princípios InnerSource como Colaboração ou Transparência. Além disso, espera-se que abra alguma discussão sobre o tema deste tipo de modelos que geralmente são iniciados como um conjunto de boas práticas, mas no final são vistos como pura bureocracia dentro das organizações.

A plataforma Siemens InnerSource começou como uma forma de uma divisão manter uma pilha padrão em toda sua gama de produtos. A partir desses começos, rapidamente se tornou algo muito maior: um ambiente de desenvolvimento de última geração, uma ferramenta para construir plataformas dentro da empresa. Também se tornou um exemplo altamente visível para uma forma colaborativa e ágil de trabalhar dentro da Siemens. Nesta palestra, vamos rever a história da plataforma e as principais razões de seu sucesso até agora, bem como desafios passados e presentes.

InnerSource – o que chamamos de Bosch Internal Open Source (BIOS) internamente – é uma ótima ferramenta para uma variedade de casos de uso em uma configuração corporativa. Uma delas é ferramenta interna. Achamos que InnerSource é um ajuste natural. Graças aos nossos esforços constantes de impulsionar a BIOS nos últimos nove anos, finalmente conseguimos convencer o setor corporativo de TI da Bosch a iniciar a adoção da InnerSource. A primeira ferramenta interna que se tornará um projeto da BIOS é o chamado Open Source Desktop (OSD), um OS altenativo baseado em Linux para associados da Bosch. Além de fornecer detalhes sobre os primeiros passos que demos, também vamos dar algumas informações sobre as condições prévias que são fundamentais para um projeto InnerSource bem sucedido e dar uma breve visão geral sobre as áreas onde o OSD é usado dentro de Bosch.

Aqueles de nós estabelecendo programas InnerSource encontram problemas semelhantes. Desenvolver padrões é uma forma de capturar soluções comprovadas para esses problemas. Vamos trabalhar juntos e fornecer soluções para a comunidade maior! Esta oficina fornecerá uma breve introdução dos padrões InnerSource, e os componentes padrão dos padrões. Então vamos entrar em grupos para criar padrões para problemas penetrantes. Se tiver um problema que queira que cubramos na oficina, avise-nos com antecedência! Email: erin.bank@ca.com

Sourcing interno nas redes centrais da NOKIA e as pessoas pareciam um jogo feito no céu. Para a gerência sênior, é um programa de eficiência em P&D. Para os desenvolvedores, é uma oportunidade de se expressarem. A jornada teve seu quinhão de sucessos e fracassos que nos fizeram fazer várias correções de curso no caminho. Logo, a fantasia de terceirização/reuso interno e as expectativas de cumprir os objetivos corporativos tinham suas próprias maneiras de se unir. A lua de mel tinha acabado logo e tivemos a tarefa onerosa de fazer aquele coquetel, a mistura certa entre o desafio de código aberto e o talento corporativo. Ainda estamos procurando por essa mistura elusiva… essa conversa vai explorar as coisas que funcionaram, coisas que não funcionaram, aspirações das pessoas, frustrações.

Em código aberto, projetos muitas vezes diferem significativamente um do outro. Consequentemente, não é surpresa que projetos de fontes internas e até mesmo programas possam ter uma variedade de formas diferentes também. Ao adotar a fonte interna ao fundar um novo programa de fonte interna, ou mesmo ao gerenciar a evolução de uma iniciativa existente, é crucial entender que formas diferentes (classes) de projetos e programas de fonte interna existem. Nesta palestra, apresentamos uma estrutura de classificação que estabelece diferentes classes de projetos e programas de fontes internas. Nós aplicamos o framework a onze empresas fazendo IS e discutimos diferenças de seus programas de origem interna. O quadro de classificação apresentado é o primeiro de seu tipo para classificar e estruturar o espaço do programa de fonte interna existente. Depois de ouvir esta conversa, você será capaz de aplicar o quadro para sua própria empresa.

Cientistas de dados não são desenvolvedores. E ainda assim, eles estão constantemente escrevendo código fonte. Escrever software é complexo, ainda mais no domínio da ciência de dados. Engenharia de Software é a reificação de décadas de falhas e sucessos na entrega de produtos de software. Talvez o código aberto seja um dos casos mais paradigmáticos: com práticas inovadoras, vimos como equipes distribuídas globalmente, misturas de desenvolvedores pagos e voluntários, reutilizando dezenas de pedaços de código, têm fornecido consistentemente software de alta qualidade. O que a ciência de dados pode aprender com Engenharia de Software e Código Aberto? Nesta palestra, mostraremos como as equipes de ciência de dados podem aprender com Engenharia de Software e Open Source, adotar uma abordagem InnerSource, reutilizar código e resultados e entregar resultados de alta qualidade, que são mais fáceis de promover para a produção.

Todo mundo pode instalar uma forja de software, prescrever que “estamos fazendo fonte interna agora” e chamá-lo de um sucesso por definição. Muitos vão mais longe e até começam a medir métricas sobre sua eficácia. Métricas são complicadas, porém, muitas vezes eles apenas frustram desenvolvedores, são fáceis de jogar e muito raramente se ligam a qualquer coisa que o negócio entende – complexidade ciclomática e KLOC alguém? Esta palestra vai propor algumas métricas usadas por um fundo de capital de risco que gerencia empresas como Docker, Twitter, Blabla Car e Hello Fresh para medir o sucesso de seus investimentos. Mostraremos o impacto econômico dessas métricas em exemplos concretos de sua aplicação em grandes empresas como Allianz, Continental e Zalando. Como muitas dessas métricas têm a ver com a aplicação da fonte interna (fonte aberta nos limites das empresas), nós também vamos desmistificar a provável maior percepção errada sobre a fonte interna que está dificultando especialmente a gestão média para adotá-la – o medo de que cada desenvolvedor de agora em diante apenas faça o que ele ou ela quiser.

Fonte interna é a aplicação de metodologias de código aberto para software desenvolvido internamente. Embora simples de definir, fonte interna pode ser difícil de explicar e implementar com sucesso. Esta apresentação introduz os termos, conceitos e princípios chave para uma fonte interna eficaz, juntamente com explicações e exemplos reais. É o conteúdo que é acessível aos recém-chegados enquanto ao mesmo tempo refrescante para aqueles com experiência. A mesma informação nesta apresentação também é entregue como um O’Reilly Oriole, disponível livremente no https://www.safaribooksonline.com/oriole/. Vamos rever o Oriole, como usá-lo, e outros Orioles relacionados à fonte interna que estão a caminho.