Ágil en la práctica – Cuatro razones para “construir para hoy”
“El éxito es simple. Hacer lo que es correcto, de la forma correcta, en el momento adecuado”.- Arnold H. Glasgow, Autor.
Una de las filosofías de los proyectos Agiles es “construir para hoy“. En otras palabras, se debe diseñar, construir y probar sólo lo necesario para satisfacer las necesidades de las historias de usuarios que se seleccionan en la iteración actual.
En algunos aspectos esto va en contra de la intuición de muchos miembros del equipo que sienten que es más eficiente en el largo plazo si toman en cuenta los requisitos potenciales en el futuro. La idea es que debes construir para apoyar esta funcionalidad futura “mientras que estás ahí” y después, más adelante cuando el requisito es seleccionado realmente puedes terminar el trabajo con mucho menos esfuerzo.
En el modelo Agile esto se considera generalmente como un intercambio falso por cuatro razones.
• En primer lugar, el tiempo que te tardas en diseñar, construir y probar características futuras significará que no puedes hacer tanto para el ciclo actual. Estás apoyando menos necesidades actuales, concretas y de alta prioridad a cambio de necesidades futuras potenciales, distantes y que quizás no sean elegidas nunca. Esto no se ve como un buen intercambio.
• En segundo lugar, es posible que esta funcionalidad adicional, futura, nunca sea necesaria o solicitada. El cliente puede haber solicitado esta funcionalidad en un proyecto tradicional, pero en un proyecto Ágil, la diferencia entre “quiere” y “necesita” es mucho más enfocada. ¿Quién sabe si la funcionalidad adicional se convertirá en una iteración futura? El mundo está lleno de funcionalidad de sistemas que se codifican, pero nunca se utilizan.
• En tercer lugar, es muy posible que, de todos modos, no puedas implementar correctamente el requerimiento futuro. El propietario del producto no lo discutirá ni probará para esta condición futura. Incluso si un requisito futuro parece simple y plenamente comprendido, es posible que se produzcan malentendidos y errores. Entonces estás fuera de sincronización tratando de probar y depurar problemas que ni siquiera deberían ser parte de la iteración. Cada ciclo también tendrá sus propios desafíos. No es necesario componer las cosas introduciendo problemas que no forman parte de esta versión.
• En cuarto lugar, si la funcionalidad adicional es necesaria en el futuro, tendrá su turno en una iteración futura. Cuando se elige la funcionalidad, se construirá y probará el trabajo. En un proyecto Ágil, es probable que visite las mismas secciones de la solución varias veces. No tienes que preocuparte de la construcción de funcionalidad adicional “mientras estás ahí“, porque es muy probable que “estarás ahí” muchas más veces antes de que el proyecto sea completado.
Esta filosofía debe aplicarse a la funcionalidad del proceso, al rendimiento, a la seguridad, etc. El enfoque de “construir para hoy” es también un ejemplo de lo que en la filosofía ágil se entiende como “mínimo necesario“. Quieres asegurarte de que haces todo lo necesario para apoyar las necesidades del cliente, pero no más.
Autor: Jorge Valdés Garciatorres, PMP, SMC.
