Inner source ágil, ¿es posible?

La actividad sin fronteras de las comunidades Open Source contrasta con los enfoques más populares de desarrollo ágil corporativo como Scrum diseñados para equipos que trabajan juntos en una oficina que se comunican cara a cara. Los desarrolladores de estos proyectos no solo tienen trabajar juntos, sino que deben reunirse regularmente con los usuarios del software y otras partes interesadas. Todo este intercambio informal de información reduce la necesidad de documentación y requisitos formales.

Por su parte las comunidades Open Source en organizaciones (o InnerSource) suelen estar formadas por un gran número de personas, distribuidas en múltiples geografías. En este contexto todo tiene que quedar por escrito, lo que requiere un esfuerzo considerable de documentación. Además la cadencia de disponibilidad del software suele ser menor que en agilidad. Eso sí, a cambio se obtiene un gran compromiso y motivación por parte de los colaboradores y, por tanto, una altísima calidad.

¿Podemos aprovechar las ventajas de las comunidades InnerSource y la agilidad? ¿Pueden InnerSource y Agilidad convivir juntos?

Transcript

1. Inner source ágil, ¿es posible? Jorge Maestre @sunzu https://www.linkedin.com/in/jorgemaestre/
2. ¿Qué es inner source? InnerSource consiste en el uso de las mejores prácticas de desarrollo de software open source en los procesos de desarrollo de las empresas comerciales para crear y publicar software propietario. Tim O’Reilly en 2.000 APERTURA TRANSPARENCIA COMUNIDAD ABIERTA CONTRIBUCIÓN VOLUNTARIA
3. ¿Por qué inner source? 1. Reutilización del código 2. Romper silos 3. Desarrollo más rápido y mayor calidad 4. Documentación completa 5. Satisfacción en el trabajo
4. vs AGILE INNERSOURCE
5. Estructura organizacional AGILE • Equipos pequeños autoorganizados y físicamente cercanos • La composición la deciden los managers • Escalado en base nuevos roles y/o marcos INNERSOURCE • Autoorganización en comunidades abiertas distribuidas geográficamente • Líder (BDFL) • Trusted Committers • Contributors • Meritocracia • Diseñado para escalar
6. Producto AGILE • Visión Product Manager • Incorpora a los usuarios • Feedback loops cortos • Orientado a features y, con suerte, a impacto en el usuario • Adaptación por iteraciones cortas INNERSOURCE • Visión del Líder/BDFL/Product Manager • Orientado a componentes o features • Feedback loops en comunidad cortos, más largos con usuarios • Adaptación por tamaño de comunidad
7. Colaboración AGILE • Con lo miembros del equipo • Con el negocio • Con los usuarios • Con otros equipos del mismo producto INNERSOURCE • Con la comunidad • Con equipos invitados • Con unidades de negocio • En otros productos • Potentes relaciones Trusted Committer – Contributor que requieren dedicación
8. Transparencia y comunicación AGILE • Transparencia radical • Cara a cara en el equipo, muy rápida • Requiere poca documentación y requerimientos “formales” INNERSOURCE • Transparencia radical • Comunicación formal, abierta y preferiblemente por escrito • Decisiones y acuerdos documentados • Peligro de saturación en la comunicación
9. Conocimiento y mejora continua AGILE • Se crea conocimiento tácito en los miembros del equipo • Se priman las interacciones entre personas • Existen mecanismos para mejorar el trabajo en equipo INNERSOURCE • La naturaleza distribuida requiere que el conocimiento sea explícito • La documentación y las decisiones deben ser archivables • Mejora individual gracias a las relaciones Trusted Committer – Contributor • Polinización cruzada entre comunidades por Contributors
10. AGILE + INNERSOURCE
11. Qué nos ha funcionado 1. Ecosistema inner source abierto: patrón Review Committee 2. Comunidades de producto enfocadas en el usuario, incluyendo negocio, UX, devs y usuarios 3. Identificar un Host Team como “dueño del producto” e invitar a otros equipos a colaborar 4. Méritos del equipo sobre méritos individuales 5. Documentar sólo cuando se necesite, pensando en la comunidad sin crear “Deuda documental”
12. Libros Getting Started with InnerSource by Andy Oram Adopting InnerSource - Principles and Case Studies by Danese Cooper, Klaas-Jan Stol Understanding the InnerSource Checklist by Silona Bonewald Managing InnerSource Projects by Daniel Izquierdo
13. Enlaces de interés • Inner Source Commons [https://innersourcecommons.org/] • Patrones InnerSource [https://github.com/InnerSourceCommons/InnerSourcePatterns] • Open and Inner Source in Bosch [https://www.bosch.com/research/know- how/open-and-inner-source/] • Inner Source - Adopting Open Source Development Practices in Organizations [https://www.infoq.com/articles/inner-source-open-source-development- practices/] • Inner Source Definition, Benefits, and Challenges [https://www.researchgate.net/publication/311477364_Inner_Source_Definition_Benefits_and_ Challenges]
14. Enlaces de interés • Application of inner source on small development teams - A case study [http://sam.cs.lth.se/ExjobGetFile?id=450] • Key Factors for Adopting Inner Source [https://www.researchgate.net/publication/257304296_Key_Factors_for_Adopting_Inner_Source] • An Empirical Investigation into the Adoption of Inner Source in IT Companies: A Case Study [https://gupea.ub.gu.se/bitstream/2077/62555/1/gupea_2077_62555_1.pdf]
15. jorge.maestre@vass.es ¿hablamos?