Buenas prácticas, metodologías y Scrum

Que no existen balas de plata metodológicas es algo que ya hemos dicho muchas veces y que seguro que sabemos todos.

Y por tanto, no hay una metodología para controlarlas a todas, cada equipo, cada proyecto, cada entorno es distinto e intransferible, y lo que vale para uno no vale para otros, por tanto es de vital importancia entender cómo funcionamos, tanto como equipo, como cada miembro individual, para poder aplicar lo que funciona y lo que no.

Lo cierto es que supongo que no estoy contando nada nuevo, es algo que siempre se habla, y que últimamente, Ivar Jacobson nos ha recordado tanto en aquel evento de ALM del año pasado en Madrid, como en otra ocasión que tuve de estar hablando con el despues del TechEd en Barcelona.

Y es que, en gran medida estoy de acuerdo con su mensaje, al final, una de las cosas más importantes a la hora de poner orden, es aplicar las prácticas que funcionan en la que sea nuestra situación actual.

Hay muchas prácticas definidas en otras tantas metodologías, desde Test Driven Development, programación por parejas, desarrollo iterativo (aunque esta es omnipresente), casos de uso, retrospectivas, etc., etc., que podemos aplicar, aunque no apliquemos la metodología en cuestión.

Con esto no se quiere decir que no se aplique con rigor una metodología, y que simplemente apliquemos prácticas, nada más lejos de la realidad. Es muy importante, sobre todo al principio, que tengamos algo en lo que apoyarnos y que guíe nuestros pasos.

Siempre es indispensable contar con una buena metodología, escogida según nuestras necesidades, que forme la base de nuestra gestión. Lo que quiero decir con esto, es que, basándonos en nuestra experiencia, debemos evolucionar nuestro proceso, adoptando prácticas que observemos y veamos válidas, aunque no formen parte de nuestra metodología, y descartar prácticas que nos creen impedimentos o aporten lo suficiente.

Pero ojo al añadir o eliminar prácticas (especialmente al eliminar), no todas las prácticas aportan beneficios inmediatos, y debemos ser muy conscientes de todo el proceso, no sólo de la situación inmediata, como decía Ivar, “Be Smart”. Cuando nos planteemos el quitar o añadir, debemos tener razones de peso, observadas durante un tiempo y compartidas con el equipo.

Y por eso agrego aquí a Scrum, ya que es probablemente la más “ligera” de las metodologías, las prácticas que específica son relativamente pocas y fáciles de seguir, pero hay una que encaja a la perfección con esto que aquí escribo, y son las reuniones de retrospectiva del sprint. En estas reuniones siempre detallaremos que es lo que hemos hecho bien, lo que hemos hecho mal, lo que hemos aprendido, y lo que no es necesario. En definitiva, la observación de todas nuestras prácticas para evolucionar el proceso.

Esta es una de las grandes cosas de Scrum, el tratar el proceso en si mismo como algo vivo, y no sólo como algo vivo, si no como algo que se puede cambiar con relativa facilidad (todos sabemos que no todo es tan fácil como parece), y con frecuencia.

Al final, en el proceso de desarrollo, dependemos de las personas y de como funcionan, y esto es lo que debemos observar para poder tener un proceso consistente, y, aunque en esto difiero con Ivar, yo si considero que el proceso de desarrollo es un 80% de pensar, y un 20% de aplicar patrones y/o prácticas (justo al contrario que Ivar), ya que por muy detallados que sean esos patrones, y esas prácticas, debemos de aplicar nuestro conocimiento y pensamiento para aplicarlas a nuestros procesos.

Bueno Ivar, al final, y aunque un poco tarde, escribí esta pequeña reflexión que te dije que escribiría tanto en Madrid, como en Barcelona, espero que a pesar de estar en español, no se te haya hecho muy duro de leer :).


Este post es cross-posting desde www.lfraile.net y estoy muy interesado en tu opinión. ¿te vienes por aquí y me dejas un comentario?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *