Vamos por partes, ser ágil poco o nada modifica la necesidad de documentar requerimientos. No importa el nombre o la estructura que utilicemos. Las llamamos épicas, historias de usuario o requerimientos. Las usamos dentro del contexto de operación, proyectos o innovación. Documentar estas estructuras, nuestras necesidades, o cómo hemos de explotar las oportunidades que identificamos es fundamental para cualquier iniciativa. Y no me refiero con esto al único propósito de comunicar a otros lo que pensamos, incluyo también el proceso de documentar para el futuro. Documentar es un proceso contempla escribir, al hacerlo y sin querer muchas veces, estructuramos mejor nuestros pensamientos.
Algo de historia para empezar. El desarrollo de software es hoy, y ha sido siempre, un gran reto de comunicación entre personas. Desde la época de las tarjetas perforadas, los programadores, aquellos capaces de crear programas para computadoras, y los de las ideas, aquellos incapaces de crear los programas, pero con buenas ideas para aprovechar la capacidad de cómputo de las máquinas, han tenido problemas para «entenderse».
Requerimientos
Muchas herramientas han sido creadas para resolver este problema de comunicación, y el concepto básico detrás se conoce como «requisito o requerimiento» de software.
En la ingeniería de desarrollo de sistemas, un requisito es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas, ingeniería de software e ingeniería de requisitos.
Wikipedia (abril de 2020) – https://es.wikipedia.org/wiki/Requisito_(sistemas)
¿Por qué es tan difícil escribir requerimientos?
Existen muchas teorías sobre la complejidad de los requerimientos. No obstante, para ilustrar mi punto quiero usar un concepto que siempre me ha parecido fabuloso: integridad conceptual de Fred Brooks. Este hace referencia a la capacidad de una persona o un grupo muy pequeño de personas de contener la totalidad del diseño de un sistema, un producto o un modelo.
En uno de sus libros – el diseño del diseño – plantea la integridad conceptual con un ejemplo: piense por un momento quien inventó la bombilla eléctrica, el teléfono, el telégrafo o el avión. En todos esos ejemplos es fácil identificar al inventor. No obstante, cuando la complejidad del sistema bajo diseño aumenta sustancialmente es casi imposible que una sola persona pueda tener en su cabeza el detalle de todos los componentes. En ese momento, mantener la integridad conceptual es un verdadero reto.
Si aún no tiene claro el problema, piense en algún libro que haya leído y discutido con alguien más. ¿Cuál es la probabilidad de que su imagen mental de los personajes y las motivaciones de cada uno sea la exactamente la misma de la otra persona? ¡NINGUNA! Y hablamos de libros de cientos de páginas.
Alguna vez un alumno me dijo en clase cuando veíamos este concepto: «el problema [de la integridad conceptual] es que a los demás les da por pensar«. Aunque entiendo su motivación personal y la frustración que puede generar que las diferentes interpretaciones no están de ninguna manera alineadas, no podemos defender la idea de «dejar de pensar». Lo que buscamos es precisamente lo contrario, queremos que cada individuo miembro de un equipo piense.
Colaboración o búsqueda de culpables
Otro aspecto a considerar a la hora de determinar que herramientas usar para facilitar la comunicación entre «quienes tienen las ideas» y «quienes pueden materializarlas» es la magnitud de dicha colaboración. En otras palabras qué tanta colaboración y confianza hay entre los miembros de un equipo y al interior de una organización.
La confianza requiere de seguridad psicológica al interior de los miembros de un equipo y dentro de una organización o empresa. La seguridad psicológica es un término acuñado por Amy C. Edmondson, profesora de Harvard Business School que impacta la forma como nos comunicamos y – en particular – lo hacemos durante procesos creativos o de construcción de nuevas soluciones.
Un entorno con seguridad psicológica baja, los miembros de un equipo o grupo de trabajo no confían los unos en los otros. Al presentarse una amenaza, ya sea un problema, un error o una mala interpretación, los individuos buscan «descargar la responsabilidad» en otros. Si esta situación sucede con regularidad, los requerimientos se convierten en el «contrato» que regula la relación. El resultado termina por ensanchar en detalles y explicaciones los documentos que moderan la conversación entre las partes. Como intentando «documentar» de quien es culpa si algo sale mal.
Casos de uso
Son la documentación paso a paso de la interacción de un usuario con un sistema de información. La descripción de este paso a paso, clic a clic y momento a momento, dio paso a los Casos de Uso. Un UC – o Use Case en inglés – contiene información detallada de los flujos de interacción que tiene un tipo de usuario (Actor) que, casi siempre, se plantea como una conversación:
- El usuario realiza la acción X
- El sistema bajo diseño (SuD por sus siglas en inglés) realiza la acción Y
- El usuario realiza la acción Z
- …
Creo que ya tienen el punto. A esta conversación entre el usuario y el sistema, le incluyeron:
- Caminos de excepción – que pasa si algo sale diferente en alguno de los pasos,
- Casos de prueba – conversaciones sobre como validar cada uno de los pasos,
- Descripciones,
- Imágenes
Uno de los mejores libros para documentar buenos Casos de Uso llegó a mí de la mano de un gran emprendedor – Alex Torrenegra – cuando aún intentaba codificar para vivir: Writting Effective Use Cases de Alistair Cockburn.
Pros
- Los UC son muy valiosos cuando los sistemas que diseñamos (SuD) son complejos en extremo.
- Cuando el equipo asignado al desarrollo desconoce el funcionamiento del SuD. Por ejemplo, cuando tenemos nuevos miembros de equipo, nuevos equipos o incorporamos nuevos proveedores a nuestra estructura de desarrollo.
- Proveen un claro nivel de detalle sobre lo que se espera en las pantallas, secuencias y procesos de un sistema complejo.
- Dejan poco espacio a la creatividad y el pensamiento divergente.
Cons
- Los UC no dejan espacio para proponer mejoras, ser creativos o tener en general pensamiento divergente.
- No permiten la discusión abierta de nuevas ideas de usabilidad, funcionales o de performance.
- Los UC tienen una alta dependencia de la Integridad Conceptual.
Ambientes innovadores para historias de usuario
En ambientes de mayor incertidumbre, donde no hay claridad en los requerimientos, tener un nivel detallado puede ser difícil o simplemente poco práctico. Para poner un ejemplo, cuando trabajamos en el descubrimiento o diseño de nuevos productos, definir los requerimientos con tanto detalle puede ser un dolor de cabeza o muy limitante para el equipo de trabajo.
User stories
Para favorecer la participación de todos los miembros y promover el pensamiento divergente surgieron nuevos modelos de documentación mucho más ligera y orientada a potenciar las discusiones que aportaran valor a la solución. eXtreme Programming (XP), un proceso ágil de desarrollo de software que nació en los 90, propuso el uso de las Historias de Usuario (US por sus siglas en inglés).
Las historias de usuarios tienen el mismo propósito que los casos de uso, pero no son lo mismo. Se utilizan para crear estimaciones de tiempo para la reunión de planificación de la liberación (release). También se utilizan en lugar de un documento de requisitos de gran tamaño. Las historias de usuario son escritas por los clientes como cosas que el sistema debe hacer por ellas. Son similares a los escenarios de uso, excepto que no se limitan a describir una interfaz de usuario. Están en el formato de aproximadamente tres oraciones de texto escritas por el cliente en la terminología del cliente sin tecnicismos.
eXtreme Programming (abril de 2020) – http://www.extremeprogramming.org/rules/userstories.html
A diferencias de los Use Cases, las US promueven varias cosas:
- Centrarse en el objetivo (la oportunidad o necesidad a resolver) más que en el cómo
- Mantener el foco en el objetivo promueve soluciones innovadoras
- Simplifica que usuarios, clientes e interesados no necesitan conocer el sistema para aportar ideas o solicitar nuevas funcionalidades
- Es bienvenida la conversación, discusión y debate sobre cómo resolver o completar una US – cosa que en las UC puede suceder, pero casi siempre parece más una «explicación del flujo» que una verdadera discusión de iguales
Pros
- Las US promueven el pensamiento divergente y las soluciones creativas
- Permiten propuestas diferentes – y seguramente más eficientes – a los problemas o necesidades planteadas
- Aumentan la productividad de los equipos – maduros y bien compenetrados
- Promueven la participación del cliente – y otros interesados clave – al ser simples de escribir (lo que reduce las barreras de entrada a la participación y el aporte)
Cons
- Equipos no alineados pueden violar los diseños o arquitecturas de aplicación diseñados a gran escala – en grandes organizaciones.
- Obligar el uso de US puede ser un verdadero dolor de cabeza – por la misma falta de detalle. Por ejemplo, alguna vez vi un equipo intentando usar US para describir operaciones de BI y Analítica.
- Muchos creen que las US no pueden convivir en un mismo Backlog – lista priorizada de requerimientos o trabajo por hacer – con otro tipo de instrumentos como tareas, casos de uso o requerimientos técnicos (NFR)
Si desea conocer más sobre cómo escribir buenas historias de usuario le recomiendo leer el libro «angular» de las Historias de Usuario de Mike Cohn: User Stories Applied. Hago una merecida mención para dos colombianos (Lucho Salazar y Jorge Abad) que hicieron un excelente trabajo con su publicación Historias de usuario: Una visión pragmática.
Modelado ágil
El modelado ágil hace referencia al uso de otros instrumentos y herramientas para documentar requerimientos – en su mayoría de software. Pueden entenderse como una especie de «Extension Pack» a marcos de trabajo como XP o Scrum. Dentro de mi experiencia, las herramientas complementarias más útiles de este tiempo son:
- Agile Personas
- Wireframes y Mockups
- Story maps
- Empathy Maps
Escala y desglose, más allá de las historias de usuario
No obstante, usar un único instrumento dentro del Backlog – o describir todos a la misma escala – es ineficiente cuando en el mismo instrumento tenemos diferentes horizontes de tiempo. Es decir, el Backlog incluye requerimientos que están tan claros y son tan importantes que deben ser ejecutados y completados en las próximas semanas; y también puede incluir elementos que apenas son ideas vagas.
Estas «anotaciones» al Backlog parecen más un «recordatorio» para una discusión futura – en mi opinión muy personal, y tal vez influenciado por las herramientas informáticas de gestión, uno debería siempre anotar todas las ideas y conceptos con potencial de convertirse en realidad en el Backlog y no depender de la memoria humana.
En consecuencia, la magnitud del esfuerzo y la complejidad de un elemento dentro del Backlog puede considerar muchos requerimientos – en formas de historias o casos de uso, o simples tareas – acá me separo de los puristas radicales. En su afán de nombrar diferentes escalas de detalle y magnitud, y de alguna manera dejar claro que dichos elementos requieren un desglose posterior se crearon conceptos como Épicas, Características y Capacidades – Epics, Features y Capabilities.
Consejo práctico: Use los nombres Épica, Característica y Capacidad como bien se le antoje, pero no los intercambie para no crear confusión. Puede usar uno, puede usar varios, puede usar estos y otros más. No se complique, solo dele a cada término un contexto y un uso especial.
Épicas
Una excelente idea que tuvo el equipo de Scaled Agile Framework fue el definir propósitos específicos para cada instrumento – y también objetivos dentro de los horizontes de tiempo de planificación y ejecución. Sin ser la única manera, si me parece la mejor (hasta ahora) de diferenciar cada escala.
En este marco de referencia, las épicas son instrumentos para definir inversiones de un portafolio – por temas de mercadeo y distanciamiento con el siempre rezagado PMI decidieron no usar la palabra «proyecto». Las épicas entonces son componentes de un portafolio o programa que incluyen la validación de hipótesis técnicas o de negocio – similar a un Caso de Negocio Ágil. Ellos insisten en que las épicas y los proyectos no son los mismos, pero, así como tengo mis diferencias personales con la «filosofía PMI» también las tengo con la «filosofía SAFe».
Dentro de una Épica podemos contemplar muchísimas cosas, algunas orientadas a reducir riesgos, otras a habilitar nuestras capacidades organizacionales o técnicas, y otras 100% orientadas al cumplimiento de objetivos estratégicos.
Características – Features
No obstante, una épica definida en este contexto parece muy lejana al trabajo que realizan los equipos ágiles. Por eso necesitamos instrumentos intermedios que conecten la escala estratégica con la operación y realización de dicho valor de negocio. Acá es donde, muy a mi pesar, usaron términos muy ligados con el desarrollo de productos: las características.
Las características dos cosas, un requerimiento de alto nivel, en un punto medio entre las Épicas y las Historias, y por lo tanto representan también un conjunto de elementos del Backlog que es un instrumento cercano al equipo – aunque en SAFe definen otros Backlogs de alto nivel. Lo interesante es la relación de tiempo que intentan cuidar entre las historias y las características.
Capacidades – Capabilities
En SAFe existe un instrumento adicional de agregación conocido como capacidad, cuya diferencia más notable con las características es que se completa gracias al trabajo de diferentes ART – un término para un equipo de gran escala ágil enfocado a un producto, servicio o Value Stream.
Instrumentos de planificación
Recordemos que los elementos del Backlog son instrumentos para identificar valor y mantener alineación entre el propósito y la entrega – un concepto que toma fuerza en el mundo que promueve el «flujo de valor de negocio». Del mismo modo, estos elementos son muy útiles para establecer horizontes de tiempo y, nos guste o no, hitos de negocio.
Tener elementos que representan diferentes escalas de esfuerzo es muy útil para establecer cadencia de entrega. Por citar un ejemplo, podemos ver la propuesta de Scaled Agile Framework:
- Iteraciones de dos semanas (de más tiempo me parece innecesario, me gustan más las de una semana) deberían entregan varias historias de usuario.
- Ciclos de 5 o 6 iteraciones o Sprints para entregar varias Características y Capacidades (Incremento del Programa en SAFe)
- Un año podría entregar, resolver o atender varias Épicas (Lean Portfolio)
Conclusiones y consideraciones
El reto es el mismo, mantener la integridad conceptual entre las partes interesadas – los maravillosos, distintos y dispersos seres humanos – y facilitar y promover el desarrollo de «las mejores soluciones posibles» – técnica, económica, funcional y de fácil y amigable uso. Existen instrumentos que limitan la creatividad y el pensamiento divergente – muy útiles para resolver problemas complejos donde los equipos no tienen la experiencia y/o el conocimiento, o donde simplemente es poco práctico proponer soluciones diferentes o promover la interpretación – como cálculos avanzados con datos, reportes, y procesos de negocio fuertemente regulados. Existen instrumentos que promueven el pensamiento divergente y las soluciones innovadoras, que aporta en la creación de nuevos y mejores productos, plantea mecanismos de alineación mental – como las Agile Personas – para fortalecer la integridad conceptual.
Estos instrumentos, como las historias de usuario, además son útiles de acuerdo a las etapas de madurez del equipo y el conocimiento mismo del sistema por parte de los miembros. Imagine usted un grupo de «recién llegados» sin experiencia previa intentando diseñar un sistema dentro de una organización con fuertes restricciones al diseño o limitaciones técnicas – como sistemas legados – a punta de historias de usuario ¡Sería frustrante!
Por el contrario, imagine un grupo experimentado de colegas muy compenetrados intentando resolver un reto siguiendo los pasos de alguien que no está con ellos ¡Aburridor! – debemos siempre equilibrar las capacidades con el reto y estos instrumentos pueden ser útiles en cada etapa de cada ciclo.
Otros instrumentos solo existen para permitirnos manejar diferentes escalas de esfuerzo y/o tiempo, como las épicas y las características. Son útiles para manejar múltiples equipos a alto nivel y comunicar intenciones, propósitos y objetivos de valor.
Como reflexión final les dejo este corto video sobre el concepto de Integridad Conceptual. Nada profundo y radical como el video de Amy.
Seguramente en el futuro veamos nuevas formas de comunicar y documentar nuestras necesidades, y espero estar allí para usarlas y sacarles el máximo provecho.
