Aplicando el patrón C.S.P. (Common Sense Pattern…) en nuestros desarrollos, observamos que debemos cumplir con las necesidades del cliente. Acto seguido, descubrimos, que estas cambian más que los nos gustaría (ouchh!). Por lo tanto, se crea la necesidad de ir ajustando el avance del proyecto a las necesidades reales (y cambiantes) del proyecto.
¿Pero como…?
La respuesta que nos aportan las metodologías agiles es sencilla, iterando. Partiendo el desarrollo de la aplicación en pequeños entregables que el usuario pueda probar e ir enriqueciendo. Suena lógico, pero vamos a hacer un esfuerzo de plasmar negro sobre blanco las principales ventajas que esta forma de trabajar nos ofrece:
- Gestión de riesgos
Asumámoslo, el resultado deseado no es concebible por adelantado. Existen riesgos, algunos ya identificados y otros por identificar. Para gestionarlos correctamente debes demostrar o refutar tus requisitos y diseñar las suposiciones implementando incrementalmente elementos que son objetivos del sistema, empezando con los de más alto riesgo. - Económicos
En un ambiente de negocio incierto (casitodos los proyectos lo son !!) es clave optimizar los esfuerzos en las mayores prioridades del proyecto. Debemos manejar cada iteración como un conjunto de fichas de juego a apostar por un conjunto de funcionalidad que se pueda entregar, probar y que funcionen. - Enfoque
Solo podemos mantener una cantidad limitada de elementos en la mente. Trabajando con pequeños lotes de trabajo podemos focalizar nuestros esfuerzos con un conjunto de funcionalidades que comprendemos y somos capaces de encajar y entender. - Motivación
No existe un mecanismo mejor de motivación de acción prolongada (el dinero solo motiva en un espacio reducido de tiempo!!) para un profesional que comprobar como su creación se usa, es efectivo y valorado por los usuarios. - Control de la teoría
Las iteraciones nos permiten controlar mejor las desviaciones, reduciendo el impacto de los errores en las estimaciones y crear un mecanismo de retroalimentación sobre los planes del proyecto. - Implicación de los interesados
Los patrocinadores (clientes, usuarios, dirección…) pueden observar los resultados más rápidamente (cumpliendo así con la visibilidad, requisito fundamental de cualquier desarrollo) y así aportar mayor compromiso, implicación y financiación. - Aprendizaje continuo
Todos los actores del proyecto aprenden en cada iteración. Los miembros del equipo adquieren conocimiento funcional y aportan mejoras desde la prospectiva tecnológica y los funcionales comprenden las implicaciones de automatizar los procesos empresariales. Todos aportan y el proyecto crece rápido y mejora.
Ya tenemos un conjunto de argumentos para convencer a los stakeholders más peleones acerca de las bondades de trabajar en pequeñas iteraciones, ahora el que quiera entender que entienda…
Estoy totalmente de acuerdo. En algunas empresas todavía creen en modelos de desarrollo en cascada… Que al final sólo acaban cascando al equipo de desarrollo… y generando un montón de problemas.
Buen artículo.
Saludos
Pues sí, son mentalidades anticuadas de los equipos directivos que pagamos los de siempre.
Yo estoy de acuero pero sólo en parte, en la parte positiva que es de la que has hablado pero deberiamos también hacer referencia a la parte negativa, la imposibilidad con la que nos encontramos en muchísimas ocasiones de tener módulos independientes, en mi caso me encuentro con ello todos los días….
Sin proformas no puedes acabar pedidos, sin pedidos no puedes acabar albaranes, sin movimientos de almacen no puedes acabar recepción de mercancia…una cadena.
Las iteraciones que se dan por acabadas no lo están del todo y una modificación en otra la afecta directamente.
Creo que podría ser correcta si las iteraciones son muy pequeñas pero eso llevará muchisimo tiempo de planificación y muchísmas entregas y reuniones.Y eso es también es incremento económico.
Como ya hemos dicho alguna vez no existen balas de plata. En este post he pretendido reflejar lo bueno que tiene iterar, que aunque no siempre es posible si es deseable.
Respecto a los modulos independientes, la idea es desarrollar selectivamente funcionalidad de todos los modulos relacionados para que todos avancen sprint a sprint, evitando tener que terminar uno completamente para comenzar con el siguiente. (Desarrollo en cascada!)
En el ejemplo que comentas quizas le podamos dar un enfoque más «verticalizado» en base al aporte al negocio. Mitigamos la funcionalidad mínima del cicuito (proforma, pedido, albarán…) para al menos tener un circuito mínimo comercial sobre el que el usuario pueda centrarse, validando también así el workflow mínimo.
Los artefactos de esa iteracción funcionan y le son útiles (pero mejorables) al usuario. Por lo tanto, está hecho.
Otra cosa, es que la funcionalidad entregada al cliente no sea la suficiente para hacer una release (que consumirá varios sprints) que distribuir entre los testers.
Sí pero hay que tener en cuenta que en ocasiones hay modulos que se basan los unos en los otros con lo que que esté perfecto es fundamental para no acumular errores en varios sitios, ya que, esto provocaría un aumento considerable del tiempo de corrección.
Por otro lado repito mi desacuerdo con enseñar funcionalidades que no aporten un valor añadido al cliente porque este va a decir:»Esto ya lo tenía, ¿cuando estará lo demás? y sobre todo no abusar de reuniones para mostrar cosas porque el cliente se quema y se impacienta más.
Estoy de acuerdo contigo en que siempre es deseable iterar pero debemos tambien exponer los problema que conlleva