Para ser parte de este mundo moderno, el cuál depende fuertemente del software, necesitamos movernos a usar métodos de desarrollo de soluciones más ligeros, flexibles, adaptables y cliente-céntricos – generalmente coacheados bajo la etiqueta de Lean y Agile. El beneficio neto de esta adopción es la mejora económica del proceso de desarrollo de software, el cual dirige a las organizaciones de cualquier tamaño a adoptar y mejorar estos nuevos métodos
Dean Leffingwell – Agile Software Requirements (2011)
Partimos de la analogía de que el código es el motor de nuestras soluciones basadas en software, sin embargo el código es una abstracción de todas esas necesidades existentes, ya sea que hayan surgido en pláticas o documentadas, y con las cuales somos capaces de establecer parámetros e indicadores para saber si estamos construyendo la solución correcta y si lo estamos haciendo correctamente.
Para ser capaces de generar esa evaluación objetiva de una solución de software, necesitamos requisitos que permitan contrastar con lo que se está construyendo. Los primeros esfuerzos de documentación y estandarización de la práctica de gestión de las necesidades surgen a través de estándares como los establecidos por la IEEE los cuales nos ofrecen una forma completa de documentar las necesidades de una solución.
Quizá debido a la apariencia, estructura o incluso la información que necesitamos llenar en ese documento, se genera una especie de efecto repulsivo por parte de los desarrolladores de software, a quienes les cuesta mucho trabajo entusiasmarse por la lectura de esos documentos, o por lo menos no he conocido a ningún desarrollador que con una sonrisa en su cara y con mucha emoción me diga que está leyendo el listado de requerimientos de la aplicación que va a construir como si fueran cómics, revistas gráficas o incluso una novela de ciencia ficción que lo mantiene emocionado y con el interés incesante por conocer el desenlace de las tramas. Esto no es así cuando hablamos de requerimientos de software.
Vale la pena platicar de 3 herramientas de gestión de requerimientos ‘ágiles’ sirven para iniciar distintas actividades de desarrollo y pueden despertar el interés de nuestros lectores de requerimientos: los desarrolladores.
Casos de Uso
Una de las técnicas populares y formales en grandes organizaciones es el trabajo desarrollado por Alistair Cockburn, quien en su libro “Writing effective use cases” brinda un panorama del porque y para que de los casos de uso, y que expone un modelo de gestión de las necesidades que tiene influye el modelo de requerimientos sugerido por SAFe.
Los casos de uso son medulares para el Proceso Unificado de Rational (RUP), metodologia precursora del desarrollo ágil a escala, pero que se critica por ser demasiado “prescriptiva” en la forma de abordar las etapas del trabajo lo que propiciaba a considerarse una mezcla entre la gestión del trabajo en cascada mezclando prácticas “ágiles”.
Aún y con esas críticas, vale la pena rescatar que los casos de uso introducen un elemento fundamental en las prácticas ágiles cliente-céntricas que es la definición del concepto de Actor.
Los casos de uso se escriben alrededor de actores los cuales tienen metas específicas para el uso del sistema que se está diseñando (SUD). Esto orilla a que el equipo piense en todos los actores necesarios así como las metas que tienen para realizar un trabajo más robusto en el entendimiento de necesidades, incluyendo entre ellas algunas herramientas gráficas sugeridas por el autor como pueden ser los “pantalones rayados”, que se trata de una visualización de escenarios exitosos y fallidos.
Los casos de uso tienen una estructura recomendada para su documentación dentro de los cuales se encuentra el actor primario (y secundarios en caso de que los haya), el alcance, el nivel de profundidad, escenario principal, extensión de escenarios (pasos alternativos) y variaciones. Dicha formalidad en su estructura y su forma de documentar las extensiones es lo que hace que padezca un síntoma que acarreamos con el uso de documentos de requerimientos que es lo grande y detallados que se pueden convertir y que por tanto pierdan el interés de los usuarios que los consumen: los desarrolladores.
Historias de Usuario
Kent Beck introduce en su libro “Extreme Programming Applied” el concepto de la historia de usuario el cual es el mecanismo a la postre más usado para la documentación ágil de requerimientos. Las historias de usuario se vuelven un acuerdo de llevar a cabo conversaciones poderosas entre los diferentes involucrados sobre el comportamiento de la solución ante escenarios específicos y con ello se logre confirmar la forma en cómo se evaluará el éxito de la necesidad. Beck explica en su libro que las historias son una especie de antídoto a los requerimientos los cuales se ven como obligatorio o mandatario y que como tal interfieren en el camino de habilitar el cambio
Una historia de usuario consta de 3 partes elementales:
- un título,
- una descripción utilizando la voz de usuario (como <rol> quiero <necesidad/meta> para <beneficio>) ,y
- un listado de criterios de aceptación.
Las historias de usuario están diseñadas para ser ligeras, lo cual significa que las partes elementales deberían ser documentadas en lo equivalente a un post-it y si – la historia que quieres contar no cabe en un post-it, busca uno más pequeño – es la receta que un agilista recomienda porque detrás de esto se encuentra la idea de que trabajar en lotes pequeños aumenta la velocidad.
Se recomienda INVERTIR en buenas historias de usuario procurando que cumplan criterios conocidos como INVEST, lo cual refiere a que las historias sean Independientes, Negociables, que generan Valor para el usuario que las consuma, que sean claras para poder ser estimables, lo suficientemente pequeñas (small) para que puedan ser desarrolladas en periodos cortos y finalmente que los criterios de aceptación faciliten a que puedan ser Testeadas
Tener la posibilidad de trabajar con los requerimientos en herramientas tan sencillas y convencionales como son post-its, da oportunidad a desarrollar mapas de historias. Jeff Paton en su libro User Story Mapping explora herramientas que permiten analizar y visualizar las historias alusivas a flujos de trabajo complejos, permitiendo que la segmentación que se hace de ellas facilite la organización de incrementos de valor en las distintas liberaciones.
Rapid Application Development
Barry Boehm y James Martin son los precursores del método RAD puesto que en los 1980s reconocieron que el trabajo con software no era una especie de ‘recurso mineral crudo’, sino que observaron que era más bien un ‘recurso infinitamente maleable’. Este pensamiento detonó la mentalidad que permitió dar paso a los principios y prácticas ágiles.
En la actualidad RAD se considera un término genérico para un tipo de desarrollo enfocado en producir una serie de prototipos que permitan de manera incremental validar las ideas de los distintos participantes involucrados.
Escribir requerimientos utilizando la metodología RAD es tan sencillo como tener conversaciones con el cliente para recopilar la “esencia” del producto a construir. Con toda intención los requerimientos no son tan detallados, dado que bajo esta metodología asume el permiso de que los requerimientos cambien en cualquier momento dentro del ciclo de desarrollo.
Continuamos prototipando la solución para obtener retroalimentación del cliente. Hoy en día existe ya una gran base de lenguajes de 4ta generación (low-code) y frameworks que aceleran la disponibilidad del software funcionando. Esta retroalimentación sucede de manera iterativa en ciclos acordados con los clientes para que una vez encontrando el punto adecuado de las necesidades se proceda a finalizar el producto, lo cual típicamente amerita optimizar el código, conectar el backend, gestionar los datos y escribir la documentación de soporte.
Esta metodología de desarrollo se caracteriza por su velocidad de implementación a un costo razonable dado que los desarrolladores solo se dedican a construir lo que el cliente requiere exactamente y nada más, esto a su vez aumenta la satisfacción del programador quien está todo el tiempo ocupado en el desarrollo del producto.
Desafortunadamente escalar esta metodología es complicado, debido a las características de las organizaciones que trabajan en silos o departamentos lo cual naturalmente genera demoras en la retroalimentación. También RAD necesita compromiso tanto del cliente como de los desarrolladores, si no se tiene la retroalimentación oportunamente volvemos a reducir la velocidad que propicia el método y finalmente los prototipos enfocan mucha energía en las interfaces y la calidad se aprecia por las funcionalidades que están disponibles y pueden ser ejecutadas, lo cual no siempre es posible si no se balancea adecuadamente la construcción del front-end con el back-end.
Aprendizajes y recomendaciones
Cómo agilista predomina más en mi el gusto por las historias de usuario, puesto que fomentan el principio de que las mejores maneras de convenir información son las conversaciones cara a cara. Comprender el contexto en el que nos encontramos nos servirá para seleccionar la mejor técnica.
La recomendación personal es que se usen:
- Casos de uso: cuando el cliente requiera documentación detallada, escenarios diferenciados e insumos suficientes para poder probar todos los flujos de la solución. Algunos ejemplos son las agencias gubernamentales, instituciones financieras y organizaciones altamente reguladas.
- Historias de usuario: cuando la formalidad en la documentación de las necesidades no sea mandatoria, cuando estamos explorando terrenos que no se han explorado anteriormente y cuando tenemos la fortuna de contar con un rol presente estilo product owner que se asegure de mantener un backlog de historias disponible.
- Rapid Application Development: Cuando contamos con un equipo experimentado en herramientas low-code que utilice los prototipos como el mecanismo principal para mantener un entendimiento compartido y una retroalimentación constante con los usuarios finales.
