2012

MANUAL DE SCRUM
Mtodos giles de programacin
El presente documento muestra los elementos y artefactos necesarios para desarrollar un proyecto con la metodologa gil SCRUM

Prof. Sergio Ernesto Moreno Soto CECyT 9 Juan de Dios Btiz 01/05/2012

Tabla de contenido
HISTORIA DE SCRUM...................................................................................................3 ASPECTOS GENERALES DE LA PROGRAMACIN CON SCRUM...........................................3 ROLES Y RESPONSABILIDADES.....................................................................................4 LOS ELEMENTOS.........................................................................................................5 HERRAMIENTAS..........................................................................................................6 CONCEPTOS CLAVE.....................................................................................................6 COMO LLEVAR A LA PRCTICA SCRUM..........................................................................9 LAS REUNIONES EN SCRUM........................................................................................12 REUNIN DE PLANIFICACIN DEL SPRINT.........................................................................................................12 REUNIN SEGUIMIENTO DEL SPRINT...............................................................................................................13 REUNIN REVISIN DEL SPRINT....................................................................................................................14 CONCLUSIN............................................................................................................16 BIBLIOGRAFA...........................................................................................................17

Historia de SCRUM
Scrum es una metodologa gil para administrar proyectos de software, su origen data del ao 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 metodologa es el trabajo en equipo tal como en un juego de rugby se realiza el Scrum, este consiste en realizar una formacin en conjunto de todo el equipo para unificar su fuerza y llevar el baln al otro lado del campo para realizar una anotacin.

De esta manera se identifica la metodologa gil con esta formacin, ya que el equipo de desarrollo deber tener la conviccin 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 Programacin con SCRUM.

Esta metodologa se considera gil por que el desarrollo es de carcter adaptable, iterativo e incremental, est orientada a las personas antes que a los procesos y para llevar a cabo la administracin de proyectos no se basa en el seguimiento de un plan, sino en la adaptacin continua a las necesidades de la evolucin del proyecto. Para que esta metodologa 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 estn divididos en dos grupos los cuales son las personas que estn comprometidos con el proyecto y el proceso de Scrum y las personas que no son parte del proceso pero que se requiere de su participacin para hacer posible el proyecto. A continuacin 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 perfeccin el negocio (para el cual se desarrollara el producto). Es la persona que conoce a detalle la metodologa de Scrum, su papel es fundamental ya que es quien guiar al equipo de desarrollo eliminando los obstculos que impiden los alcances de los objetivos planteados, cabe aclarar que su papel no es ser lder, solamente har que las reglas y el proceso se cumplan. El equipo de desarrollo tiene la responsabilidad de realizar las 1

Scrum master
(Guia de Scrum)

Scrum team

