MANUAL DE
SCRUM
Métodos ágiles de programación
El presente documento muestra los elementos y artefactos necesarios para desarrollar un proyecto con la metodología ágil SCRUM2012
Tabla de contenido
HISTORIA DE SCRUM ... 3
ASPECTOS GENERALES DE LA PROGRAMACIÓN CON SCRUM. ... 3
ROLES Y RESPONSABILIDADES ... 4
LOS ELEMENTOS ... 5
HERRAMIENTAS ... 6
CONCEPTOS CLAVE ... 6
COMO LLEVAR A LA PRÁCTICA SCRUM. ... 9
LAS REUNIONES EN SCRUM ... 12
REUNIÓNDE PLANIFICACIÓNDEL SPRINT...12
REUNIÓNSEGUIMIENTODEL SPRINT...13
REUNIÓN REVISIÓNDEL SPRINT...14
CONCLUSIÓN. ... 16
Historia de SCRUM
Scrum es una metodología ágil para administrar proyectos de software, su origen data del año de 1986 y sus precursores son Hirotaka Takeuchi e Ikujiro Nonaka. La palabra Scrum proviene de un juego en equipo llamado “Rugby”. Se retoma de este juego ya que el objetivo que tiene esta metodología es el trabajo en equipo tal como en un juego de rugby se realiza el Scrum, este consiste en realizar una formación en conjunto de todo el equipo para unificar su fuerza y llevar el balón al otro lado del campo para realizar una anotación.
De esta manera se identifica la metodología ágil con esta formación, ya que el equipo de desarrollo deberá tener la convicción de trabajar en equipo unificando sus habilidades y conocimientos para realizar productos de software.
Scrum tiene los mismos principios que XP, la diferencia radica en los roles, responsabilidades y los elementos que se utilizan para realizar el proyecto.
Aspectos Generales de la Programación con SCRUM.
Esta metodología se considera ágil por que el desarrollo es de carácter adaptable, iterativo e incremental, está orientada a las personas antes que a los procesos y para llevar a cabo la administración de proyectos no se basa en el seguimiento de un plan, sino en la adaptación continua a las necesidades de la evolución del proyecto.
Para que esta metodología cumpla con su objetivo el cual es crear un producto de software que satisfaga las necesidades del cliente, se deben tomar en cuenta tres aspectos importantes los cuales son:
El producto El desarrollo del
producto El funcionamiento de Scrum
Es el software o sistema
que vamos a desarrollar. Define como y quien lo realizara. Se especifica el responsable de guiar el trabajo de Scrum
Dado esto en Scrum se definen varios roles que están divididos en dos grupos los cuales
son las personas que están comprometidos con el proyecto y el proceso de Scrum y las personas que no son parte del proceso pero que se requiere de su participación para
hacer posible el proyecto. A continuación te mostramos los nombres de los roles y responsabilidades en Scrum acorde a los grupos antes mencionados.
Roles y responsabilidades
Personas comprometidas con el proyecto y el proceso de Scrum
Product owner
(propietario del producto).
Es el representante del cliente y es el responsable de obtener el mejor resultado del producto de software, ya que él será quien acepte el trabajo realizado, regularmente esta persona forma parte de la empresa que solicita el sistema y es quien conoce a la perfección el negocio (para el cual se desarrollara el producto).
Scrum master
(Guia de Scrum)
Es la persona que conoce a detalle la metodología de Scrum, su papel es fundamental ya que es quien guiará al equipo de desarrollo eliminando los obstáculos que impiden los alcances de los objetivos planteados, cabe aclarar que su papel no es ser líder, solamente hará que las reglas y el proceso se cumplan.
(equipo) entregas del o los productos de software a desarrollar, este debe estar conformado por un grupo entre 5 y 9 personas, todas deben contar con los conocimientos de un analista, diseñador, programador y tester.
Personas que no son parte del proceso Scrum
Estas personas no son parte del proceso de la metodología pero deben tomarse en cuenta, ya que aportan información valiosa para el desarrollo del producto de software.
Usuarios
Son la personas que usaran el producto de software, ellos no tendránninguna responsabilidad, otro nombre que reciben es el de usuario final.
Stakeholder
s
(parte interesadas)
Se refiere a la gente interesada en el producto de software y que afectan o son afectados por el proyecto, estos pueden ser, proveedores, inversores, gerentes, patrocinadores. Estas personas tienen información valiosa para el desarrollo del sistema ya que son los que determinan necesidades y expectativas del producto.
Como observamos cada actor tendrá una tarea en específico que realizar en el proyecto, para ello se requiere que hagan uso de ciertos elementos, herramientas y conceptos clave que llevan por nombre ciertos tecnicismos propios de la metodología, por lo cual necesitamos familiarizarnos en ellos.
Los elementos
Product
Backlog
. Esto es un tecnicismo y lo podemos interpretar como ”Lista de productos a realizar”.Es un documento que se puede generar en Excel o en algún software especializado para llevar la metodología de Scrum en el cual se enlistan los requerimientos funcionales, mejoras, tecnologías y corrección de errores que deben desarrollarse o incorporarse al producto (software) a través de las sucesivas iteraciones de desarrollo. Los requerimientos pueden estar representados a través de historias de usuario, de esta forma el product backlog tendrá un condensado de las historias a desarrollar.
Representa todo aquello que esperan los clientes, usuarios y en general los interesados en el producto. Todo lo que suponga un trabajo por parte del equipo debe de estar reflejado en este documento.
A diferencia de un documento de requerimientos, este se puede modificar a lo largo del desarrollo ya que esta en continuo crecimiento y evolución hasta el término del mismo.
Sprint
Backlog.
Es la lista que divide las funcionalidades del product backlog en las tareas necesarias para construir un incremento en el sistema; es decir una parte completa y operativa del producto.
Sprint
Es la una unidad básica de desarrollo en Scrum. Un sprint es similar a una iteración, ya que su duración es entre una semana a un mes, es decir. Antes de comenzar cada Sprint debe estar precedida de una reunión de planificación donde serán identificadas cada una de las tareas que se llevarán durante el Sprint.Incremento
El incremento es la parte del producto desarrollada en un sprint, su característica principal es que debe de estar completamente terminada y operativa, en condiciones para ser entregada al usuario final; es decir, parte del software realizado en un sprint o iteración potencialmente entregable (terminada y probada).Herramientas
Gráfico
Burn-Up.
Es una grafica que muestra de forma visual la evolución del desarrollo del producto, esta ayuda a la planificación y seguimiento por parte del Product owner (propietario del producto).
Gráfico
Burn-Down
Es una herramienta de seguimiento para el equipo, que muestra el avance del sprint día a día y revela de forma temprana las posibles desviaciones.
Conceptos clave
El protocolo de Scrum para Software definido por Jeff Sutherland y Ken Schwaber establece los siguientes componentes y conceptos: 1
Conceptos Definición
Tiempo real o tiempo de trabajo
Tiempo efectivo para realizar un trabajo. Se suele medir en horas o días.
Tiempo teórico o
tiempo de tarea Tiempo que es necesario para realizar un trabajo en “condiciones ideales”. No toma en cuenta el tiempo en, llamadas telefónicas, descansos, reuniones, etc.
1 Juan Palacio, Flexibilidad con Scrum, primera edición digital Octubre 2007 http://www.lulu.com/content/1338172
Puntos de función o puntos de funcionalidad
Unidad de medida relativa para determinar la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario del Product Backlog.
Estimaciones Cálculo del esfuerzo que se prevé necesario para desarrollar una funcionalidad. Las estimaciones se pueden calcular en unidades relativas (puntos de función) o en unidades absolutas (tiempo teórico).
Velocidad
absoluta Cantidad de producto construido en un sprint. Se expresa en la misma unidad en la que se realizan las estimaciones (puntos de función, horas o días reales o teóricos).
Velocidad relativa
Cantidad de producto construido en una unidad de tiempo de trabajo. Por ejemplo; puntos de función/semana de trabajo real u horas teóricas/día de trabajo real.
Ahora que conocemos los elementos, herramientas y conceptos propios de Scrum podemos presentarte el ciclo de vida de un desarrollo con Scrum. En el siguiente diagrama podemos observar sus correspondientes etapas.
El desarrollo se inicia desde la visión general del producto (Product Backlog), dando detalles sólo a las funcionalidades (Sprint Backlog) que, por ser las de mayor prioridad para el negocio del cliente son las que se van a desarrollar en primer lugar y pueden llevarse a cabo en un periodo de tiempo breve entre 15 a 60 días recomendablemente.
Cada uno de los ciclos de desarrollo es una iteración (Sprint) que produce un incremento terminado y operativo del producto, estas iteraciones son la base del desarrollo ágil en Scrum.
Cuando trabajamos con Scrum, el seguimiento y la administración del proyecto se basa en la información que se obtiene de tres reuniones que forman parte de esta metodología, donde se trataran temas sobre la planificación, seguimiento y revisión del Sprint.
Reuniones
Reunión Previa al
Sprint
Reunión Diaria
Reunión al termino del
Sprint
Sprint.
Reunión previa al inicio de cada sprint donde tomando como base las prioridades y necesidades del producto se determina cuáles y cómo van a ser las funcionalidades que se deben cubrir con esa iteración, en esta se genera el Sprint Backlog.
Sprint.
Reunión diaria y breve, de no más de 15 minutos en la que todos los integrantes del equipo dicen las tareas en las que están trabajando, si se han encontrado o prevén encontrarse con algún impedimento, para poder actualizar sobre el Sprint Backlog las tareas realizadas o los tiempos de trabajo que les restan.
Esta reunión se realiza al final de sprint, con una duración máxima de cuatro horas; el equipo presenta al propietario del producto el incremento construido en el sprint.
Estas reuniones van a permitir revisar el trabajo realizado por el equipo ya que en la reunión diaria se comentará que se ha hecho durante el sprint de acuerdo a lo planeado en la reunión anterior y que planea realizar para el sprint del día presente.
Como llevar a la práctica Scrum.
A través del siguiente ejemplo, que trata de un proyecto para el desarrollo de un sistema de venta de seguros para autos, te mostramos la forma en la cual trabaja Scrum. En el proyecto se solicitaron las siguientes funcionalidades que debe cubrir el sistema:
Estas funcionalidades deben ser transformadas en historias de usuario las cuales contendrán todos los detalles para el desarrollo.
Para comenzar con el desarrollo del producto (sistema de software) se necesita tener una visión de los objetivos que se quieren conseguir con el producto, y es necesario que estos sean comprendidos por todo el equipo que desarrollará el proyecto, además de contar con los elementos suficientes en el mismo para poder llevar a cabo el primer sprint.
Para iniciar con el proyecto debemos construir el Product backlog, cabe mencionar que no es un documento de requerimientos, sino una herramienta de referencia para el equipo de
Permitir a los usuarios la consulta de los distintos tipos de seguros ofertados por la aseguradora. Permitir la cotización de un seguro mediante una interfaz web. Reducir el tiempo de instalación de un programa.
trabajo. Este elemento de tener un formato en el cual se incluya la siguiente la información para cada funcionalidad.
• Identificador único de la funcionalidad o trabajo.
• Descripción de la funcionalidad.
• Campo para indicar la prioridad de desarrollo.
• Estimación de esfuerzo para desarrollar cada funcionalidad.
Dependiendo el tipo de proyecto, funcionamiento del equipo y la organización, podemos utilizar los campos:
• Observaciones sobre la funcionalidad.
• Criterio de validación.
• Número de sprint en el que se realiza.
• Módulo del sistema al que pertenece.
A continuación te mostramos un Product backlog utilizado para nuestro ejemplo del sistema de venta de seguros.
NO. HISTOR
IA
FUNCIONALIDAD PRIORIDA
D ESTIMACIÓN OBSERVACIONES VALIDACIÓN SPRINNO. T MODULO 10 Permitir a los usuarios la consulta de los distintos tipos de seguros ofertados por la aseguradora. ALTA 6 Consultar cada uno de los seguros 1 Cotización y emisión 20 Permitir la cotización de un seguro mediante una interfaz web.
ALTA 10 Realizar cotizaciones con diferentes parámetros 1 Cotización y emisión 30 Reducir el tiempo de instalación de un programa. BAJA 20 Reinstalación
Posteriormente se crea el Sprint Backlog donde se especifican las tareas que se deben llevar acabo para desarrollar cada una de las funcionalidades identificadas en él, es importante señalar que “se asignan las personas a la tarea, ya que se podría asignar una o más personas a una sola tarea”. Además es una herramienta de soporte para la comunicación directa del equipo, esté puede tener tres tipos de forma de poderla presentar, dependiendo las necesidades de la empresa, estas son:
1. Hoja de Cálculo.
2. Pizarra o Pared Física.
3. Software especialmente diseñado para llevar la gestión de proyectos con Scrum.
Es importante saber que en el Sprint backlog se indica el tiempo de trabajo que se estima, o el que aún falta para terminar; es útil porque divide el proyecto en tareas de tamaño adecuado, cada tarea debe de estar en un rango de cuatro a dieciséis horas, esto se hace con el objetivo de determinar el avance diario e identificar riesgos y problemas sin la necesidad de procesos complejos.
Se realiza en forma conjunta por todos los miembros del equipo, cubriendo todas las tareas identificadas por los mismos para conseguir el objetivo del Sprint.
Siguiendo con el ejemplo del sistema para venta de seguros para autos te mostramos el Sprint backlog.
Sprint: 1
Inicio: 01/04/2009 Duración: 50
Backlog Tarea Tipo Estado Responsabl e Horas Trabaj o Observaciones 1 Comparació n de Arquitecturas
Análisis Terminada Jorge 16 1 Diagrama de
Procesos
Diseño En Curso Jorge 16 2 Revisión y
Análisis de Historias de Usuario
Análisis Terminada Ernesto 16
2 Mapa de
Navegación Diseño Terminada Ernesto 16 2 HTML y lenguajes script Codificació n Terminada Ignacio 16 2 Recorrer la funcionalidad del sistema
Pruebas Terminada Ernesto 8 3 Revisión y Análisis Terminada Alejandro 8
Análisis de Historias de Usuario 3 Diagrama Entidad Relación
Diseño En Curso Jorge 16 3 Estructura de Base de Datos en SQL Codificació n Pendiente Jorge 16 3 Carga de Catálogos y Datos de Prueba
Pruebas Pendiente Ignacio 16
Las reuniones en SCRUM
Ahora que tenemos estos dos elementos Product backlog y Sprint backlog, es necesario realizar la planificación del trabajo para nuestro proyecto, esto lo vamos hacer mediante las tres tipos de reuniones que previamente explicamos, la cuales se muestran en el siguiente diagrama.
Reunión de Planificación del Sprint.
- La primera reunión que puede tener una duración de una a cuatro horas en la que se decide que elementos del Product backlog se van a desarrollar.
- En la segunda reunión se desglosan cada uno de los elementos seleccionados para poder determinar las tareas necesarias a desarrollar, estimando el esfuerzo, para poder asignarlas a las personas que integran el equipo.
La planificación de un sprint no debe durar más de un día. Las características de esta reunión son:
Condiciones para realizar la reunión
- El área de sistemas u organización tienen determinados los recursos posibles para realizar el sprint.
- El propietario del producto tiene preparado el backlog delmismo.
- De ser posible el propietario del producto ya trabajó previamente con el equipo. - El equipo cuenta con un conocimiento de las tecnologías empleadas y del negocio
del producto, suficiente para comprender los conceptos del negocio y poder realizar estimaciones asertivas.
Elementos de entrada
- El Product Backlog.
- El producto desarrollado hasta la fecha de esta reunión a través de los sucesivos incrementos (exceptuando esto si se trata del primer sprint).
- Puntos sobre las condiciones de negocio del cliente. - Escenario tecnológico empleado.
Elementos de salida:
- Sprint Backlog
El responsable de la organización y gestión de esta reunión es el Scrum Manager, a la cual también deben de asistir el propietario del producto y el equipo de trabajo. En una metodología tradicional esta reunión se realiza cuando se levantan requerimientos con el cliente.
Reunión seguimiento del Sprint.
Uno por uno, los miembros del equipo exponen estas tres cuestiones: 1. Tarea en la que trabajaron ayer.
2. Tarea o tareas en las que trabajarán hoy.
su trabajo.
Las características de esta reunión son:
Condiciones para realizar la reunión
- Disponibilidad de un lugar físico en la organización para realizar la reunión.
- Sprint Backlog actualizado, recordemos que puede ser una hoja de cálculo, un dibujo sobre un pizarrón o el uso de tarjetas.
- Debe de asistir todo el equipo (SCRUM Manager, equipo de trabajo).
Elementos de entrada
- Sprint Backlog.
- Gráfico de Avance (Burn-down).
- Información de las tareas realizadas por cada uno de los elementos del equipo.
Elementos de salida:
- Sprint Backlog actualizado.
- Gráfico de Avance (Burn-down) actualizado.
Reunión Revisión del Sprint
El propietario del producto (Product owner) obtiene una revisión del progreso del sistema, conociendo el ritmo al que se va construyendo. Al ver el incremento en funcionamiento el propietario y el equipo en general obtienen una retroalimentación que les permitirá evolucionar y darle un valor real al Product Backlog. Las características de esta reunión son:
Condiciones para realizar la reunión
- El sprint debe de estar terminado en su totalidad.
- Asiste todo el equipo, es decir, todas las personas involucradas en el proyecto.
Elementos de entrada
Elementos de salida
- Retroalimentación para el propietario del producto, así como para el Scrum manager.
- Convocatoria para la reunión de planificación del siguiente Sprint.
Como podemos observar el equipo de desarrollo está totalmente comprometido con la entrega oportuna de los incrementos terminados.
Ahora veremos cómo se construyen las herramientas que nos auxilian en la gestión de proyectos con Scrum, las cuales se construyen a partir de la información del Product Backlog y del Sprint Backlog.
1. GRÁFICO BURN-UP
Es una grafica que muestra de forma visual la evolución del desarrollo del producto, esta ayuda a la planificación y seguimiento por parte del Product owner (propietario del producto). Se construye con:
- La estimación de esfuerzo prevista en el Product Backlog. - La velocidad del equipo (velocidad absoluta).
Este gráfico se construye con la información que se encuentra en el Product Backlog considerando lo siguiente:
El eje “Y” representa el esfuerzo, y sobre él se marcan los puntos de referencia de
versiones previstas en el backlog y el eje “X” representa el tiempo de desarrollo con las
fechas de los sprints previstos.
En el área del gráfico se proyecta la línea que representa la velocidad de desarrollo del
equipo. Este dato se obtiene sobre el histórico de velocidad desarrollada por el mismo equipo en proyectos o sprints anteriores.
Si no se tiene información histórica, un buen dato para comenzar es utilizar “tiempo real” como unidad para el esfuerzo y la velocidad (horas o días reales) y suponer como velocidad del equipo un tercio del tiempo disponible de trabajo
Ejemplo: Para un equipo de 4 personas y sprints de 20 días laborables, el tiempo disponible es de: 4 * 30 = 120 días disponibles. Velocidad previsible: 40 (120/3).
2. GRÁFICO BURN-DOWN
Se muestra a través de un gráfico cartesiano que representa en el eje “X” los días laborables del sprint y en el eje de las “Y” la cantidad de esfuerzo estimada, que como recordarás puede estar dada en horas o en días.
En la reunión diaria cada miembro del equipo actualiza el sprint con lo realizado en el día anterior y lo que tiene previsto realizar hoy, así como también si ya termino alguna de las tareas asignadas y actualiza el esfuerzo en las que todavía tiene pendientes.
De esta forma al final de la reunión la columna del día del sprint backlog muestra el esfuerzo que según el equipo falta para terminar el sprint, y el equipo marca en el gráfico el punto que tiene como ordenada ese valor, y como abscisa la fecha del día. El recorrido sobre la
diagonal es síntoma de problemas o sub-estimación del sprint backlog. El recorrido bajo la diagonal es síntoma de sobre-estimación del backlog.
Conclusión.
A través de esta unidad temática pudiste conocer los elementos de dos metodologías de desarrollo más populares en lo que respecta a la industria del software, te proporcionamos los artefactos para que puedas utilizarlos posteriormente en el desarrollo de proyectos, así mismo te dimos a conocer el nombre de rol que juegan las personas en ambas metodologías. Cómo pudiste apreciar estas metodologías se realizan en equipo en la que todos se encuentran involucrados y comprometidos, algo que no puedes dejar pasar desapercibido.
Bibliografía.
Juan Palacio, Flexibilidad con Scrum, primera edición digital Octubre 2007
http://www.lulu.com/content/1338172
