Cómo escribir el mejor requisito ágil posible

El mayor problema que nos encontramos cuando tratamos de que una persona cambie el chip de pensar en una definición tradicional de requisitos y pase a un nuevo modelo es que deje de traerse el documento de requisitos funcionales cambiándole el formato.

Queremos compartir con vosotros un re-descubrimiento para explicar mejor cómo hacer una Historia de Usuario. Este descubrimiento nace del siguiente artículo (https://universos.es/que-es-el-pensamiento-dialectico-la-herramienta-del-desarrollo-humano/) donde se explica un concepto que hemos impartido como parte de los cursos de Scrum Master de Scrum Manager. 

Primero repasemos un poco: cuando leemos sobre cómo debe ser un requisito en el desarrollo de productos ágiles lo más normal es encontrarnos el patrón propuesto en Extreme Programing (XP) de Historias de Usuario. 

Está claro que este patrón es muy útil para las personas que nunca han escrito un requisito ágil. Pero no debemos olvidar que estamos en agilidad y, por tanto, siempre va por delante lo que mejor se adapte a nuestro contexto que una “buena práctica”, estándar o herramienta (siempre que no nos saltemos los valores y principios ágiles). 

Por otro lado, si seguimos profundizando sobre cómo ha de ser una buena Historia de Usuario nos encontraremos que ha de ser INVEST (Independiente, Negociable, Valiosa, Estimable, Pequeña  -Small- y Testeable).

Conseguir que una Historia de Usuario o cualquier requisito ágil cumpla con todas estas características no es nada sencillo, pero si es bueno tenerlo como objetivo. 

Por último, un buen requisito ágil ha de tener unos Criterios de Aceptación donde indiquemos aquellas características que, de manera imprescindible, deben cumplirse para que el trabajo realizado se dé por bueno.

En un documento funcional se especifica qué funcionalidades se quieren y cómo se quieren. Sin embargo, un buen requisito ágil ha de exponer una necesidad, pero no definir cómo se va a llegar a ella. La misión es generar una conversación donde se discuta las diferentes maneras que tiene cada persona de solventar dicha situación en base a su propia percepción de la realidad y sus conocimientos.

En el artículo mencionado anteriormente nos encontramos con un ejemplo sobre las interpretaciones que podemos tener respecto a una mesa que nos puede venir muy bien para entender la diferencia entre un requisito funcional y un requisito ágil. 

Si queremos que nos construyan una mesa podemos definirlo de dos maneras:

• Se tendrá una tabla de madera apoyada en cuatro patas de madera en cada una de sus esquinas.
• Se necesita un objeto para apoyar cosas con las que interactuar como comer o trabajar con un ordenador.

La primera define claramente lo que se ha de construir mientras que la segunda va a generar una conversación alrededor de la necesidad y el contexto, pensamiento dialéctico, que dará como resultado un objeto que cumpla esas necesidades pero que puede tener 3 patas, puede ser plegable, 2 patas en un lado y fijo o móvil en la pared al otro, etc. 

Las diferentes posibilidades de construcción de la mesa las ofrecerá el equipo de trabajo, los técnicos saben las posibilidades existentes y si se fomenta este tipo de diálogo, con objetivos retadores, llegaremos a obtener innovación. Algo imprescindible en el mundo en que vivimos donde todo evoluciona tan rápido.

Y tú, ¿qué escribes en un requisito, la necesidad o la solución?

Un saludo.

María Mira y Rubén Álavarez