Requirements Writing Pitfalls That Sabotage Projects (and How to Fix Them)
Avoid the most common requirements writing mistakes. A practical guide covering ambiguity, vague terms, structure problems, attributes, and document formats.
¿Es la historia de usuario el nuevo requisito?
Si trabajas en un entorno ágil, seguramente oyes hablar constantemente de términos como «historia de usuario» y «requisitos», pero ¿te has parado a pensar alguna vez en lo que realmente significan?
¿Son intercambiables las historias de usuario y los requisitos?
En un sistema ágil en el que hay tanta flexibilidad y las líneas divisorias se difuminan continuamente, ¿cómo podemos distinguir realmente entre estos dos términos tan habituales en el sector?
Hay quien se pregunta si las historias de usuario se están convirtiendo en los nuevos requisitos, lo que podría alterar el modo en que se supone que debe funcionar un sistema ágil de Azure DevOps. Entonces, ¿qué está pasando exactamente?
¿Son intercambiables las historias de usuario y los requisitos?
¿Son, por el contrario, las dos caras de una misma moneda?
En esta entrada, vamos a analizar las diferencias y similitudes entre las historias de usuario y los requisitos, y cómo los utilizan tanto los equipos que siguen el método en cascada como los equipos ágiles.
Aquí tienes una plantilla básica para una historia de usuario:
«Como _____, quiero ______ para que ________.»
Imaginemos que soy un usuario que busca una aplicación que me ayude a conseguir un viaje en los trenes locales.
Mi historia de usuario podría ser algo así:
«Como pasajero de tren, quiero que me informen de los retrasos en tiempo real para poder planificar mi viaje en consecuencia».
Ahora bien, además de esta historia de usuario, es posible que también haya «criterios de aceptación». Estos criterios son, en esencia, los umbrales de la historia de usuario (es decir, la funcionalidad de la aplicación) que determinan cuándo se da por concluida la historia de usuario y cuándo el software satisface las necesidades del usuario final.
Cuando los evaluadores ágiles pongan a prueba tu producto, estos criterios de aceptación son los que utilizarán para evaluar tu software.
Si por cualquier motivo no cumple los requisitos, tendrás que volver a empezar desde cero. Estos criterios establecen de forma efectiva las prioridades de la historia de usuario y obligan al equipo de desarrollo a ver las cosas desde la perspectiva del usuario final, modificando el producto según sea necesario.
¿Qué es un requisito?
Los requisitos determinan cómo debe funcionar un programa informático una vez finalizado.
En lo que respecta a los requisitos, se hace hincapié en la finalidad del sistema y en su capacidad para cumplir con la tarea que se le exige. Si alguna vez has leído un documento de requisitos, habrás observado que estos describen con gran detalle cómo deben funcionar determinadas funciones del software.
Se espera que estos requisitos detallados sirvan de guía al equipo, garantizando que desarrollen un producto que cumpla con los estrictos requisitos del proyecto.
Los documentos de requisitos son excesivamente detallados y contienen información sobre los riesgos del proyecto, el alcance, resúmenes ejecutivos y mucho más. Estos documentos están diseñados para establecer los estándares de la experiencia de usuario y la funcionalidad del producto final, entre otros factores.
Siguiendo con el ejemplo anterior de la aplicación de trenes, a continuación se muestran algunos requisitos ágiles para la aplicación:
– Mostrar la hora de llegada de cada tren.
– Mostrar la hora de salida de cada tren.
– Actualizar los horarios de los trenes que sufren retrasos.
– Permitir al usuario reservar asientos.
Como puedes ver, esto entra en más detalles funcionales que una historia de usuario, con requisitos específicos para cada una de las funciones que debe tener la aplicación.
¿Cuál es la diferencia entre una historia de usuario y un requisito?
En la mayoría de los casos, verás que los requisitos son más habituales en los enfoques de trabajo de tipo «cascada» y estructurados, mientras que las historias de usuario son más habituales en los enfoques ágiles e híbridos.
Esto se debe a que el carácter dinámico y flexible del método ágil resulta difícil de compaginar con una larga lista de requisitos estrictos, mientras que es mucho más fácil de integrar con una única historia de usuario global que establezca que el producto debe pasar del punto A al punto B.
Historia de usuario:
«Como pasajero de tren, quiero estar informado de los retrasos en tiempo real para poder planificar mi viaje en consecuencia».
Requisito:
Mostrar los tiempos de retraso estimados de cada tren.
Las historias de usuario constituyen una forma de trabajar posiblemente más moderna, ya que dejan margen para el debate entre los miembros del equipo, quienes pueden adaptar su flujo de trabajo en consecuencia.
Por otro lado, muchas empresas siguen utilizando los métodos de trabajo tradicionales de tipo «cascada» o híbridos, que se benefician de la especificidad y el rigor de los requisitos.
Si tienes un producto destinado a un fin muy concreto, lo mejor suele ser definir los requisitos.
Si trabajas con documentos de requisitos, es bastante inusual que el equipo de desarrollo modifique alguno de los requisitos una vez que se han redactado. Por este motivo, es fundamental que los requisitos del proyecto los redacte una persona que tenga un profundo conocimiento del producto en cuestión.
Además, los sistemas de gestión de requisitos pueden ayudar a los equipos ágiles a clasificar estos requisitos; algunos de estos sistemas se han desarrollado en Azure DevOps para garantizar una mayor fluidez.
Por el contrario, si se trabaja con el modelo de historias de usuario, cualquier miembro del equipo de desarrollo ágil puede aportar ideas al backlog de historias de usuario en cualquier momento a lo largo del proyecto.
Esto significa que los«requisitos»como tales podrían cambiar a lo largo del proyecto. Esto implica que los desarrolladores deben adaptar su trabajo para hacer frente a los cambios que se produzcan en la lista de tareas pendientes.
Esto hace que las historias de usuario ágiles sean ideales para proyectos que ofrecen cierta flexibilidad, lo que permite a los desarrolladores crear un software que resulta natural e intuitivo.
En resumen
Aunque ambos marcan el rumbo de un proyecto, las historias de usuario y los requisitos son conceptos muy distintos.
Los equipos que siguen el método tradicional en cascada suelen basarse en los requisitos y se esfuerzan por cumplirlos todos, mientras que los entornos ágiles suelen recurrir a las historias de usuario debido a su flexibilidad y agilidad.
Dependiendo del proyecto en cuestión, un equipo puede optar por utilizar requisitos, historias de usuario o una combinación de ambos.
¡Solicite una demostración!
- Programe una demostración con uno de nuestros expertos en productos.
- Reciba una demostración personalizada que imita el proceso de su equipo.
- Consulte a nuestros expertos sobre temas como flujos de trabajo o mejores prácticas.
Reducir los esfuerzos de UAT
Reducción del 50 % en los esfuerzos de UAT
Ahorro de tiempo comprobado
Ahorro del 80 % en tiempo de creación del análisis de trazas.
Agilizar las aprobaciones
Reducción significativa de los retrasos en la aprobación
Aumentar el rendimiento
50 % de requisitos de mejora de la productividad
Reducir la repetición del trabajo
Reducción de 10 veces en la reelaboración del desarrollo
Simplifique el cumplimiento normativo
Reducción del 40 % en los esfuerzos de presentación de informes de cumplimiento normativo.
