User Stories : La importancia de los roles.
Un punto a tocar a la hora de refactorizar o diseñar un sistema son los roles. Todas las personas que usaran nuestro sistema son usuarios, o más bien grupos de usuarios. Cada uno de estos grupos tiene intereses muy distintos y únicos al momento de operar el sistema. No puedes englobarlos todos en una misma categoría (a menos que trabajes con un diseño simple que tenga baja complejidad o nulo crecimiento a futuro), es importante darse un tiempo de verificar que se cubre las necesidades de todos. Hay que tener en cuenta lo siguiente:
¿Qué es un rol de usuario?.
Un rol de usuario es un conjunto de usuarios con las mismas características, intereses y necesidades. Un rol, en principio, no debe representar solo a un usuario individual (aunque el sistema solo tenga un usuario de determinado rol, como el tipo de sistemas, por ejemplo).
El interés en el sistema no es igual para todos.
Un sistema en la empresa no le sirve a todos para lo mismo. Imagina un sistema de recepción de facturas. Los proveedores buscan subir sus facturas a un portal para que inicie su proceso de pago. La gente del área de finanzas debe de validar la factura, y en caso de que todo este en orden marcarla como buena. Quizá el gerente de área este interesado en saber que pagos están pendientes y cuáles ya han sido liberados. Cada uno de estos actores accede al sistema para cubrir sus propios intereses egoístas, no está interesado en saber que hacen los otros grupos de usuarios.
Aléjate de los diseños anémicos.
Un error común es englobar el conjunto de usuarios como solamente: «el usuario», o quizá: «el cliente», esto plasmado en una historia de usuario no ofrece pista alguna sobre la problemática de quien estás solucionando o el valor que se busca ofrecer al trabajar en ello. Es necesario hacer un esfuerzo para encontrar los grupos de usuarios que van a operar, imagina diseñar historias de usuario con los roles: Usuario y Administrador. En este caso se sabe que existen usuarios y otra clase con más poderes, y ya. ¿Qué pasaría si haces un esfuerzo y te das cuenta de que hay muchas más categorías?, por ejemplo: proveedores, dueños de empresa, asociados, comerciales, gerencia, administradores. Es claro, sin saber mucho del requerimiento, que el sistema en cuestión resolverá varias problemáticas, en varios niveles. Y las soluciones pensadas para un rol pueden no aplicar para otro rol. Definitivamente, las historias que se redacten con un modelo robusto tendrán más posibilidades de ser exitosas.
Está bien no conocer todos los roles al principio.
Diseñar sistemas no es una ciencia, es posible que no conozcas todos los roles. O también roles que inicialmente creías que eran uno solo se dividan con la respectiva corrección en las historias de usuario. Las historias de usuario deben de ser buenas, no perfectas. Si esperas por tener un modelo, requerimiento o historias de usuario perfectas también estás generando desperdicio.
Buenos roles hacen buenas historias de usuario.
Uno de los principales objetivos de las historias de usuario es aportar valor medible, un rol bien definido en una historia de usuario indica que tanto valor aporta, que tan importante es y que tan negociable es en la priorización. También ayuda a completar flujos de usuarios o incluso estimar tiempos. Si conoces el valor que se aporta a cada rol, puedes usarlo como moneda a la hora de tomar decisiones, por ejemplo: Se debe de priorizar el flujo asociado y proveedores, los reportes gerenciales y el módulo de administración pueden dejarse de lado hasta una nueva etapa. ¡Ves!, medibilidad y visibilidad.
Autor imagen: Marco Verch
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20