INFORME SCRUM

5/14/2018 INFORME SCRUM - slidepdf.com

http://slidepdf.com/reader/full/informe-scrum 1/26

1

SCRUM

1. INTRODUCCIÓN

Scrum significa melé. Melé es un tipo de jugada del deporte Rugby. Todos los jugadores

de ambos equipo se agrupan en una formación en la cual lucharán por obtener el balónque se introduce por el centro. La complejidad de una melé hace que: “Si un miembro delequipo se viene abajo, se cae toda le melé”

En consecuencia, los jugadores deben estar bien coordinados, apoyándose en suscompañeros para empujar al mismo tiempo y con ello, avanzar a la misma velocidad.

Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porqueno se basa en el seguimiento de un plan, sino en la adaptación continua a lascircunstancias de la evolución del proyecto, realizado por Hirotaka Takeuchi e IkujijoNonaka a mediados de los 80 y restructurado por Jeff Sutterland.

2. CARACTERÍSTICAS

Scrum es un marco de trabajo ágil que se basa en la iteración y entrega de incrementalesde desarrollo de un producto o servicio. Posee las siguientes características:

Su prioridad es la satisfacción del cliente; que se da con la continua interacción entreéste y el equipo de desarrolladores.

Se aceptan requisitos cambiantes. Enfocado a conseguir pequeños incrementos de software completamente

funcionales Es un modo de desarrollo adaptable, antes que predictivo. Orientado a las personas, más que a los procesos. Emplea el modelo de construcción incremental basado en iteraciones y

revisiones. Alta flexibilidad

3. ROLES Y RESPONSABILIDADES

El product Owner (dueño del producto):

Características

El Dueño de Producto es la única persona autorizada para decidir sobre cuálesfuncionalidades y características funcionales tendrá el producto. Es quien representa alcliente, usuarios del software y todas aquellas partes interesadas en el producto, cuidandolos intereses de cada uno de ellos.



2

Funciones y responsabilidades: Crear la pila de producto. Para esto puede contar con la colaboración del resto del

equipo, pero es importante recordar que el responsable de este documento es él. Encaminar las necesidades del negocio, sabiendo "escuchar" a las partes

interesadas en el producto y transmitirlas en "objetivos de valor para el producto",

al equipo de trabajo. Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI),

abogando por los intereses del negocio. Estima el financiamiento inicial y el requerido en el curso del proyecto mediante la

creación de los requisitos totales e iniciales del proyecto, preocupándose deretornar los objetivos de inversión (ROI), y los planes de revisión.

Revisar el producto e ir adaptándole sus funcionalidades, analizando las mejorasque éstas puedan otorgar un mayor valor para el negocio.

Aptitudes que debe tener un Dueño de Producto: Excelente facilidad de comunicación en las relaciones interpersonales. Excelente conocimiento del negocio. Facilidad para análisis de relaciones costo/beneficio. Visión de negocios.

El Equipo (Scrum Team):

Características

Está integrado por programadores, diseñadores, arquitectos, testers y demás, que enforma auto-organizada, será los encargados de desarrollar el producto. Se auto-gestiona y

auto-organiza, y dispone de atribuciones suficientes en la organización para tomardecisiones sobre cómo realizar su trabajo.

Funciones y responsabilidades: Tienen la responsabilidad, en cada iteración, de transformar el Product Backlog

en un incremento en la funcionabilidad del producto y planificar su propio trabajopara lograrlo.

Los miembros del equipo son responsables en conjunto del éxito de cada iteracióny del proyecto en su totalidad.

Aptitudes que deben tener los integrantes de un Equipo.

Ser profesionales expertos o avanzados en su disciplina. Tener vocación para trabajar en equipo. Capacidad de auto-gestión.

El Scrum Master:



3

Características:

El Scrum Master es el alma mater de Scrum, es un un auténtico servidor neutral, queserá el encargado de fomentar e instruir sobre los principios ágiles de Scrum, gracias asus excelentes conocimientos de esta metodología.

Protege al equipo de distracciones y de otros elementos externos. Elimina obstáculos quealejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya queel grupo se autogestiona.

El Scrum Master es responsable del proceso Scrum, debe enseñar la metodología Scruma cada integrante implicado en el proyecto, preocupándose de poner la metodología enpráctica de modo que se encuentre dentro de la cultura de la organización y así entreguelas ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas deScrum.

Funciones y responsabilidades:

Garantizar la correcta aplicación de Scrum. Esto incluye, desde la correctatrasmisión de sus principios a las altas gerencias, hasta la prevención de lainversión roles (es decir, guardar especial cuidado en que el dueño de producto noactúe en nombre del equipo y viceversa, o que la audiencia se inmiscuya en tareasque no le son propicias).

Resolver los conflictos que entorpezcan el progreso del proyecto. Incentivar y motivar al Equipo de trabajo, creando un clima de trabajo colaborativo,

