Informe Scrum

26
UNIVERSIDAD DE ORIENTE NÚCLEO DE ANZOÁTEGUI COORDINACIÓN DE POSTGRADO MAESTRÍA EN INFORMÁTICA GERENCIAL ASIGNATURA: GERENCIA ESTRATÉGICA DE PROYECTOS METODOLOGÍA SCRUM FACILITADOR: Prof. Andrés Martínez PARTICIPANTES: María Santamaría Angel Espinoza Abraham Morales 0

description

metodologia Scrum

Transcript of Informe Scrum

Page 1: Informe Scrum

UNIVERSIDAD DE ORIENTE

NÚCLEO DE ANZOÁTEGUI

COORDINACIÓN DE POSTGRADO

MAESTRÍA EN INFORMÁTICA GERENCIAL

ASIGNATURA: GERENCIA ESTRATÉGICA DE PROYECTOS

METODOLOGÍA SCRUM

FACILITADOR:Prof. Andrés Martínez

PARTICIPANTES:María SantamaríaAngel EspinozaAbraham Morales

Barcelona, Octubre de 2015

0

Page 2: Informe Scrum

ÍNDICE GENERAL

1. Introducción ______________________________________________________________2 1.1 Principales características ________________________________________________ 2 1.2 Principales elementos de la metodología____________________________________ 2 1.3 Esquema general _______________________________________________________ 3

2. Herramientas y Practicas ____________________________________________________5 2.1 Product Backlog List ___________________________________________________5

2.2 Sprints _______________________________________________________________ 5 2.3 Reunión diaria de sincronización del equipo (Scrum Daily Meeting)_____________6

2.4 Demostración de los requisitos completados (Sprint Review)____________________72.5 Retrospectiva (Sprint Retrospective)________________________________________8

3. 2.3 Burn down Chart _______________________________________________________ 6 2.4 Sprint Backlog_________________________________________________________ 7 2.5 Stabilization Sprints _____________________________________________________ 7 2.6 Scrum of Scrums o MetaScrum____________________________________________ 7

4. El Proceso ________________________________________________________________8 3.1 Pregame Phase ________________________________________________________ 9 3.2 Development Phase____________________________________________________10

5. Roles y Responsabilidades__________________________________________________11 4.1 Scrum Master _________________________________________________________11 4.2 Product Owner ________________________________________________________11 4.3 Scrum Team__________________________________________________________11 4.4 Customer ____________________________________________________________11 4.5 Management _________________________________________________________11

6. Visión General del Modelo_________________________________________________12 7. Conclusion__________________________________________________________17

8. Bibliografías _____________________________________________________________13

1

Page 3: Informe Scrum

1. INTRODUCCION

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. Scrum es una metodología ágil, y como tal: Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.

Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).

Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto.

Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente.

El ciclo de vida definido por Scrum es incremental iterativo y se caracteriza por ser muy adaptable.

1.1 Principales características Equipos autodirigidos Utiliza reglas para crear un entorno ágil de administración de proyectos No prescribe prácticas específicas de ingeniería Los requerimientos se capturan como ítems de la lista Product Backlog El producto se construye en una serie de Sprints de un mes de duración

1.2 Principales elementos de la metodología

Herramientas

Product Backlog Sprint Backlog

Prácticas

Sprints Sprint Planning Meeting Daily Meetings

2

Page 4: Informe Scrum

Sprint Review Meeting Design Review Meeting Stabilization Sprints Meta Scrums

Roles y responsabilidades

Scrum Master Product Owner Scrum Team Customer Management

1.3 Esquema general

En el esquema anterior se muestra en forma esquemática el proceso de desarrollo de Scrum.

El trabajo a ser realizado en un proyecto Scrum es listado en el Product Backlog, que es una lista de todos los cambios requeridos sobre un producto.

3

Page 5: Informe Scrum

Los proyectos se realizan durante una serie de iteraciones de un mes de duración llamadas Sprints. Al comienzo de cada Sprint tiene lugar una Sprint Planning Meeting durante la cual el Product Owner prioriza el Product Backlog y el Scrum Team selecciona las tareas que serán completadas durante el Sprint que va a comenzar. Esas tareas son removidas del Product Backlog para ser llevadas al Sprint Backlog.

Durante el Sprint el equipo se mantiene en contacto a través de las Daily Meetings. Y al final del Sprint debe mostrar la funcionalidad completa en la Sprint Review Meeting.