(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, diseador, programador y tester.

Personas que no son parte del proceso Scrum Estas personas no son parte del proceso de la metodologa pero deben tomarse en cuenta, ya que aportan informacin valiosa para el desarrollo del producto de software.

Usuarios Stakeholder s
(parte interesadas)

Son la personas que usaran el producto de software, ellos no tendrn ninguna responsabilidad, otro nombre que reciben es el de usuario final. 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 informacin 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 especfico 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 metodologa, 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 algn software especializado para llevar la metodologa de Scrum en el cual se enlistan los requerimientos funcionales, mejoras, tecnologas y correccin de errores que deben desarrollarse o incorporarse al producto (software) a travs de las sucesivas iteraciones de desarrollo. Los requerimientos pueden estar representados a travs 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 evolucin hasta el trmino del mismo.

Sprint Backlog. Sprint

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. Es la una unidad bsica de desarrollo en Scrum. Un sprint es similar a una iteracin, ya que su duracin es entre una semana a un mes, es decir. Antes de comenzar cada Sprint debe estar precedida de una reunin de planificacin donde sern identificadas cada una de las tareas que se llevarn durante el Sprint. El incremento es la parte del producto desarrollada en un sprint, su caracterstica 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 iteracin potencialmente entregable (terminada y probada).

Incremento

Herramientas
Grfico Burn- Es una grafica que muestra de forma visual la evolucin del desarrollo del producto, esta ayuda a la planificacin y seguimiento Up.
por parte del Product owner (propietario del producto).

Grfico Burn- Es una herramienta de seguimiento para el equipo, que muestra el avance del sprint da a da y revela de forma temprana las posibles Down
desviaciones.

Conceptos clave
El protocolo de Scrum para Software definido por Jeff Sutherland y Ken Schwaber establece los siguientes componentes y conceptos: 1 Conceptos Definicin Tiempo real o Tiempo efectivo para realizar un trabajo. Se suele medir en horas o tiempo de trabajo das. Tiempo terico o tiempo de tarea Tiempo que es necesario para realizar un trabajo en condiciones ideales. No toma en cuenta el tiempo en, llamadas telefnicas, descansos, reuniones, etc.

Juan Palacio, Flexibilidad con Scrum, primera edicin digital Octubre 2007 http://www.lulu.com/content/1338172 Pginas 130- 146

Puntos de funcin o puntos de funcionalidad Estimaciones

Unidad de medida relativa para determinar la cantidad de trabajo necesaria para construir una funcionalidad o historia de usuario del Product Backlog. Clculo del esfuerzo que se prev necesario para desarrollar una funcionalidad. Las estimaciones se pueden calcular en unidades relativas (puntos de funcin) o en unidades absolutas (tiempo terico). Cantidad de producto construido en un sprint. Se expresa en la misma unidad en la que se realizan las estimaciones (puntos de funcin, horas o das reales o tericos). Cantidad de producto construido en una unidad de tiempo de trabajo. Por ejemplo; puntos de funcin/semana de trabajo real u horas tericas/da de trabajo real.

Velocidad absoluta Velocidad relativa

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 visin general del producto (Product Backlog), dando detalles slo 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 das recomendablemente. Cada uno de los ciclos de desarrollo es una iteracin (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 administracin del proyecto se basa en la informacin que se obtiene de tres reuniones que forman parte de esta metodologa, donde se trataran temas sobre la planificacin, seguimiento y revisin del Sprint.

Reunin Previa al Sprint

Objetivo: Planificacin del

Reuniones Reunin Diaria

Objetivo: Seguimiento del

Reunin al termino del Sprint

Objetivo: Revisin del Sprint. 1

Sprint. Reunin previa al inicio de cada sprint donde tomando como base las prioridades y necesidades del producto se determina cules y cmo van a ser las funcionalidades que se deben cubrir con esa iteracin, en esta se genera el Sprint Backlog.

Sprint. Reunin diaria y breve, de no ms de 15 minutos en la que todos los integrantes del equipo dicen las tareas en las que estn trabajando, si se han encontrado o prevn encontrarse con algn impedimento, para poder actualizar sobre el Sprint Backlog las tareas realizadas o los tiempos de trabajo que les restan. Esta reunin se realiza al final de sprint, con una duracin mxima 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 reunin diaria se comentar que se ha hecho durante el sprint de acuerdo a lo planeado en la reunin anterior y que planea realizar para el sprint del da presente.

Como llevar a la prctica Scrum.

A travs 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:

Permitir a los usuarios la consulta de los distintos tipos de seguros ofertados por la aseguradora.

Permitir la cotizacin de un seguro mediante una interfaz web.

Reducir el tiempo de instalacin de un programa.

Estas funcionalidades deben ser transformadas en historias de usuario las cuales contendrn todos los detalles para el desarrollo. Para comenzar con el desarrollo del producto (sistema de software) se necesita tener una visin 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, adems 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 1

trabajo. Este elemento de tener un formato en el cual se incluya la siguiente la informacin para cada funcionalidad. Identificador nico de la funcionalidad o trabajo. Descripcin de la funcionalidad. Campo para indicar la prioridad de desarrollo. Estimacin de esfuerzo para desarrollar cada funcionalidad.

Dependiendo el tipo de proyecto, funcionamiento del equipo y la organizacin, podemos utilizar los campos: Observaciones sobre la funcionalidad. Criterio de validacin. Nmero de sprint en el que se realiza. Mdulo del sistema al que pertenece.

A continuacin te mostramos un Product backlog utilizado para nuestro ejemplo del sistema de venta de seguros.
NO. HISTOR IA FUNCIONALIDAD PRIORIDA D ESTIMA CIN OBSERVA CIONES VALIDACIN NO. SPRIN T MODULO

10

Permitir a los usuarios la consulta de los distintos tipos de seguros ofertados por la aseguradora. Permitir la cotizacin de un seguro mediante una interfaz web. Reducir el tiempo de instalacin de un programa.

6 ALTA

Consultar cada uno de los seguros

Cotizacin y emisin

10 ALTA

20

Realizar cotizaciones con diferentes parmetros Reinstalacin del programa

Cotizacin y emisin

20 BAJA

Cotizacin y emisin

30

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 sealar que se asignan las personas a la tarea, ya que se podra asignar una o ms personas a una sola tarea. Adems es una herramienta de soporte para la comunicacin directa del equipo, est puede tener tres tipos de forma de poderla presentar, dependiendo las necesidades de la empresa, estas son: 1. Hoja de Clculo. 2. Pizarra o Pared Fsica. 3. Software especialmente diseado para llevar la gestin de proyectos con Scrum. Es importante saber que en el Sprint backlog se indica el tiempo de trabajo que se estima, o el que an falta para terminar; es til porque divide el proyecto en tareas de tamao adecuado, cada tarea debe de estar en un rango de cuatro a diecisis 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 Duracin: 50 Backlog Tarea 1 1 2 Comparaci n de Arquitecturas Diagrama de Procesos Revisin y Anlisis de Historias de Usuario Mapa de Navegacin HTML y lenguajes script Recorrer la funcionalidad del sistema Revisin y Tipo Anlisis Diseo Anlisis Estado Responsabl e Horas Trabaj o 16 16 16 Observaciones

Terminada Jorge En Curso Jorge

Terminada Ernesto

2 2 2 3

Diseo Codificaci n Pruebas Anlisis

Terminada Ernesto Terminada Ignacio Terminada Ernesto Terminada Alejandro

16 16 8 8 1

3 3

Anlisis de Historias de Usuario Diagrama Entidad Relacin Estructura de Base de Datos en SQL Carga de Catlogos y Datos de Prueba

Diseo Codificaci n Pruebas

En Curso Pendiente

Jorge Jorge

16 16

Pendiente

Ignacio

16

Las reuniones en SCRUM

Ahora que tenemos estos dos elementos Product backlog y Sprint backlog, es necesario realizar la planificacin 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.

Reunin de Planificacin del Sprint.

Esta reunin en realidad se divide en dos: 1

La primera reunin que puede tener una duracin de una a cuatro horas en la que se decide que elementos del Product backlog se van a desarrollar. En la segunda reunin 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 planificacin de un sprint no debe durar ms de un da. Las caractersticas de esta reunin son: Condiciones para realizar la reunin El rea de sistemas u organizacin tienen determinados los recursos posibles para realizar el sprint. El propietario del producto tiene preparado el backlog del mismo. De ser posible el propietario del producto ya trabaj previamente con el equipo. El equipo cuenta con un conocimiento de las tecnologas 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 reunin a travs de los sucesivos incrementos (exceptuando esto si se trata del primer sprint). Puntos sobre las condiciones de negocio del cliente. Escenario tecnolgico empleado.

Elementos de salida: Sprint Backlog

El responsable de la organizacin y gestin de esta reunin es el Scrum Manager, a la cual tambin deben de asistir el propietario del producto y el equipo de trabajo. En una metodologa tradicional esta reunin se realiza cuando se levantan requerimientos con el cliente.

Reunin 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 trabajarn hoy. 3. Si van a necesitar alguna cosa especial o prevn algn impedimento para realizar 1

su trabajo. Las caractersticas de esta reunin son: Condiciones para realizar la reunin Disponibilidad de un lugar fsico en la organizacin para realizar la reunin. Sprint Backlog actualizado, recordemos que puede ser una hoja de clculo, un dibujo sobre un pizarrn o el uso de tarjetas. Debe de asistir todo el equipo (SCRUM Manager, equipo de trabajo).

Elementos de entrada Sprint Backlog. Grfico de Avance (Burn-down). Informacin de las tareas realizadas por cada uno de los elementos del equipo.

Elementos de salida: Sprint Backlog actualizado. Grfico de Avance (Burn-down) actualizado.

Reunin Revisin del Sprint

El propietario del producto (Product owner) obtiene una revisin 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 retroalimentacin que les permitir evolucionar y darle un valor real al Product Backlog. Las caractersticas de esta reunin son: Condiciones para realizar la reunin 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 Incremento Terminado

Elementos de salida Retroalimentacin para el propietario del producto, as como para el Scrum manager. Convocatoria para la reunin de planificacin del siguiente Sprint.

Como podemos observar el equipo de desarrollo est totalmente comprometido con la entrega oportuna de los incrementos terminados. Ahora veremos cmo se construyen las herramientas que nos auxilian en la gestin de proyectos con Scrum, las cuales se construyen a partir de la informacin del Product Backlog y del Sprint Backlog. 1. GRFICO BURN-UP Es una grafica que muestra de forma visual la evolucin del desarrollo del producto, esta ayuda a la planificacin y seguimiento por parte del Product owner (propietario del producto). Se construye con: La estimacin de esfuerzo prevista en el Product Backlog. La velocidad del equipo (velocidad absoluta).

Este grfico se construye con la informacin 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 grfico se proyecta la lnea que representa la velocidad de desarrollo del equipo. Este dato se obtiene sobre el histrico de velocidad desarrollada por el mismo equipo en proyectos o sprints anteriores.

Si no se tiene informacin histrica, un buen dato para comenzar es utilizar tiempo real como unidad para el esfuerzo y la velocidad (horas o das 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 das laborables, el tiempo disponible es de: 4 * 30 = 120 das disponibles. Velocidad previsible: 40 (120/3). 2. GRFICO BURN-DOWN Se muestra a travs de un grfico cartesiano que representa en el eje X los das laborables del sprint y en el eje de las Y la cantidad de esfuerzo estimada, que como recordars puede estar dada en horas o en das. En la reunin diaria cada miembro del equipo actualiza el sprint con lo realizado en el da anterior y lo que tiene previsto realizar hoy, as como tambin si ya termino alguna de las tareas asignadas y actualiza el esfuerzo en las que todava tiene pendientes.

De esta forma al final de la reunin la columna del da del sprint backlog muestra el esfuerzo que segn el equipo falta para terminar el sprint, y el equipo marca en el grfico el punto que tiene como ordenada ese valor, y como abscisa la fecha del da. El recorrido sobre la diagonal es sntoma de problemas o sub-estimacin del sprint backlog. El recorrido bajo la diagonal es sntoma de sobre-estimacin del backlog.

Conclusin.
A travs de esta unidad temtica pudiste conocer los elementos de dos metodologas de desarrollo ms 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 metodologas. Cmo pudiste apreciar estas metodologas se realizan en equipo en la que todos se encuentran involucrados y comprometidos, algo que no puedes dejar pasar desapercibido.

Bibliografa.
Juan Palacio, Flexibilidad con Scrum, primera edicin digital Octubre 2007 http://www.lulu.com/content/1338172 Consultado 19 de abril de 2011