Llegamos a ustedes gracias a:



Columnas de opinión

La Ingeniería de Requerimientos en el Contexto Ágil

Por: Guilherme Siqueira Simões, socio - director de Fatto consultoría y sistemas

[23/05/2018] El objetivo de este artículo es realizar un enfoque entre la relación de la Ingeniería de Requerimientos (IREQ) y las metodologías de desarrollo ágiles, en especial el SCRUM.

Para iniciar, se puede definir la Ingeniería de Requerimientos como una disciplina de la Ingeniería de Software que consiste en el uso sistemático y repetitivo de técnicas para cubrir actividades de Levantamiento, Análisis y Gestión de un conjunto de requerimientos para software que sean de calidad y atiendan a los objetivos de negocio.

Dicho esto, y para un mejor entendimiento del enfoque que proponemos en el artículo, vamos a trazar una diferencia importante entre los dos contextos. Si, de forma general, dentro de un proceso de desarrollo tradicional, en la IREQ cada papel es desempeñado por una persona distinta con un título específico (analista, ingeniero de requerimientos, etc.), en las metodologías ágiles, la IREQ es de responsabilidad principal del dueño del producto o si es delegada por él, del equipo de desarrollo, que es por lo general multifuncional.

Pero ¿por qué el dueño del producto? Porque se trata de quién mejor representa el interés del usuario final y, por lo tanto, tiene la autoridad para decir lo que va o no a formar parte del producto final. Es él el encargado de hacer lo que llamamos Backlog del producto, una lista con los requerimientos del producto deseado que va a ser construido.

Una metodología ágil tiene, también, otro diferencial importante con relación a los métodos tradicionales. Son los ciclos cortos de entrega, llamados en el SCRUM de Sprint, un período fijo y predeterminado dentro del cual el equipo completa conjuntos de elementos del Backlog. Este ciclo puede ser de dos a cuatro semanas.

Es importante destacar, además, otra característica importante del proceso ágil. En él, la IREQ restringe el esfuerzo gastado para entender un requisito al mínimo necesario para ese momento, no siendo necesario refinar detalles de todos los requisitos, con excepción, por supuesto, de los casos más críticos o complejos. Demanda así, un gasto mínimo necesario para tener una visión del alcance y deja para detallar el requerimiento cuando éste, esté cerca del desarrollo. Esto difiere de una metodología tradicional, que busca definir todo el alcance de forma detallada antes de seguir en el desarrollo.

A diferencia de la metodología tradicional, la visión inicial del producto no es estática en el proceso ágil: el conjunto de requerimientos que se elabora en el momento inicial difícilmente será el mismo que el producto final va a tener. A lo largo de las interacciones para su desarrollo, requerimientos, historias o ítems de backlog serán eliminados, y otros serán añadidos en la medida en que la visión del producto es madurada, no sólo por el equipo de desarrollo, sino incluso por el propio cliente.

Es importante subrayar que, en general, la visión del producto inicial representa un conjunto de requerimientos que no es originado de una sola persona, sino de varios interesados, con demandas específicas. Es necesario entonces que alguien ejecute las actividades de ingeniería de requerimientos: descubrir quién son esas personas y cuáles son sus necesidades para refinar las historias y priorizar las que se desarrollarán en el próximo ciclo. En caso contrario, el equipo no podrá seguir adelante con el desarrollo del proyecto.

Otro aspecto importante para mencionar sobre el proceso ágil es la cuestión de la documentación. Muchas personas piensan que el trabajo requerimientos consiste solo en generar documentación. Pero la verdad es que si hay documentos sin relación con las necesidades del cliente que se deben satisfacer, entonces ese trabajo de los requerimientos se ha hecho mal. Ellos se vuelven mera burocracia, pues no reflejan los deseos para el producto final; sólo generan papel, sin beneficios y sin entregar valor.

Dicho todo esto, llegamos a algunas conclusiones importantes. En primer lugar, la IREQ es una disciplina independiente de cualquier tipo de proceso de desarrollo, pero necesaria para todos ellos.

Otro punto es que el modo que se ejecuta la IREQ en un proceso tradicional no es igual al de un proceso ágil, y que, aunque se cambie nombres de actividades, cargos de quienes las ejecutan, momentos en que éstas son ejecutadas y artefactos generados, la IREQ siempre está presente.

Al final de cuentas, los dos conceptos son complementarios: Ágil - Entrega rápida de software funcionando; y IREQ - Entrega del software correcto. Y, por último, ¡nunca olvidar que la velocidad sin dirección no vale nada!