fomentar la auto-gestión del equipo e impedir la intervención de terceros en la

gestión del equipo.

Aptitudes que debe tener un Scrum Master

Amplia vocación de servicio. Predisposición generosa. Amplia capacidad para la resolución de problemas. Analítico y observador. Saber incentivar y motivar. Capacidad docente e instructiva. Buen carisma para las negociaciones.

4. ARTEFACTOS O ELEMENTOS DE SCRUM

Scrum, aplicado al software, emplea dos formatos para registrar los requisitos:

Pila del producto (Product Backlog) Pila del sprint (Sprint Backlog)



4

La pila del producto se sitúa en el área de necesidades de negocio desde el punto devista del cliente. Es el área que en la ingeniería del software tradicional, cubren losrequisitos del sistema o ConOps (Concept of Operations).

La pila del sprint cubre la especificación de los requisitos de software necesarios para dar

respuesta a las funcionalidades esperadas por el cliente.

Estas listas no tienen que cumplir con un determinado “formato scrum-estándar”; pueden,y deben adoptar la forma más adecuada al sistema equipo-proyecto. Algunos equiposágiles emplean pilas de requisitos, otras historias de usuario, WBS,entre otras. Lorelevante no es tanto la forma, sino qué.

Pila del producto: los requisitos del cliente

La pila del producto es el inventario de funcionalidades, mejoras, tecnología y correcciónde 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 losinteresados. Todo lo que suponga un trabajo que debe realizar.

Para dar comienzo al desarrollo se necesita una visión de los objetivos de negocio que sequieren conseguir con el proyecto, comprendida y conocida por todo el equipo, yelementos suficientes

Formato de la pila del producto :

El desarrollo ágil prefiere la comunicación directa, a la comunicación con documentos. La

pila del producto no es un documento de requisitos, sino una herramienta de referenciapara el equipo.

Si se emplea formato de lista, es recomendable que al menos incluya la siguienteinformación en cada línea:

Identificador único de la funcionalidad o trabajo. Descripción de la funcionalidad. Campo o sistema de priorización. Estimación

Dependiendo del tipo de proyecto, funcionamiento del equipo y la organización, puedenresultar aconsejables otros campos como observaciones, criterio de validación, personaasignada, número de Sprint en el que se realiza, módulo del sistema al que pertenece,entre otros.

Ejemplo:



5

Pila del Sprint

La pila del sprint, (sprint backlog) es la lista que descompone las funcionalidades de la piladel producto en las tareas necesarias para construir un incremento: una parte completa yoperativa del producto.

La realiza el equipo durante la reunión de planificación del sprint, en donde se estimacada tarea para luego ser asignada entre sus miembros; además, se indica en la mismalista cuánto tiempo falta aún para que la termine. Las duraciones estimadas de las tareasno son ni inferiores, ni superiores a los límites definidos en el equipo

Es útil porque descompone el proyecto en unidades de tamaño adecuado para determinarel avance a diario, e identificar riesgos y problemas sin necesidad de procesos complejosde gestión. Es también una herramienta de soporte para la comunicación directa delequipo.

Condiciones

Realizada de forma conjunta por todos los miembros del equipo. Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del

sprint. Sólo el equipo lo puede modificar durante el sprint. Es visible para todo el equipo. Idealmente en una pizarra o pared en el mismo

espacio físico donde trabaja el equipo.

Formato y soporte

Hoja de cálculo. Pizarra física o pared. Herramienta colaborativa o de gestión de proyectos.

Y sobre la que mejor se adecua a las características del proyecto, oficina y equipo, loapropiado es diseñar el formato más cómodo para todos, teniendo en cuenta lossiguientes criterios:



6

Incluye la información: lista de tareas, persona responsable de cada una, estadoen el que se encuentra y tiempo de trabajo que queda para completarla.

Sólo incluye la información estrictamente necesaria. El medio y modelo elegido es la opción posible que más facilita la consulta y

comunicación diaria y directa del equipo.

Sirve de soporte para registrar en cada reunión diaria del sprint, el tiempo que lequeda a cada tarea.

El Incremento

El incremento es la parte de producto producida en un sprint, y tiene como característicasque está completamente terminada, probada y operativa, en condiciones de ser entregadaal cliente final. No se trata por tanto de módulos o partes a falta de pruebas, odocumentación.

Idealmente en el desarrollo ágil:



7

Cada funcionalidad de la pila del producto se refiere a funcionalidades entregables, noa trabajos internos del tipo “diseño de la base de datos”

Se produce un “incremento” en cada iteración.

Sin embargo suele ser una excepción habitual el primer sprint. En el que objetivos del tipo

“contrastar la plataforma y el diseño” pueden ser normales, e implican trabajos de diseñoo desarrollo de prototipos para probar la solvencia de la plataforma que se va a emplear,entre otros.

