Crear y administrar el trabajo pendiente

Artículo
06/10/2015

Por Mitch Lacey. Propietario de Mitch Lacey & Associates, Inc., una empresa de consultoría especializada en adopciones y mejoras de Agile y 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 bueno y proporciona algunos procedimientos recomendados para crear y mantener el trabajo pendiente.

Se aplica a

Application Lifecycle Management; Team Foundation Server (TFS)

En este artículo:

Introducción
El trabajo pendiente del producto
- Casos de usuario
- Estimaciones
- Clasificación por orden de prioridad
Un trabajo pendiente del producto vivo
- Limpieza

El trabajo pendiente del producto es una lista clasificada por orden de prioridad de todas las características y funciones necesarias para completar un proyecto. En TFS, administre el trabajo pendiente del producto con los elementos de trabajo. Su elección de tipos de elementos de trabajo variará en función de la plantilla de proceso utilizada para crear el proyecto de equipo. Para obtener más información sobre las plantillas de proceso y los tipos de elementos de trabajo que admiten, consulte Trabajar con artefactos de proyecto de equipo y elegir una plantilla de proceso.

Un buen trabajo pendiente del producto es la esencia de cualquier equipo ágil que funciona bien y tiene las siguientes características:

Está clasificado por orden de prioridad para garantizar que el equipo crea primero las características más importantes.
El equipo realiza las estimaciones necesarias para ofrecer datos claros al propietario del producto y permitirle responder a preguntas como "¿Cuándo se realizarán estos casos?".
Incluye todo el trabajo necesario para completar el proyecto.
Es un documento vivo: cambia y evoluciona constantemente para reflejar la realidad actual del proyecto.

Un buen trabajo pendiente del producto no garantiza automáticamente un buen software. No obstante, la falta de un buen trabajo pendiente del producto a menudo tiene como resultado software incompleto que no satisface los requisitos de los clientes y las partes interesadas.

La administración del trabajo pendiente del producto es un trabajo a jornada completa. Unas sencillas técnicas pueden transformar lo que puede llegar a ser un proceso abrumador y que requiere una gran inversión de tiempo en un proceso interactivo e iterativo que involucre eficazmente a los miembros del equipo, los clientes y las partes interesadas. Por tanto, es fundamental dominar técnicas sólidas para crear el trabajo pendiente del producto, clasificarlo por orden de prioridad y realizar su mantenimiento.

El trabajo pendiente del producto

El trabajo pendiente del producto es una lista maestra dinámica clasificada por orden de prioridad de todas las características y funciones necesarias para completar el proyecto. Los trabajos pendientes del producto suelen incluir casos de usuario de requisitos (por ejemplo, requisitos), errores, tareas de investigación (picos) y mejoras de ingeniería. Estos elementos se calculan en unidades abstractas llamadas a menudo "puntos de caso".

Los trabajos pendientes del producto incluyen todo el trabajo necesario para el proyecto y evolucionan con el tiempo. Así, pues, no solo contienen las características nuevas de un producto, sino también correcciones de errores y actividades de investigación, es decir, cualquier cosa que ocupe el tiempo del equipo. Todo el trabajo que realizará el equipo debe proceder del trabajo pendiente del producto: es la puerta al proyecto. Si el trabajo pendiente del producto incluye todo el trabajo, el propietario del producto, el equipo y el equipo de administración tendrán un mejor panorama del trabajo pendiente y se reducirán las sorpresas de última hora.

Al principio de cualquier proyecto, es poco probable que tenga una lista de elementos del trabajo pendiente del producto bien definidos y optimizados, listos para realizar estimaciones y clasificarse por orden de prioridad. En lugar de eso, lo más probable es que tenga una pila de notas sobre casos y quizás un par de especificaciones funcionales. Como propietario del producto, debe poner algo de orden en este lío, para que el equipo pueda comenzar a realizar estimaciones del trabajo pendiente.

Casos de usuario

El primer paso es convertir todas las ideas y notas en casos de usuario, que expresan la funcionalidad (lo que debe hacer el software) deseada por los usuarios finales, pero no los detalles de implementación (cómo crear software que satisfaga esos requisitos). El título de cada caso de usuario debe seguir el formato "Como <usuario>, deseo <funcionalidad> para que <motivo>".

Ejemplo de tarjeta de historial

Como el trabajo pendiente del producto, cada caso de usuario irá evolucionando con el tiempo. En el transcurso del proyecto, el equipo clasificará por orden de prioridad estos casos y realizará las estimaciones pertinentes, les agregará información detallada y los dividirá en casos más pequeños o los eliminará por completo. Los que se incluyan en sprints se implementarán y se entregarán a los clientes.

Para obtener más información acerca de los casos de usuario, vea Crear el trabajo pendiente y Crear guiones gráficos de sus ideas con PowerPoint.