¿Cómo funciona la Metodologia Scrum?

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita).

Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la replanificación de objetivos que realiza al inicio de cada iteración.

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se autoasignan las tareas.

Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:

• ¿Qué he hecho desde la última reunión de sincronización?

4

Page 6: Informe Scrum

• ¿Qué voy a hacer a partir de este momento?

• ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

• Elimina los obstáculos que el equipo no puede resolver por sí mismo.

• Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.

2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

5

Page 7: Informe Scrum

2. HERRAMIENTAS Y PRACTICAS

Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado por la complejidad e imposibilidad de realizar predicciones.

2.1 Product Backlog List

Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin embargo, suelen surgir los más importantes que casi siempre son más que suficientes para un Sprint.

La Product Backlog List puede crecer y modificarse a medida que se obtiene más conocimiento acerca del producto y del cliente. Con la restricción de que solo puede cambiarse entre Sprints. El objetivo es asegurar que el producto definido al terminar la lista es el más correcto, útil y competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el producto.

Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar cualquier modificación sobre la lista por ejemplo: agregar o incrementar la prioridad de sus elementos tiene que convencer al Product Owner.

2.2 Sprints

Un Sprint es el procedimiento de adaptación de las cambiantes variables del entorno (requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante un Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño evolucionan durante el desarrollo.

El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y esté siempre presente en el equipo. Es posible definir una serie de restricciones que el equipo deba aplicar durante un Sprint.

Un Sprint tiene una duración planificada de entre una semana y un mes. No es posible introducir cambios durante el Sprint, por lo tanto para planificar su duración hay que pensar en cuanto tiempo puedo comprometerme a mantener los cambios fuera del Sprint. Dependiendo del tamaño del sistema, la construcción de un release puede llevar entre 3 y 8 Sprints. Por otra parte podrían formarse equipos para desarrollar en forma paralela distintos grupos de funcionalidad.

6

Page 8: Informe Scrum

Las actividades que se desarrollan durante del Sprint son: Sprint Planning Meeting, Sprint Backlog, Daily Scrum Meetings y Sprint Review Meeting. En la siguiente gráfica se pueden ver las prácticas involucradas en un Sprint.

2.3 Reunión diaria de sincronización del equipo (Scrum Daily Meeting)

El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.

Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para al finalizar la reunión poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el equipo adquirió para la iteración (en la reunión de planificación de la iteración).

Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cómo máximo 15 minutos:

• ¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?

• ¿Qué voy a hacer a partir de este momento?

7

Page 9: Informe Scrum

• ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteración y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, así como con el gráfico de horas pendientes en la iteración.

Beneficios

• Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto:

Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o por que hay dependencias (especialmente si existe un retraso).

Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar los impedimentos que el equipo no puede solucionar por sí solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.

Las tareas no planeadas que está realizando que el equipo no conoce y puede que no estén alineadas con el compromiso del equipo, aunque él crea que lo que está haciendo es lo mejor que se puede hacer.

Cuáles son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el máximo valor y no realizar tareas que no proporcionan ningún beneficio al resto del equipo.

Cuál es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo está realizando tareas por debajo del rendimiento esperado. Se evita que una persona señale con el dedo a otra, dado que la reunión de sincronización pone a todos los miembros del equipo en la misma situación de tener que explicar en qué tareas están trabajando.

Cuáles son los criterios que está utilizando para realizar sus tareas, de manera que estén alineados con los objetivos comunes del equipo.

• Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan los otros según sus especialidades y experiencias.

• Conocer el estado de la iteración, ver si es posible completar los requisitos a que se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.

Restricciones

• La reunión diaria de estado y sincronización del equipo no es para resolver problemas, los problemas se resuelven después de la reunión.

8

Page 10: Informe Scrum

No a todos los miembros del equipo les interesan todos los detalles de cada tema. En la reunión los miembros del equipo programan reuniones entre ellos donde colaborar

sincronizando tareas, ayudando a resolver problemas, etc. No puede haber una persona explicando su estado mientras otras "se han apartado" de la

reunión para comentar un tema particular. Si apareciese alguna conversación de interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin distraer el principal objetivo de que todos conozcan en qué están trabajando los demás. Si la mini conversación no es del interés de todos, debe hacerse después de la reunión.

• El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución de las de tareas

El proceso de ejecución de las tareas debe estar consensuado para evitar que cada reunión sea una exposición de discrepancias entre los miembros del equipo.

Recomendaciones

• Realizar la reunión diaria de sincronización de pie, para que los miembros del equipo no se relajen ni se extiendan en más detalles de los necesarios.

• Realizar las reuniones de colaboración entre miembros del equipo justo después de la de sincronización.

2.4 Demostración de los requisitos completados (Sprint Review)

Reunión informal donde el equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al objetivo que se pretende cubrir.

En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto. Se realiza en un timebox de cómo máximo 4 horas.

Beneficios

El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos que proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que necesita y tomar mejores decisiones respecto al proyecto.

El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.

El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va obteniendo. No está meses trabajando sin poder exhibir su obra.

Restricciones

9

Page 11: Informe Scrum

Sólo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedará como un requisito más a replanificar.

2.5 Retrospectiva (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que está desarrollando, el equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no:

Qué cosas han funcionado bien. Cuales hay que mejorar. Qué cosas quiere probar hacer en la siguiente iteración. Qué ha aprendido. Cuáles son los problemas que podrían impedirle progresar adecuadamente. El Facilitador

se encargará de ir eliminando los obstáculos identificados que el propio equipo no pueda resolver por sí mismo.

Notar que esta reunión se realiza después de la reunión de demostración al cliente de los objetivos conseguidos en la iteración, para poder incorporar su feedback y cumplimiento de expectativas como parte de los temas a tratar en la reunión de retrospectiva

Se realiza en un timebox de cómo máximo 3 horas (si la iteración es mensual).

Beneficios

Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera sistemática, iteración a iteración, con resultados a corto plazo.

Aumenta la motivación del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir eliminando lo que molesta e impide que sea más productivo.

Restricciones

En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es frustrante encontrar sistemáticamente los mismos obstáculos y no poder solucionarlos

2.6 Burn down Chart

10

Page 12: Informe Scrum

En Scrum se planifica y mide el esfuerzo restante necesario para desarrollar el producto. Esta gráfica suele utilizarse en lugar de un diagrama de PERT debido a que el camino crítico en un desarrollo ágil cambia diariamente. Esto haría obsoleto el diagrama de PERT cada día. Es por esto que no es útil una herramienta que modele el camino crítico a partir de actividades. La solución es utilizar una técnica que permita medir la velocidad de desarrollo. Para esto se utiliza el criterio del equipo a partir del cual se calcula diariamente el camino crítico. Esto permite recalcular el plan y la velocidad en que se realiza el trabajo. En función de esto el equipo puede trabajar para acelerar o desacelerar el trabajo para cumplir con la fecha de entrega.

2.7 Sprint Backlog

Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog List que van a ser implementados en el siguiente Sprint.

Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la Sprint Planning Meeting a partir de la priorización de los ítems y los objetivos que se marcaron para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum Team determina que tareas debe desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog. Es importante destacar que es el equipo quien se organiza para alcanzar el objetivo. El Manager no asigna tareas a los individuos y tampoco toma decisiones por el equipo. El equipo puede agregar nuevas tareas o remover tareas innecesarias en cualquier momento si lo considera necesario para cumplir el objetivo. Pero el Sprint Backlog solo puede ser modificado por el equipo. Las estimaciones se actualizan cada vez que aparece nueva información.

2.8 Stabilization Sprints

En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad. Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están realizando

11

Page 13: Informe Scrum

pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o cuando la calidad de un producto no alcanza los límites esperados.

No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta metodología.

2.9 Scrum of Scrums o MetaScrum

Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo está metodología ha sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a cabo dividiendo a los accionistas en equipos de pequeños de hasta 10 personas aproximadamente. Y definiendo jerárquicamente personas que pertenecen a dos equipos, es decir, además de su rol específico dentro de un equipo tienen el rol de enlace en un equipo superior.

3 EL PROCESO

Scrum consta de tres fases: Pregame, Development y Postgame.

La fase de Pregame incluye dos subfases: Planning y Architecture

Planning

12

Page 14: Informe Scrum

Consiste en la definición del sistema que será construido. Para esto se crea la lista Product Backlog a partir del conocimiento que actualmente se tiene del sistema. En ella se expresan los requerimientos priorizados y a partir de ella se estima el esfuerzo requerido. La Product Backlog List es actualizada constantemente con ítems nuevos y más detallados, con estimaciones más precisas y cambios en la prioridad de los ítems.

Architecture / High level Design

El diseño de alto nivel del sistema se planifica a partir de los elementos existentes en la Product Backlog List. En caso de que el producto a construir sea una mejora a un sistema ya existente, se identifican los cambios necesarios para implementar los elementos que aparecen en la lista Product Backlog y el impacto que pueden tener estos cambios. Se sostiene una Design Review Meeting para examinar los objetivos de la implementación y tomar decisiones a partir de la revisión. Se preparan planes preliminares sobre el contenido de cada release.

La fase de Development también llamada Game Phase es la parte ágil de Scrum:

En esta fase se espera que ocurran cosas impredecibles. Para evitar el caos Scrum define prácticas para observar y controlar las variables técnicas y del entorno, así también como la metodología de desarrollo que hayan sido identificadas y puedan cambiar. Este control se realiza durante los Sprints. Dentro de variables de entorno encontramos: tiempo, calidad, requerimientos, recursos, tecnologías y herramientas de implementación. En lugar de tenerlas en consideración al comienzo del desarrollo, Scrum propone controlarlas constantemente para poder adaptarse a los cambios en forma flexible.

La fase de PostGame:

Contiene el cierre del release. Para ingresar a esta fase se debe llegar a un acuerdo respecto a las variables del entorno por ejemplo que los requerimientos fueron completados. El sistema está listo para ser liberado y es en esta etapa en la que se realiza integración, pruebas del sistema y documentación.

3.6 Pregame Phase

Entrada: La concepción inicial del producto que tienen los accionistas o interesados.

Tareas

Nombre de la tarea Descripción Responsables Requerida/ Opcional

Crear la Product Backlog List y controlar su consistencia

Posibles elementos de esta lista son requerimientos técnicos y del negocio, funciones, errores a reparar, defectos, mejoras y actualizaciones tecnológicas requeridas. Es importante controlar la consistencia de la lista. Para esto se agregan, modifican, eliminan, especifican y

Product Owner Requerida

13

Page 15: Informe Scrum

priorizan sus elementosPriorizar la Product Backlog List

Esta actividad se basa en considerar que elementos tienen más o menos influencia en el éxito del proyecto en un momento dado; considerando que los elementos con mayor prioridad se realizan primero.

Product Owner Requerida

Effort Estimation Es un proceso iterativo que reúne toda la información que haya acerca un elemento para tener un mayor nivel de precisión en la estimación.Siempre se mide el esfuerzo que falta para cumplir con el / los objetivos tanto a nivel de la lista Product Backlog como para el Sprint Backlog (lo que resta).

Product Owner

Scrum TeamRequerida

Design Review Meeting En esta instancia se comunica el diseño a los interesados para revisar el cumplimiento de los ítems especificados en el Product Backlog

Requerida

Verificación: Deben estar realizadas todas las tareas requeridas

Salida: Product Backlog List, Arquitectura

3.7 Development Phase

Entrada: Product Backlog List

Tareas

Nombre de la tarea Descripción Responsables Requerida/ Opcional

Sprint Planning Meetin

Es una reunión organizada por el Scrum Master, que se realiza en dos fases. La primera fase tiene como objetivo establecer que ítems de la Product Backlog List van a ser realizados durante el Sprint. Esto se realiza a partir de lo que el Scrum Team considera que puede construir durante el Sprint.

Scrum Master Customer, User ManagementProduct Owner Scrum Team

RequeridaEn la segunda fase se decide como se van a alcanzar los objetivos del Sprint. En esta fase se crea la Sprint Backlog, indicando qué tareas debe desempeñar el equipo para cumplir con dichos objetivos.

Scrum TeamScrum Master Product Owner

Daily Scrum Meeting Las reuniones se realizan en el mismo lugar y a la misma hora cada día. Idealmente en la mañana para definir el trabajo para el día. Tienen una duración de 15 minutos y los participantes se quedan parados. Estas reuniones no se utilizan para resolver problemas. En ellas se realizan tres preguntas:

¿Qué hiciste ayer? ¿Qué harás hoy? ¿Qué obstáculos ves en tu camino?

Los participantes son clasificados según el compromiso que tengan con las actividades del proyecto en dos categorías: gallinas y chanchos1 . Los chanchos son los que están más comprometidos y por lo tanto son los que pueden hablar y brindar opiniones. Esto ayuda a evitar reuniones innecesarias.

Scrum Team Requerida

1 Esto proviene del siguiente cuento: “En una tortila de jamón y huevo, la gallina participa pero el chancho está comprometido, porque él deja la vida, mientras que la gallina solo pone los huevos”.

14

Page 16: Informe Scrum

Estas reuniones no pueden ser sustituidas por reportes vía mail por dos motivos:

El equipo entero ve todo el paisaje cada día Es un elemento de presión para que el

individuo haga lo que dijo que va a hacerSprint Review Meeting Es una reunión informal que tiene como regla que su

preparación no puede tomar más de 2 horas. En ella el equipo presenta lo que ha logrado durante el Sprint. Generalmente toma la forma de una demo de las nuevas características o la arquitectura

Customers Management Product Owner otros interesados

Requerida

Verificación: Durante un sprint se puede acortar funcionalidad pero la fecha de entrega debe ser respetada.

Salida: Incremento del producto

4 ROLES Y RESPONSABILIDADES

4.6 Scrum Master

Es un rol de administración que debe asegurar que el proyecto se está llevando a cabo de acuerdo con las prácticas, valores y reglas de Scrum y que todo funciona según lo planeado. Su principal trabajo es remover impedimentos y reducir riesgos del producto. Este rol suele ser desempeñado por un Gerente de Proyecto o Líder de equipo.

4.7 Product Owner

Es el responsable del proyecto, administra, controla y comunica la Backlog List. Es el responsable de encontrar la visión del producto y reflejarla en la Backlog List. Generalmente esta persona puede ser el Product Manager, Marketing, Internal Customer, etc.

4.8 Scrum Team

Es el equipo del proyecto que tiene la autoridad para decidir como organizarse para cumplir con los objetivos de un Sprint. Sus tareas son: Effort Estimation (Estimar Esfuerzo), crear el Sprint Backlog, revisar la Product Backlog List y sugerir obstáculos que deban ser removidos para cumplir con los items que aparecen.

Típicamente es un equipo de entre 5 y 10 personas cada una especializada en algún elemento que conforma los objetivos a cumplir, por ejemplo: Programadores, Diseñadores de Interfaz de usuario, etc. La dedicación de los miembros del equipo debería ser full-time con algunas excepciones. La membresía solo puede cambiar entre sprints (no durante).

4.9 Customer

El cliente participa en las tareas que involucran la lista Product Backlog.

15

Page 17: Informe Scrum

4.10 Management

Es el responsable de tomar las decisiones finales, acerca de estándares y convenciones a seguir durante el proyecto. Participa en la selección de objetivos y requerimientos y en la selección del Scrum Owner. Tiene la responsabilidad de controlar el progreso y trabaja junto con el Scrum Master en la reducción de la Product Backlog List

16

Page 18: Informe Scrum

17

Page 19: Informe Scrum

5 VISIÓN GENERAL

18

Page 20: Informe Scrum

6 Conclusión

Scrum se basa en el desarrollo incremental de los requisitos del proyecto en bloques

temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se

necesita). La priorización de los requisitos por valor para el cliente y coste de desarrollo en

cada iteración. El control empírico del proyecto. Por un lado, al final de cada iteración se

demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones

necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro

lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.

La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le

otorga la autoridad necesaria para organizar su trabajo. La sistematización de la colaboración y

la comunicación tanto entre el equipo y como con el cliente. El timeboxing de las actividades

del proyecto, para ayudar a la toma de decisiones y conseguir resultados.

Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la

manera de trabajar de equipos altamente productivos.

19

Page 21: Informe Scrum

7 BIBLIOGRAFIA

Schwaber, K. (1995). SCRUM Development Process. Burlington: OOPSLA 95.

[AgileJournal] Revista electrónica sobre metodologías de desarrollo de software. Agile Journal, nº1, Marzo-2006. Http:// www.agilejournal.com. Accedido 05/12/2011.

Abrahamsson, Salo, Ronkainen & Warsta (2002) “Agile software development methods. Review and analysis”. www.info.vtt.fi/pdf/ Sutherland, Jeff (2001) “Inventing and Reinventing SCRUM in Five Companies”

MountainGoatSoftware – http://www.mountaingoatsoftware.com/scrum/index.php

20