Si el proyecto o el sistema requiere documentación, o procesos de validación yverificación documentados, o con niveles de independencia que implican procesos conterceros, éstos también tienen que estar realizados para considerar que el producto está“terminado”.

5. LAS REUNIONES

Scrum realiza el seguimiento y la gestión del proyecto a través de las tres reuniones queforman parte del modelo y la retrospectiva que nos ayuda a reconocer los problemas y aplantear mejoras:

Planificación del sprint Seguimiento del sprint Revisión del sprint Retrospectiva

Planificación del sprint

En esta reunión se toman como base las prioridades y necesidades de negocio delcliente, y se determina cuáles y cómo van a ser las funcionalidades que incorporará elproducto tras el siguiente sprint. Las características de la planificación del sprint son:

Pre-condiciones La organización tiene determinados los recursos disponibles para llevar a cabo el

sprint.



8

El Product Owner tiene preparada la pila del producto, con su criterio de prioridadpara el negocio, y un número suficiente de elementos para desarrollar en el sprint.

Siempre que sea posible, Product Owner debe haber trabajado antes con elequipo. De esta forma su estimación previa del trabajo que se puede realizar en elsprint será bastante ajustada.

El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio delproducto suficiente para realizar estimaciones basadas en "juicio de expertos”, ypara comprender los conceptos del negocio que expone el propietario delproducto.

Entradas El backlog del producto El producto desarrollado hasta la fecha a través de los sucesivos incrementos

(excepto si se trata del primer sprint) Circunstancias de las condiciones de negocio del cliente y del escenario

tecnológico empleado.

Resultados Los elementos de la backlog del producto que se van a ejecutar. El objetivo del sprint. Backlog del sprint con todas las tareas estimadas y asignadas. La duración del sprint y la fecha de la reunión de revisión.

Formato de la reunión Duración máxima: un día.

Deben asistir: el Product Owner, el equipo y el Scrum Master (o responsable deeste rol) Pueden asistir: es una reunión abierta a todos los que puedan aportar información

útil.

Consta de dos partes separadas por una pausa, según la duración.

Primera parte: Duración de 1 a 4 horas.

Propietario del producto: El Scrum Master actúa de moderador de la reunión. Presenta las funcionalidades de la pila del producto que tienen mayor prioridad

y que estima se pueden realizar en el sprint. La presentación se hace con un nivel de detalle suficiente para transmitir al

equipo toda la información necesaria para construir el incremento. El equipo: Realiza las preguntas y solicita las aclaraciones necesarias.



9

Propone sugerencias, modificaciones y soluciones alternativas. Las aportaciones del equipo pueden suponer modificaciones en la pila.

Tras reordenar y replantear las funcionalidades de la pila del producto, el equipo defineel “objetivo del sprint” o frase que sintetiza cuál es el valor que se le va a entregar al

cliente.

Exceptuando sprints dedicados exclusivamente a refactorización o a colecciones detareas desordenadas (que deberían ser los menos), la elaboración de este lema de formaconjunta en la reunión es una garantía de que todo el equipo comprende y comparte lafinalidad del trabajo; y durante el sprint sirve de criterio de referencia en las decisionesque auto gestiona el equipo.

Segunda parte:

Su duración es hasta el final de la jornada. El equipo desglosa cada funcionalidad en

tareas, y estima el tiempo para cada una de ellas, determinando de esta forma las tareasde la pila del sprint, el equipo debe tener en cuenta los elementos de diseño y arquitecturaque deberá incorporar el sistema.

Los miembros del equipo se auto-asignan las diferentes tareas tomando como criteriossus conocimientos, intereses y distribución homogénea del trabajo. El objetivo del ProductOwner es atender a dudas y comprobar que el equipo comprende y comparte su objetivo.

Seguimiento del sprint

Reunión diaria breve, de no más de 15 minutos, en la que cada miembro del equipo dicelas tareas en las que está trabajando, si se ha encontrado o prevé encontrarse con algúnimpedimento, y actualiza sobre la pila del sprint las ya terminadas, o los tiempos detrabajo que les quedan.

Pre-condiciones Disponibilidad de un lugar físico en la organización para realizar diariamente la

reunión. Sprint backlog actualizado en el soporte que emplee el equipo (dibujado en

pizarra, con post-it’s, sobre hoja de cálculo…) Asiste todo el equipo. Asiste un responsable con rol de Scrum Master de la organización. Un miembro del equipo (team leader) conduce y garantiza el protocolo, formato y

tiempos de la reunión.

Entradas



10

Sprint backlog y gráfico de avance (burn-down) actualizados con la información dela reunión anterior.

Información de las tareas realizadas por cada componente del equipo

Resultados

Sprint backlog y gráfico de avance (burn-down) actualizados. Identificación denecesidades e impedimentos.

Formato de la reunión

