DESARROLLO

Scrum controla de forma empírica y adaptable la evolución del proyecto, empleando las siguientes prácticas de la gestión ágil:

3.1. Revisión de las Iteraciones
Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto.

3.2. Desarrollo incremental
Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones.
El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.

3.3. Desarrollo evolutivo
Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos.
Intentar predecir en las fases iniciales cómo será el producto final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces.
Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la arquitectura que se irá generando durante el desarrollo.
El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto. No los considera como productos que deban realizarse en la primera “fase” del proyecto. (El desarrollo ágil no es un desarrollo en fases)

3.3.1. Auto-organización
Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos.
En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas.

3.3.2. Colaboración
Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la auto organización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto.

3.3.3. Desarrollo Ágil
Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad dedesarrollo y que pueden llevarse a cabo en unperiodo de tiempo breve (normalmente de 30días).
Cada uno de estos periodos de desarrollo es unaiteración que finaliza con laproducción de unincremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, yScrum gestiona su evolución a través dereuniones breves diarias en las que todo elequipo revisa el trabajo realizado el día anterior yel previsto para el día siguiente.



3.3.4. Reuniones en Scrum
3.3.4.1. Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:
• La reunión comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo para quien llegue tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello, etc.).
• Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
• La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
• Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
• La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
• Durante la reunión, cada miembro del equipo contesta a tres preguntas:
• ¿Qué has hecho desde ayer?
• ¿Qué es lo que estás planeando hacer hoy?
• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

3.3.4.2. Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
• Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose especialmente en áreas de solapamiento e integración.
• Asiste una persona asignada por cada equipo.
• La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
• ¿Qué ha hecho tu equipo desde nuestra última reunión?
• ¿Qué hará tu equipo antes que nos volvamos a reunir?
• ¿Hay algo que demora o estorba a tu equipo?
• ¿Estás a punto de poner algo en el camino del otro equipo?


3.3.4.3. Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva a cabo.
• Seleccionar que trabajo se hará
• Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo.
• Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint
• Ocho horas como límite
• Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión del Sprint” y la “Retrospectiva del Sprint”


3.3.4.4. Reunión de Revisión del Sprint (Sprint Review Meeting)
• Revisar el trabajo que fue completado y no completado
• Presentar el trabajo completado a los interesados (alias “demo”)
• El trabajo incompleto no puede ser demostrado
• Cuatro horas como límite

3.3.4.5. Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.


3.3.5. Documentos
3.3.5.1. Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su valor para el negocio (business value). Es el qué va a ser construido. Es abierto y cualquiera puede modificarlo. Contiene estimaciones grosso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

3.3.5.2. Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.

3.3.5.3. Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos.

3.3.6. Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.



La ficha adjunta incluye una descripción sinóptica del proceso y sus elementos que son:
• Roles: Propietario del producto, Gestor o Manager del Scrum, Equipo e Interesados.
• Componentes del proceso: Pila del producto (Product Backlog), Pila del sprint (Sprint Backlog), Incremento.
• Reuniones.
• Planificación del sprint, Revisión diaria, Revisión del sprint.
• Sprint