Imagen de cabecera

¡Agilidad!

Publicado por Unknown el viernes, 11 de mayo de 2012 0 comentarios
No se trata de correr mas, de ser mas precisos, ni de ser mejores, ni siquiera de ser los primeros.



Puedes el mas veloz, pero si no sabes el camino seras en primero en perderte. Puedes ser el mas exacto, tomarte tu tiempo para elegir el mejor camino, pasar por la floristería, comprar bombones y seguramente cuando llegues tu cita se habrá cansado de esperar y se habrá ido con otro que encima es mas feo que tu.

Hay que ser ágil, ser capaz de tomar decisiones y después cambiarlas, de adaptarte a los cambios del medio en el que te mueves y de tratar de llegar el primero al cliente con algo que funcione y además sea funcional. Tu producto puede que no sea perfecto, pero si eres el primero el cliente no te podrá comparar. Llegará la competencia, mas bonita y probablemente mas barata pero la posición es tuya, ya has tenido un tiempo para obtener cierto feedback y puede que tu rival tenga un producto mas bonito, pero tu ya puedes defenderte con un producto mas adecuado, mas perfecto.

Hay que ser ágil porque te puedes equivocar. Las modas cambian, los gustos cambian y las necesidades cambian (por no hablar de los presupuestos). Si de camino a la pastelería te enteras de que tu cita es diabética quizá sea mejor dejarlo solo en unas flores. Llegarás tarde por haber dado la vuelta hasta la floristeria, pero serás mejor recibido que todos los que hayan llegado con bombones (mira que no saber que no puede comerlos, que vergüenza).

Ser ágil no significa ser caótico, ni desordenado. Simplemente es una cuestión de cintura. Una vez que se marca la ruta, que se planifica todo, no se puede uno poner la anteojera y dejar de ver lo que pasa por nuestro lado.

Equivalente humano de la anteojera equina


Bajando un poco al contexto en el que me muevo es necesario que todos los involucrados (clientes, diseñadores, jefes, analistas y programadores) tengan asumido que su cintura ha de estar muy en forma. Siempre dependemos de los cambios que puedan producirse en el mercado. Podemos tener un plan perfecto, sin fisuras, redondo, genial... pero durante la ejecución la competencia lanza una funcionalidad que nosotros no habíamos previsto o que  pensábamos hacerla dentro de 6 meses ¿seguimos con nuestro plan?. Es la pregunta del millón pero no hay respuesta. Evalúa rápidamente el impacto de esa nueva funcionalidad y decide, pero ¡rápido! debes seguir con el plan (re-elaborado o no).



Tradicionalmente se apostaba por desarrollos largos donde no el cliente firmaba un conjunto de requisitos y meses después recibía el software que cumplía perfectamente las necesidades que el cliente tenia hace meses. Como comentaba antes esto ya no es rentable. Actualmente se apuestan por desarrollos donde el cliente y el equipo de desarrollo colaboran estrechamente. Se intenta estructurar el proyecto de manera que el cliente pueda tener entregas parciales y funcionales (y por tanto empezar a amortizar el coste). Cada entrega parcial permite al cliente y al desarrollador comprobar que todas las necesidades siguen siendo interesantes y que no hay que adelantar ninguna (o si). Esto es ser ágil en el desarrollo de software.

Ser ágil no son todo ventajas, hay un lado oscuro: los proyectos infinitos. Un proyecto puede ser infinito por dos razones:
  • La búsqueda de la perfección. El cliente se obsesiona con que todo este perfecto y se dedica a cambiar cosas continuamente antes de poner algo en producción. Esto bloquea el avance del proyecto y provoca que la fecha final del proyecto se posponga repetidamente. Esta bien que el cliente busque tener un producto excelente pero existen otras maneras (acabar las funcionalidades, ponerlo en marcha y refinarlo a posteriori).
  • Los requisitos no se acaban nunca. El cliente añade cada vez mas y mas requisitos sobre el sistema inicial. Las funcionalidades que no se tienen en cuenta en el diseño inicial de la aplicación tienden a deteriorar el software (bajada de rendimiento por un diseño que no lo tuvo en cuenta, caída en la calidad del interfaz por sobrecargar las pantallas de información y acciones). Cliente y desarrollador deben negociar que cosas se pueden añadir y cuales deben dejarse para una segunda versión (que incluya la adaptación lógica del diseño).
Tradicionalmente se optaba por modelos de procesos para desarrollar software. El 2001 un grupo de diecisiete expertos se reune para criticar los rígidos modelos de desarrollo que se empleaban hasta la fecha. De esas reuniones nacen una respuesta bajo el nombre de metodologías ágiles. Dichas metodologias se basan el cuatro postualdos que se dieron a conocer como El manifiesto ágil (próximamente en este blog).

0 comentarios:

Publicar un comentario