“Dime y lo olvido, enséñame y lo recuerdo, involúcrame y lo aprendo» (Benjamin Franklin)
El terror de muchos, el Freddy Krueger que por las noches persigue a muchos responsables de proyectos, el Alien que muchos otros pobres e incautos responsables software desconocen que está incubando en su proyecto para estallar en algún momento: la dependencia de personas concretas.
La dependencia de personas concretas es tan antigua como el software, es aquello de que ciertas partes del desarrollo solo las conoce (sabe mantener, explicar, etc.) aquel que las hizo. Si aquel que las hizo no está… pues nadie sabe cómo meterle mano a aquello. Aquel que las hizo, el a veces llamado Rambo, es al que se le llama por las noches cuando algo se cae, el que nadie quiere que se vaya de vacaciones, etc.
La dependencia tiene un impacto altísimo en la productividad de un equipo y de una organización. Por ejemplo, impide a muchas organizaciones dar el salto a equipos ágiles (pequeños y multifuncionales), ya que si, por ejemplo, al dividir un equipo grande en 2 de menos de 10 personas solo hay un Rambo, Rambo quedará en uno de los equipos… frenando al otro.
De hecho, la dependencia de personas es una de las piezas clave para disparar los ingresos en el negocio oculto de hacer mal software (y software malo).
No te engañes a ti mismo limpiando tu conciencia con papel
Parece mentira, pero aún hay quien cree que teniendo pdfs, que supuestamente documentan un desarrollo software, tiene bajo control el tema de la dependencia de personas, ya que lo que ellos saben “está documentado”. Ja, ríete. Ríete de que lo que hay en un pdf esté actualizado y con el suficiente detalle para llevar el conocimiento de la persona A a la B.
Por ejemplo en 233 Grados de TI, se sigue la práctica de no documentar en papel, tiempo perdido, desperdicio Leen (desperdicio en hacer papeles y en mantenerlos) y basar la difusión del conocimiento entre personas haciendo que todo el mundo haga de todo, rotando cada mes, porque la verdadera manera de saber hacer algo es haberlo hecho antes…
Con seguridad alguien sabrá hacer algo… si lo ha hecho antes. No hay mejor garantía
En este punto, hay algunas cuestiones sobre el aprendizaje que debemos conocer, importantes en lo que aquí nos atañe:
a) Se aprende haciendo. Luego puedes hacer las cosas con mayor frecuencia y aumentar tu experiencia, pero si al menos una vez haces aquello que quieres aprender… la siguiente vez que te toque hacerlo no irás a ciegas.
b) Cuanto más complejo es algo más se tarda en aprender (y, obviamente, más difícil es documentarlo y de menos ayuda es). Por ello, es tan importante que, en temas relativos a desarrollo software, te preocupes al máximo de la calidad software, entre otros, para reducir la dependencia de personas, si las cosas son complejas sin necesidad fomentas que sólo el que hizo aquello tan complejo sea capaz de mantenerlo.
Algunas técnicas para evitar que el conocimiento esté sólo en unos cuantos
En base a lo anterior, desde hace muchos años, el mundo del desarrollo software ha ido aportando varias técnicas para difundir el conocimiento de un proyecto. Muchas de estas técnicas han sido potenciadas por el mundo ágil. Si bien sería deseable encontrárnoslas mucho más en los proyectos.
Ejemplo popular es el “pair programming” (¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?), que entre otros objetivos y beneficios busca que no sólo una persona sepa cómo se programan ciertas partes del código. Se basa en que dos programadores trabajan juntos en un solo ordenador. Uno de ellos desarrolla mientras que el otro ayuda y revisa el código del compañero.
De manera complementaria al anterior, también idóneo para aquellos que ven el pair programming como demasiado, demasiado eso de dedicar a dos personas al mismo ordenador, otras empresas utilizan el “pair review”, revisión por pares, alguien hace algo y otra persona, posteriormente, lo revisa (un caso de estudio sobre esto viene en el libro de How Google Test, del que hablamos en el Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)).
En esta línea, siempre con la idea de que otra persona “haga” para aprender, esta el Mob Programming: un único ordenador para todo el equipo (más allá del pair programming).
Y es que ya lo dejaba bien claro el “framework” de buenas prácticas ágiles eXtremme Programming, si quieres que el conocimiento se comparta, lo que allí llamaron la práctica del “Shared understanding”, rodéate de las siguientes prácticas: Coding standard (buenas prácticas de programación), Collective code ownership (que todo el código sea de todo el mundo), Simple design (mantenlo simple) y System metaphor (que se pueda explicar con facilidad).
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Un post muy interesante. Soy un lector «pasivo» pero esta vez el tema que tratas toca directamente con uno de los trabajos que estamos realizando y he pensado que podría ser de utilidad comentarlo.
En concreto, hemos trabajado con el concepto de bus factor, que creo que está relacionado con el tema del blog post. Este factor indica «el número de desarrolladores clave que si son arrollados por un bus provocaría que el proyecto no pueda avanzar». Creo que este factor puede ayudar a lozalizar quien es (in)dispensable en el proyecto y adelantarse a la aparición de Rambos (i.e., resultados de bus factor muy bajos).
Hemos creado una herramienta que permite calcular el «bus factor» en proyectos basados en Git, que puedes encontrar aquí:
http://github.com/atlanmod/busfactor
También tenemos un artículo que describe la herramienta y que será publicado en la conferencia SANER (precisamente la semana que viene). Aunque no está todavía disponible, puedes encontrar más información en este blog post:
http://modeling-languages.com/whats-bus-factor-software-project/
Un saludo!
Muy interesante. Agrego desde mi perspectiva una cuestión más que ayuda, y es interesante, y es la de tener una arquitectura y un diseño lo más compacto y cohesivo posible.
Pienso en componentes pequeños o micro-services (http://martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture). Por más que un desarrollador sea el que hizo el 90% de los micro-services y se vaya, los problemas/requerimientos/cambios, si está el código bien organizado, debería afectar a un número mínimo de componentes. Y como cada componente es muy específico, compacto y pequeño, es mucho más fácil de controlar para alguien que no conoce el código (y si el dominio del problema).
Saludos!