Jim Coplien (también conocido como Cope) es uno de los principales fundadores del movimiento de patrones de software y del desarrollo ágil, coautor de “Organizational Patterns of Agile Software Development” y “Lean Software Architecture for Agile Software Development” aparte de otros libros importantes.
Ahora trabaja junto con los padres de Scrum para facilitar su evolución y formalización.
Personalmente, es un gran honor para mí entrevistar a Jim, porque parte de mi tesis fue sobre patrones de diseño. Y Jim es uno de los padres del movimiento.
Jim, muchas gracias por la entrevista.
1 – La mayoría conoce tu trabajo sobre patrones, pero…¿Quién es Jim? ¿De dónde vienes? ¿Experiencia previa? ¿Dónde trabajas?
Nací en un pequeño pueblo del medio oeste de los Estados Unidos y me gradué e hice un master en Informática en la Universidad de Winsconsin. Conseguí mi primer trabajo en la informática en enero de hace 40 años, en un laboratorio de ingeniería informática. Más tarde comencé una emocionante carrera en AT&T Bell Laboratories donde me moví a través de diversas disciplinas los siguientes 22 años, incluyendo la administración de programas, la investigación aplicada en los entornos de desarrollo de software con un enfoque en el desarrollo multi-hilo, y el diseño orientado a objetos. Fui el primer usuario de C++ fuera de Bell Labs Research y ayudé a Bjarne Stroustrup en la evolución del lenguaje – es probable que más gente me conozca por eso que por mi trabajo sobre patrones.
Después pasé a Bell Labs Research y llegué a ser uno de los fundadores de Software Patterns Discipline y pionero en el uso de patrones organizativos. Ese trabajo es reconocido ampliamente como uno de los fundamentos de Scrum y XP. También he dado charlas académicas en Europa, Australia y los Estados Unidos, y estuve durante dos años en la cátedra Vloebergh en Vrije Universiteit Brussels (VUB). Mi experiencia investigadora incluye un Ph.D y Doctorado en Ciencias Aplicadas por la VUB.
Más recientemente, he servido a la industria como consultor. Mi mujer y yo hemos creado nuestra propia empresa, Gertrud & Cope, y vivimos en Dinamarca. Soy también socio en la empresa de Jeff Sutherland Scrum, Inc. Jeff fue el inventor de Scrum.
2 – Ahora lidera y actualiza el catálogo de patrones de Scrum en scrumplop.org. Háblanos acerca del proyecto, cuál es su futuro y sus metas.
Ayudo a dar forma a Scrum de diferentes maneras. La vía más importante es trabajando directamente con compañías que colaboran con nosotros para mejorar su cultura del desarrollo. En segundo lugar, también ayudo a Jeff Sutherland en la evolución de la Guía de Scrum, que es el “libro de reglas” para Scrum. Mi misión ahí es infundir más agilidad en la evolución de la definición propia de Scrum.
En tercer lugar, como dices, soy Product Owner de Scrum Patterns effort, Scrum PLOP ® (http://www.scrumplop.org). Es, en cierto modo, una consecuencia del trabajo en patrones organizativos que se inició hace 20 años (http://orgpatterns.wikispaces.com). Estoy orgulloso de este trabajo, ya que es el único grupo no-partidista que conozco que quiere evolucionar hacia una definición racionalizada de Scrum. Jeff Sutherland recientemente lo destacó como la fuente a la que ir si quieres entender cómo realizar un cierto progreso en la implementación de tu propio Scrum que puede aliviar muchos dolores de cabeza a los Scrum Masters.
Ikujiro Nonaka-sensei, el “abuelo de Scrum”,
Hay tres factores que hacen los Patrones de Scrum especiales.
1. Adoptan un sistema de visión del pensamiento de la transformación organizativa en vez de un enfoque de libro de reglas. Esto significa que podemos ir más allá de la estructura de organización técnica y de los principios y valores y abordar los problemas humanos que hacen que el desarrollo se vuelva tan complejo. Los patrones nos ayudan a pensar de forma sistemática, que es lo contrario más o menos de “analizar las causas de origen”.
2. Los patrones de Scrum están moldeados por los fundamentos de Scrum y escritos de primera mano por grandes pensadores: Jeff Sutherland, Michael Beedle, Gabrielle Benefield, Jens Østergaard y más.
3. Son el reflejo de entrada de las mayores entidades certificadoras, y donde nos falta el compromiso de los principales grupos actuales, estamos intentando incluirlos.
Creo que es importante entender que lo que estamos construyendo no es sólo un catálogo de patrones. Se puede hacer una compra por catálogo en la que elige una o dos cosas que llevar a casa. Nosotros estamos construyendo algo mucho más formal llamado patrones del lenguaje. Patrones del lenguaje incluye una serie de reglas que limitan el número de combinaciones de los patrones de acuerdo a una gramática generativa, que pueden ser utilizados por el diseñador para generar una gran cantidad de resultados. Significa en términos simples que estamos construyendo una hoja de ruta que puede inspirar a las organizaciones, mostrándoles las muchas rutas de acceso a la construcción de grandes equipos de Scrum.
Un lenguaje de patrones requiere juicio, la visión y la adaptación por parte de sus usuarios. Muy pocas de las publicaciones que actualmente se hacen llamar de “patrones” tienen esta capacidad generativa. Sin embargo, el inventor de patrones, Christopher Alexander, insiste en que esta es una propiedad esencial de los patrones. Lo componen entre sí para crear «conjuntos morfológicos.» Estos conjuntos son equipos, cadenas de valor, las relaciones, los ciclos en el tiempo, y otras estructuras de la organización de desarrollo.
La última vía en la que estoy contribuyendo a la comunidad ágil es con un juego divertido del iPad llamada Scrum Knowsy (https://itunes.apple.com/us/app/scrum-knowsy/id570583518). Lo hemos diseñado para el juego en equipo, dejando que los miembros del equipo desafíen el conocimiento de cada uno de Scrum. También pueden preguntar a los Oráculos – Las autoridades mundiales en Scrum – para ver cómo coinciden con los expertos. La parte divertida es que ¡no hay respuestas correctas!
Yo trabajo en áreas de conocimiento maduras: los excelentes vinos de la ingeniería de software. Me ha llevado 40 años de práctica para llegar allí. La mayoría de los estudiantes tienen dificultades para apreciar estas ideas, o incluso la búsqueda de acceso a los mismos, a medida que aprenden a dominar los fundamentos de sus ciencias, artes y oficios. Ellos no han ido lo suficientemente lejos o no se han golpeado contra la misma pared de ladrillo a menudo lo suficiente para apreciar los problemas más difíciles – los que permanecen dormidos pero erosionan las organizaciones lentamente. Creo que cuanta menos experiencia tienes en esta profesión, más piensas en el diseño del sistema solo a corto plazo.
La mayoría de los estudiantes de ingeniería piensan en términos de cortos periodos de tiempo, un buen ingeniero maduro piensa en el futuro, de cómo el uso y la naturaleza harán que una estructura se debilite o se vuelva obsoleta. Los patrones atacan a ese tipo de entropía. Los ingenieros que construyen templos japoneses hoy en día, plantan árboles que se utilizarán para construir sus sucesores dentro de 200 años; los patrones de la construcción sientan las bases para un futuro mejor mediante la comprensión del pasado. Los patrones pueden proporcionar una puerta de entrada a los estudiantes para apreciar los elementos cruciales de la construcción del producto más allá de un contexto académico, y el juego es una un inicio divertido de Scrum para niños de todas las edades. Se pueden encontrar los patrones en http://www.scrumplop.org/.
3 – ¿Cómo ves el futuro de la agilidad?
Si por “agilidad” te refieres a aquello en lo que se centra el manifiesto ágil, lo veo como una señal de tráfico en un viaje social más amplio, desde una sociedad complicada a una sociedad compleja. Este es otro de los cambios en el mundo, que contribuyen a la evolución y paso de lo complicado a lo complejo, como también lo hicieron la transición desde la sociedad de fabricación a la sociedad de servicios, o desde las estructuras sociales de hace 60 o 70 años a un mundo completamente conectado.
Uno encuentra problemas y paradojas aquí. En primer lugar, el grado en el que el mundo está conectado, permite a los individuos acceder a los conocimientos de forma más sencilla con respecto a como ocurría en el pasado, lo que significa que los individuos trabajan de manera más independiente. En segundo lugar, el crecimiento en la economía de servicios refleja que la sociedad humana ha madurado y que tiene la habilidad de alcanzar metas más altas de la existencia social, particularmente cuando los servicios más rutinarios se han automatizado. La libertad de no depender directamente en recursos y materias primas, contribuye de nuevo a esta independencia y a una economía mercantil: No voy a tener nunca que montar mi propio ordenador, o incluso comprar uno. Si en su lugar dispongo de un terminal con la que puedo acceder a la nube, puedo hacer casi todas las cosas que necesito de un ordenador.
Sabemos por la experiencia que los equipos dan mejores resultados que los individuos que simplemente cooperan (hay una gran diferencia entre los dos conceptos), pero la mismas fuerzas que han liberado a la sociedad hacia un mundo ágil, lanzan agua fría en las llamas del trabajo en equipo, que puede aprovechar la agilidad para crear un gran cambio en el mundo. El concepto ágil, habla de individuos e interacciones, pero en el mundo actual, la mayoría de las comunicaciones se dan entre individuos y máquinas, en vez de entre equipos.
La mayor parte de los productos software son más “commodities” que productos. La mercantilización también erosiona el valor ágil de la colaboración con el cliente. ¿Por qué debería satisfacer tus necesidades? Se podría crear un producto y que valiera para todo el mundo. Henry Ford dijo que tú podrías tener el color de coche que quieras, siempre y cuando fuera negro.
Los productos software actuales y los entornos de desarrollo, tienen una naturaleza muy fuerte de commodity y eso no se lleva muy bien con lo ágil.
Las commodities tienden a introducir inercia, y esto va en contra de promover el cambio. Mucho de nuestro software se construye por capas; las capas inferiores evolucionan más lentamente y por razones de compatibilidad, provocan la mayor parte de las dificultades que sufre el software en su evolución. Los programadores de aplicaciones crean pequeñas variaciones encima de esas pilas heredadas de bits y monumentos al poco cuidado que provocan los excesos corporativos, pero la historia es una gran ancla de barco.
Imagina si hoy alguna persona de tendencia ágil encuentra una nueva y radical alternativa a Internet – a lo mejor algo que incluso podría impedir que los gobiernos se entrometieran en tus conversaciones. Nuestra herencia de consumo masivo limita estas visiones a un mundo puramente fantástico hacia el que es difícil evolucionar gradualmente y en el que es impensable introducir esos cambios en masa. Muy a menudo vemos Internet como infinitamente maleable y una columna vertebral libre de contexto, pero de hecho es un modelo muy limitado por soportar interacciones complejas. Después de todos estos años, ahora es cuando estamos empezando a realizar llamadas fiables y de calidad por internet tan solo pulsando un botón.
Este tema abarca más que el software ágil. Como parte de este amplio cambio en el mundo, hemos perdido el apetito por planificar las cosas. Vivimos en el mundo de la inmediatez. No tengo ningún dato, pero tengo la fuerte sensación de que el compromiso empresarial ya no significa lo mismo que antes. El ágil simplista del Manifiesto Ágil verá prosperar sus valores en este mundo. Pero en el sentido más profundo de provocar cambio: ¿puede lo ágil estar a la altura de las circunstancias e instigar una vuelta a los sistemas de pensamiento, razonamiento y planificación? No soy muy optimista: esto es un nivel más profundo de cambio de lo que creo que está permitido a los valores ágiles que los llamados Agilistas viven día a día.
En el término medio, deseo que las ideas del Sistema de Producción de Toyota (TPS) crezcan y prevalezcan en las culturas del desarrollo de sistemas. En su lugar, veo el crecimiento y predominio de las prácticas superficiales de TPS, popularmente llamadas “Lean”. “Lean” fue la popularización de las prácticas superficiales de TPS, documentadas en un estudio académico de 1980. Por ahora tengo la esperanza de que los ideales de TPS, y particularmente tal y como se manifiestan en Scrum, pueden enseñar a los equipos cómo manejar complejidad con planificación. Pienso que es importante señalar que la agilidad y TPS a menudo se centran en cosas opuestas y que además, Scrum está más relacionado con los principios de TPS que con los principios ágiles. Ágil fue un manifiesto específico del software escrito en 2001; Scrum se remonta a 1993 o 1994.
Podemos decir que lo ágil viene de Scrum, muy tarde en el juego – no vice-versa. De forma más realista, ambos surgieron de una conciencia cada vez mayor en la década de 1990 de la necesidad de apoyar el desarrollo de sistemas complejos. Scrum hace hincapié en los sistemas de pensamiento responsables de tales cambios y espero que prevalezcan a medio plazo.
En un futuro lejano, me parece que el desarrollo de software debe dar paso a un modelo de enjambre y a algo que se parezca más al código abierto, donde podemos aprovechar los productos de consumo (UNIX, C) de la actualidad para volver de nuevo a la dinámica de los sistemas. Si podemos encontrar nuestro camino hacia ese panorama, habremos hecho un gran salto con respecto al incómodo y terrible matrimonio entre el alto individualismo y las culturas de bajo contexto de desarrollo.
Animo a los estudiantes a invertir en aprender sobre el proceso de fabricación japonés en general y sobre TPS en particular. Pienso que uno no puede explorar las partes de alta rentabilidad de este mundo sin dedicar tiempo a entender la cultura en la que creció y las raíces de esa cultura. Esto va a sonar raro, pero los alumnos lo agradecerán dentro de 50 años: estudia japonés y la cultura japonesa; estudia el Budismo y la historia japonesa. Lee “The Reckoning”de Halberstam.
En términos más generales, el estudio de un puñado de culturas: sumérgete tanto en las artes como en las ciencias, y más aún en las ciencias humanas. La excelencia en ingeniería prepara a los grandes seguidores: un aprendizaje amplio prepara a aquellos que tendrán que establecer las agendas en el futuro. E involúcrate en el código libre. Ensucia tus manos; crea algo junto a otros en equipo. Demasiada ingeniería del software es un trabajo de torre de marfil.
Continúa en Entrevista a Jim Coplien (2/2)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
La segunda parte de la entrevista no esta disponible.
Es que esto es como las teleseries, para mantener la tensión del espectador… sale mañana 😉