Hace mucho tiempo que me convencieron las ideas de la metodologías ágiles para desarrollar software y desde entonces las he ido aplicando, con bastante éxito, a los proyectos de desarrollo que he llevado a cabo.

Nunca las he seguido «al pie de la letra», sino que más bien las he ido adaptando a mis necesidades y al flujo de trabajo de mi equipo, pero en general el resultado ha sido bueno.

Algunas de esas prácticas las he ido refinando con el tiempo, como el uso de test unitarios, ya sea mediante TDD, BDD o simplemente escribiendo los tests a la vez que el código.

Otras han demostado su valor desde el principio y me han permitido mejorar mucho la calidad del software, como la integración continua o la programación en pareja.

No obstante, he encontrado casos en los que ser demasiado ágil puede ser un problema.

Una de las cosas que promueven las metologías ágiles es el Release early, release often, es decir, liberar pronto y liberar frecuentemente. La idea es que cuanto antes puedas poner en producción lo desarrollado, antes estará generando valor ese desarrollo. Esto a priori parece una idea muy buena (y lo es), pero no está exenta de problemas, sobre todo dependiendo del tipo de proyecto que estemos desarrollando.

Liberando con demasiada frecuencia

Si estamos desarrollando una aplicación web, es fácil liberar frecuentemente puesto que toda nuestra aplicación estará online. Cuando despleguemos los cambios en los servidores de producción, los cambios estarán disponibles automáticamente.

Esto puede ser confuso para los usuarios si no lo hacemos con cuidado, porque si los cambios son grandes, pueden tener que volver a aprender a manejar la aplicación, no encontrar las opciones que ya conocían, etc. Para mi, un ejemplo claro de esto es Google Analytics, que cada poco tiempo cambia el interface y tienes que dedicar un rato para encontrar las 4 opciones que acabas usando todos los días.

Aun así, si se hace con un poco de cuidado, en el mundo web es una alternativa viable.

Sin embargo, cuando se trata de aplicaciones instaladas en el cliente (ya sea un PC, un Smartphone o lo que se os ocurra), esta idea de liberar versiones frecuentemente implica varias cosas.

En una aplicación cliente hay que tener un sistema de actualizaciones automáticas desde el primer día. A no ser que nuestros usuarios sean muy avanzados y estén dispuestos a preocuparse por actualizar el softare manualmente (cosa que nunca casi nunca ocurre), si no tenemos listo un sistema de actualizaciones automáticas jamás se actualizarán a las nuevas versiones.

¿Por qué es importante mantenerlos actualizados? Porque al final de una forma u otra tenemos que dar soporte a la aplicación y no hay nada más frustrante que recibir incidencias por fallos que están corregidos en versiones posteriores. Es una mala manera de gastar recursos de soporte.

Además, el sistema de actualizaciones automáticas se convierte en una parte fundamental de la aplicación, ya que toda nuestra teoría de release early, release often se basa en que puedo dar valor cada poco tiempo y mejorarlo en cada actualización, así que mi manera de protegerme frente a fallos e incrementar valor es actualizar la aplicación, pero si el fallo está en el sistema de actualización… estoy perdido.

Liberar demasiado pronto

Cuando se trata de un desarrollo «a medida», para un cliente concreto, esta idea funciona bastante bien porque permite al cliente disfrutar del software que estamos construyendo lo antes posible, lo que además le facilita darnos su opinión y ajustar el desarrollo para que el producto final sea realmente útil para él.

Realmente, funciona bien si el cliente es consciente de lo que estamos haciendo, es decir, está implicado en el desarrollo y sabe que la versión que le estamos dando es «incompleta» y será mejor dentro de 2 semanas (o cuando acabemos el siguiente sprint).

Sin embargo, cuando se trata de una aplicación estándar, destinada al público en general, muchas veces no podemos permitirnos causar una mala impresión. El usuario de la aplicación, y en esto da igual que sea una aplicación web o una aplicación instalada, no tiene ni idea de si estamos trabajando en mejorar la aplicación o no, no sabe si dentro de 15 días será mucho mejor y aparecerán las 3 funcionalidades que necesita. Y además no le importa. Ni le tiene que importar.

Hoy en día, para resolver cualquier problema es muy fácil encontrar en internet multitud de alternativas. Eso quiere decir que tu aplicación va a competir con muchas otras y, el usuario típico, probará varias y se quedará con una. Si tienes suerte y tu aplicación es una de las que prueba, más te vale que le guste, porque si no le gusta, lo más probable es que no vuelva a probarla durante bastante tiempo. Él no tiene tiempo de revisar cada 2 semanas si has hecho avances o no.

Por supuesto, si eres Apple, o Google, o Microsoft esto no se aplica porque tu equipo de marketing será capaz de generar expectativas durante bastante tiempo (y bastantes versiones), pero si no lo eres, más te vale preocuparte de que el usuario no catalogue directamente tu aplicación como basura.

Es lo mismo que decía Joel Spolsky sobre el lanzamiento de Trello:

couldn’t stop thinking that you never have a second chance to make a first impression. We got 131,000 eyeballs on 9-month-old Trello when we launched, and it was AWESOME, so 22% of them signed up. If we had launched 3-month-old Trello, it would have been NOT SO AWESOME. Maybe even MEH. I don’t want 131,000 eyeballs on MEH.

No puedo dejar de pensar que nunca tienes una segunda oportunidad para causar una primera impresión. Cuando lanzamos de Trello (tras 9 meses de desarrollo) era INCREIBLE y de los 131000 primeros visitantes, el 22% se registro. Si lo hubiésemos lanzado tras 3 meses de desarrollo, hubiera sido NO TAN INCREIBLE. Tal vez incluso ABURRIDO. No quiero 131000 visitas a algo ABURRIDO.

El termino medio entre dos vicios

Decía Aristóteles (y esta debe ser la única frase que todos sabemos de él) que la virtud es el término medio entre dos vicios. En este caso se puede aplicar perfectamente.

Por una parte, no tiene sentido encerrarnos en nuestra torre de marfil durante 18 meses desarrollando funcionalidad sobre funcionalidad hasta generar El Producto Perfecto ™, sólo para darnos cuenta al liberarlo de que no es lo que la gente necesita. Que nuestra forma de ver las cosas no es la misma que la de nuestros usuarios. Para eso es preferible fallar rápido y perder menos tiempo.

Pero por otra parte, si después de un mes liberamos un producto incompleto, inacabado, sin un mínimo de atractivo, muchos de nuestros usuarios potenciales lo verán, lo despreciarán y nunca más volverán a él.

En cuanto a la frecuencia de liberación, necesitamos alcanzar un equilibrio entre volver loco al usuario con nuevas versiones (como hace Java que cada día quiere instalarme una actualización nueva) y darle la impresión de que nuestro producto está estancado y descontinuado.

Encontrar el punto justo para liberar un producto es todo un arte y me temo que no hay recetas mágicas para encontrarlo. Hay factores que pueden ayudar, pero no garantizan nada. Algunas de las cosas que ayudan a encontrar el momento:

• Conocer la competencia para ver a qué nos enfrentamos.
• Conocer a los usuarios para intentar saber qué necesitan.
• Tener claras las funcionalidades de cada versión para evitar alargar el desarrollo eternamente.
• Hacer betas cerradas/controladas para no perder todos los usuarios a la vez :).

Siguiendo estos pasos no tendremos garantías absolutas, pero al menos estaremos controlando un poco más los riesgos que asumimos.