Compilar y administrar el trabajo pendiente del producto

Artículo
04/10/2013

Por Mitch Lacey.Propietario, Mitch Lacey & Associates, Inc, firma consultora especializada en adopciones y mejoras de metodologías ágiles y de Scrum.

Enero de 2012

En este artículo, Mitch Lacey explica la importancia de un trabajo pendiente del producto, describe qué hace que un trabajo pendiente sea pendiente y proporciona algunos procedimientos recomendados para crear y mantener el trabajo pendiente.

Se aplica a

Administración del ciclo de vida de la aplicación; Team Foundation Server

En este artículo:

Introduction
Trabajo pendiente del producto
- Casos de usuario
- Estimar
- Asignación de prioridades
Trabajo pendiente activo del producto
- Preparación
Conclusión

Un trabajo pendiente del producto es una lista prioritaria de todas las características y funcionalidades necesarias para completar un proyecto.Un buen trabajo pendiente del producto es la esencia de cualquier equipo ágil que funcione bien y tiene las características siguientes:

Se da prioridad para asegurarse de que el equipo compila las características más importantes primero.
El equipo estima que hay que ofrecer transparencia al propietario del producto y habilitarle para responder a preguntas como “¿Cuándo se finalizarán estos casos?”
Incluye todo el trabajo necesario para completar el proyecto.
Es un documento activo, en constante cambio y evolución para reflejar las realidades actuales del proyecto.

Un buen trabajo pendiente del producto no garantiza directamente un buen software.Sin embargo, la falta de un buen trabajo pendiente del producto da lugar a menudo a software incompleto que no cumple los requisitos de los clientes y partes interesadas.

Administrar el trabajo pendiente del producto es un trabajo a tiempo completo.Las técnicas simples pueden ayudar a cambiar lo que sería un proceso complicado y largo por un proceso interactivo e iterativo que involucre eficazmente a los miembros del equipo, los clientes y las partes interesadas.Es esencial, por consiguiente, aprender técnicas sólidas para ayudar a compilar, establecer las prioridades y mantener el trabajo pendiente del producto.

Trabajo pendiente del producto

El trabajo pendiente del producto es una lista general activa y con prioridades de todas las características y funcionalidades necesarias para completar el proyecto.Los trabajos acumulados de producto incluyen normalmente los casos de usuario de requisitos (eg... requisitos), errores, tareas de investigación (puntos) y mejoras de ingeniería.Estos elementos se estiman en unidades abstractas que a menudo se denominan puntos de caso.

Los trabajos pendientes del producto incluyen todo el trabajo que el proyecto requiere y evoluciona con el tiempo.Como tal, contienen no solo las nuevas características de un producto sino también las correcciones de errores e investigación (todo lo que pueda robar tiempo al equipo).Todo el trabajo que el equipo realizará debe proceder del trabajo pendiente del producto: es la puerta principal al proyecto.Si el trabajo pendiente del producto incluye todo el trabajo, el propietario del producto, el equipo y la dirección tendrán una idea más clara del trabajo que resta por hacer y reduce las sorpresas de última hora.

Al principio de cualquier proyecto, es improbable que disponga una lista de elementos de trabajo pendiente del producto ordenados y bien definidos, listos para ser valorados y clasificados según prioridades.En su lugar, probablemente tenga una pila de tarjetas de notas sobre casos y quizás una o dos especificaciones funcionales.Como propietario del producto, es su trabajo ordenar todo este lío para que el equipo pueda comenzar a calcular el trabajo pendiente.

Casos de usuario

El primer paso es convertir todas las ideas y notas en casos de usuario, que expresan la funcionalidad deseada del usuario final (lo que el software debe hacer) pero no los detalles de implementación (cómo crear software que cumpla esos requisitos).El título de cada caso de usuario debe tener este formato: “Como <usuario>, deseo <funcionalidad> de modo que <motivo>”.

Ejemplo de tarjeta de historial

Como el trabajo pendiente del producto en sí mismo, cada caso de usuario evolucionará con el tiempo.A lo largo del proyecto, el equipo dará prioridad y estimará estos casos, les agregará información detallada y los desglosará en casos más pequeños o los eliminará en conjunto.Los que se incorporen en los sprints se implementarán y se entregarán a los clientes.

Para obtener información más detallada sobre los casos de usuario, vea Crear o agregar al trabajo pendiente del producto y Guión gráfico un elemento de trabajo pendiente utilizando PowerPoint.

Después de convertir todas las ideas y notas en casos de usuario, es la hora de calcular y establecer prioridades.

Estimar