Tras convertir todas las ideas y notas en casos de usuario, debe realizar las estimaciones y clasificarlos por orden de prioridad.

Estimaciones

Por definición, las estimaciones son imprecisas. No obstante, con tiempo, práctica y la participación de todo el equipo puede mejorar enormemente su capacidad para crear estimaciones relativamente precisas. El primer paso es reunir al equipo para que proporcione estimaciones sobre los elementos del trabajo pendiente del producto. Cuando el equipo realiza la estimación de cada caso, le asigna una estimación de tamaño relativo con una unidad de medida abstracta, llamada "punto de caso".

Las estimaciones son fundamentales por dos motivos:

Ayudan a responder a la pregunta "¿Cuándo se hará?".
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 concreto, lo cual, a su vez, ayuda al propietario del producto a clasificar los distintos casos por orden de prioridad. Cuanto mayor sea la estimación de un elemento, tanto más costosa será su implementación en cuanto a tiempo y recursos. Por consiguiente, un elemento que estaba en los primeros puestos de la lista de deseos del propietario de un producto podría bajar de prioridad si su costo es elevado.

El equipo puede usar Planning Poker, Big Wall u otras técnicas para realizar estimaciones del trabajo en cuanto a puntos de caso. Para obtener más información acerca de las técnicas de estimación y una lección rápida sobre los puntos de caso, vea Estimación y Repasar y estimar el trabajo pendiente.

Una vez que el equipo haya realizado las estimaciones de todos los casos, es hora de realizar la clasificación por orden de prioridad.

Clasificación por orden de prioridad

Todos los trabajos pendientes del producto se clasifican por orden de prioridad en cuanto a valor y riesgo. El propietario del producto compara cada elemento del trabajo pendiente con los demás para determinar su prioridad relativa. Para ello, el propietario del producto tiene en cuenta el tamaño de cada elemento, su valor para la empresa y cualquier riesgo asociado. A continuación, los elementos se clasifican por orden de prioridad descendiente. Los elementos de alta prioridad aparecen en la parte superior del trabajo pendiente del producto o cerca de esta y los de menor prioridad se encuentran en la parte inferior o cerca de esta. Los equipos eligen el trabajo del próximo sprint entre los elementos de mayor prioridad, de modo que los elementos más importantes se completan primero.

No todos los elementos del trabajo pendiente tienen el mismo tamaño. Algunos se pueden completar en un sprint, pero otros son tan grandes que el equipo no puede saber con certeza qué actividades hay que realizar o cuánto se tardará en implementarlos. Es normal, no pasa nada. A medida que los elementos se acerquen a la parte superior del trabajo pendiente, el equipo los acotará y delimitará para que todos los implicados comprendan mejor el trabajo que se realizará en los próximos sprints.

Al igual que pasa con las estimaciones, clasificar por orden de prioridad el trabajo pendiente del producto inicial puede ser abrumador. ¿Cómo se consigue un equilibrio real entre las demandas rivales de las distintas partes interesadas teniendo en cuenta el producto final, los riesgos y los costos? Por suerte, hay varias técnicas que facilitan la tarea, incluidos los juegos de innovación y la ponderación relativa. Vea Asignación de prioridades y Repasar y estimar el trabajo pendiente para obtener más información sobre estas y otras técnicas.

Independientemente de la técnica de clasificación por orden de prioridad que elija, debe ordenar el trabajo de manera que se garantice que el equipo crea las características que aportan mayor valor a la empresa, a las partes interesadas y a los clientes. Si no clasifica el trabajo por orden de prioridad, aumenta el riesgo de entregar casos de usuario de baja prioridad en lugar de casos de alta prioridad y casos de usuario incompletos cuando los recursos y las programaciones cambien.

(Para obtener más información acerca de la naturaleza de los elementos del trabajo pendiente, vea Crear el trabajo pendiente y Trabajar con trabajos pendientes de cartera).

Un trabajo pendiente del producto vivo

Lo que he descrito hasta ahora se ha centrado en pasar de la nada a un trabajo pendiente del producto con estimaciones y clasificado por orden de prioridad. A diferencia de un documento de requisitos, los trabajos pendientes del producto no se crean al principio del proyecto y luego se abandonan en un estante. En lugar de eso, el trabajo pendiente del producto evoluciona y se amplía y contrae junto con la realidad del proyecto. Algunos elementos del trabajo pendiente del producto acabarán siendo irrelevantes y deberán quitarse. Otros saldrán a la superficie y deberán dividirse en casos más pequeños. A medida que surjan requisitos adicionales, se agregarán nuevos casos de usuario, se realizarán sus estimaciones y se clasificarán por orden de prioridad.

