Mitos y leyendas ágiles

Con el tiempo, uno se da cada vez más cuenta de la gran cantidad de mitos arraigados que se pueden encontrar en esta nuestra profesión del desarrollo del software, en este caso concreto hablo de agilidad, y por extensión, más allá del software, a aquellos que sin desarrollar hacen uso de las ideas ágiles. Hay tantos que hasta da para muchos post.
Así que, en este post, voy a ir poniendo una lista de mitos sin fundamento, pero que, como las leyendas urbanas, han ido calando en mucha gente. Vamos a ello…

En agilidad No se documenta

En ningún sitio dice que esté prohibido documentar (de hecho, si alguien o algo te prohíbe algo… mandalo a paseo). Ni siquiera el manifiesto ágil lo dice (Working software over comprehensive documentation, ojo con el “over”).
Otra cosa es que en el mundo ágil, con mucha razón, se mire con lupa cualquier documento, por el desperdicio que pueda suponer hacerlos, por la falsa seguridad que puedan dar, y por la rigidez que suelen conllevar, por minimizar la interacción entre personas, etc. Y por ello que en su día te dejé aquel Taller de desintoxicación documental y superación de la abstinencia del word y powerpoint

No hay fechas

A este mito, muy típico, ya le dediqué un post largo, aquel de “En agilidad no hay fechas y no se sabe cuando se termina”, como este tema es profundo y algo más largo de contar prefiero que te leas ese post.

Siempre un paso a producción al final del Sprint

Este mito también tiene un post dedicado, el de ¿Un Sprint termina con un paso a Producción?, que te recomiendo para ampliar este punto. Pero resumiendo, más en Scrum, se termina con un incremento, que típicamente, hablando de software, es algo que añade valor en pre-producción o producción. Y aquí pasa algo similar al caso de la documentación, no estás obligado, pero si que deberías hacerlo cuanto antes, para pensar en MVPs, validar cuanto antes frente a la realidad, etc.

La calidad es menor

Scrum no habla de prácticas técnicas, se las deja a eXtreme Programming. Y, en el mundo software, usar Scrum sin algo similar a eXtreme Programming es raro raro y si usas las buenas prácticas de eXtreme Programming… ¿de verdad vas falto de calidad? lo dudo.

Work in progress

Bueno, me habré dejado mitos, seguro, este será un post vivo. Si tienes alguno por ahí que a mí se me ha pasado… déjamelo en los comentarios de este post para añadirlo.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

3 comentarios en “Mitos y leyendas ágiles”

  1. Hola Javier,
    buena idea la de «denunciar» (cariñosamente) estos mitos ágiles. Suelen surgir del desconocimiento de elementos básicos como el Manifiesto Ágil o la Guia de Scrum. De hecho me sorprende en los cursos que la mayoría de asistentes que «hacen Scrum» en sus organizaciones no han leido la guía.
    En el blog de Scrum.org vamos a ir publicando como 20 mitos sobre Scrum durante los próximos meses. A ver si entre todos despejamos el máximo de éstos. 🙂
    ¡Feliz año!
    Alex – http://www.itnove.com

  2. Mito: Si tengo que programar tests iré más lento.
    En realidad programar tests mejora tu velocidad. Y un factor importante dependiendo de la tecnología.
    Cometes menos errores (esto es ahorrarte mucho tiempo). Los detectas antes (esto es ahorrarte muchísimo más tiempo). Y no tienes arrancar servidor, navegar y preparar un escenario completo de test para probar una pequeña funcionalidad (según la tecnología, esto puede ser ahorrarte una barbaridad de tiempo).
    Finalmente, pensar que la velocidad de desarrollo sólo depende (o depende principalmente) del número de líneas que escribas, es un error.

  3. Hola Javier,
    Para mi el mito número 1, y el más peligroso de todos, es que con la agilidad se desarrolla más rápido. Esto crea unas expectativas que cuando no se cumplen amenazan la transición a esta nueva forma de trabajar.

Dejar un comentario

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