2012
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 SCRUM
Prof. Sergio Ernesto Moreno Soto CECyT 9 “Juan de Dios Bátiz” 01/05/2012
Tabla de contenido
HISTORIA DE SCRUM...... ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ........... ........ ....... ........ ........ ......3 ASPECTOS GENERALES GENERALES DE LA PROGRAMACIÓN CON SCRUM....... ............ ........... ......... ........ ........ ........ ........ ........ ......3 ROLES Y RESPONSABILID RESPONSABILIDADES ADES...... ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ........... ......... ........ .... 4 LOS ELEM ELEMENT ENTOS OS.............................................................................................. ...................................................................................................... ........... ... 5 HERRAMIE HERR AMIENT NTAS AS............................................................................................... ....................................................................................... ................ ........... ...6 CONCEPTO CONC EPTOS S CLA CLAVE VE............................................................................ .................................................................................... ................ ................ ..........6 COMO LLEV LLEVAR AR A LA PRÁCTICA PRÁCTICA SCRUM....... ............ ............ ............ ............ ............ ........... ........ ....... ........ ....... ....... ........ ........ ........ ...... ..9 LAS REUNIONES EN SCRUM...... ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ .......... ........ ...... ..12 REUNIÓN DE PLANIFICACIÓN DEL SPRINT.........................................................................................................12 REUNIÓN SEGUIMIENTO DEL SPRINT...............................................................................................................13 REUNIÓN REVISIÓN DEL SPRINT........................................................................ .............................................................................................................. ............................................14 ......14
CONCLU CONC LUSIÓN. SIÓN........................................................................................................ .............................................................................................. ............. ....16 BIBLIOGRAFÍA. BIBLIOGRAFÍ A....... ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ ............ .......... .... 17
1
Historia de SCRUM Scrum es una metodología metodología ágil para administrar administrar proyectos de software, software, su origen data del año de 1986 y sus precursores son Hirotaka Takeuchi 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 desarrollo es de carácter adaptable, 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 satis satisfa faga ga las nece necesid sidad ades es del del clien cliente, te, se debe deben n tomar tomar en cuen cuenta ta tres tres aspe aspecto ctos s importantes los cuales son:
1
El producto
Es el software o sistema que vamos a desarrollar.
El desarrollo del producto
Define como y quien lo realizara.
El funcionamiento de Scrum
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 hace hacerr posi posibl ble e el proy proyec ecto to.. A cont contin inua uaci ción ón te most mostra ramo mos s los los nomb nombre res s de los los role roles s 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).
Scrum master (Guia de Scrum)
Scrum team
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 empre empresa sa que solici solicita ta el siste sistema ma y es quie quien n cono conoce ce a la perfección el negocio (para el cual se desarrollara el producto). Es la persona que conoce a detalle la metodología de Scrum, su pape papell es fund fundam amen enta tall ya que que es quie quien n guia guiará rá al equi equipo po 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. El equipo equipo de desarro desarrollo llo tiene tiene la respons responsabil abilidad idad de realiza realizarr las 1
(equipo)
entregas de del o los pr productos de de so software a desarrollar, es este de debe estar conformado conformado por un grupo grupo entre 5 y 9 personas, personas, todas deben deben cont contar ar con con los los cono conoci cimi mien ento tos s de un anali nalist sta, a, dise diseña ñado dorr, 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 Stakeholder s (parte interesadas)
Son la personas que usaran el producto de software, ellos no tendrán ninguna responsabilidad, otro nombre que reciben es el de usuario final. Se refiere a la gente interesada interesada en el producto producto de software y que afectan o son son afec afecta tado dos s por por el proy proyec ecto to,, esto estos s pued pueden en ser ser, prov provee eedo dore res, s, 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 especial especializad izado o para llevar llevar la metodolog metodología ía de Scrum Scrum en el cual se enlis enlistan tan los reque requeri rimie miento ntos s funcio funcional nales es,, mejor mejoras, as, tecno tecnolog logías ías y correc correcció ción n de error errores es que que debe deben n desa desarro rrolla llarse rse o incorp incorpora orarse rse al prod produc ucto to (sof (softw twar are) e) a trav través és de las las suce sucesi siva vas s iter iterac acio ione nes s 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. Repre Represe senta nta todo todo aque aquello llo que esper esperan an los los clien clientes tes,, usuar usuarios ios y en gener general al los los inter interes esado ados s en el produ producto cto.. Todo odo lo que que supon suponga ga un trab trabaj ajo o por por part parte e del del equi equipo po debe debe de esta estarr refl refle ejado jado en este este documento. A diferencia de un documento de requerimientos, 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.
1
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. decir. Antes Antes de comenzar comenzar cada Sprint debe estar estar precedida de una una reunión de planificac planificación ión donde serán serán identificadas 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 cara caract cter erís ísti tica ca prin princi cipa pall es que que debe debe de estar estar completa completament mente e 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 BurnUp.
Es una una graf grafic ica a que que mue muestra stra de form forma a visu visua al la evol evoluc ució ión n del del desarrollo del producto, esta ayuda a la planificación y seguimiento por parte del Product owner (propietario del producto).
Gráfico BurnDown
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 Schwaber establece 1 los siguientes componentes y conceptos: Conceptos Tiempo real o tiempo de trabajo
Definición 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 ideale ideales”. s”. No toma toma en cuen cuenta ta el tiempo tiempo en, en, llamad llamadas as telef telefón ónica icas, s, descansos, reuniones, etc.
1
Juan Palacio, Palacio, Flexibilidad con con Scrum, primera primera edición digital digital Octubre 2007 http://www http://www.lulu.com/content/1 .lulu.com/content/1338172 338172 Páginas 130- 146
1
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.
Esti Estima maci cion ones es
Cálc Cálcul ulo o del del esfu esfuer erzo zo que se prevé prevé neces necesar ario io para para desa desarr rrol olla larr una una funciona funcionalida lidad. d. Las estimacio estimaciones nes se pueden pueden calcular calcular en unidade unidades s rela relati tiva vas s (pun (punto tos s de func funció ión) n) o en unid unidad ades es abso absolu luta tas s (tie (tiemp mpo o teórico).
Velocidad absoluta
Canti Cantidad dad de prod product ucto o cons constru truido ido en un sprin sprint. t. Se expre expresa sa en la misma misma unida unidad d en la que se realiz realizan an las estim estimac acion iones es (punto (puntos s de función, horas o días reales o teóricos).
Velocidad relativa
Cantidad de producto construido construido en una unidad de tiempo de trabajo. Por ejempl ejemplo; o; punto puntos s de funció función/s n/sema emana na de traba trabajo jo real real u horas horas teóricas/día de trabajo real.
Ahora que conocemos los elementos, elementos, herramientas y conceptos propios de Scrum podemos presentarte presentarte el ciclo de vida de un desarrollo desarrollo con Scrum. En el siguiente diagrama diagrama podemos podemos observar sus correspondientes etapas.
1
El desarrollo se inicia desde la visión general general del producto (Product (Product Backlog), dando detalles sólo a las funcionali funcionalidade dades s (Sprint (Sprint Backlog) Backlog) que, que, por ser las de mayor mayor priorida prioridad d para 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.
Reunión Previa al Sprint Objetivo: Planificación del
Reuniones Reunión Diaria Objetivo: Seguimiento del
Reunión al termino del Sprint Objetivo: Revisión del Sprint. 1
Sprint.
Reunión previa al inicio de cada sprint donde tomando como base las prioridades y nece necesid sidad ades es del del produ producto cto se determina cuáles y cómo van a ser las funcio nciona nali lid dades que se deben cubrir con esa iteración, en esta se genera el Sprint Backlog.
Sprint.
Esta Esta reun reunión ión se reali realiza za al Reunión Reunión diaria y breve, breve, de final de sprint, con una no más de 15 minutos en la duración máxima de cuatro que todo todos s los los integ integran rantes tes horas; el equipo presenta al del equipo dicen las tareas propieta propietario rio del product producto o el en las que están trabajando, incremento construido en el si se han encontrado o sprint. pre prevén vén enco encont ntra rars rse e con con algú algún n impe impedi dime ment nto, o, para para pode poderr actu actual aliz izar ar sobr sobre e el Spri Sprint nt Back Backlo log g las las tare tareas as realizadas o los tiempos de trabajo que les restan.
Estas reuniones 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 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 cotización de un seguro mediante una interfaz web.
Reducir el tiempo de instalación de un programa.
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 proyecto debemos construir construir el Product Product backlog, cabe mencionar mencionar que no es un documento de requerimientos, sino una herramienta de referencia para el equipo de 1
trabajo. Este elemento elemento de tener un formato formato en el cual se incluya la siguiente siguiente la información 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 continuación te mostramos un Product backlog utilizado para nuestro ejemplo del sistema de venta de seguros. NO. HISTOR IA
10
FUNCIONALIDAD
Permitir a los usuarios la consulta de los distintos tipos de seguros ofertados por la aseguradora.
20
Permitir la cotización de un seguro mediante una interfaz web.
30
Reducir el tiempo de instalación de un programa.
PRIORIDA D
ESTIMA CIÓN
VALIDACIÓN
NO. SPRIN T
6
Consultar Consultar cada uno de los seguros
1
Cotización y emisión
10
Realizar cotizaciones con diferen diferentes tes parámetros
1
Cotización y emisión
20
Reinstalación del programa
1
Cotización y emisión
ALT ALTA
ALT ALTA
BAJA
OBSERVA CIONES
MODULO
1
Posterio Posteriormen rmente te se crea crea el Sprint Sprint Backlog Backlog donde se especific especifican an las tareas que se deben lleva llevarr acabo acabo para para desa desarro rrolla llarr cada cada una de las las funci funcion onali alidad dades es identi identific ficada adas s en él, es importante señalar señalar que “se asignan asignan las personas a la tarea, tarea, ya que se podría asignar asignar una o más más pers person onas as a una una sola sola tare tarea” a”.. Ademá demás s es una una herr herram amie ient nta a de sopo soport rte e para 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 Hoja de Cálc Cálcul ulo. o. 2. Pizar Pizarra ra o Par Pared ed Físi Física ca.. 3. Software Software especialmente especialmente diseñado diseñado para para llevar llevar la gestión gestión de proyectos proyectos con 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 falta para para termi terminar nar;; es útil útil porqu porque e divi divide de el proyec proyecto to en tarea tareas s de tamañ tamaño o adecuado, cada tarea debe de estar en un rango de cuatro a dieciséis horas, esto se hace con el objet objetivo ivo de deter determin minar ar el avance avance diario diario e identi identific ficar ar riesg riesgos os y proble problemas mas 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
1
Análisis
Terminada Jorge
Horas Trabaj o 16
En Curso
16
1 2
2 2
2
3
Comparació n de Arquitecturas Arquitecturas Diagrama de Procesos Revisión y Análisis de Histo Historia rias s de Usuario Mapa de Navegación HTML y lenguajes script Recorrer la la funcionalidad del sistema Revisión y
Diseño
Responsabl e
Jorge
Análisis
Terminada Ernesto
16
Diseño
Terminada Ernesto
16
Codificació n
Terminada Ignacio
16
Pruebas
Terminada Ernesto
8
Análisis
Terminada Alejandro
8
Observaciones
1
3
3
3
Análisis de Histo Historia rias s de Usuario Diagrama Entidad Relación Estructura de Base de Datos en SQL Carga de Catá Catálog logos os y Datos de Prueba
Diseño
En Curso
Jorge
16
Codificació n
Pendiente
Jorge
16
Pruebas
Pendiente
Ignacio
16
Las reuniones en SCRUM Ahora que tenemos estos dos elementos elementos Product backlog y Sprint backlog, 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. Esta reunión en realidad se divide en dos: 1
-
La primera primera reun reunión ión que que puede puede tener tener una duración duración de de una a cuatro cuatro hora horas s en la que que se decide que elementos del Product backlog se van a desarrollar. En la segunda segunda reuni reunión ón se desglos desglosan an cada cada uno de los elemen elemento tos s selecci seleccion onado ados s para poder poder determi determinar nar las tareas tareas necesari necesarias as a desarrol desarrollar lar,, estimand estimando o el esfuerzo 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 área de sistema sistemas s u organiza organización ción tiene tienen n determin determinados ados los los recurs recursos os posible posibles s para realizar el sprint. El prop propieta ietario rio del producto producto tiene tiene prepar preparado ado el back backlog log del mismo. De ser ser posible posible el el propieta propietario rio del del producto producto ya ya trabajó trabajó prev previame iamente nte con con el equipo. equipo. El equipo equipo cuenta cuenta con con un conoc conocimien imiento to de las las tecnolog tecnologías ías emplea empleadas das y del del negocio negocio del del prod product ucto, o, sufic suficien iente te para para compr compren ender der los conce concepto ptos s del del negoc negocio io y poder poder realizar estimaciones asertivas.
Elementos de entrada -
El Pro Prod duct Backlog. log. El product producto o desarrol desarrollado lado hasta hasta la fecha fecha de esta esta reunió reunión n a través través de los los sucesivo sucesivos s incrementos (exceptuando esto si se trata del primer sprint). Puntos Puntos sobre sobre las las condici condicione ones s de negocio negocio del cliente. cliente. Esce Escena nari rio o tecn tecnol ológ ógic ico o empl emplea eado do..
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 tamb tambié ién n debe deben n de asis asisti tirr el prop propie ieta tari rio o del del prod produc ucto to y el equi equipo po de trab trabaj ajo. o. En una 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 area en la que que trabaja trabajaron ron ayer ayer.. 2. Tarea area o tareas tareas en las que que trabajar trabajarán án hoy. hoy. 3. Si van a necesitar necesitar alguna alguna cosa especia especiall o prevén prevén algún algún impediment impedimento o para realizar realizar 1
su trabajo. Las características de esta reunión son:
-
Condiciones para realizar la reunión Disponi Disponibilid bilidad ad de un un lugar lugar físico físico en la organiza organización ción para para reali realizar zar la reuni reunión. ón. Sprint Sprint Back Backlog log actua actualiz lizad ado, o, record recordemo emos s que puede puede ser una hoja hoja de cálculo cálculo,, un dibujo sobre un pizarrón o el uso de tarjetas. Debe de asistir asistir todo el equipo equipo (SCRUM (SCRUM Mana Manager ger,, equipo equipo de de trabajo trabajo). ).
Elementos de entrada -
Sprint Backlog. Gráf Gráfic ico o de Avanc vance e (Bur (Burnn-do down wn). ). Informac Información ión de las tareas tareas reali realizada zadas s por cada cada uno de los eleme elementos ntos del del equipo equipo..
Elementos de salida: -
Spri Sprint nt Back Backlo log g actu actual aliz izad ado. o. Gráfic Gráfico o de Avan Avance ce (Bur (Burn-d n-dow own) n) actu actual aliza izado. do.
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 propie propietar tario io y el equi equipo po en gener general al obtien obtienen en una una retro retroali alimen mentac tació ión n que que les les permi permitir tirá á evolucionar y darle un valor real al Product Backlog. Las características de esta reunión son:
-
Condiciones para realizar la reunión El sprin sprintt debe debe de esta estarr termin terminado ado en su totali totalidad dad.. Asiste Asiste todo todo el equipo, equipo, es es decir, decir, todas todas las persona personas s involucr involucrada adas s en el proyect proyecto. o.
Elementos de entrada -
Incr Incre ement mento o Termi ermina nado do
1
-
Elementos de salida Retr Retroa oali lime ment ntac ació ión n para para el prop propie ieta tari rio o del del prod produc ucto to,, así así como como para para el Scru Scrum m manager. Convocat Convocatoria oria para la reunió reunión n de planif planificac icación ión del del siguien siguiente te Sprint Sprint..
Como podemos podemos observa observarr el equipo equipo de desarro desarrollo llo está totalmente totalmente comprom comprometid etido o con la entrega oportuna de los incrementos terminados. Ahora veremos cómo se construyen construyen las herramientas 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ÁF GRÁFIC ICO O BURN BURN-U -UP P Es una grafica que muestra muestra de forma visual visual la evolución del desarrollo desarrollo del producto, producto, esta ayuda a la planificación y seguimiento por parte del Product owner (propietario del producto). Se construye con: -
La estim estimac ación ión de esfue esfuerzo rzo previs prevista ta en en el el Product Backlog. La vel veloc ocida idad d del equi equipo po (velo (velocid cidad ad abso absolut luta). a).
Este Este gráfic gráfico o se const construy ruye e con con la infor informac mación ión que se encue encuentr ntra a en el Produ Product ct Back Backlog log 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.
1
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ÁF GRÁFIC ICO OB BUR URNN-DO DOWN WN 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 elementos de dos metodologías metodologías de desarrollo más populares en lo que respecta a la industria del software, te proporcionamos los artefactos artefactos para que puedas utilizarlos utilizarlos posteriormente posteriormente en el desarrollo de proyectos, proyectos, así mism mismo o te dimo imos a cono conoce cerr el nomb nombre re de rol rol que que jueg juegan an las las pers person onas as en ambas mbas metodologías. Cómo pudiste apreciar estas metodologías se realizan en equipo en la que todo todos s se encu encuen entra tran n invo involuc lucra rado dos s y compr comprome ometid tidos os,, algo algo que que no pued puedes es deja dejarr pasa pasar r desapercibido.
1
Bibliografía. Juan Palacio, Flexibilidad Flexibilidad con Scrum, primera edición digital Octubre 2007 http://www.lulu.com/content/1338172 Consultado 19 de abril de 2011
1
