Ayer comentábamos tres “walking deads” que muy frecuentemente y con temor uno se suele encontrar en proyectos de implantación de metodologías de desarrollo software. “Walking deads” que cuando te los encuentras… ya te haces a la idea de cómo va a acabar la historia (y no acaba como en las películas, en la realidad gana el zombi). Proyectos de implantación de metodologías que no suelen acabar muy bien. Y no acabar muy bien normalmente significa que, después de numerosas discusiones acaloradas, la metodología muere en el olvido, queda sólo para el recuerdo de algunos, se acaba quedando en un cajón y nadie la usa.
Y para terminar el recopilatorio, me ha parecido interesante dejaros también otros diez consejos a tener en cuenta cuando se implanta una metodología. Aunque hay muchos recopilatorios de este tipo, hay uno que me gusta especialmente, el de Cockburn [1], porque, entre otros, es bastante sensato, y que parafraseando dice:
- Diferentes proyectos requieren diferentes metodologías.
- Te vendrá bien una metodología ligera, el peso es costoso.
- Grandes equipos necesitan más elementos de comunicación.
- Proyectos en los que el impacto de un error es mayor requieren de más elementos de validación.
- Formalidad, proceso, y documentación no son sustitutos de disciplina, habilidad y comprensión.
- La comunicación cara a cara es el canal de comunicación más económico y rápido para intercambiar información.
- El aumento de la comunicación y la retroalimentación reducen la necesidad de productos intermedios de trabajo.
- El desarrollo en serie penaliza la velocidad y la flexibilidad.
- En aquellas actividades que no están en la ruta crítica, la eficiencia es prescindible.
- Encuentra tu velocidad óptima de desarrollo.
Aunque, sí, una vez vistos todos estos consejos y problemas no nos olvidamos de que lo más difícil está en convencer a quienes tienen “los poderes”, al contratar o lanzar un proyecto, de en software las cosas son así y no como en las cadenas de montaje de coches.
[1] (Os dejo la referencia a la antigua usanza porque el artículo parece haber desaparecido de la Web, otra razón más para dejar en este post los diez consejos) Cockburn, A., «Learning from Agile Software Development,» parts 1 and 2, CrossTalk: The Journal of Defense Software Engineering, October 2002
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 interesantes esta serie de posts, la verdad. Te dejo el link del artículo que citas, que todavía está disponible en la web:
Part 1: http://www.crosstalkonline.org/storage/issue-archives/2002/200210/200210-Cockburn.pdf
Part 2: http://www.crosstalkonline.org/storage/issue-archives/2002/200211/200211-Cockburn.pdf
Desde que cambiaron crosstalk, es dificil encontrar los artículos, pero por ahí siguen. Aquí puede encontrarse el archivo de lo publicado hasta ahora, desde 1998: http://www.crosstalkonline.org/back-issues/
Gracias por los consejos para escoger una metodología. Sin embargo, cuando no se tiene experiencia desarrollando software, como en mi caso que recién estoy preparando mi tesis, se hace complicado escoger una metodología apropiada. ¿Alguien podría darme un consejo de cómo escogerla? Muchas gracias!
@Francisca:
Hola,
Tenía medio escrito un post sobre esto. Lo termino y a ver si te ayuda.
Saludos