Como seguro ya sabrás, el próximo 20 de octubre, en Madrid, en la Peopleware – Agile Management #PAM2016 tendremos la gran suerte de tener como “Keynote” a Alistair Cockburn (incluso puede haber más, ya que estamos organizando un curso con él los días previos, veremos)
Alistair es uno de los fundadores del moviento ágil, uno de los firmantes del manifiesto ágil, elegido como uno de los “The All-Time Top 150 Tecnology i-Heroes” en 2007, puso sensatez al concepto de caso de uso y un montón de cosas más, te dejo para más información en la entrevista que le hice hace unos años y algunos post que hay por el blog inspirados en sus trabajos: La separación física entre los miembros de un equipo impacta en su rendimiento (2015), o el de Una metodología para cada proyecto, o la escala de Cockburn (2011) y aquel de Las metodologías Crystal. Otras metodologías ágiles que, quizás, te puedan encajar más que Scrum (2012).
Aparte de los anteriores, y muchos otros, una de las aportaciones más carismáticas de cockburn es la de que el “El desarrollo software es un juego colaborativo”. Plasmada en aquel mítico, y ya con años, artículo de software development is a cooperative game, donde Cockburn escribía (translated by jGarzás, of course):
“Si el desarrollo software fuese realmente una ciencia, se podría aplicar el método científico a la misma. Si fuera realmente una ingeniería, entonces se podrían aplicar técnicas de ingeniería […]
Sin embargo, no es ninguna de ellas. El desarrollo de software es un «juego», un juego de velocidad y cooperación en equipo, en competencia con otros equipos (de otras empresas o en la misma). Es un juego contra el tiempo y un juego mental.“
Como irás viendo, más allá de que hay otras cosas de moda hoy, cosas más recientes, más coolianas, etc., este artículo, de 1999, es de obligatoria lectura para cualquiera que se dedique al mundo del desarrollo software, extendería, incluso, a la creación de productos intelectuales, y ya no te digo para aquellos en el mundo Ágil.
Y es por ello que no he querido dejarlo pasar, sintetizandote las ideas que me parecen más importantes.
Como no quería quedarme corto, ni soltarte el “tocho” post, este post tendrá dos partes (la de hoy y la segunda será el lunes, que mañana yo libro de post, lo cual no quiere decir que no habrá post mañana :-).
Aún así esta es mi personal interpretación y síntesis, yo te recomiendo que te leas el artículo original entero, pero si no tienes tiempo… aquí algo tienes.
Idea previa 1: La comunicación SIEMPRE es IMperfecta
Lo primero que hay que tener claro es que no hay comunicación perfecta y completa. El oyente, o el receptor de la comunicación, tiene que superar una “brecha” para entenderte, y tiene que hacerlo solito. Cuanto más diferentes (culturalmente, idioma, etc.) sean receptor y emisor, y más canales ponga de por medio… mayor será la brecha.
Así que la primera idea es que la comunicación completa no es posible y una de nuestras tareas en un proyecto de desarrollo software es gestionar el carácter incompleto de las comunicaciones entre personas.
Además, la separación física entre los miembros de un equipo impacta en su rendimiento (2015), llegando a la conclusión de que la comunicación cara a cara, frente a una pizarra, es la más efectiva.
Idea Previa 2: Las Personas son “dispositivos” activos
Lo que nunca se te tiene que pasar es que los procesos de desarrollo de software utilizan seres humanos como componentes activos principales. Y los seres humanos NO son “dispositivos” lineales.
Así que cuando hablemos procesos de desarrollo de software, lo primero que hay que tratar de tener claro es cuáles son las características de “estas cosas” llamadas “personas».
Vamos con algunas importantes e interesantes, vamos con lo que se les da bien a las personas y con lo que no se le da tan bien:
– La gente tiene un montón de características interesantes. La gente es muy buena en lo que refiere a la comunicación con otras personas, cara a cara, por supuesto. La gente es muy buena tomando la iniciativa cuando hay problemas, y esto es lo que salva la mayoría de los proyectos (quizá recuerdes aquel post de 2011 de por los héroes), la gente hace lo que sea necesario, no importa lo que diga el proceso, o la metodología, se la saltan, y saltarán, para solucionar el problema.
– Sin embargo, las personas no suelen ser constantes en su trabajo, suelen tender a ser descuidadas e indisciplinadas. No leen las instrucciones. Alternan la “procrastinación” con el trabajo duro. Se resisten a aprender, a cambiar y utilizar las nuevas ideas. Cualquiera que sea la técnica que haya que aplicar… la gente se va a resistir a usarla.
—
Vistos los antecedentes, el lunes vamos con la segunda parte de este post, para mi, la más profunda e interesante, por qué debemos ver al desarrollo software como un tipo de juego, en el que el equipo colabora para obtener un objetivo, con una reglas, dentro de unas restricciones.
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
Con este tipo de post me hace pensar en que algunas cosas que no aclaran en las universidades de las cualidades recomendadas que deberían tener los desarrolladores de software:
– Disposición a trabajar en equipo.
– Capacidad de crear y seguir procedimientos.
– Disposición al cambio (adaptación).
– Perseverancia.
– Actitud autodidacta.
– Humildad.