Scrum, 4ta. parte - Artefactos | IDS Comercial

Scrum, 4ta. parte - Artefactos

Scrum, 4ta. parte - Artefactos

Martes, Diciembre 2, 2014

Los Artefactos en Scrum representan trabajo o valor añadido que aportan transparencia y oportunidades para la revisión y adaptación. Los Artefactos están diseñados específicamente para facilitar la transparencia de la información clave y unificar los criterios de compresión de dicho artefacto.

Product Backlog

El Product Backlog es una lista ordenada de todo lo que podría necesitarse en el producto y es la única fuente de requerimientos para los cambios que se realizarán en el producto. El Product Owner es responsable del Product Backlog incluyendo su contenido, disponibilidad y jerarquización.

El Product Backlog nunca se termina. Inicialmente, contiene los requerimientos de lo que se conoce y entiende al momento de iniciar el desarrollo. El Product Backlog evoluciona conforme el producto y su entorno evolucionan. El Product Backlog es dinámico; cambia constantemente de acuerdo a lo que el producto requiere para mantenerse adecuado, competitivo y útil. Mientras exista un producto, su Product Backlog también existe.

El Product Backlog incluye todas las características, funciones, requerimientos, mejoras y correcciones que constituyen los cambios que deben introducirse en el producto en futuras versiones. Los elementos del Product Backlog deben contender los siguientes atributos: descripción, orden, estimaciónvalor.

Conforme el produto se utiliza y su valor útil aumenta y recibe retroalimentación del mercado, el Product Backlog crece y se convierte en una lista más exhaustiva. Cambios en las necesidades del negocio, las condiciones del mercado o la tecnología tienen un impacto directo en el Product Backlog, por lo que es un Artefacto dinámico.

Es común que varios Equipos Scrum trabajen en un mismo producto y, por lo tanto, utilicen un mismo Product Backlog para identificar el trabajo a realizar. En estos casos, se podrá incluir un atributo que agrupe los elementos registrados.

El refinamiento del Product Backlog es la tarea de añadir detalles, estimaciones, y orden a los elementos del Product Backlog. Es un proceso continuo en el que el Product Owner y el Equipo de Desarrollo colaboran en aportar detalles a los elementos en El Product Backlog. Durante el refinamiento del Product Backlog, los artículos son revisados y examinados. El Equipo Scrum decide cómo y cuándo se realiza el refinamiento.

El Refinamiento suele consumir no más del 10% de la capacidad del equipo de desarrollo. Sin embargo, los elementos del Product Backlog pueden ser actualizados en cualquier momento y a discreción del Product Owner.

Por lo general, los elementos ordenados en la parte alta del Product Backlog deben tener mayor claridad y por lo tanto mayor detalle. De la misma forma, las estimaciones son más precisas en la parte alta de la lista. Los elementos seleccionados por el Equipo Scrum para ser ejecutados, y  marcados como “Terminado”,  durante el siguiente Sprint, serán refinados para aportar la información necesaria para su correcta realización. Estos elementos, elegibles para su desarrollo durante el siguiente Sprint, serán etiquetados como “Listos” dentro del Product Backlog. Los elementos del Product Backlog suelen adquirir este grado de transparencia a través de las actividades de refinación descritos anteriormente.

El Equipo de Desarrollo es responsable de todas las estimaciones y aunque el Product Owner puede influir, ayudando en la comprensión y proponiendo intercambios en los compromisos, las personas que van a realizar el trabajo son las que realizan la estimación final.

Seguimiento del progreso hacia una Meta

En cualquier momento,  el trabajo total restante para alcanzar un objetivo puede ser cuantificado. El Product Owner monitorea este progreso por lo menos en cada Revisión de Sprint y lo compara contra el trabajo remanente de las Revisiones de Sprint anteriores para proyectar el progreso hacia completar la meta. Esta información se hace transparente hacia todos los Stakeholders.

Diversas prácticas proyectivas están siendo utilizadas para cuantificar el progreso, como burn-downs, burn-ups y flujos acumulativos y han demostrado cierta utilidad. Sin embargo, no reemplazan la importancia del proceso empírico; en entornos complejos, lo que sucederá es desconocido. Sólo lo que ha sucedido puede ser utilizado para la toma de decisiones con visión a futuro.

Sprint Backlog

El Sprint Backlog es el conjunto de elementos seleccionados del Product Backlog para el Sprint, además de un plan para la entrega del Incremento y el cumplimiento del objetivo del Sprint. El Sprint Backlog es una proyección realizada por el Equipo de Desarrollo sobre  la funcionalidad que  estará en el próximo Incremento y el trabajo necesario para convertir esa funcionalidad en un incremento  "Terminado".

El Sprint Backlog hace visible todo el trabajo que el equipo de desarrollo ha identificado como necesario para cumplir con el objetivo del Sprint.

