Página
Tema 3.1 - Elementos de SCRUM
Los elementos que forman a Scrum son:
- Product Backlog: lista de necesidades del cliente.
- Sprint Backlog: lista de tareas que se realizan en un sprint.
- Incremento: parte añadida o desarrollada en un sprint, es un parte terminada y totalmente operativa
Product Backlog.
Es el inventario en el que se almacenan todas las funcionalidades o requisitos en forma de lista priorizada. Estos requisitos serán los que tendrá el producto o los que irá adquiriendo en sucesivas iteraciones.
La lista será gestionada y creada por el cliente con la ayuda del Scrum Master, quien indicará el costo estimado para completar un requisito, y además contendrá todo lo que aporte un valor final al producto.
Las tres características principales de esta lista de objetivos serán:
- Contener los objetivos del producto para expresarlos de una manera organizada en las HU
- En cada objetivo, se indicará el valor que le da el cliente y el costo estimado, de esta manera, se realiza la lista, priorizando por valor y costo.
- En la
lista se tendrán que indicar las posibles iteraciones y los releases que se han
indicado al cliente.
- La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para solventarlos.
Es necesario que antes de empezar el primer sprint se definan cuáles van a ser los objetivos del producto y tener la lista de los requisitos ya definida. No es necesario que sea muy detallada, simplemente deberá contener los requisitos principales para que el equipo pueda trabajar. Realizar este orden de tareas tiene como beneficios:
- El proyecto no se paraliza simplemente por no tener claro los requisitos menos relevantes, y el cliente podrá ver resultados de forma más rápida.
- Los requisitos secundarios aparecerán a medida que se va desarrollando el proyecto, por lo tanto, no se pierde tanto tiempo en analizarlos al principio y el cliente será más consciente de sus necesidades.
- Los requisitos secundarios puede que no se lleguen a necesitar porque se han sustituido o porque no reportan un retorno ROI (retorno de la inversión) interesante.
Una
vez definidos los requisitos se tendrá que acordar cuándo se tiene que entender
un objetivo como terminado o completado.
Se entiende que un producto está completado si:
- Asegura que se puede realizar un entregable para realizar una demostración de los requisitos y ver qué se han cumplido.
- Incluirá todo lo necesario para indicar que se está realizando el producto que el cliente desea.
Como
complemento a la definición de completado, se debería de asociar una condición
de aceptación o no aceptación a cada objetivo en el mismo momento en el que se
crea la lista.
Como complemento a la definición de completado, se debería de asociar una condición de aceptación o no aceptación a cada objetivo en el mismo momento en el que se crea la lista.
Finalmente el Product Backlog irá evolucionando mientras el producto exista en el mercado. Esta es la forma para evolucionar y tener un valor de producto para el cliente suficiente para ser competitivo.
Las historias de Usuario.
Son las descripciones de las funcionalidades que va a tener el software.
Estas historias de usuario, serán el resultado de la colaboración entre el cliente y el equipo, e irán evolucionando durante toda la vida del proyecto.
Las historias de usuario se componen de tres fases denominadas “Las 3 C”:
- Card: Será una breve descripción escrita que servirá como recordatorio.
- Conversation: Es una conversación que servirá para asegurarse de que se ha entendido bien todo, y concretar el objetivo.
- Confirmation: Tests funcionales para fijar detalles que sean relevantes e indicar cuál va a ser el límite.
En
cuanto al formato, un modelo podría ser como el que se muestra en la siguiente
imagen
- ID: Identificador de la historia de usuario.
- TÍTULO: Título descriptivo de la historia de usuario
- DESCRIPCIÓN: Descripción sintetizada de la historia de usuario.
- ESTIMACIÓN: Evaluación del coste de implementación en unidades de desarrollo. Estas unidades representarán el tiempo teórico (desarrollo/hombre) que se haya estimado al comienzo del proyecto.
- PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:
- M – Must, se debe completar este requerimiento para finalizar el proyecto.
- S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.
- C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.
- W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)
Figura: Ejemplo de Historia de usuario (fuente: http://devnettips.blogspot.com.es/)
DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea.
Las historias de usuario del Product Backlog deben estar
suficientemente segmentadas a un nivel que le brinde al Equipo Scrum la información
adecuada para crear entregables a partir de las tareas mencionadas en el Sprint
Backlog
Formato de la Pila Del Producto (Product Backlog).
En scrum, la preferencia por tener documentación en todo momento es menos estricta. Se encuentra más necesario el mantener una comunicación directa con el equipo, por eso se usa como herramienta el backlog.
Aunque no hay ningún producto especial a la hora de confeccionar la lista, es conveniente que incluya información relativa a:
- Identificador para la funcionalidad.
- Descripción de la funcionalidad.
- Sistema de priorización u orden.
- Estimación.
Figura: Ejemplo de un Product Backlog(Fuente: Scrum Manager. Gestión de Proyectos)
Sprint Backlog.
Es la lista de tareas que elabora el equipo durante la planificación de un sprint. Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.
De esta manera el proyecto se descompone en unidades más pequeñas y se puede determinar o ver en qué tareas no se está avanzando e intentar eliminar el problema.El Sprint Backlog contiene el conjunto de elementos del Product Backlog seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.
Figura.- Ejemplo de Sprint Backlog.
Cómo funciona la lista:
- Es una lista ordenada por prioridades para el cliente.
- Puede haber dependencias entre una tarea y otra, por lo tanto, se tendrá que diferenciar de alguna manera.
- Todas las tareas tienen que tener un coste semejante que será entre 4-16 horas.
Formato de la lista:
Hay 3 opciones:
- Hojas de cálculo.
- Pizarras.
- Herramientas colaborativas.
Generalmente,
las tareas a completar se suelen gestionar mediante el scrum taskboard, a cada
objetivo se le asignan las tareas necesarias para llevarlo a cabo, se usan
post-its que se van moviendo de una columna a otra para cambiar el estado.
Se debe incluir:
- Lista de tareas.
- Persona responsable de cada tarea, el estado en que se encuentra y el tiempo que falta en terminarla.
- Permite la consulta diaria del equipo.
- Permite tener una referencia diaria del tiempo que le queda a cada tarea.
Incremento
- Un Incremento es un peldaño concreto hacia el Objetivo del Producto.
- Cada Incremento se suma a todos los Incrementos anteriores y se verifica minuciosamente, lo que garantiza que todos los Incrementos funcionen juntos.
- Para proporcionar valor, el Incremento debe ser utilizable.
- Se pueden crear múltiples Incrementos dentro de un Sprint.
- La suma de los Incrementos se presenta en la Sprint Review apoyando así el empirismo.
- Se puede entregar un Incremento a los interesados antes del final del Sprint.
- La Sprint Review nunca debe considerarse una puerta para liberar valor.
- El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de Terminado
Compromiso: Definición de Terminado
- La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.
- Incremento
- Un incremento nace en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado.
- La Definición de Terminado crea transparencia. (Brinda entendimiento de qué trabajo se terminó).
- No se publican ni presentan en el Sprint Review elementos del Product Backlog que no cumplen con la Definición de Terminado.
- Los elementos del Product Backlog que no cumplen con la definición de terminado vuelven al Product Backlog para ser considerados en el futuro.
- La Definición de Terminado para un Incremento, puede ser parte de los estándares de la organización.
- Si no es un estándar organizacional, el Scrum Team debe crear una Definición de Terminado apropiada para el producto.
- Todos los Scrum Teams deben seguir la Definición de Terminado.
- Los Developers deben adherirse a la Definición de Terminado.
- Si hay varios Scrum Teams trabajando juntos en un producto, deben definir y cumplir mutuamente la misma Definición de Terminado
Eventos Scrum
Los eventos o reuniones del marco de scrum técnico son:
Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el pulso de avance por tiempos prefijados (time boxing).
El propósito de cada Sprint es entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción, por lo que no siempre se libera a producción o se envía a los clientes al final de cada Sprint. El incremento debe estar en condiciones
de utilizarse sin importar si el product owrner decide liberarlo o no. Los Equipos de Desarrollo entregan un Incremento de funcionalidad de producto en cada Sprint. Este Incremento es utilizable, de modo que el Dueño de Producto podría elegir liberarlo
inmediatamente.
Reunión de Planificación del sprint: reunión de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el objetivo del sprint y las tareas necesarias para conseguirlo.
Scrum diario (Daily): breve reunión diaria del equipo.
Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la pila del producto si resulta necesario. Una cuarta reunión se incorporó al marco estándar de scrum en la primera década de 2.000:
Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint.
Todos los eventos de Scrum son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Scrum trata al tiempo como uno de los limitantes más importantes en la gestión de un proyecto. Para hacer frente a la restricción del tiempo,
Scrum introduce un concepto de Time-boxing (o asignación de un bloque máximo de tiempo), que propone la fijación de una cierta cantidad máxima de tiempo para cada evento en un proyecto Scrum. Esto garantiza que los miembros del Equipo Scrum no ocupen
demasiado o muy poco tiempo para un trabajo determinado, y que no desperdicien su tiempo y energía en un trabajo para el cual tienen poca claridad.
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación a través de los eventos de Scrum, incluyendo: los Scrums Diarios (Daily Scrums), la Revisión del Sprint (Sprint Review),
y la Retrospectiva del Sprint (Sprint Retrospective).
Última modificación: miércoles, 6 de abril de 2022, 09:10