Refinamiento del trabajo pendiente: automatizado

Refinamiento de la cartera de pedidos

El refinamiento del trabajo pendiente es la actividad de preparar elementos de trabajo para que trabaje su equipo de software. Su acumulación de historias de usuarios, tareas de desarrolladores e ideas épicas es la cola de posibles elementos de trabajo para trabajar en las próximas semanas (sprints). Para mantener un flujo constante de trabajo para el equipo, debe estar lista una lista de elementos refinados del trabajo pendiente para que el equipo pueda comenzar a trabajar en cualquier momento. Debería haber un poco más listo y priorizado de lo que el equipo necesita para los próximos sprints.

¿Qué significa el refinamiento de la cartera de pedidos?

El refinamiento del trabajo pendiente (también conocido como preparación del trabajo pendiente) significa trabajar en la validez y los detalles de los requisitos/ideas/tareas para que las preguntas clave se respondan correctamente, de modo que el desarrollador/probador haga lo correcto a la primera. Las historias de usuarios deben refinarse y estar listas antes de que comience el trabajo de codificación y prueba.

Para acortar las reuniones pendientes, desea que sus aportaciones sean de la mayor calidad posible. Esto significa que su analista de negocios o propietario del producto refine las historias de los usuarios tanto como sea posible antes de la reunión. El análisis automatizado realmente puede ayudar con esto, ya que le ayudará a tener sus historias en buena forma antes de la reunión de refinamiento.

¿Qué significa realmente "listo"?

Listo, o definicion de listo, significa que se ha completado suficiente verificación, cuestionamiento, reformulación, revisión y análisis ANTES de la codificación, para que el trabajo de codificación se pueda realizar correctamente la primera vez. Esto significa que los objetivos del usuario se entienden completamente, son claros, idealmente mensurables y ciertamente inequívocos antes de escribir una línea de código. (Nota: la creación de prototipos suele ser un medio útil para verificar los requisitos, pero la creación de prototipos no es necesariamente codificación).

Una historia de usuario refinada debería ser:

Simplificado

Sus historias de usuario deben ser declaraciones funcionales breves y concisas que describan completamente los pasos funcionales de los requisitos completos de un usuario. De modo que el sistema esté en estado estable antes y después de que se hayan realizado los pasos.

Aclarado

Sus historias de usuario deben ser claras, concisas e inequívocas. Lo ideal es que varios miembros describan su interpretación de cada historia de usuario. Cada interpretación es la misma. Ahora bien, esto es difícil con el idioma inglés, a veces incluso si todas las partes estuvieron presentes durante la conversación que describió la historia del usuario. El objetivo es lograr esa interpretación coherente por parte de todos los miembros del equipo, es decir. a entendimiento compartido.

Orientado al usuario

Vemos que muchas historias de usuarios comienzan con "como desarrollador...". Esto no describe el requisito desde la perspectiva del usuario, sino que es una tarea.  Antes de crear tareas de desarrollador, primero debe tener una historia de usuario que describa lo que el usuario necesita lograr y por qué. Entonces y sólo entonces podrás dividirlo en tareas de desarrollador, si es necesario.

Consistencia comprobada

Es vital que utilice términos coherentes en todas sus historias de usuario para cada personaje de usuario. También es vital que utilices palabras idénticas para cada tipo de objeto. Este problema es muy común cuando dos o más personas están creando las historias de usuario, pero puede ocurrir incluso si solo una persona está haciendo el trabajo. El uso inconsistente de nombres de objetos o personas de usuario dará lugar a interpretaciones inconsistentes y errores.

Completitud comprobada

¿Su historia de usuario está completa? ¿Describe todas las funciones necesarias para brindar la experiencia de usuario o la funcionalidad necesaria? ¿Ha “enterrado” la funcionalidad real en sus criterios de aceptación (este es un error muy común)?

Si mantiene datos dentro de un sistema, es una práctica común realizar un análisis CRUD y crear una matriz CRUD. Esto le ayudará a garantizar que todos los datos se creen, lean, actualicen y eliminen mediante al menos un proceso. El análisis CRUD es un medio eficiente y eficaz para garantizar que sus historias de usuario sean competitivas por sí mismas. En última instancia, todos los datos deben ser mantenidos en su totalidad por un sistema. Realizar un análisis CRUD con antelación permitirá apreciar mejor el alcance final de su proyecto.

Tamaño

Es importante dimensionar cada historia de usuario, épica o tarea en su trabajo pendiente. ¿Por qué? Para que puedas planificar y priorizar el trabajo. Aunque muchos equipos utilizarán la idea de tallas de camiseta o puntos de historia, estos son de uso limitado ya que son inconsistentes y no tienen un significado absoluto. Nosotros recomendamos:

• Tareas se dimensionan en horas de personal o en días de personal.
• Historias de usuarios, las historias de usuarios específicamente funcionales se dimensionan en puntos de función COSMIC (CFP).
• Épicas normalmente puede estimarse en CFP.

Nótese bien. Los CFP de un equipo suelen ser fácilmente convertibles en horas estimadas. Para obtener más información sobre los puntos de función COSMIC.

Priorizado

Se deben priorizar los elementos pendientes. La prioridad (y la secuenciación de elementos de prioridad similar) debe determinarse teniendo en cuenta al menos las siguientes consideraciones:

• Valor de la funcionalidad para la empresa, incluido el uso probable
• Tamaño (determina el esfuerzo probable de entrega).
• Impacto en el negocio de retrasar esto. Costo del retraso.
• Relación técnica de esta funcionalidad con otras, es decir, dependencias técnicas.
• Riesgo de incógnitas que podrían conducir a un cambio significativo en otros trabajos realizados.

Una técnica común para asignar algunas de estas consideraciones a un valor numérico se denomina Trabajo más corto ponderado primero (WSJF).

Colin Hammond, 2022

Refinamiento del trabajo pendiente automatizado

Otros artículos sobre este tema discutirán la división y elaboración de la historia. Consideramos que estos términos son un poco vagos. Hemos sido más específicos porque es importante serlo. Una palabra incorrecta en un requisito puede dar lugar a que se malinterprete y, potencialmente, a horas y horas de desperdicio, si es necesario reescribir el código.

Lecturas adicionales de sitios externos

Luché por encontrar muchos artículos que pudiera defender firmemente. Recomiendo este libro Requisitos de software, de Karl Wiegers y Joy Beatty

Artículo digital sobre el refinamiento del trabajo pendiente