+34 691 225 633
Rev. Febrero 2023
Autor: Pablo Egas Sánchez
INGENIERÍA DE REQUERIMIENTOS
Introducción
Ya conocemos qué es y cómo funciona Scrum. Ahora aprenderemos cómo gestionar
adecuadamente los requerimientos de los usuarios a través de historias de usuarios.
Dentro de Scrum, se promueve la evolución de las historias de usuarios con
cada iteración. No se trata solo de definir lo que se debe construir, sino de
mantener una conversación constante con los stakeholders, de adaptarse al
flujo cambiante del mercado y de abrazar la incertidumbre como un desafío
más que como un obstáculo.
La gestión de requisitos en proyectos ágiles no se limita a documentar lo que se
desea lograr, sino que abraza la idea de experimentar y aprender en cada ciclo. Es
un viaje en el que la transparencia, la comunicación y la flexibilidad constituyen los
combustibles que impulsan la entrega de valor de manera rápida y sostenible. No se
trata solo de seguir una hoja de ruta, sino de navegar en un océano de cambios con
astucia y agilidad.
Profesionales de diversos campos que van desde los ingenieros de software (quienes
propiciaron el nacimiento de la agilidad), hasta analistas de negocios, arquitectos,
gente de marketing y publicidad, entre otros, encontrarán que esta metodología,
adecuadamente implementada, potencia sus habilidades gracias a que Scrum
habilita una operación de entrega de valor iterativa, frecuente y continua.
Reto
¿Qué son las historias de usuarios? ¿Cómo crear historias de usuarios? ¿Qué es
un producto mínimo viable?
+34 691 225 633
Rev. Febrero 2023
Palabras claves
Ingeniería de requisitos, historias de usuarios, planeación de proyecto ágiles.
Ingeniería de requisitos
Se requiere de, al menos, estos componentes:
- Estrategia claramente definida.
- Habilidad para extraer los detalles precisos que permitan definir qué lo
que realmente necesita el usuario.
- Compromiso para desarrollar e integrar el requerimiento.
Descubriendo el producto o servicio
Para que un producto sea exitoso, debe ser valioso, utilizable y posible de
crear/desarrollar.
Este apartado tiene el objetivo crear una visión compartida de cómo alcanzar las
metas propuestas por el cliente. Esto supone un análisis inicial que permita
determinar dónde estará el valor del producto o servicio, cómo va a ser usado
(su usabilidad) y, por supuesto, si técnicamente es factible de construir.
Se debe evaluar:
- ¿Quiénes son los actores principales y qué procesos de negocios llevarán
a cabo? Se debe categorizar y priorizar esta información.
- ¿Cuáles son los problemas más importantes que desean resolver?, ¿por
qué es necesaria esta herramienta/solución/proyecto? Este conocimiento
será la base para un mejor diseño de la solución propuesta.
+34 691 225 633
Rev. Febrero 2023
- ¿Cómo se generará valor? Se deben priorizar y destacar las características
y funcionalidades imprescindibles (aquellas que no pueden faltar o con
las que el cliente obtendrá más beneficios).
- Producto mínimo viable: es fundamental entender cuál es el experimento
mínimo que nuestros clientes están dispuestos a testear con usuarios
reales. Es clave gestionar sus altas expectativas para evitar que busquen
implementación de todas sus ideas a la vez.
Figura 1: Producto mínimo viable. Zuppa, Federico. Recuperado de:
https://scrum.mx/informate/descubrimiento-de-producto
- Modelo de negocio: clasificar al cliente. Una start-up tiene
comportamientos y requerimientos diferentes a los de una gran
corporación. Se debe determinar: ¿cuáles son los
procesos/productos/servicios que esta solución optimizará y cómo se
obtendrán nuevos ingresos a partir de la misma?
+34 691 225 633
Rev. Febrero 2023
- Riesgos: es muy común que en las conversaciones realizadas en esta etapa se
detecten riesgos. Estos deben ser marcados y discutidos, ya que representan
información esencial para la posterior priorización de features.
- Estimación inicial de la magnitud: a partir de las conversaciones
sostenidas en esta etapa, se puede tener una idea inicial de cuán grande
podría llegar a ser el desarrollo.
Historias de usuarios
Las historias de usuarios son pequeñas descripciones de los requerimientos de
un cliente. Su utilización es común cuando se aplican marcos de entornos ágiles
como Scrum.
Al redactar las historias de usuarios, se debe tener en cuenta describir el rol, la
funcionalidad y el resultado esperado en una frase corta. La historia debe venir
acompañada (al reverso) de los criterios de aceptación, hasta un máximo de
cuatro por historia, redactados también en una frase que indique el contexto, el
evento y el comportamiento esperado ante ese evento.
Es deseable que las historias de usuarios sean escritas por el usuario, en una frase
corta. Se debe describir el rol desempeñado por el usuario de forma explícita e
indicar el beneficio para el área de negocio que representa esta funcionalidad.
En la práctica, se evidencia que las historias de usuarios no son requerimientos
escritos; son mecanismos que construyen entendimiento compartido a través
de la colaboración, con palabras e imágenes. Son discusiones acerca de las
soluciones a problemas para la organización, los clientes y los usuarios, que
llevan a acuerdos sobre los cuales construir lo deseado.
Una historia de usuario sigue el siguiente formato:
Como <quién> quiero <qué> para <objetivo>.
+34 691 225 633
Rev. Febrero 2023
Ejemplo: Como vendedor, quiero registrar los productos y cantidades que me solicita un
cliente para crear un pedido de venta.
Definir quién utilizará la funcionalidad que se va a desarrollar
Es útil imaginarnos qué características tienen las personas que usarán el producto
y detallar su necesidad y problemas actuales para dar lugar al entendimiento
sobre sus expectativas reales.
Para poder identificar más fácilmente quién es nuestro usuario, podemos hacernos
preguntas como las siguientes: ¿para qué usuario estamos trabajando en esta
historia?, ¿qué hace, en qué trabaja?, ¿cómo y dónde vive?, ¿cuántos años tiene?,
¿qué tecnología sabe usar?, ¿le sería fácil aprender?, ¿para qué quiere usar la
aplicación?, ¿qué problemas se le presentan actualmente para resolver su necesidad?
Especificar qué producto quiere el usuario
Las historias de usuarios deben describir qué se espera como salida de la
implementación y cómo se ve beneficiado el usuario final. Se expresa en lenguaje
natural y sencillo, para poder conversar directamente con ellos sobre el tema. Hay
que considerar que los usuarios finales tienden a desconocer el lenguaje técnico,
por lo que deben evitarse palabras difíciles. Al usuario no le importa qué
tecnología se usa; lo que busca es que le ayudemos a resolver su problema y saber
cómo usará esa solución, que desea que sea simple, intuitiva y fácil de usar.
Para qué utilizará el producto
En este sentido, es importante definir el contexto donde surge la historia que se
está creando. Esto ayudará a entender el valor agregado que se dará y a establecer
el objetivo de construcción, y aporta la posibilidad de explorar otras alternativas
para llegar al mismo fin.
Criterios de aceptación
Aquí se especifica qué salidas obtendremos cuando finalice el proceso de
ejecución de la funcionalidad. Nos sirve para verificar que está terminada la
funcionalidad. Está relacionada con las pruebas que se realizarán para verificar
el cumplimiento de la expectativa de diseño, usabilidad, rendimiento y
satisfacción del usuario.
+34 691 225 633
Rev. Febrero 2023
Las historias de usuarios facilitan la interacción permanente con el cliente para
verificar que lo que estamos construyendo está de acuerdo a sus expectativas. Esta
negociación se va registrando según se necesite como comentarios o notas
adicionales para tener en cuenta. Esta forma de trabajo permite colaborar y mantener
una comunicación fluida entre los miembros del equipo. Así, la historia va
cambiando durante la marcha de la iteración y se va perfeccionando en conjunto.
Técnicas para construir buenas historias de usuario
La metodología ágil Extreme Programming (XP) inició el uso de un formato con
tres componentes para registrar las historias de usuarios:
- Tarjetas (medio físico).
- Conversación (y la discusión que la rodea).
- Confirmación (evidencia de que los clientes comprueban la tarjeta).
El valor de este medio radica en que simplifica la interacción entre los miembros
del equipo de desarrollo (habitualmente de rol técnico) y los usuarios
(normalmente con rol funcional), utilizando un lenguaje natural, que ambos
manejan y entienden de manera efectiva.
+34 691 225 633
Rev. Febrero 2023
Figura 2: Scrum manager. Historias de usuario. Recuperado de:
https://www.scrummanager.com/files/scrum_manager_historias_usuario.pdf
Para generar historias de usuarios con información efectiva, se recomienda
utilizar dos técnicas, resumidas a través de acrónimos: el método INVEST y el
método SMART.
Método INVEST
Es el acrónimo, en inglés, de:
I – Independent (independiente)
N – Negotiable (negociable)
V – Valuable (valioso)
E – Estimable (estimable)
S – Small (pequeño)
T – Testable (comprobable)
+34 691 225 633
Rev. Febrero 2023
Independiente
Es más fácil trabajar con historias si son independientes. Esto sería lo ideal, pues
corresponderían a historias de usuario que no se superpusieran entre sí; como
consecuencia, podrían ser implementadas en cualquier orden. Sin embargo, esto
no siempre ocurre.
Negociable y negociado
Una buena historia es negociable. No es un contrato explícito de funciones; más
bien, los detalles serán creados conjuntamente por el cliente y el desarrollador
durante el sprint o la iteración. Una buena historia capta la esencia, no los
detalles. Con el tiempo, la tarjeta puede adquirir notas, ideas de prueba, etc., pero
no las necesitamos para priorizar o programar historias.
Valioso
Una historia debe ser valiosa; pero no nos importa el valor para cualquiera: debe ser
valioso para el cliente. Los desarrolladores pueden tener inquietudes (legítimas),
pero enmarcadas de manera que el cliente las perciba como importantes.
Esto es un problema, especialmente, al dividir historias. Piense en una historia
completa como un pastel de varias capas, por ejemplo, una capa de red, una capa
de persistencia, una capa lógica y una capa de presentación. Cuando dividimos
una historia, servimos solo una parte de ese pastel. Si queremos darle al cliente
la esencia de toda la tarta, la mejor manera será cortar verticalmente las capas.
Con esta analogía, consideremos que los desarrolladores suelen tener tendencia
a trabajar solo en una capa a la vez (y hacerlo "bien"); pero una capa de base de
datos completa, por ejemplo, tiene poco valor para el cliente si no hay una capa
de presentación. Hacer que cada porción sea valiosa para el cliente respalda la
actitud de pago por uso de XP hacia la infraestructura. Por otro lado, en Scrum,
se aplica el principio del mínimo viable.
Estimable
Se puede estimar una buena historia. No necesitamos una estimación exacta, pero
sí la suficiente para ayudar al cliente a clasificar y planificar la implementación
de la historia. Ser estimable es, en parte, una función de ser "negociado", ya que
+34 691 225 633
Rev. Febrero 2023
es difícil estimar una historia que no entendemos. También es una función del
tamaño: las historias más grandes son más difíciles de estimar.
Finalmente, es una función del equipo: lo que es fácil de estimar variará
dependiendo de la experiencia del equipo. (A veces, es posible que un equipo
tenga que dividir una historia en un “pico” (con un período de tiempo) que le
dará al equipo información suficiente para hacer una estimación decente, y el
resto de la historia que realmente implementará la característica deseada).
Pequeño
Las buenas historias tienden a ser pequeñas, no incompletas. Se debe recordar y
mantener siempre el enfoque de "mínimos viables" y "duración máxima de
sprint" (4 semanas). Además, las historias más pequeñas tienden a obtener
estimaciones más precisas. Las descripciones de las historias también pueden ser
pequeñas (y ponerlas en una ficha ayuda a que eso suceda).
Comprobable
Una buena historia es comprobable. Escribir una tarjeta de historia conlleva una
promesa implícita: "Entiendo lo que quiero lo suficientemente bien como para
poder escribir una prueba para ello". Varios equipos han informado que, al exigir
pruebas a los clientes antes de implementar una historia, el equipo es más
productivo. La “probabilidad” siempre ha sido una característica de los buenos
requisitos; de hecho, escribir las pruebas con anticipación nos ayuda a saber si se
cumple este objetivo.
Si un cliente no sabe cómo probar algo, esto puede indicar que la historia no es
lo suficientemente clara, o que no refleja algo valioso para él, o que el cliente
simplemente necesita ayuda para realizar la prueba.
Método SMART
Las tareas SMART buscan crear metas más efectivas. SMART es el acrónimo de:
S – Specific (específico)
M – Measurable (medible)
+34 691 225 633
Rev. Febrero 2023
A – Achievable (alcanzable)
R – Relevant (relevante)
T – Time-boxed (a tiempo)
Específico
Una tarea debe ser lo suficientemente específica como para que todos puedan
entender lo que implica. Esto ayuda a evitar que otras tareas se superpongan y
ayuda a las personas a comprender si las tareas se suman a la historia completa.
Mensurable
La medida clave es la siguiente: ¿podemos marcarlo como hecho? El equipo debe
ponerse de acuerdo sobre lo que eso significa, pero debe incluir "hace lo que está
previsto", "se incluyen pruebas" y "el código ha sido refactorizado".
Realizable
Busca garantizar que el o los responsables de ejecutar esta tarea sepan cómo hacerlo.
Importante
Cada tarea debe ser relevante y contribuir a la historia en cuestión. Las historias
se dividen en tareas para beneficio de los desarrolladores, pero el cliente aún debe
poder esperar que cada tarea pueda explicarse y justificarse.
Dentro del tiempo
Una tarea debe tener un límite de tiempo: limitarse a una duración específica. No es
necesario que sea una estimación formal en horas o días, pero debe haber una
expectativa para que las personas sepan cuándo deben buscar ayuda. Si una tarea es
más difícil de lo esperado, el equipo necesita saber que debe dividir la tarea, cambiar
de jugadores o hacer algo para ayudar a que se complete la tarea (y la historia).
Conclusión
Mientras documenta historias, escriba tarjetas y divida historias, el acrónimo
INVEST puede ayudarle a recordar las características de las buenas historias. Al
crear un plan de tareas, aplicar el acrónimo SMART puede mejorar tus tareas.
+34 691 225 633
Rev. Febrero 2023
Bibliografía
Beck, K., Beedle, M. y otros (2001). Manifiesto por el desarrollo ágil de software.
Obtenido de: https://agilemanifesto.org/iso/es/manifesto.html
Beck, K., Beedle, M. y otros (2001). Principios del Manifiesto ágil. Obtenido de:
https://agilemanifesto.org/iso/es/principles.html
Kelvin, L. (s. f.). IEDS - Instituto de Energía y Desarollo Sustentable. Obtenido de:
https://www.cab.cnea.gov.ar/ieds/index.php/34-institucional/noticias/374-lo-
que-no-se-mide-no-puede-
mejorarse#:~:text=William%20Thomson%20Kelvin%20(Lord%20Kelvin,mejora%
2C%20se%20degrada%20siempre%22.
Martin, D. y Tardini, D. (noviembre de 2020). 2020 Scrum Guide Spanish
European. Obtenido de:
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-
European.pdf
Tortorella, P. B. (julio de 2018). Estrategia-organizacional. Obtenido de:
https://scrum.mx/informate/estrategia-organizacional
Tabla de ilustraciones
Figura 1: Produto mínimo viable. Zuppa, Federico. Recuperado de:
https://scrum.mx/informate/descubrimiento-de-producto
Figura 2: Scrum manager. Historias de usuario. Recuperado de:
https://www.scrummanager.com/files/scrum_manager_historias_usuario.pdf
