"Deadly Sins", o "walking deads", de implantar una metodología software. (2/2) Diez consejos más

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:

1. Diferentes proyectos requieren diferentes metodologías.
2. Te vendrá bien una metodología ligera, el peso es costoso.
3. Grandes equipos necesitan más elementos de comunicación.
4. Proyectos en los que el impacto de un error es mayor requieren de más elementos de validación.
5. Formalidad, proceso, y documentación no son sustitutos de disciplina, habilidad y comprensión.
6. La comunicación cara a cara es el canal de comunicación más económico y rápido para intercambiar información.
7. El aumento de la comunicación y la retroalimentación reducen la necesidad de productos intermedios de trabajo.
8. El desarrollo en serie penaliza la velocidad y la flexibilidad.
9. En aquellas actividades que no están en la ruta crítica, la eficiencia es prescindible.
10. 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