Los Elementos en SCRUM Tema 3
Rolando JaldĂn
Scrum maneja tres elementos fundamentales que hacen a la documentación guía del desarrollo del producto de software. Product Backlog. Es la lista de requisitos o necesidades del usuario, también denominada “Pila del producto”. Sprint Backlog. Es la lista de tareas que deben realizarse durante un sprint para obtener un incremento del producto. Incremento. Es una parte del producto, desarrollado durante un sprint, terminada y totalmente operativa.
El Product Backlog El product backlog es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. Todo lo que suponga un trabajo que debe realizar el equipo tiene que estar reflejado en el Product Backlog. A diferencia de un documento de requisitos del sistema, el product backlog nunca se da por completo; está en continuo crecimiento y evolución.
Formato del Product Backlog
PRODUCT BACKLOG PROYECTO: XXXXXXXXXXXX
ID
DESCRIPCIÓN
PRI.
EST. ESF.
SPRINT
PRUEBA
NOTAS
Construcción del Product Backlog 1. El Product Owner define su lista de requerimientos Primera parte
2. Se asigna un ID a cada requerimiento 3. Se define la prioridad de los requerimientos
4. Se ordena la lista según la prioridad de los requerimientos 5. Se hace la estimación de esfuerzo por requerimiento 6. Se definen las iteraciones 7. Se completan las pruebas de aceptación
Segunda parte
Sistema de atención de Servicios Mecánicos El taller de mecánica automotriz ZZ, para la atención a sus clientes requiere de un sistema de información que cumplan con los siguientes procesos. Cuando un cliente llega al taller, la movilidad es inspeccionada por el jefe técnico, el cual llena un formulario con las características técnicas del auto, los datos del propietario y las fallas detectadas en el vehículo, una copia del formulario se entrega a Recepción de Vehículos y el original al equipo de mantenimiento asignado. De acuerdo a la disponibilidad de tiempo el vehículo es asignado a uno de los 5 equipos que existen de mantenimiento, el responsable del equipo de mantenimiento traslada el vehículo al área correspondiente de trabajo. El equipo de mantenimiento procede al diagnóstico y reparación de la movilidad, en caso de que se detecte la necesidad de cambiar repuestos el responsable indica a Recepción las partes que son necesarias de cambiar. El responsable de Recepción comunica vía telefónica al propietario del vehículo las piezas que se requieren dando la opción también de que el taller incluya los repuestos como parte del trabajo. Si el propietario decide hacer la compra de los repuestos, estos una vez recibidos son entregados al equipo de mantenimiento. Si el propietario decide que el taller compre los repuestos entonces se envía a la compra de los repuestos y el costo de los mismos es incluido por el responsable de Recepción en un formulario de repuestos utilizados.
Continuación Una vez concluido el trabajo, el responsable del equipo de mantenimiento completa un formulario de trabajo realizado en el que registra: el trabajo de reparación realizado, los insumos y materiales empleados con sus respectivas cantidades y el tiempo empleado en el trabajo. Este formulario es entregado al Jefe técnico que completa los precios correspondientes de cada ítem del formulario de acuerdo a la tabla de precios de atención vigentes. Este formulario es entregado a Recepción quien completa los precios de mantenimiento con los costos de los repuestos utilizados, en caso de existir. El responsable de Recepción comunica al propietario que su movilidad esta lista y el costo del trabajo realizado. El propietario al momento de recoger su vehículo, cancela el monto total del trabajo recibiendo la factura con todo el detalle de sección Caja.
PRODUCT BACKLOG (inicial) Sistema de atención de Servicios Mecánicos Id. R1 R2
Requerimiento
R4
Actualizar datos de movilidad Actualizar datos de propietario cliente Recepcionar ingreso de movilidad al taller con orden de mantenimiento Asignar movilidad a equipo de mantenimiento
R5
Controlar carga de trabajo de los equipos de mantenimiento
T6 T7 T8
Registrar diagnóstico Registrar requerimiento de repuestos Emitir reporte de requerimiento de repuestos
T9
Actualizar trabajo de mantenimiento realizado en el vehículo
T10
Registrar insumos y materiales utilizados en mantenimiento del vehículo
R3
T11 R12 T13 R14 C15
Registrar tiempo empleado en el mantenimiento del vehĂculo Disponer de lista de insumos, materiales y tareas de mantenimiento con sus respectivos precios Registrar precios de insumos, materiales y trabajo en el mantenimiento del vehĂculo Actualizar los precios de repuestos usados en el mantenimiento si corresponde Registrar pago del servicio por parte del propietario
C17 R18
Emitir reporte detallado del mantenimiento realizado al vehĂculo para el propietario Emitir factura a propietario Registrar salida de movilidad del taller
R19
Emitir reportes de mantenimientos realizados para gerencia
R20
Emitir reportes de ingresos por mantenimientos realizados para gerencia
T21
Disponer de informaciĂłn de los equipos de mantenimiento
R16
PRODUCT BACKLOG (final) Id. R12 T21
Requerimiento Prioridad Est. Esf. Disponer de lista de insumos, materiales y tareas de mantenimiento con sus 1 5 respectivos precios Disponer de informaciรณn de los equipos 2 4 de mantenimiento
Sprint 1 1
R1
Actualizar datos de movilidad
3
4
1
R2
Actualizar datos de propietario cliente
4
4
1
5
4
1
6
3
1
7
2
1
R3 R5 R4
Recepcionar ingreso de movilidad al taller con orden de mantenimiento Controlar carga de trabajo de los equipos de mantenimiento Asignar movilidad a equipo de mantenimiento
Prueba Ingresar lista actual de precios del taller
Nota Ver kardex de precios del taller
Registrar datos del personal de cada equipo Ingresar formulario de servicios anteriores Ingresar formulario de servicios anteriores Verificar con formularios de servicios anteriores Simular la asignaciรณn de trabajos a los equipos
Kardex de servicios efectuados, por gestiones
El SPRINT BACKLOG
El sprint backlog o Iteración, es la lista que descompone las funcionalidades del product backlog en las tareas necesarias para construir un incremento: una parte completa y operativa del producto. En el Sprint Backlog para cada requerimiento se definen las tareas para llevarla a cabo, estimando el tiempo de trabajo requerido y los responsables de su implementación. Participan el Team y el Scrum Master. Realizado de forma conjunta por todos los miembros del equipo. Sólo el equipo lo puede modificar durante el sprint. El tamaño de cada tarea está en un rango de 4 a 16 horas de trabajo. Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo espacio físico donde trabaja el equipo.
Formato del Sprint Backlog
Sprint # - <descripciรณn del sprint>
ID Hist.
Requerimiento / Tareas
Responsable
Estado
Estim. S
Ejercicio Sprint Backlog Sprint 1 : Parametrización y Recepción Id. R12
T21
R1
Responsable
Est. Esf. Horas
A A A A A
10 8 6 6 8
B
8
Actualizar datos del personal por equipo
B
10
Especificar Jefe de mantenimiento Actualizar datos de movilidad Ingresar nueva movilidad Editar datos de movilidad Dar de baja / eliminar movilidad Buscador de movilidad por placa, chasis, motor, etc.
B
6
C C C
10 6 6
C
8
Requerimiento / Tarea Disponer de lista de insumos, materiales y tareas de mantenimiento con sus respectivos precios Actualizar categoría de ítems Registrar nuevo ítem en categoría Editar ítem Dar de baja ítem Actualizar precios a ítems Disponer de información de los equipos de mantenimiento Registrar nuevo equipo de trabajo
La Estimación de Esfuerzo Una de las principales dificultades en Scrum es la estimación del esfuerzo de trabajo o esfuerzo de desarrollo, tanto para el Product Backlog, así como de las tareas en el Sprint Backlog. La estimación de esfuerzo debe traducirse necesariamente en días, ya que eso nos permitirá determinar el inicio y final de un sprint y por lo tanto decir al cliente hasta cuándo tendremos un resultado que entregar. Se han ideado muchas propuestas de las cuales hacemos referencia a las tres más usadas: 1. 2. 3.
Estimación basada en la experiencia Estimación por puntos de función Estimación poker
Estimación basada en la Experiencia de Expertos
Estimación basada en puntos de función
Estimación Poker
Experiencia en proyectos similares Se toma en cuenta la plataforma de desarrollo Un Punto es una unidad de medida relativa para determinar la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario. En equivalencia un punto puede ser 4 o 5 horas, es algo que define la organización. Se toma muy en cuenta el número de miembros del equipo de desarrollo.
Las Historias de Usuario Son las descripciones de las funcionalidades que deberá tener el software, representan los requisitos del usuario, son descripciones breves pero claras sobre lo que se quiere. Son elaboradas por los usuarios. Las Historias de Usuario se constituyen en la documentación base que sustenta a Scrum, son una constancia de lo que requiere el usuario y en un compromiso de lo que debe hacer el desarrollador. La elaboración y aprobación de las Historias de Usuario tiene tres pasos llamado “Las 3 C”: Card. En una tarjeta el usuario hace una breve descripción de la funcionalidad o requerimiento. Conversation. El equipo recibe la explicación y aclaración de lo que se quiere del usuario. Confirmation. Test funcionales para fijar detalles que sean relevantes e indicar cuál va a ser el límite.
Características de las Historias de Usuario Independientes unas de otra. Una historia no debe contener varios requerimientos. Negociable. La historia no es suficiente para su desarrollo, la participación del usuario es fundamental y su aprobación final debe señalarse en los criterios de prueba o validación. Valoradas por el usuario. La historia debe tener valor significativo sobre lo que requiere para el usuario más que para el desarrollador. Estimables. Las historias deben permitir estimar su tiempo de desarrollo, lo que permite calcular el tiempo total del proyecto. Pequeñas. Conviene definir historias cortas con funcionalidades específicas. Verificables. Las historias deben permitir verificar la funcionalidad requerida y posteriormente verificar el cumplimiento de la implementación realizada.
Formato de la Historia de Usuario
Las Historias Técnicas El desarrollo de un Sprint y la especificación de tareas no solo comprenden la realización de funcionalidades o requerimiento de los usuarios, sino también es necesario cumplir con ciertas tareas denominadas Técnicas o no-funcionales. Estas tareas técnicas también las realiza el equipo de desarrollo. Entre estas tareas podemos señalar: la instalación y mantenimiento de la plataforma de desarrollo, la configuración y soporte de los servicios de red, la atención a los servidores, la administración de la base de datos, los servicios y conectividad de internet, etc. Las historias técnicas también son parte del Sprint con exactamente el mismo formato y también se contemplan en la estimación del tiempo total del Sprint.