Vísteme despacio que tengo prisa

Este domingo por la tarde estaba haciendo un postre, lo he hecho múltiples veces, y por lo que dicen mis compañeros no me queda mal :-) En esta ocasión cuando lo saqué del horno y lo probé, tras dejarlo enfriar claro, casi me muero del susto, no estaba malo, estaba mucho peor. ¡Me olvidé de poner el azúcar!, un error de principiante. Pero se me encendió una bombilla ya que de esta experiencia podía sacar un artículo "interesante" para el blog.

El post de Ancor que me animo a escribir esta entrada en el blog.

Es curioso como puedes conectar cualquier anécdota cotidiana para sacar conclusiones de otro campo que nada tiene que ver. Aquí van las conclusiones que saqué de hacer un postre, aplicadas al desarrollo de software.

Evita el Cowboy Style

Cuando a la gente le hablas por primera vez de desarrollo ágil muchas veces piensa que no es más que tirar la documentación y ponerse a programar como si no hubiese mañana. Nada más lejos de la realidad. El desarrollo ágil intenta evitar hacer cosas que no tienen valor (muy parecido a "lean"), pero eso no quiere decir que no haya que planificar o tener en mente la "imagen global" del proyecto.

Lo que yo he hecho en la cocina es Cowboy Style, he ido cogiendo los ingredientes a medida que los necesitaba y mezclándolos, incluso prestando atención a otras cosas durante el proceso, lo raro es que no hubiese metido la pata más aún. Gracias a Dios no es lo que hago normalmente. Lo que debía haber hecho es terminar con todo lo que estuviese haciendo para que no hubiesen intromisiones, preparar todos los ingredientes antes de empezar revisándolos con la lista de la receta y posteriormente con calma preparar el postre.

En el desarrollo de software es exactamente igual, incluso muchos equipos han incluido un sus tableros Scrum o Kanban (o Scrumban o como quieras llamarlos) una columna que indica cuando una funcionalidad está lista para ser implementada, es decir cuando tienes todos los datos necesarios para no hacer una chapuza y que dicha funcionalidad de verdad aporte valor una vez la hayas completado. Si, en cambio, haces lo que yo he hecho en la cocina terminarás trabajando por dos o peor.

Que lo hayas hecho muchas veces no quiere decir que no te pueda salir mal

Este postre en concreto lo había hecho unas cuantas veces, razón por la que me he confiado, muy mal. Ya habéis visto que incluso cuando tienes experiencia puedes meter la pata, somos humanos. Ya tenía un proceso que me funcionaba, ha sido cuando he modificado ese proceso, sin ninguna razón aparente, cuando todo ha fallado.

Lo mismo se puede aplicar al desarrollo y sus metodologías. Si tienes un proceso que te funciona, o no, no lo puedes cambiar de cualquier manera, tienes que experimentar, documentarte sobre como mejorarlo, pero no cambiarlo a la ligera porque algo simplemente no te gusta. Ocurre muy a menudo que equipos que aplican Scrum en sus proyectos no terminan de sentirse cómodos, pero lo que hacen muchos es cambiar sus practicas sin una experiencia previa, mal, porque no sabes si estas mejorando o empeorando.

Intenta hacer TDD 

Recordando el tweet de Ancor, ha sido el no tener una prueba unitaria lo que ha provocado que fallase al hacer el postre. Imaginad que con la lista de ingredientes los preparo todos y los dispongo para hacer la masa. Luego cuando termino de hacer la masa reviso que los he utilizado todos, no habría cometido ese error, ¿verdad?

En desarrollo de software puedes lograr algo muy similar haciendo uso de TDD (Test Driven Development). Al pensar en una prueba antes de desarrollar la funcionalidad, te está forzando a pensar el problema de forma que se evita fácilmente el Cowboy Style. Y como punto extra, tienes un código soportado por pruebas :-)


Y eso es todo por esta vez amigos :-)