Actualmente estamos trabajando en un proyecto y debatiendo con otros la mejor manera de dividir el proyecto. A continuación, solo proporciono títulos, no escribo las Historias de usuario completas, para que sea más rápido de leer.
Ahora, existe cierto debate sobre si los números de contacto realmente deben dividirse en dos historias separadas. Mi opinión es que hay una necesidad. Podemos iniciar con solo la captura del número de teléfono de casa, luego el número de móvil en una fecha posterior.
El segundo debate es que los desglosaría aún más para tener una historia separada para la validación, por ejemplo:
Entonces, el argumento puede ser que esta historia no tiene ningún valor para el cliente. Sin embargo, tiene algún valor, ya que ayuda al cliente a asegurarse de que ha ingresado un número de teléfono móvil válido, es decir, el Reino Unido comienza con 07 o +447. Aparte de eso, mi razón para tener historias separadas para la validación es que podríamos lanzar sin la validación del número de móvil, aunque sería bueno tenerlo.
Dividir las cosas en partes más pequeñas hace que todo sea más manejable: más fácil de progresar, más fácil de seguir el progreso y el progreso es mucho más visible. Además, facilita la iteración.
Además, estaría incluso tentado a desglosar la Vista y la Actualización del número móvil en historias separadas porque, de nuevo, podríamos empezar a funcionar solo con Vista. Siento que esto refleja la construcción de manera incremental, al igual que Spotify sugiere con su ejemplo de Skateboard, Scooter, Bicycle, Motorbike, Car.
¿Es válido mi enfoque?
Su enfoque parece válido, pero solo usted y su equipo pueden determinar si es óptimo para su proceso actual. La descomposición se trata de encontrar el tamaño óptimo de la historia para el proceso de su equipo ; mientras que las historias más pequeñas ayudan a mantener el flujo, algunas historias pueden ser tan pequeñas que el tamaño de la unidad de trabajo se ve abrumado por la sobrecarga del proceso que implica cada historia.
¿Está desglosado correctamente mi tema de "Información de contacto personal"?
No hay una respuesta canónica a esta pregunta, ya que la granularidad necesaria de las historias de usuario (o los paquetes de desglose de trabajo tradicionales, para el caso) dependerá en gran medida de cosas como:
Como ejemplo, considere si hacer que los pasos de visualización, actualización y validación separen las historias tiene sentido para el proyecto. Esto dependerá mucho de:
Tu marco.
Algunos marcos hacen que sea trivial tratar los tres entregables como una sola unidad de trabajo, mientras que otros no lo hacen. Por lo tanto, su kilometraje variará.
Tus dependencias.
Si las historias se pueden hacer de forma independiente, entonces ciertamente puede hacer que sean historias separadas si eso agrega valor para el proyecto. Sin embargo, tratar elementos interdependientes a nivel de tarea como historias de usuario separadas suele ser un olor a proyecto.
La delimitación entre una historia y una tarea dentro de su proyecto.
Tratar un montón de subtareas como múltiples historias de usuario simplemente agrega una sobrecarga al proceso. Como consideración adicional, una historia rara vez (o nunca) debe ser prescriptiva, y los elementos a nivel de tarea generalmente son prescriptivos por naturaleza. Trate de mantener sus historias lo más detalladas posible mientras se asegura de que incluso la historia más pequeña permanezca por encima del nivel de la tarea.
Su unidad de trabajo.
Como ejemplo brillante, si bien no hay nada intrínsecamente malo en dividir las historias en historias más pequeñas que se mantengan por encima del nivel de la tarea, en un proyecto de Rails con un equipo maduro, podría crear una sola historia con "números de teléfono celular validados de soporte en la página de contacto". ." A mí, esa unidad de trabajo me parece relativamente pequeña e idempotente. Nuevamente, su kilometraje puede variar según el contexto y las capacidades.
¿Es válido mi enfoque?
Su enfoque ciertamente parece válido en abstracto, pero si es útil dentro del contexto de su proyecto particular es algo que su equipo puede determinar. La pregunta subyacente es si el nivel adicional de detalle ayuda o dificulta al equipo. Si una historia generalmente sigue los principios de INVEST y se ajusta a una sola iteración, entonces la descomposición adicional puede simplemente agregar gastos generales o complejidad al proceso de planificación.
Hay dos cosas de nota especial a considerar aquí:
La "V" de valor en INVEST no siempre tiene que ser valor para el usuario final.
El valor puede ser para el proyecto , en lugar de solo para el usuario final. Mientras haya un "consumidor de valor" claramente identificado para la historia, y mientras el propietario del producto (o una parte interesada comparable en su marco) encuentre valor en la historia, entonces eso es suficiente para "V".
Descomponer historias es una compensación.
Como usted dice, las historias más pequeñas son más fáciles de administrar en una variedad de formas y, en general, son más "ágiles". Sin embargo, todas las historias conllevan una cantidad fija de gastos generales de proceso, por lo que se debe lograr un equilibrio entre mantener la historia lo más pequeña posible sin hacerla tan pequeña que agregue contabilidad innecesaria o gastos generales de estructura. Este acto de equilibrio requerirá diferentes compensaciones para cada proyecto, equipo e historia, por lo que su equipo tendrá que encontrar su propio óptimo.
Voy a estar en desacuerdo con las otras dos respuestas aquí y decir: no, su enfoque no es válido. Considere el caso de uso simple de un contacto que no tiene un teléfono fijo, solo uno móvil. Se sentirán frustrados por un sistema que rechaza su único teléfono por tener un número de teléfono residencial no válido.
En su lugar, te sugiero que pienses en términos de dividir las historias en:
La historia 1 sería la prioridad más alta, pero dependiendo de la velocidad alcanzada frente a la esperada, podría, por ejemplo, abandonar la historia 2 por completo e ir directamente a la 3, implementar la historia 5 después de la 1, etc., lo que le brinda flexibilidad en lo que se entrega en cada versión.
Me parece bien.
Probablemente dividiría las historias así:
entonces la OP/negocio puede equilibrar su prioridad relativa.
En cuanto a la validación de los números de teléfono, se debe tomar una decisión sobre si son historias por derecho propio o criterios de aceptación adicionales en las dos historias de actualización.
No creo que haya una respuesta correcta o incorrecta para eso. Depende del valor para el negocio de la validación y el costo de limpiar los números de teléfono no válidos, siempre y cuando las historias de validación finalmente se implementen.
Personalmente, haría que la validación del número de teléfono fuera parte de los criterios de aceptación asumiendo que es una tarea muy pequeña y evitará el desperdicio (datos no válidos que tendrán un costo para limpiar en el futuro)
Lee Walker