Se recomienda realizarla de pie y emplear un formato de pila de tareas en una pizarra, junto con el gráfico de avance del sprint, para que todo el equipo pueda ver y anotar.Cada miembro del equipo expone estas tres cuestiones:

1.- Tarea en la que trabajó ayer.

2.- Tarea o tareas en las que trabajará hoy.

3.- Si va a necesitar alguna cosa especial o prevé algún impedimento para realizar sutrabajo. Y actualiza sobre el sprint backlog el tiempo de trabajo que queda pendiente enlas tareas que tiene asignadas, o marca como finalizadas las ya completadas.

Al final de la reunión: Con las estimaciones actualizadas, el equipo refresca el gráfico de avance del

sprint. El Scrum Master comienza la gestión de necesidades e impedimentos

identificados.

REVISIÓN DEL SPRINT

Reunión realizada al final del sprint en la que, con una duración máxima de 4 horas, elequipo presenta al Product Owner, clientes, usuarios, gestores… el incremento construidoen el sprint.

Objetivos El Product Owner obtiene información objetiva del progreso del sistema. Esta

reunión marca a intervalos regulares, el ritmo de construcción del sistema y latrayectoria que va tomando la visión del producto.

Al ver y probar el incremento, el Product Owner, y el equipo en general obtienenfeedback clave para evolucionar y dar más valor a la pila del producto.

El Scrum Master obtiene retroinformación sobre buenas prácticas y problemasdurante el sprint, necesaria para las prácticas de ingeniería de procesos y mejoracontinua de la implementación Scrum Master.



11

Pre-condiciones Se ha concluido el sprint. Asiste todo el equipo de desarrollo, el Product Owner, el responsable de procesos

de la empresa y todas las personas implicadas en el proyecto que lo deseen.

Entradas Incremento terminado.

Resultados Feedback para el Product Owner: hito de seguimiento de la construcción del

sistema, e información para mejorar el valor de la visión del producto. Feedback para el Scrum Master: buenas prácticas y problemas durante el sprint. Convocatoria de la reunión del siguiente sprint.

Formato de la reunión

Es una reunión informativa e informal. El objetivo es ver el incremento. El equipo no debeinvertir más de una hora en preparar la reunión, y lo que se muestra es el resultado final:terminado, probado y operando en el entorno del cliente (incremento), además puedeincluir también documentación de usuario, o técnica.

Un protocolo recomendado:

1.- El team leader expone el objetivo del sprint, la lista de funcionalidades que se incluíany las que se han desarrollado.

2.- El equipo hace una introducción general del sprint y demuestra el funcionamiento delas partes construidas.

3.- Se abre un turno de preguntas y sugerencias sobre lo visto.

4.- El responsable del proceso (Scrum Master), de acuerdo con las agendas del ProductOwner y el equipo cierra la fecha para la reunión de preparación del siguiente sprint.

RETROSPECTIVA

Conviene señalar que una reunión retrospectiva no es lo mismo que la reunión de revisióndel sprint.

Al igual que los modelos de procesos incorporan prácticas de “ingeniería de procesos”para conseguir una mejora continua de su capacidad, en agilidad también van surgiendoprácticas para lo que sería el equivalente de mejora continua de la agilidad de laorganización; y en esta línea, las reuniones retrospectivas son un una “meta-practica” ágil.



12

Una reunión retrospectiva se centra en “CÓMO” lo estamos construyendo: “CÓMO”estamos trabajando, con el objetivo de analizar problemas y aspectos mejorables.

Se plantean los inconvenientes tenidos durante el desarrollo del Sprint, así como lasmejoras posibles para trabajos futuros.

6. MEDICION

¿Para que medir?:

Dentro de la metodología SCRUM es necesario medir para verificar el cumplimiento de losobjetivos planteados en un tiempo transcurrido, estas nos proporcionan criterios objetivosde gestión y seguimiento.

Se considera tres fondos de escala, o de zoom con los que se puede medir el trabajo:

Desarrollo y gestión de la solución técnica. Gestión de proyecto. Gestión de la organización.

En el desarrollo del proyecto podemos medir en los campos de: Organización(rendimiento, satisfacción clientes, eficiencia, desempeño, etc), proyecto (esfuerzo, coste,tamaño, etc) y desarrollo (densidad de fallos, complejidad de diseño, disponibilidad, etc).

Antes de incorporar un procedimiento de medición, se debe cuestionar su conveniencia, yla forma en la que se aplicará.

Criterios para el diseño y aplicación de métricas

¿Por qué se va a usar?

El uso de las métricas es tanto para uso del equipo de trabajo como para el cliente.

Dentro del equipo de trabajo permite saber si están cumpliendo con su trabajo yasí poder tomar medidas de corrección, etc.

Para el cliente, porque puede ver el progreso y desarrollo del software si estásatisfactoriamente y se encuentra dentro del coste y así poder tomar decisiones de

