Cerrar

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

NUESTRO BLOG

¿Cómo busca el desarrollo ágil (SCRUM) resolver la “encrucijada” de problemas en los que se ven sumidos los proyectos de desarrollo de software tradicionales? PARTE 2

¿Cómo busca el desarrollo ágil (SCRUM) resolver la “encrucijada” de problemas en los que se ven sumidos los proyectos de desarrollo de software tradicionales? PARTE 2

Otra premisa de ágil (SCRUM) consiste en iterar un desarrollo de software en ciclos cortos de duración exacta y determinada, denominados “Sprints”.  En SCRUM, cada Sprint del proyecto de desarrollo de software normalmente tiene una longitud de 1 a 4 semanas como máximo.  La idea fundamental de ágil es que al final de cada Sprint, exista código nuevo y operante que pueda ser “explorado” en vivo por el usuario interno del proyecto, pues solo viendo la aplicación funcionando será el usuario capaz de verdaderamente determinar si el proyecto de ingeniería de software va o no por un buen rumbo. Otro factor que agrega mucho valor al proceder de ésta manera, es que el usuario, al ver y utilizar una porción del software, despierta su pensamiento creativo sobre algo concreto, ocurriéndosele entonces nuevas ideas de cómo continuar mejor el desarrollo y rumbo de la aplicación.  

Por supuesto, es imposible desarrollar todo un proyecto de software en un Sprint de unas cuantas semanas.  Normalmente, múltiples Sprints son requeridos para culminar un proyecto de desarrollo de software ágil bajo SCRUM. Sin embargo, como ágil no pretende anticiparse a un futuro relativamente incierto, se concentra entonces en entender muy bien aquello que se desarrollará en el próximo Sprint.  Es así como en un proyecto de, digamos 40 historias de usuario, es muy probable que el primer Sprint tan solo contemple el desarrollo de las primeras 4.  Ya los siguientes Sprints, paulatinamente, se encargarán de contemplar el desarrollo de las restantes 36.

Lo que sucede, de mucho valor, en esta aproximación metodológica, es que al final de cada Sprint se recopilan tanto las nuevas ideas como los aprendizajes (o cambios de entorno) que impliquen potenciales adiciones al “backlog” (¿Qué es backlog?).  Entonces, en un proceso denominado en inglés “backlog grooming” (en español no existe una buena traducción... pero significa “revisión” del backlog) el Grupo define, dentro de un presupuesto de esfuerzo por definición limitado, cuál de las nuevas ideas entra a reemplazar las que ya estaban antes en la “lista de pendientes por desarrollar”.  

Éste proceso se hace crítico para desarrollar solo lo que es verdaderamente importante en la aplicación, puesto que el backlog no puede crecer “ad infinitum”.  Lo que normalmente termina pasando en este caso, es que una nueva funcionalidad crítica entra a reemplazar otras previamente existentes en el backlog que, en el análisis final, son “deseables más innecesarias”.  De esta manera, el “backlog” de lo que se tiene que codificar en cada Sprint: 1) siempre se mantiene relevante a las necesidades más apremiantes de la compañía en todo momento; 2) el mecanismo de priorización y constante re-priorización elimina la presión existente en las metodologías tradicionales de que “lo que no se pida al principio del proyecto no quedará en el software”, evitando el embotamiento de los requerimientos (software bloat) que genera gastos en funcionalidad innecesaria.  (Nótese que en proyectos de ingeniería de software bajo metodologías tradicionales, consultoras como el Standish Group calculan que la funcionalidad desplegada que no es utilizada o es poco utilizada alcanza el 45% del total de la funcionalidad del software.  Solo con eliminar esta ineficiencia, ¡una aproximación al desarrollo ágil prueba su valor!)

Entrando a un grado un poco mayor de detalle, el desarrollo de software ágil bajo SCRUM recomienda una forma de enfrentar la priorización de actividades durante el desarrollo.  En los primeros SPRINT, recomienda SCRUM, el equipo debe buscar desarrollar aquella funcionalidad que es considerada de alto valor para el negocio y que, además, es de alta complejidad desde el punto de vista técnico.  Esto hace sentido puesto que al comienzo de un proyecto existe más tiempo para franquear obstáculos complejos.  Si algo complejo y de alto valor se deja para el final, además del estrés desmesurado que ésto produce en el equipo, se corre el riesgo de que no exista tiempo suficiente para resolver el obstáculo, generando atrasos o problemas de calidad y/o desempeño.  

Consecuentemente, en los Sprints subsiguientes, el equipo se encarga de desarrollar aquellas funcionalidades que se consideran de alto valor de negocio y baja complejidad técnica (dicho de otra forma, los “mangos bajitos se afrontan de segundos”).  En esta etapa el equipo normalmente es altamente productivo y el proyecto evoluciona muy bien.  Finalmente, y solo si queda tiempo y presupuesto, el equipo afronta aquellas funcionalidades del backlog que son consideradas de bajo valor de negocio y baja complejidad.  Por definición, las funcionalidades que fueron evaluadas como de alta complejidad técnica y bajo valor de negocio no se desarrollan, pues en el análisis final, partiendo por definición de presupuestos de esfuerzo limitados, éstas destruyen valor.

 

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