El Sprint Backlog es un plan con suficiente detalle como para que los cambios en curso puedan ser  entendidos durante el Scrum Diario. El Equipo de Desarrollo modifica el Sprint Backlog durante todo el ciclo y, conforme avanza en el plan y entiende mejor el trabajo necesario para lograr el objetivo, el Sprint Backlog emerge y se concreta.

Conforme se identifican nuevas tareas, el Equipo de Desarrollo las añade al Sprint Backlog. Conforme se realizan o completan,  el tiempo para completar el trabajo se actualiza. Cuando se identifican tareas que ya no son necesarias, se eliminan. Sólo el Equipo de Desarrollo puede realizar cambios en el Sprint Backlog, el cual representa una imagen en tiempo real de lo que planea realizar durante el Sprint. Por lo tanto, este artefacto pertenece únicamente al Equipo de Desarrollo.

Seguimiento del progreso del Sprint

En cualquier momento,  el trabajo restante para completar el Sprint puede ser cuantificado. El Equipo de Desarrollo monitorea este progreso para asegurarse que, por lo menos, cada Scrum Diario refleje la probabilidad de alcanzar el objetivo del Sprint. Mediante el seguimiento de las tareas pendientes en el Sprint, el equipo de desarrollo puede administrar su progreso.

El Incremento

El Incremento es la suma de todos los elementos del Product Backlog completos durante un Sprint, más el valor de todos los Incrementos anteriores. Al final de un Sprint, el nuevo incremento debe poder marcarse como "Terminado", lo que significa que debe estar en condición de ser utilizable y cumplir con la definición del Equipo Scrum de "Terminado". El incremento debe estar en condición de ser utilizado, independientemente de que el Product Owner decida o no  liberarlo.

Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y el riesgo de control se realizan basándose en el estado percibido de los artefactos. En la medida en que la transparencia se hace realidad, estas decisiones tienen una base sólida. En el caso en que los Artefactos no cumplan con esta característica, las decisiones pueden llegar a ser erróneas, disminuir el valor y aumentar el riesgo.

El Scrum Master debe trabajar con el Product Owner, el Equipo de Desarrollo, y otras partes interesadas para asegurarse de que los Artefactos sean completamente transparentes. Existen prácticas para enfrentar la falta de transparencia y el Scrum Master debe dar el soporte necesario para aplicarlas cuando sea necesario. Un Scrum Master puede detectar la falta de transparencia mediante la inspección de los Artefactos, identificando patrones, escuchando atentamente lo que se dice, y detectando diferencias entre los resultados esperados y reales.

El trabajo del Scrum Master es trabajar con el Equipo Scrum y la organización para aumentar la transparencia de los artefactos. Este trabajo implica generalmente capacitación, negociación  y cambio. La transparencia no se logra de un día a otro, pero es el camino a seguir.

Definición de "Terminado"

Cuando un elemento del Product Backlog o un Incremento se describe como “Terminado”, todo el equipo tiene que entender lo que significa. Esta definición puede variar significativamente de un Scrum Team a otro, pero dentro del equipo y para garantizar la transparencia,  es indispensable que todos tengan el mismo entendimiento de lo que significa terminar una tarea. Esta es la definición de “Terminado” para el Equipo Scrum y se utiliza para evaluar cuando el trabajo ha sido completado en el Incremento del producto.

La misma definición guía al Equipo de Desarrollo en saber cuántos elementos del Product Backlog puede seleccionar durante la Planificación del Sprint. El propósito de cada Sprint es entregar incrementos de funcionalidad potencialmente liberable que se adhieren a la definición actual del Equipo Scrum de “Terminado”. Los Equipos de Desarrollo entregan un incremento de la funcionalidad del producto cada Sprint. Este incremento es utilizable, por lo que el Product Owner puede optar por liberar inmediatamente. Si la definición de “Terminado” para un incremento forma parte de las convenciones, normas o directrices de la empresa de desarrollo, todos los Equipos Scrum deben apegarse a esta definición. Si por el contrario esta definición no es parte de las convenciones, el Equipo de Desarrollo del Equipo Scrum debe describir una definición apropiada para el producto. Si varios Equipos Scrum van a trabajar en un mismo sistema o producto de liberación, los Equipos de Desarrollo en cada Equipos Scrum deben definir en conjunto el término “Terminado”.

Cada incremento se agrega a todos los incrementos anteriores y, por lo tanto, debe ser probado globalmente, asegurando que todos los incrementos trabajan correctamente en conjunto.

Conforme los Equipos Scrum maduran, se espera que sus definiciones de "Terminado" se amplíen para incluir criterios más estrictos, que aseguren la más alta calidad. 

 

En esta serie:

Fuente original en inglés: https://www.scrum.org