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?

Próximo evento Madrid.NET: Mesas redondas

Como ya sabréis los que seguís el blog de Madrid.NET, os pedimos vuestra opinión para el evento del 22 de enero.

Y bueno, tras ver opiniones, tanto online, como offline, ganaron las mesas redondas.

Y ahora es vuestro turno, lógicamente para que las mesas redondas funcionen, necesitamos vuestra asistencia y colaboración. Colaboración para proponer temas, hablar, dar ideas, y por supuesto vuestra asistencia allí. Así que os animo a todos a que vengáis a este evento.

Aquí os dejo el link con la información de registro.

Nos vemos el 22.


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?

Cuando metemos la pata …

Y es que esto es algo que antes o después ocurre, fallamos en el diseño de una arquitectura, hacemos checkin de código que no compila, tomamos una decisión de implementación totalmente desafortunada, o cualquiera de las múltiples situaciones que se nos dan en un proyecto.

Es algo que nos va a ocurrir, no en vano los errores nos ocurren en nuestra vida diaria, ese típico creo que puedo cargar con un plato más de camino a la cocina que acaba en tragedia, o esta bolsa seguro que aguanta este peso (curiosamente la bolsa dónde llevamos las botellas de cerveza), o más serios como ese típico mensaje/correo que justo cuando le das a enviar, te das cuenta de que lo estás enviando a la persona equivocada, y el contenido, ejem, dejémoslo ahí …

Diagrama-para-resolucion-marrones_1

Los errores ocurren, somos humanos, y no podemos evitarlos, tenemos que aprender a convivir con ellos.

Lo realmente importante de esto, es como reaccionamos ante ellos. Para mí es más importante, como cliente, el como alguien me soluciona un fallo, que alguien que “presuntamente” no tiene fallos.

Nuestro primer paso siempre será reconocer el error (es difícil eh), de nada nos valdrá ocultarlo, no va a desaparecer.

Ahora que ya sabemos, y hemos puesto en común el error cometido, lo siguiente es ver la gravedad del error. No todos los errores son igual de graves o de preocupantes, habrá fallos, que simplemente sepamos que tenemos, cuya única acción sea “saber que está ahí”, y vivir con el. No vivir eternamente claro está (o sí …), pero que no sea necesario tomar una acción de modo inmediato.

En el caso de que la gravedad del asunto requiera tomar acciones inmediatas, el resolver este error debe ser prioritario. Es igual que el principio de no desarrollar funcionalidades nuevas mientras haya bugs abiertos.

Por supuesto, en una situación ideal, en la que tengamos una matriz de riesgos, dónde aparezca esta situación, tendríamos un “plan de contingencia”. Pero como suelen decir los americanos, “shit happens”, y no siempre vamos a tener la suerte de tener un plan de contingencia. Esto tampoco debe desanimarnos, las cosas ocurren.

Cada error es un mundo, y no es lo mismo un fallo de diseño que uno en los requerimientos, y desde aquí no pretendo dar una solución universal a la solución de errores.

Lo realmente importante es que cuando detectemos un error por primera vez, el flujo no se convierta en el gráfico que acompaña este post, en el que lo que se intenta es ocultarlo, escurrir el bulto, colarselo a alguien, en defnitiva escapar del problema.

Reitero, el flujo siempre pasa por la comunicación, el famoso triage para evaluar su gravedad, y el tomar las acciones correctivas necesarias antes de continuar, y que el error nos genere un efecto bola de nieve.

Y bueno, cuanto rollo para esta pequeña conclusión, pero es que hoy no estaba demasiado inspirado jeje.

Ahh si, por supuesto, feliz año nuevo a todos, y espero que se cumplan todos vuestros propósitos.

En cuanto a mi, como decía Joe Strummer, “the future is unwritten”, así que simplemente espero ir mejorando día a día, aprendiendo, descubriendo, viajando, y pudiendo hacer las cosas que me mantienen vivo y “despierto” día a día, y dejemos que cada día nos vaya descubriendo nuevas cosas para hacer.

Y también deciros, que no, este año tampoco os libráis de mí, ya me han reconfirmado como MVP de Team System para el 2009 :), muchas gracias a todos los que me leéis, que suponéis una motivación extra para mi.

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?