Por definición, la valoración es imprecisa.Sin embargo, puede mejorar mucho mejor en la creación de estimaciones relativamente precisas con el tiempo, práctica y la división de todo el equipo. El primer paso es reunir al equipo para proporcionar estimaciones en los elementos de trabajo pendiente del producto.Cuando el equipo estima cada caso, le proporciona una estimación de tamaño relativo con una unidad de medida abstracta, denominada punto de caso.

Las estimaciones son esenciales por dos motivos:

Ayudan a responder a la pregunta: “¿Cuándo habremos terminado?”
Ayudan al propietario del producto a determinar la prioridad de cada elemento.

Las estimaciones proporcionan al propietario del producto y al equipo una idea del costo de un caso determinado, que, a su vez, ayuda al propietario del producto a dar prioridad a casos relacionados entre sí.Cuanto mayor sea la estimación del elemento, más costoso será implementarlo en términos de tiempo y recursos.Por consiguiente, la prioridad de un elemento que puede haber estado en las primeras posiciones de la lista de deseos del propietario del producto puede reducirse si tiene un alto costo.

El equipo puede utilizar la planeación de póker, el gran muro u otras técnicas para calcular el trabajo en términos de puntos de caso.Para obtener más información sobre las técnicas de estimación y una lección rápida sobre puntos de caso, vea El calcular y Repasar y estimar el trabajo pendiente.

Después de que el equipo haya evaluado todos los casos, es el momento de clasificarlos según su prioridad.

Asignación de prioridades

Todos los trabajos pendientes del producto se clasifican según su prioridad en términos de valor empresarial y riesgo.El propietario del producto compara cada elemento del trabajo pendiente con el resto para determinar su prioridad relativa.Para ello, el propietario del producto tiene en cuenta el tamaño de cada elemento, su valor para el negocio y cualquier riesgo relacionado.Los elementos se ordenan en orden descendente de prioridad.Los elementos con prioridad alta aparecen en o cerca de la parte superior del trabajo pendiente del producto y los elementos con menos prioridad están en o cerca de la parte inferior.Los equipos elijen el trabajo para el próximo sprint entre los elementos de prioridad máxima, de forma que los elementos más importantes se completen primero.

No todos los elementos en el trabajo pendiente son del mismo tamaño.Algunos se pueden completar en un sprint, mientras que otros son tan grandes que el equipo no está muy seguro de los recursos implicados o de cuánto tiempo llevará implementarlos.Es normal.Cuando los elementos se acercan al principio del trabajo pendiente, el equipo los hará más pequeños y centrados de modo que todo el mundo comprenda mejor el trabajo que se ejecutará en los próximos Sprints.

Como con la estimación, el establecimiento de prioridades para el trabajo pendiente inicial del producto puede ser complicada.¿Cómo puede equilibrar eficazmente las peticiones de las partes interesadas competitivas, mientras se tiene en cuenta el producto final, los riesgos y los costos?Afortunadamente, varias técnicas existen que crean la tarea más fácil, incluidos Innovation Games y Relative Weighting.Vea Planear un sprint y Repasar y estimar el trabajo pendiente para obtener información sobre estas y otras técnicas.

Sea cual sea la técnica de clasificación por prioridades que elija, debe ordenar el trabajo para garantizar que el equipo compila las características que proporcionan mayor valor a la empresa, a las partes interesadas y a los clientes.Si no asigna prioridades al trabajo, aumenta el riesgo de entregar casos de usuario de menor prioridad en lugar de aquellos con mayor prioridad y casos de usuario incompletos cuando cambien los recursos y programas.

(Para obtener más información sobre la naturaleza de los elementos de trabajo pendiente, vea Crear o agregar al trabajo pendiente del producto y Iteraciones y planeación de Agile).

Trabajo pendiente activo del producto

Lo que he descrito hasta ahora se ha centrado en ir desde cero a un trabajo pendiente del producto estimado y con prioridades.A diferencia de un documento de requisitos, los trabajos pendientes del producto no se crean al principio del proyecto y luego se abandonan en una estantería.En su lugar, el trabajo pendiente del producto evoluciona, ampliándose y contrayéndose con las realidades del proyecto.Algunos elementos de trabajo pendiente del producto se convertirán en irrelevantes y deberán eliminarse.Otros emergería a la superficie y deben ser desglosados en casos más pequeños.Los nuevos casos de usuario se agregarán, estimarán y establecerán sus prioridades según surgen requisitos adicionales.

El equipo y las partes interesadas se ocupan de crear y administrar el trabajo pendiente del producto, pero la responsabilidad última recae en el propietario del producto.El propietario del producto debe asegurarse de que el trabajo pendiente está limpio, con prioridades y actualizado de modo que tanto los clientes como el equipo tengan una imagen clara del plan de trabajo para la versión del proyecto.Incluso después de que el proyecto esté en marcha, los propietarios del producto tienen mucho trabajo por delante para mantener en buenas condiciones el trabajo pendiente del producto:

Agregar y clasificar por orden de prioridad nuevos casos
Pida al equipo que valore nuevos casos y que vuelva a evaluar los antiguos ya que se comprenden mejor
Revisar los futuros casos de usuario con el equipo para analizar los elementos según sea necesario
Reunirse con los clientes y las partes interesadas para revisar y agregar requisitos

Cualquiera puede agregar elementos al trabajo pendiente del producto en cualquier momento, pero solo el propietario del producto puede darles prioridad.El propietario del producto también es la única persona que puede asignar una prioridad a un caso.Todos los demás miembros del equipo y las partes interesadas deben dejar en blanco la prioridad al agregar un caso, incluso si se usa una herramienta electrónica que les solicita esa información.

Cuando se agrega un caso, el propietario del producto creará una evaluación preliminar de su prioridad basándose en su comprensión de él.Debatirá el caso con su creador para entenderlo mejor de modo que pueda, a su vez, responder a preguntas del equipo.En un momento predeterminado durante cada sprint, el propietario del producto se reunirá con el equipo para analizar los nuevos casos y para valorarlos conjuntamente de forma que pueda establecer prioridades con mayor exactitud en relación con otros casos del trabajo pendiente.Este proceso se preparar el trabajo pendiente.

Preparación

La preparación del trabajo pendiente del producto, como se ha mencionado anteriormente, debe realizarse con regularidad.

En Scrum, el equipo debe pasar un 5%-15% de su tiempo en cada Sprint en actividades de preparación.El equipo debe entender lo que está surgiendo y lo que está cambiando para poder analizar cualquier caso grande cuya prioridad esté subiendo, estimar los casos se hayan creado, y hacer algún diseño y planeación emergente para los casos futuros.Para asegurarse de que esto ocurre, durante cada reunión de planeación del sprint, el propietario del producto y el equipo deben reservar parte del tiempo durante ese sprint para preparar el trabajo pendiente juntos.Para obtener más información sobre la planeación del sprint, vea Planear un sprint y Planear una iteración.

Durante un Sprint de dos semanas, me gustaría mantener una reunión en la segunda semana.Esto da al propietario del producto tiempo suficiente para mantener conversaciones significativas con los clientes y las partes interesadas, entender los cambios que se producen en el negocio, y clarificar los casos de usuario y los casos que son nuevos o cuya prioridad aumenta.Es también lógico durante el Sprint anticipar los Sprints siguientes.Puede decidir cuándo se celebrará la reunión.Lo importante es proporcionar un plazo de tiempo suficiente durante el sprint para completar las actividades de preparación.

Durante una reunión de repaso típica, el propietario del producto muestra las novedades, lo que ha cambiado y el plan para los próximos Sprints.Además de calcular los nuevos casos y desglosar los que se deben completar pronto, el equipo se toma su tiempo durante esta reunión para revisar la arquitectura actual del sistema y para planear o para diseñar características futuras.Durante este proceso, la valoración de los casos cambia a menudo y tienden a aparecer nuevos casos según se desglosan los casos más grandes en otros más pequeños.

Este proceso parece sencillo, pero puede resultar algo problemático.Para ayudar a que todo se desarrolle sin sobresaltos, el propietario del producto debe estar preparado para responder preguntas.El conflicto puede seguir si, por ejemplo, el propietario del producto está planeando completar un caso en el siguiente Sprint pero no puede proporcionar la claridad que necesita el equipo para proporcionar una buena valoración.Si esto ocurre durante las reuniones de planeación del Sprint, el ScrumMaster debe indicar al propietario del producto qué información debe traer de los clientes y de las partes interesadas al equipo.

Al final de cada reunión de repaso, el propietario del producto debe publicar los cambios para las partes interesadas y los clientes de modo que todo el mundo pueda ver las novedades, lo que va a venir y el plan de actualización de la versión.

Un buen trabajo pendiente del producto garantiza que el software que se compila tiene las características más importantes tal como se identificaron en las conversaciones con los clientes y las partes interesadas y se definieron en los casos de usuario.Para crear y mantener un buen trabajo pendiente del producto, debe permanecer comprometido activamente con la parte interesada o grupo de clientes y el equipo de forma regular, en cada Sprint.

Compilar un buen registro de trabajos pendientes no garantiza un buen sistema, pero la falta de un buen registro de trabajos pendientes garantizará prácticamente en última instancia que tiene un sistema que no hace lo que han pedido los clientes.Es decir, no mantener el trabajo pendiente actualizado en casi todas las ocasiones hará que el proyecto fracase.

El propietario del producto tiene un trabajo a tiempo completo, y el trabajo pendiente es su responsabilidad.Tómese en serio el rol.Mantenga el trabajo pendiente del producto en buen estado, los clientes se lo agradecerán.