continuar con el desarrollo del mismo y poder invertir en él.

Para tomar una métrica debemos tomar en cuenta un indicador.

¿El indicador es apropiado para el fin que se debe conseguir?



13

El medir es una parte difícil, debemos tomar un indicador que nos ayude a medir lonecesario, ya que si no lo es solo supondrán un coste de gestión evitable; muchas vecesempeorarán lo que se intentaba mejorar.

Medición de la eficiencia en la empresa

La organización plantea indicadores para medir el grado de eficiencia de losdepartamentos, combinándola con otra que es la de tiempo de respuesta. Si laimplantación del indicador ha dado buenos resultados: el departamento ha comenzado aser más eficiente y conseguir mayor satisfacción de su cliente:

1.- Va reduciendo los costes que suponen la incorporación de nuevas personas a laempresa.

2.- Va reduciendo los tiempos de respuesta a los departamentos que solicitan nuevopersonal.

Medición del avance del proyecto

La organización ha diseñado un cuadro de información para mostrar el grado de avancede cada proyecto. Los indicadores de progreso de los proyectos, y de las tareas en lasque se descomponen; se elaboran con el sistema clásico de la gestión de proyectospredictiva:

1.- Se realiza la estimación del tiempo de trabajo necesario para cada tarea.

2.- Diariamente se actualizan los tiempos de trabajo invertidos.

3.- La diferencia muestra el porcentaje ejecutado de las tareas, y por tanto, el de cadaproyecto.

Medición de la eficiencia de los trabajos de programación

Para esto se ha adoptado métricas estándar de eficiencia de Ingeniería del Software:LOC/Hour: Número total de líneas de código nuevas o modificadas en cada hora.

Al vincular los resultados de esta métrica a la retribución por desempeño de los

programadores. Esta aumenta el resultado de las líneas de código en el programa. Elresultado ha sido producir más líneas de código sin incrementar la plantilla.

Para evitar que se trate de un incremento “hueco” de líneas de código, o que conlleve unaumento de los errores por programar más deprisa, se ha dotado de mayor “rigor” alsistema de métrica, incorporando al poco tiempo otras métricas para complementar ymejorar el sistema de calidad.



14

Las Unidades

Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil,y componen la fórmula de la velocidad, definiéndola como: cantidad de trabajo realizadapor unidad de tiempo.

Velocidad = Trabajo / Tiempo

Tiempo

El desarrollo ágil emplea la técnica “timeboxing”6 para gestión de tiempo. En el caso deScrum, la unidad de tiempo para cada incremento de producto es el Sprint. Podemosdiferenciar dos tipos de tiempo:

Tiempo real, es el efectivo de trabajo. Es equivalente a la jornada laboral. Tiempo ideal se refiere al tiempo de trabajo necesario, en “condiciones ideales”,

esto es, sin ninguna interrupción, pausa, distracción o atención a tareas ajenas ala tarea del sprint que se tiene asignada.

Trabajo

Medir el trabajo puede ser necesario por dos razones: para registrar lo ya hecho, o paraestimar anticipadamente, el que hay que realizar. En ambos casos se necesita unaunidad, y un criterio objetivo de cómo se cuantifica.

Velocidad=trabajo/tiempo tiempo=sprint

Trabajo ya realizado: no es de gran dificultad, se puede hacer con unidadesrelativas al producto (p. ej. líneas de código) o a los recursos empleados (coste,tiempo de trabajo…). La gestión ágil no determina el grado de avance del proyectopor el trabajo ya realizado, sino por el pendiente de realizar.

Trabajo pendiente de realizar : Scrum mide el trabajo pendiente para: Estimar el esfuerzo y la duración prevista para completar el trabajo (tareas,

historias de usuario). Determinar el avance del proyecto, y en especial en cada sprint.

Las unidades para medir el trabajo pueden estar relacionadas directamente con elproducto, como los tradicionales puntos de función de COCOMO; o indirectamente, através del tiempo necesario para realizarlo.

Velocidad = Trabajo / Tiempo



15

La gestión ágil suele llamar a las unidades que emplea para medir el trabajo “puntos”,“puntos de funcionalidad” “puntos de historia”…

Cada organización, según sus circunstancias y su criterio institucionaliza su métrica detrabajo definiendo el nombre y las unidades. Lo importante es que la métrica empleada,

su significado y la forma de aplicación sea consistente en todas las mediciones, en todoslos proyectos de la organización y conocida por todas las personas.

Velocidad

Velocidad es la magnitud que viene determinada por la cantidad de trabajo realizada enun periodo de tiempo.

Los equipos que miden el trabajo con tiempo ideal, hablan de “Velocidad”. Si en el sprintsiguiente consiguen una velocidad mayor, querrá decir que han logrado programar másstory points en el mismo tiempo, o lo que es lo mismo que han conseguido aumentar el

