INFORME SCRUM

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ón que se introduce por el centro. La complejidad de una melé hace que: “Si un miembro del equipo se viene abajo, se cae toda le melé ” En consecuencia, los jugadores deben estar bien coordinados, apoyándose en sus compañ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, porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto, realizado por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80 y restructurado por por Jeff Sutterland. Sutterland. 2. CARACTERÍSTICAS Scrum es un marco de trabajo ágil que se basa en la iteración y entrega de incrementales de 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 l os procesos. Emplea el modelo de construcción incremental increm ental basado en iteraciones y revisiones. Alta flexibilida f lexibilidadd 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áles funcionalidades y características funcionales tendrá el producto. Es quien representa al cliente, usuarios del software y todas aquellas partes interesadas en el producto, cuidando los 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 de retornar los objetivos de inversión (ROI), y los planes de revisión. Revisar el producto e ir adaptándole sus funcionalidades, analizando las mejoras  que é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 en forma 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 tomar decisiones sobre cómo realizar su trabajo. 



Funciones y responsabilidades: responsabilidades :  Tienen la responsabilidad, responsabili dad, en cada iteración, de transformar el Product Backlog en un incremento en la funcionabilidad del producto y planificar su propio trabajo para lograrlo. Los miembros del equipo son responsables en conjunto del éxito de cada iteración  y 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, que será el encargado de fomentar e instruir sobre los principios ágiles de Scrum, gracias a sus excelentes conocimientos de esta metodología. Protege al equipo de distracciones y de otros elementos externos. Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona. El Scrum Master es responsable del proceso Scrum, debe enseñar la metodología Scrum a cada integrante implicado en el proyecto, preocupándose de poner la metodología en práctica de modo que se encuentre dentro de la cultura de la organización y así entregue las ventajas previstas, asegurándose de que cada uno siga las Reglas y prácticas de Scrum. 

Funciones y responsabilidades: 

 