El equipo y las partes interesadas participan en la creación y la administración del trabajo pendiente del producto, pero el propietario del producto ostenta la responsabilidad final. El propietario del producto debe asegurarse de que el trabajo pendiente esté limpio, clasificado por orden de prioridad y actualizado, para que tanto los clientes como el equipo tengan una imagen clara del plan de trabajo para el lanzamiento del proyecto. Incluso después de que el proyecto esté funcionando a pleno rendimiento, los propietarios del producto tienen mucho por hacer para mantener al día el trabajo pendiente del producto:

Agregar nuevos casos y clasificarlos por orden de prioridad
Pedir al equipo que realice estimaciones de nuevos casos y que vuelva a realizarlas para los antiguos a medida que se comprendan mejor
Revisar los próximos casos de usuario con el equipo para desglosar 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 clasificarlos por orden de prioridad. El propietario del producto también es el único que puede asignar una prioridad a un caso. Los demás miembros del equipo y las partes interesadas deben dejar la prioridad en blanco al agregar un caso, aunque usen una herramienta electrónica que les solicite esa información.

Cuando se agrega un caso, el propietario del producto realizará una evaluación preliminar de su prioridad partiendo de sus conocimientos sobre el caso. Hablará del caso con su autor para comprenderlo mejor, de manera que pueda, a su vez, responder a las preguntas del equipo. En un momento predeterminado durante cada sprint, el propietario del producto se reunirá con el equipo para hablar de nuevos casos y realizar sus estimaciones en colaboración con el equipo, de manera que pueda clasificarlos por orden de prioridad de manera más precisa en relación con otros casos del trabajo pendiente. Este proceso se conoce como la limpieza del trabajo pendiente.

Limpieza

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

En Scrum, el equipo debe invertir entre el 5 % y el 15 % de su tiempo en cada sprint en actividades de limpieza. El equipo debe comprender qué viene a continuación y qué cambia para poder dividir los casos grandes cuya prioridad aumenta, realizar las estimaciones de los casos que se han creado y realizar actividades de diseño y planeación emergentes para los próximos casos. Para asegurarse de que suceda esto, el propietario del producto y el equipo deben, durante cada reunión de planeación de sprint, reservar tiempo durante ese sprint para limpiar el trabajo pendiente. Para obtener más información acerca de la planeación de sprints, vea Planear un sprint y Trabajar con sprints.

Durante un sprint de dos semanas, esta reunión debería celebrarse durante la segunda semana. Esto daría al propietario del producto suficiente tiempo para sostener conversaciones útiles con los clientes y las partes interesadas, comprender los cambios en el negocio y aclarar los casos de usuario y los casos nuevos o cuya prioridad vaya en aumento. También es el punto lógico durante el sprint para empezar a prever los próximos sprints. Puede decidir cuándo celebrar la reunión. Lo importante es dejar suficiente tiempo durante el sprint para completar las actividades de limpieza.

Durante una reunión de limpieza típica, el propietario del producto presenta las novedades, los cambios y su plan para los próximos sprints. Además de realizar las estimaciones de casos nuevos y dividir los que deben completarse pronto, el equipo dedica tiempo durante esta reunión a revisar la arquitectura del sistema actual y prever o diseñar las próximas características. Durante este proceso, a menudo las estimaciones de casos cambian y los casos nuevos tienden a aparecer como casos grandes que se dividirán en casos más pequeños.

Este proceso parece sencillo, pero puede presentar cierta complejidad. Para que todo vaya como la seda, el propietario del producto debe estar preparado para responder a preguntas. Pueden surgir conflictos si, por ejemplo, el propietario del producto prevé que un caso se realice durante el próximo sprint, pero no puede proporcionar las aclaraciones que necesita el equipo para proporcionar una buena estimación. Si esto sucede durante las reuniones de planeación de sprints, el ScrumMaster debe indicar al propietario del producto qué información debe conseguir de los clientes y las partes interesadas para el equipo.

Al final de cada reunión de limpieza, el propietario del producto debe publicar los cambios a las partes interesadas y los clientes para que todos puedan ver las novedades, lo que está por venir y el plan de lanzamiento actualizado.

Un buen trabajo pendiente del producto contribuye a garantizar que el software que cree tenga las características más importantes identificadas en las conversaciones con los clientes y las partes interesadas, y definidas en los casos de usuario. Para crear y mantener un buen trabajo pendiente del producto, debe implicarse de manera activa y con regularidad (en cada sprint) tanto con el grupo de partes interesadas y clientes como con el equipo.

Crear un buen trabajo pendiente no garantiza un buen sistema, pero la falta de un buen trabajo pendiente prácticamente garantizará en última instancia que tendrá un sistema que no hará lo que los clientes pidieron. Es decir, si no actualiza el trabajo pendiente, el proyecto casi siempre fracasará.

Ser propietario del producto es un trabajo a jornada completa y su responsabilidad es el trabajo pendiente. Tómese este rol en serio. Mantenga el trabajo pendiente del producto en buen estado. Sus clientes se lo agradecerán.