porcentaje de tiempo ideal en la jornada de trabajo: han reducido los tiempos deinterrupciones, distracciones o dedicados a otras tareas.

Se le puede llamar velocidad o eficiencia, cuando un equipo en un siguiente sprint lograprogramar más story points. Velocidad y eficiencia son términos similares. Se suelepreferir “velocidad” cuando las mediciones se basan en tiempo teóricos, y “eficiencia”cuando lo hacen en tiempo real.

7. HERRAMIENTAS DE SCRUM

Historias de usuario

Cada historia de usuario contiene lo que el cliente quiere, con total claridad y ningunaambigüedad. Deben ser breves, concretas y algo estimables. Son el resultado deescuchar al cliente y ayudarle a resumir el requisito en una sola frase. Algo muyimportante es que están escritas con el vocabulario del negocio del cliente, no convocabulario técnico. Ejemplo:



16

Cada historia provoca una serie de preguntas acerca de los múltiples contextos en que sepuede dar. Son las que naturalmente hacen los desarrolladores a los analistas de negocioo al cliente. Ejemplo:

¿Qué hace el sistema si el libro que se quiere añadir al carrito ya está dentro de él?

¿Qué sucede si se ha agotado el libro en el almacén? ¿Se le indica al usuario que el libro ha sido añadido al carrito de la compra?

Las respuestas a estas preguntas son afirmaciones, ejemplos, los cuales se debentransformar en test de aceptación. Por tanto, cada historia de usuario tiene asociados unoo varios test de aceptación (ejemplos):

Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otrashistorias que pasan a engrosar el backlog o lista de requisitos: “Si el libro no está enstock, se enviará un email al usuario cuando llegue”.

Gráfico de producto o burn-up:

Es una herramienta de planificación y seguimiento del propietario del producto, quemuestra de un vistazo, en un gráfico muy simple el plan general de desarrollo delproducto, y la traza de su evolución. Se confecciona con:

La estimación del esfuerzo prevista en la pila del producto. La velocidad del equipo.

Se lo representa con un diagrama cartesiano que en el eje de ordenadas muestra el

trabajo estimado para desarrollar el producto, y en el de abcisas las fechas, medidassegún las duraciones previstas para los sprints.

Además, se traza en el gráfico la línea de velocidad prevista. También puede resultar útilesbozar una estimación optimista y otra pesimista para tener la visión de fechasaceptables. La línea de velocidad proyecta sobre el eje X la fecha o sprint en el queprevisiblemente se completarán las versiones representadas en el eje Y.



17

Ejemplo: Representación del plan del producto, a partir de los temas previstos en la pilade producto (product backlog).

Las convenciones empleadas por el equipo son:

Unidad para medición de trabajo: tiempo ideal

Tiene previsto realizar sprints de duración fija mensual. El equipo está formado por 4 personas, y viene desarrollando una velocidad de 300

puntos por sprint.

Gráfico de avance-burndown: monitorización del sprint

Es el gráfico que actualiza el equipo en las reuniones de seguimiento del sprint, para com-probar el ritmo de avance, y detectar desde el primer momento si es el previsto, o sepuede ver comprometida la entrega prevista al final del sprint.

La estrategia ágil para el seguimiento de los proyectos se basa en medir el esfuerzo quefalta, no el realizado y el seguimiento muy cercano (diario de ser posible), en este gráficotoman forma los dos principios:

En el eje Y se registra el trabajo que aún falta por realizar. Se actualiza a diario.

El equipo dispone en la pila del Sprint, de la lista de tareas que va a realizar y en cadauno figura el esfuerzo pendiente. El primer día, en la pila de tareas figura para cada tareael esfuerzo que se ha estimado, puesto que aún no se ha trabajado en ninguna de ellas.



18

Día a día, cada miembro del equipo actualiza en la pila del sprint el tiempo que le queda alas tareas que va desarrollando, hasta que se terminan y van quedando en 0 los tiempospendientes.

Con esta información de la pila del sprint se actualiza el gráfico poniendo cada día el

esfuerzo pendiente total de todas las tareas que aún no se han terminado.

Ejemplo:

El avance ideal de un sprint estaría representado por la diagonal que reduce el esfuerzoen forma de pendiente de forma continua y gradual hasta terminarlo en el último día del

Sprint. Las gráficas de diagonal perfecta no son lo habitual, y la curva puede estar porencima o bajo ella lo que significa que se debe quitar o agregar elementos del Sprintbacklog.

Estimación de póquer

Es una práctica ágil, útil para conducir las reuniones en las que se estima el esfuerzo y laduración de tareas. Para evitar en estos casos las discusiones dilatadas que no terminande dar conclusiones concretas, James Grening ideó este juego de planificación comoayuda para conducir la reunión.



