En ingles se utiliza muchas veces “deadly sins” (algo así como “pecado capital”) para referirse a prácticas de ingeniería, gestión o desarrollo software que cuando se usan aseguran un más que probable fracaso. Aunque, personalmente, creo que en ocasiones sería más correcto usar “walking dead” que “deadly sins”, ya que aún hay mucha vieja mala práctica que algunas veces creemos que está muerta, que creíamos que ya a nadie se le pasaría por la cabeza volver a utilizarla… pero no es así, la práctica no está muerta… es capaz de levantarse de la tumba otra vez, salir de su sepultura buscando proyectos frescos de los que alimentarse, volver a implantarse en muchas empresas y cargarse cualquier cosa.
Como no hace mucho me volví a encontrar, de nuevo, con unos viejos conocidos “walking dead”, que suelen frecuentar implantaciones de metodologías software, os los he querido describir en este post por si a alguien le ayuda a identificarlos y quitarse así el miedo al encontrárselos:
– Encargar una metodología a una consultora “jet set”, famosa, y con nombre principalmente en inglés, y creer que sólo por eso el éxito está asegurado. Aún hoy hay quien se cree que una consultora le puede hacer una metodología de encargo, como el que encarga comida para llevar, sin que la empresa que “usará” la metodología participe en su elaboración. Para hacer una metodología software con mínimas garantías de éxito, hay que inevitablemente conocer el negocio de la empresa, y adaptarla al mismo, y raro es que el consultor, aunque sepa mucho de desarrollo software, sepa de tu negocio, de seguros, banca, energía o lo que sea a lo que se dedique tu empresa. Las metodologías no sólo se definen de arriba abajo, también tienen que definirse de abajo arriba, estudiando lo que sufre a diario el equipo de desarrollo para desde ahí proponer mejoras. Un consultor te puede ayudar mucho, pero si de verdad quieres una metodología útil tendrás que involucrarte con él en su desarrollo.
– Crear una metodología orientada por la documentación (Paper Driven Develoment) más que por los resultados. También aún hoy hay quien se cree aquello de que el software siempre se debe construir en cascada, y que todo lo que no sea trabajar igual que fabricas de coches es de malos ingenieros software. Aún hay que escuchar cosas del tipo a “yo quiero trabajar con las fábricas software enviándoles una especificación en papel, olvidándome hasta la entrega, igual que cuando encargo un coche a un concesionario”. Aunque los ciclos de vida en cascada, orientados por documentos, puedan funcionar, esto sucede en muy pocas ocasiones y en organizaciones que operan en negocios muy concretos. La realidad dice que desarrollar software con calidad siempre requiere de iteraciones. Ah, y eso sin olvidar que pasar del cascada a un iterativo 100% tampoco suele ser la solución. Hay que ajustar el grado de iteración y eso es una tarea compleja, más que implantar un cascada 100% o un SCRUM 100%.
– No evolucionar y no adaptar la metodología a la organización. E incluso aún hoy hay quien se cree aquello de “vamos a utilizar la metodología xxxxxxx v3, ya tengo el pdf… ahora todo el mundo a usarla y a no saltarse ni una coma”. Hagas tu una metodología, te la haga un tercero o te la bajes de la web, siempre es necesario adaptarla y evolucionarla. Hay que adaptar las metodologías a la organización y no la organización a un pdf o metodología. No existe la metodología única, cada empresa tiene la suya, por eso no funciona implantar directamente algo de otro. Tomar una metodología de un libro o de otra empresa vale para arrancar desde una base, nada más, pero siempre hay que adaptarla a tus circunstancias.
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
Pingback: Bitacoras.com
Muy interesante este post