Cerrar

¿Desea conocer información de nuestros sistemas de gestión empresarial para PYMES o plataformas para medianas y grandes corporaciones?

NUESTRO BLOG

¿Porqué el desarrollo ágil ha reemplazado el desarrollo de software tradicional en el mundo moderno? PARTE 2

¿Porqué el desarrollo ágil ha reemplazado el desarrollo de software tradicional en el mundo moderno? PARTE 2

Para lograr establecer métodos de predicción de esfuerzo más precisos y replicables, se generaron métodos predictivos estadísticamente razonables.  Sin embargo, su desventaja era que requerían unos insumos tan precisos y profundos, que el tiempo total de desarrollo de software (la codificación de la aplicación como tal) era menor al tiempo requerido para levantar los requerimientos.  En esta misma línea, para proyectos pequeños, las metodologías se hacían algo manejables (ya que los requerimientos eran pocos).  Pero, para proyectos medianos o grandes el número de requerimientos era tal, que el tiempo entre detallar el primer requerimiento y terminar el requerimiento final era muy largo, dejando prácticamente obsoleto dicho primer requerimiento. El entorno de negocio del cliente había cambiado, y era necesario comenzar de nuevo, en un círculo de nunca acabar.

Adicionalmente, existían otros problemas graves con estas metodologías predictivas tradicionales.  Todo desarrollo de software es un producto único que debe ser concebido “desde cero”.  Por tal motivo, está abierto a la creatividad humana, la cual no puede ser forzada a producir todas las ideas en el momento más propicio.  Así las cosas, un usuario experto tenía una cierta cantidad de ideas cuando llegaba el momento de “poner sus requerimientos para el software en el papel”.  Pero, una vez estos ya “quedaban en firme” nuevas ideas le venían a la mente del usuario.  Sin embargo, como ya “había arrancado el tren de la estimación” en un proceso muy formal, muy estructurado y francamente poco flexible, el usuario se volvía tímido de desorganizar este proceso sugiriendo ideas nuevas que cambiaran lo ya establecido, razón por la cual, éstas quedaban por fuera y el software no resultaba siendo tan poderoso o relevante como debía haber sido.  

En este mismo orden de ideas, debido a las dificultades de proceso y “fricciones políticas” generadas dentro de una compañía de estar estimando y re-estimando el esfuerzo y costo de un proyecto cada vez que a alguien se le ocurría un cambio, el equipo protegía los requerimientos para que éstos se quedaran estáticos. Esto, obviamente, iba en detrimento de la relevancia del software, generando aplicaciones que al momento de salir a producción estaban ya desactualizadas. 

Irónicamente, sucedía también el fenómeno de “product bloating” (en inglés) o “sobre-inflación de producto” (en español), el cual describe una aplicación a la que le sobra funcionalidad que nadie utiliza pero que el cliente tuvo que pagar para construir.  Este fenómeno se da cuando en un proceso de desarrollo de software se le dice al usuario final “piense bien lo que usted quiere y necesita, y dígalo todo desde ya, porque lo que usted no diga no quedará en el software”.  Bajo esta presión, el usuario tiende a pensar desde una perspectiva de “y que tal si necesito esto, o qué tal si necesito aquello?” y procura pedirlo todo para que después no le digan “no se puede pues usted no lo solicitó al principio, previo a que nuestro proveedor nos diera una estimación”.  Como resultado, la mayoría de las aplicaciones construidas dentro de paradigmas predictivos tradicionales (desarrollo de software en cascada, RUP, etc.) son más costosas y más grandes de lo que deberían ser en aquellos aspectos que el usuario no valora, y más pequeñas y pobres de lo que deberían ser en aquellos aspectos que el usuario más requiere, pero que, por naturaleza humana, no fue capaz de avizorar desde el principio (porque no se le ocurrieron o porque su entorno no le pedía estos requerimientos). Pero comenzado el proyecto, su entorno cambió.

Para colmo de males, los procesos que buscan ser predictivos son altamente ineficientes.  Acorde al Standish Group, consultora norteamericana que estudia más de 8,000 proyectos de desarrollo de software de diferente tamaño cada tres años, de cada $ 100 dólares invertidos en este tipo de proyectos, entre 30 y 40 dólares se van a administrar el proceso de desarrollo, y tan solo 60 a 70 dólares se van a codificar la aplicación como tal.

Adicionalmente, aún operando de manera juiciosa, los estimados producidos con requerimientos altamente detallados y dentro de un proceso rígido a los cambios y a las nuevas ideas, son regulares o malos.  El “Chaos Report” del Standish Group estima que, en promedio, solo el 32% de los proyectos de software se entregan razonablemente a tiempo y bajo el presupuesto establecido, y en promedio los proyectos “bien estimados” se desvían en un 189% de su costo estimado inicialmente (los que se estiman sin metodología tienden a desviarse hasta en un 277%!). En el siguiente artículo veremos como el Desarrollo Ágil busca una manera de resolver los problemas en los proyectos de desarrollo de software.

 

Valora este artículo del blog:
¿Cómo busca el desarrollo ágil (SCRUM) resolver la...
¿Porqué el desarrollo ágil ha reemplazado el desar...