Garantizar la correcta aplicación de Scrum. Esto incluye, desde la correcta trasmisión de sus principios a las altas gerencias, hasta la prevención de la inversión roles (es decir, guardar especial cuidado en que el dueño de producto no actúe en nombre del equipo y viceversa, o que la audiencia se inmiscuya en tareas que 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 de vista del cliente. Es el área que en la ingeniería del software tradicional, cubren los requisitos 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 deter minado “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. Lo relevante 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ón de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados. 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 se quieren conseguir con el proyecto, comprendida y conocida por todo el equipo, y elementos 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 referencia para el equipo. Si se emplea formato de lista, es recomendable que al menos incluya la siguiente informació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, pueden resultar aconsejables otros campos como observaciones, criterio de validación, persona asignada, 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 pila del producto en las tareas necesarias para construir un incremento: una parte completa y operativa del producto. La realiza el equipo durante la reunión de planificación del sprint, en donde se estima cada tarea para luego ser asignada entre sus miembros; además, se indica en la misma lista cuánto tiempo falta aún para que la termine. Las duraciones estimadas de las tareas no 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 determinar el avance a diario, e identificar riesgos y problemas sin necesidad de procesos complejos de gestión. Es también una herramienta de soporte para la comunicación directa del equipo. 

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, lo apropiado es diseñar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:

6



 



Incluye la información: lista de tareas, persona responsable de cada una, estado en 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 le queda a cada tarea.

El Incremento El incremento es la parte de producto producida en un sprint, y tiene como características que está completamente terminada, probada y operativa, en condiciones de ser entregada al cliente final. No se trata por tanto de módulos o partes a falta de pruebas, o documentación. Idealmente en el desarrollo ágil:

7





Cada funcionalidad de la pila del producto se refiere a funcionalidades entregables, no a trabajos interno s 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ño o 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 y verificación documentados, o con niveles de independencia que implican procesos con terceros, é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 que forman parte del modelo y la retrospectiva que nos ayuda a reconocer los problemas y a plantear 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 del cliente, y se determina cuáles y cómo van a ser las funcionalidades que incorporará el producto 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 prioridad para 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 el equipo. De esta forma su estimación previa del trabajo que se puede realizar en el sprint será bastante ajustada. El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para realizar estimaciones basadas en "juicio de expertos”, y para comprender los conceptos del negocio que expone el propietario del producto.

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 de  este 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 define el “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 de tareas desordenadas (que deberían ser los menos), la elaboración de este lema de forma conjunta en la reunión es una garantía de que todo el equipo comprende y comparte la finalidad del trabajo; y durante el sprint sirve de criterio de referencia en las decisiones que 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 tareas de la pila del sprint, el equipo debe tener en cuenta los elementos de diseño y arquitectura que deberá incorporar el sistema. Los miembros del equipo se auto-asignan las diferentes tareas tomando como criterios sus conocimientos, intereses y distribución homogénea del trabajo. El objetivo del Product Owner 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 dice las tareas en las que está trabajando, si se ha encontrado o prevé encontrarse con algún impedimento, y actualiza sobre la pila del sprint las ya terminadas, o los tiempos de trabajo 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 de la 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 de necesidades 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 su trabajo. Y actualiza sobre el sprint backlog el tiempo de trabajo que queda pendiente en las 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, el equipo presenta al Product Owner , clientes, usuarios, gestores… el incremento construido en 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 la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el Product Owner, y el equipo en general obtienen  feedback clave para evolucionar y dar más valor a la pila del producto. El Scrum Master obtiene retroinformación sobre buenas prácticas y problemas  durante el sprint, necesaria para las prácticas de ingeniería de procesos y mejora continua 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 debe invertir 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 puede incluir 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ían y las que se han desarrollado. 2.- El equipo hace una introducción general del sprint y demuestra el funcionamiento de las 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 Product Owner 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ón del 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 surgiendo prácticas para lo que sería el equivalente de mejora continua de la agilidad de la organización; y en esta línea, las reun iones 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 las mejoras posibles para trabajos futuros. 6. MEDICION ¿Para que medir?: Dentro de la metodología SCRUM es necesario medir para verificar el cumplimiento de los objetivos planteados en un tiempo transcurrido, estas nos proporcionan criterios objetivos de 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, y la 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 y así 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 lo necesario, ya que si no lo es solo supondrán un coste de gestión evitable; muchas veces empeorará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 los departamentos, combinándola con otra que es la de tiempo de respuesta. Si la implantación del indicador ha dado buenos resultados: el departamento ha comenzado a ser 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 la empresa. 2.- Va reduciendo los tiempos de respuesta a los departamentos que solicitan nuevo personal. Medición del avance del proyecto La organización ha diseñado un cuadro de información para mostrar el grado de avance de cada proyecto. Los indicadores de progreso de los proyectos, y de las tareas en las que se descomponen; se elaboran con el sistema clásico de la gestión de proyectos predictiva: 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 cada proyecto. 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. El resultado 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 un aumento de los errores por programar más deprisa, se ha dotado de mayor “rigor” al sistema de métrica, incorporando al poco tiempo otras métricas para complementar y mejorar 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 realizada por unidad de tiempo. Velocidad = Trabajo / Tiempo 

Tiempo

El desarrollo ágil emplea la técnica “timeboxing”6 para gestión de tiempo. En el caso de Scrum, la unidad de tiempo para cada incremento de producto es el Sprint. Podemos diferenciar 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 a la tarea del sprint que se tiene asignada.

Trabajo

Medir el trabajo puede ser necesario por dos razones: para registrar lo ya hecho, o para estimar anticipadamente, el que hay que realizar. En ambos casos se necesita una unidad, 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 unidades relativas 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 proyecto por 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 el producto, como los tradicionales puntos de función de COCOMO; o indirectamente, a travé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 de trabajo 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 todos los 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 en un periodo de tiempo. Los equipos que miden el trabajo con tiempo ideal, hablan de “Velocidad”. Si en el sprint siguiente consiguen una velocidad mayor, querrá decir que han logrado programar más story 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 de interrupciones, distracciones o dedicados a otras tareas.

Se le puede llamar velocidad o eficiencia, cuando un equipo en un siguiente sprint logra programar más story points. Velocidad y eficiencia son términos similares. Se suele preferir “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 ninguna ambigüedad. Deben ser breves, concretas y algo estimables. Son el resultado de escuchar al cliente y ayudarle a resumir el requisito en una sola frase. Algo muy importante es que están escritas con el vocabulario del negocio del cliente, no con vocabulario técnico. Ejemplo:

16

Cada historia provoca una serie de preguntas acerca de los múltiples contextos en que se puede dar. Son las que naturalmente hacen los desarrolladores a los analistas de negocio o 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 deben transformar en test de aceptación. Por tanto, cada historia de usuario tiene asociados uno o varios test de aceptación (ejemplos):

Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otras historias que pasan a engrosar el backlog o lista de requisitos: “Si el libro no está en stock, se enviará un email al usuario cuando lle gue”. Gráfico de producto o burn-up: Es una herramienta de planificación y seguimiento del propietario del producto, que muestra de un vistazo, en un gráfico muy simple el plan general de desarrollo del producto, 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, medidas segú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 útil esbozar una estimación optimista y otra pesimista para tener la visión de fechas aceptables. La línea de velocidad proyecta sobre el eje X la fecha o sprint en el que previsiblemente 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 pila de 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 comprobar el ritmo de avance, y detectar desde el primer momento si es el previsto, o se puede ver comprometida la entrega prevista al final del sprint. La estrategia ágil para el seguimiento de los proyectos se basa en medir el esfuerzo que falta, no el realizado y el seguimiento muy cercano (diario de ser posible), en este gráfico toman 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 cada uno figura el esfuerzo pendiente. El primer día, en la pila de tareas figura para cada tarea el 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 a las tareas que va desarrollando, hasta que se terminan y van quedando en 0 los tiempos pendientes. 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 esfuerzo en 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 por encima o bajo ella lo que significa que se debe quitar o agregar elementos del Sprint backlog.

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

19

El funcionamiento es muy simple: cada participante dispone de un juego de cartas, y en la estimación de cada tarea, todos vuelven boca arriba la combinación que suma el esfuerzo estimado. Cuando se considera que éste es mayor al tamaño máximo considerado por el equipo para una tarea , se levanta la carta “ &”. Cada equipo u organización puede utilizar un juego de cartas con las numeraciones adecuadas a la unidad de esfuerzo con la que trabajan, y el tamaño máximo de tarea que se va a estimar. Sin embargo hay que respetar los siguientes principios: 





No definir tareas demasiado grandes, porque entorpece la precisión de las estimaciones 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 Backlog conocido junto a un costo y cronograma estimados. Si un nuevo sistema empieza a desarrollarse, 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 la creació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 mira a las variables tiempo, requerimientos calidad, costo y competencia. La interacción con estas variables define el final de esta fase. Son múltiples los Sprints o ciclos usados para desarrollar el sistema. Dentro del Sprint la retroalimentación se obtiene con las reuniones diarias (ScrumMeetings) y el control de la curva de progreso burnup. 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 y entrega. Tareas:  integración, pruebas del sistema, documentación de usuario, preparación del  material de formación y marketing. 9. EJEMPLO DE SCRUM

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

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

22

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

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

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

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

El equipo comienza su trabajo desglosando la primera historia de la pila de producto, la cual 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 en tareas 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 ha consultado con el cliente, antes de comenzar el sprint.

24

El equipo comienza el sprint tomando las tareas priorizadas. Una vez concluida una se toma la siguiente de la lista. Se convoca todos los días una reunión del equipo donde se cuenta 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 puede volver 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 se analiza 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 de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos. Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

25







 

Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión. Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del 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 el Backlog. 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 sobre varios sprints. Esta metodología necesita solo miembros de equipo experimentados. Si el equipo consiste 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, puede ser extremadamente frustrante para ellos, llevando a la desmoralización y el fallo del proyecto. Si algunos de los miembros del equipo se marcha durante el desarrollo puede tener un efecto negativo enorme en el desarrollo del proyecto. 11. ¿QUIÉN USA SCRUM?     

Microsoft Electronic Arts Nokia Capital One Telefónica

    

Yahoo Philips Ericsson BBC BMC Software

   

Google Siemens IBM F-Secure

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 de 2011], [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-lastrincheras.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-prctico1516220.