Me gustaría hablar sobre un requisito comercial del cliente. El requisito es permitir que el usuario seleccione una gran cantidad de datos. Voy a tratar de explicar con un ejemplo. Como administrador de cartera, debería poder seleccionar una lista de modelos de la lista, para poder crear una cartera.
Aquí, puede haber más de 20000 modelos en el mercado. Por lo que la aplicación se atascará si permitimos que el usuario seleccione todos los modelos al crear una cartera. El cliente no puede usar más de 10 modelos al crear una cartera en un escenario real. Pero hay un requisito para seleccionar todos los modelos disponibles en el sistema. ¿Cómo debo manejar este escenario? ¿Tiene alguna forma alternativa de cumplir con este requisito?
Su historia de usuario actual dice:
Como administrador de cartera,
debería poder seleccionar una lista de modelos de la lista,
para poder crear una cartera.
Por un lado, esta historia no define la necesidad de seleccionar todos los modelos, solo "una lista" de ellos. En ese caso, cuántos pueden seleccionar se deja como un detalle de implementación que debe negociarse entre el equipo de desarrollo y los usuarios finales. La función se puede mejorar o perfeccionar con el tiempo a medida que cambien las necesidades.
Por otro lado, si la selección de todos los modelos es un requisito funcional para el producto, es posible que sea necesario reescribir sus historias para capturar las necesidades reales del usuario y los requisitos no funcionales que esto impone en el sistema actual. Si bien no tengo forma de extrapolar su caso de uso real de la pregunta original, considere el siguiente ejemplo:
Como administrador de cartera,
quiero poder seleccionar más de 2000 modelos a la vez
para poder ejecutar análisis de datos complejos en los datos exportados.
Esta es una historia más útil, ya que proporciona una idea más precisa del tamaño de la selección que desea el usuario. También mejora el original al proporcionar un contexto para la historia, de modo que el equipo pueda planificar y estimar con mayor precisión el esfuerzo para satisfacer la necesidad. También proporciona una línea de base para la colaboración con las partes interesadas, ya que puede haber compensaciones razonables que se pueden hacer en el caso de uso o en la implementación de la función.
Una vez que esté seguro de que tiene la historia correcta desde la perspectiva del administrador de cartera, es posible que necesite algunas historias adicionales que capturen la perspectiva administrativa o de ingeniería. Estos pueden ser requisitos funcionales o no funcionales, pero en cualquier caso representan características del producto que deben gestionarse como cualquier otro. Por ejemplo, suponiendo que se trata de una interfaz web para una base de datos típica:
Como administrador del sitio,
quiero permitir que los usuarios exporten todos los modelos en el conjunto de datos sin una gran penalización en el rendimiento
para que los análisis complejos se puedan descargar de la propia aplicación.
Al formar un tema alrededor de estas historias relacionadas, puede trabajar iterativamente en los requisitos funcionales y no funcionales en más de un Sprint mientras mantiene las historias pequeñas y negociables según los criterios de INVEST .
Lo que es más importante, al capturar el nivel correcto de detalle sobre lo que los usuarios del producto realmente quieren y por qué, le permite al equipo de desarrollo validar suposiciones (por ejemplo, ¿un usuario realmente necesita seleccionar más de 2000 modelos dentro de una interfaz de usuario web?) u ofrecer implementaciones alternativas (por ejemplo, exportaciones de datos) que no necesariamente se le ocurrirían a una persona no técnica.
Recuerde siempre que las historias de usuario son marcadores de posición de conversación, no especificaciones. Escriba historias de usuarios para capturar la perspectiva esencial y el contexto de cada historia, y luego libere la creatividad del equipo de desarrollo para colaborar en los detalles de implementación para que no restrinja demasiado el espacio de la solución.
Esa es la "salsa secreta" que hace que los marcos ágiles sean tan efectivos: un enfoque colaborativo y de mente abierta para las soluciones de colaboración colectiva; optimizar para el trabajo no realizado; y buscando la solución más sencilla que satisfaga la necesidad inmediata , dejando para el futuro los refinamientos futuros.
jithin antonio