19

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en laestimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzoestimado. Cuando se considera que éste es mayor al tamaño máximo considerado por elequipo para una tarea, se levanta la carta “&”.

Cada equipo u organización puede utilizar un juego de cartas con las numeracionesadecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea quese va a estimar. Sin embargo hay que respetar los siguientes principios:

No definir tareas demasiado grandes, porque entorpece la precisión de lasestimaciones y la identificación de riesgos. No definir tareas cuya duración (en puntos o tiempo) resulte inferior a medio día ideal

de trabajo. Utilizar la misma unidad de medida (storypoints, días, horas, entre otras) en todos los

gráficos y pilas.

8. PROCESO

Prejuego:

Planificación: definición de una nueva entrega basándose en un Product Backlogconocido junto a un costo y cronograma estimados. Si un nuevo sistema empieza adesarrollarse, esta fase consiste en conceptualización y análisis.



20

Pasos:

Desarrollo de un backlog completo. Determinación de la fecha de entrega y la funcionalidad de una o más

versiones.

Selección de la versión más adecuada para desarrollo inmediato. Trazado de los “paquetes del producto” (objetos) sobre los elementos del

backlog de la versión elegida. Selección del equipo o equipos para desarrollar la nueva versión. Evaluación y control adecuado de los riesgos. Estimación del coste de la versión, incluyendo desarrollo, material, marketing,

formación y despliegue. Conformidad de la dirección y financiación del proyecto.

Arquitectura: Diseña cómo los artículos del Backlog son implementados. Incluye lacreación o modificación de la arquitectura del sistema y el diseño de alto nivel.

Pasos:

Revisión de los elementos del backlog incluidos en la versión. Identificación de los cambios necesarios para implementar el backlog. Análisis del dominio para incluir los requisitos que incluye el desarrollo

mejorado y actualización. Acotar la arquitectura del sistema para apoyar el nuevo contexto y

necesidades. Identificar problemas del desarrollo o modificaciones. Reunión de revisión de diseño. Cada equipo presenta los cambios para

implementar los elementos del backlog, e identificar posibles reasignaciones.

Juego:

Desarrollo de los Sprints: desarrollo de una nueva funcionalidad en constante miraa las variables tiempo, requerimientos calidad, costo y competencia. La interaccióncon estas variables define el final de esta fase. Son múltiples los Sprints o ciclosusados para desarrollar el sistema. Dentro del Sprint la retroalimentación se obtienecon las reuniones diarias (ScrumMeetings) y el control de la curva de progreso burn-

up. La fase de desarrollo es un ciclo de trabajo repetitivo.

Macro-procesos:

Reunión con los equipos para revisar los planes de lanzamiento de versión. Distribución, revisión y ajuste de los estándares de conformidad para el

producto. Sprints iterativos hasta que el producto se considera listo para su distribución.



21

Postjuego:

Clausura: preparación para la entrega, incluyendo la documentación final, prueba yentrega. Tareas:

integración, pruebas del sistema, documentación de usuario, preparación delmaterial de formación y marketing.

9. EJEMPLO DE SCRUM

Un cliente se pone en contacto con una empresa que fabrica robots. El cliente les realizael pedido

El Cliente se reune con el Dueño de producto, que toma nota de lo que tiene en sucabeza.



22

El Duelo de Producto divide el proyecto en historias que son las que componen la pila deproducto.

El Dueño de Producto le entrega al Scrum Master la pila de producto para que estimen elcoste de creación del producto.

El equipo se reune para estimar el coste de cada historia de la pila de producto. En estecaso utilizan Planning Poker.

El cliente, una vez aprobado el presupuesto, reordena la pila de producto para que elequipo vaya trabajando según la prioridad del cliente.

El equipo comienza su trabajo desglosando la primera historia de la pila de producto, lacual subdividen en tareas menores para crear la pila de sprint.



23

La pila de sprint tiene como utilidad fraccionar el trabajo de un periodo de 15 días entareas más pequeñas, que tarden máximo dos días.

Estas tareas se colocan en una pila, la cual prioriza el Dueño de Producto, que haconsultado con el cliente, antes de comenzar el sprint.



24

El equipo comienza el sprint tomando las tareas priorizadas. Una vez concluida una setoma la siguiente de la lista. Se convoca todos los días una reunión del equipo donde secuenta las tareas realizadas el día anterior y cuales se van a realizar ese día.

Una vez finalizado el sprint, el Dueño de Producto le muestra al cliente el resultado del

trabajo realizado. El cliente ya tiene el primer contacto con su encargo y además puedevolver a priorizar la pila de producto antes de que comience otro sprint.

El equipo de trabajo celebra su buen hacer con una reunión de retrospectiva, donde seanaliza lo ocurrido durante el sprint. Esta reunión se celebra fueras de la oficina,normalmente con comida y bebidas de por medio.

10. VENTAJAS Y DESVENTAJAS

Ventajas:

Flexibilidad a cambios: Alta capacidad de reacción ante los cambios derequerimientos generados por necesidades del cliente o evoluciones del mercado. Lametodología está diseñada para adaptarse a los cambios de requerimientos queconllevan los proyectos complejos.

Mayor calidad del software: La metódica de trabajo y la necesidad de obtener unaversión funcional después de cada iteración, ayuda a la obtención de un software decalidad superior.



25

Maximiza el retorno de la inversión (ROI): Producción de software únicamente conlas prestaciones que aportan mayor valor de negocio gracias a la priorización porretorno de inversión.

Predicciones de tiempos: Mediante esta metodología se conoce la velocidad mediadel equipo por sprint con lo que consecuentemente es posible estimar fácilmente,

para cuando se dispondrá de una determinada funcionalidad que todavía está en elBacklog. Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor

en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto,permite despejar riesgos eficazmente de manera anticipada.

Visualización del proyecto día a día Equipos integrados y comprometidos con el proyecto, toda vez que ellos definieron el

alcance y se auto-administran.

Desventajas

No genera toda la evidencia o documentación de otras metodologías Tal vez sea necesario complementarlo con otros procesos Si no existe una fecha definitiva de finalización del proyecto es posible que se siga

solicitando, y añadiendo, nueva funcionalidad. Si una tarea no está bien definida, los costes de tiempo y dinero estimados del

proyecto no serán demasiado exactos. En ese caso, la tarea se puede extender sobrevarios sprints.

Esta metodología necesita solo miembros de equipo experimentados. Si el equipoconsiste en gente que son junior, el proyecto no puede ser completado a tiempo.

Además de los recursos sin suficiente experiencia, la falta de dirección firme pueden

llevar a los proyectos a no completarse o incluso fallar. La metodología Scrum funciona bien cuando el scrum master confía en el equipo que

lleva. Si se practican controles muy estrictos sobre los miembros del equipo, puedeser extremadamente frustrante para ellos, llevando a la desmoralización y el fallo delproyecto.

Si algunos de los miembros del equipo se marcha durante el desarrollo puede tenerun efecto negativo enorme en el desarrollo del proyecto.

11. ¿QUIÉN USA SCRUM?

Microsoft Yahoo Google Electronic Arts Philips Siemens

Nokia Ericsson IBM

Capital One BBC F-Secure

Telefónica BMC Software



26

12. ¿PARA QUÉ SE USA SCRUM?

Software comercial. Proyectos internos. Proyecto de precio fijo.

Aplicaciones financieras. Sistemas empotrados. Desarrollo de video juegos. Software de control de satélites. Sitios web. Software para dispositivos móviles. “Network switching applications”.

13. BIBLIOGRAFÍA:

PALACIO JUAN, Flexibilidad con Scrum, [Octubre – 2008], [20/03/2012],http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf

ANTOLÍ LEO, GUTIERREZ JUAN, YAGÜE AGUSTÍN; Introducción a Scrum,[19/03/2012], http://www.adictosaltrabajo.com/material_charlas/20090507/scrum.pdf

PALACIO JUAN, RUATA CLAUDIA, Scrum Manager Gestión de Proyectos, [Enero de2011], [19/03/2012], http://www.scrummanager.net/files/sm_proyecto.pdf

DUARTE ROMNY, Roles que se aplican en Scrum, [06/04/2008 17:46], [20/03/2012]http://geeks.ms/blogs/rduarte/archive/2008/04/06/roles-que-se-aplican-en-scrum.aspx

Los roles de Scrum, [20/03/2012],http://sites.google.com/site/oeguzman/losrolesdescrum

BAHIT EUGENIA, Los roles en Scrum, [14 de September de 2011], [20/03/2012],http://www.desarrolloweb.com/articulos/roles-scrum.html KNIBERG HENRIK, Scrum y Xp desde las trincheras, [Octubre-2008], [2012],

http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

MOUSQUÉS GASTÓN, Metodología SCRUM, [2003], [20/03/12],http://www.ort.edu.uy/fi/ingenieria/SubSitios/ingsoft/investigacion/ayudantias/SCRUM.pdf

ITZCOALT ALVAREZ M, Desarrollo Ágil con SCRUM, [20/03/2012],http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:sg07.p02.scrum.pdf

ORJUELA DUARTE AILIN, ROJAS C. MAURICIO, Las Metodologías de DesarrolloÁgil como una Oportunidad para la Ingeniería del Software Educativo,[2/06/2008],[20/03/2012],http://www.revista.unal.edu.co/index.php/avances/article/viewFile/10037/10567

FLOWERSINSPACE, Breve introducción a Scrum, [28/03/2012],http://www.slideshare.net/FlowersInSpace/introduccion-a-scrum-con-caso-prctico-1516220.

INFORME SCRUM

Documents

Transcript of INFORME SCRUM