La práctica y la importancia de las tareas de descomposición de cartas de historias

Se analizaron los motivos:

1) Nuestras capacidades de BA (Business Analyst) no están a la altura: los criterios de aceptación en la tarjeta de historia no están lo suficientemente detallados y no hay pensamiento en profundidad sobre todos los viajes de los usuarios relacionados.

2) En el contexto de dicha tarjeta de historia, como desarrollador, si no tiene toda la conciencia necesaria para pensar en el recorrido del usuario de antemano, descubrirá que muchos problemas solo se pueden pensar en ellos. y lo resolví cuando estuve expuesto a ellos. Descubrí que este era un gran pozo que requería discusión entre varios personajes antes de poder continuar.

3) Si los desarrolladores no piensan claramente en varios escenarios comerciales al crear tarjetas y si siguen completamente el AC incompleto, se producirán muchos errores. Si estos errores sólo aparecen cuando los evaluadores prueban la tarjeta, el problema es menor y se puede rehacer. Pero a menudo los evaluadores solo seguirán AC para realizar pruebas, por lo que la tarjeta se considerará completa y se fusionará nuevamente con su rama principal. De esta manera, estos errores quedarán expuestos más adelante (en el caso de pruebas de datos reales) y tendrás que crear una nueva tarjeta de historia para rastrearlos, lo que puede incluso afectar el lanzamiento de todo el proyecto.

Como resultado, el desarrollo y finalización de una tarjeta de historia llevará el doble de tiempo de lo esperado originalmente. La eficiencia de entrega de todo el equipo será extremadamente baja y los miembros del equipo también sufrirán mucho.

En este caso, como desarrolladores, lo que podemos hacer es solucionar este tipo de problemas en la medida de lo posible en nuestros aspectos. Lo más efectivo en este momento es dividir las tarjetas de historias en pequeñas tareas.

La primera vez que entré en contacto con este concepto fue cuando estaba aprendiendo TDD. Cuando desee implementar una función, primero puede dividirla en tareas más pequeñas.

Por ejemplo: operación de división

Tus tareas pueden ser: (1) el divisor no es 0, redondear (2) el divisor es 0 e imprimir el registro de errores.

Mientras su función cumpla con estas dos tareas, estará completa.

Del mismo modo, este concepto también se puede aplicar a las tarjetas de historia. Estos pasos son los siguientes

(1) Enumere todas las tareas, desde fáciles hasta difíciles, que se pueden lograr rápidamente y brindar a las personas una sensación de logro:

Este proceso puede ayudarlo a comprender todo el proceso. negocio de la tarjeta de historia Proceso para encontrar escenarios comerciales ocultos e información faltante que debe ser proporcionada por el personal comercial. Al mismo tiempo, el desarrollador también pensará en cómo implementar esta función y podrá ayudarlo rápidamente a aclarar sus ideas de implementación. Este tipo de tarea se parece más a un punto de control.

En cuanto a cómo descomponer las tareas, suelo utilizar el principio de la pirámide dorada para dividirlas según niveles. En las story cards, la puntuación según el recorrido del usuario debería ser la más sencilla y directa.

(2) Si la función es compleja, puede descomponer cada tarea en tareas funcionales nuevamente:

Generalmente, estas tareas puramente funcionales no necesitan desensamblarse con demasiado cuidado. los puntos importantes.

(3) Refactorización: las tareas enumeradas por primera vez no son necesariamente completas y deben mejorarse a medida que se realizan.

Cuando hay demasiados escenarios comerciales, la proporción del primer paso será demasiado grande. Pero cuando la tarjeta de historia es más funcional, puede omitir el primer paso y comenzar el segundo directamente, con algunos cambios simples en la interfaz de usuario como tarea.

Este método consiste en resumir de antemano su modo de pensar desde el principio de la creación de esta tarjeta de historia hasta el final del proceso, lo que le permitirá descubrir los problemas antes. Es muy adecuado para desarrollo, BA o pruebas. En línea con la filosofía de vida TODOLIST.

Finalmente adjuntamos un diagrama de tareas que muestra la función de la tabla de comportamiento del usuario: