Ingeniería de Software Facultad de Ingeniería Septiembre 2010 Fernando Alsuyet Ariel Illio Matias Baldini

¿Qué es Scrum? Scrum es una metodología para el desarrollo ágil de productos. Define un conjunto de prácticas y roles que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Se originó principalmente en base a que los mercados exigían:  Rapidez y flexibilidad  Ciclos de desarrollo más cortos.

Características  Inestabilidad consustancial al entorno de desarrollo.  Equipos auto-organizados.  Solapamiento de las fases del desarrollo.  Evita la burocracia y la generación documental.  La idea principal es la de ponerse a trabajar prácticamente desde el primer momento.

¿Cómo se Aplica? Scrum es simple en su composición. Lo podemos ver como 3 grandes bloques principales:  Las Personas.  Las Reuniones.  Los Artefactos.

Las Personas Todos tienen su lugar en Scrum, solo que su función ha sido redefinida para que los equipos sean más funcionales y menos burocráticos. Los principales Roles son:  Product Owner  ScrumMaster  El Equipo

Product Owner  Representa a la empresa / usuarios.  Define los requerimientos y funciones del sistema.  Prioriza las funciones a desarrollar de acuerdo al valor que aporten al negocio o mercado.  Decide cuando liberar el producto del proyecto.  Es el responsable directo sobre la recuperación de la inversión (RoI).  Acepta o rechaza el resultado del trabajo del equipo.

ScrumMaster  Tiene la figura de líder de proyecto.  Es quien determina que tareas se deben hacer, quien debe hacerlas, cuando y durante cuanto tiempo y cuanto costarían esas tareas.  Tiene como responsabilidad que el esfuerzo de desarrollo sea exitoso.  Protege al equipo de interferencias externas.  Mantiene el enfoque y efectividad del equipo.  Evangeliza los principios, valores y prácticas de scrum en toda la organización.  Es un facilitador.  Elimina los impedimentos que el equipo de desarrollo tenga para hacer su trabajo.

El Equipo  Está compuesto por las personas que diseñan, programan, prueban e implementan el sistema o producto de software.  Típicamente de 5 a 9 personas.  Multifuncional (todos diseñan, programan, prueban).  De tiempo completo.  Auto ‑ administrados. No se les asigna trabajo, cada uno selecciona tareas de la lista de tareas por hacer.  La composición del equipo no puede cambiar durante la iteración.

Las Reuniones  Inicio de Sprint  SDM (Scrum Daily Meeting)  Revisión del sprint  Retrospectiva del Sprint.

Inicio de Sprint Características:  Definir el objetivo del sprint. Este objetivo es una descripción textual de una meta tipo SMART que tanto el dueño del producto, el scrum master y el resto del equipo puedan fácilmente visualizar.  Hacer una estimación del tiempo de los requerimientos de más alta prioridad y seleccionar sobre esa base cuantos se pueden lograr terminar en el sprint. Para hacer lo anterior, el equipo y el scrum master desglosan las tareas de programación necesarias para poder considerar terminado cada uno de los requerimientos aceptados para el sprint.  Tiempo Máximo: 1 día Resultado:  La meta del sprint  El backlog del sprint

SDM (Scrum Daily Meeting)  Tiempo máximo: 15 minutos  Ocurre todos los días a la misma hora y en el mismo lugar.  Cada uno de los miembros del equipo y el Scrum Master tienen la responsabilidad y obligación de asistir.  Durante estos 15 minutos cada miembro del equipo responde a tres preguntas ¿Que hiciste/lograste ayer? ¿Que vas a hacer/lograr hoy? ¿Que impedimentos tienes para lograrlo?  El Scrum Master tiene la responsabilidad de registrar los impedimentos que el equipo haya señalado y de eliminarlos a toda costa.

Revisión del Sprint  Se programa anticipadamente como resultado de la planeación del sprint.  El equipo hace una demostración de la funcionalidad de la pieza (o piezas) de software que se terminaron durante el sprint.  Esta demostración se hace directamente en las computadoras del equipo sin mucha preparación previa.  Duración: Por lo menos 4 horas y 8 como máximo.  Si hay nuevos requerimientos durante la revisión, estos se integran al backlog del producto para ser priorizados por el Product Owner antes de la reunión de planeación del siguiente sprint.  El Product Owner debe aprovechar esta reunión para conocer las opiniones del resto de los interesados, integrar sus propios requerimientos y adaptar el proyecto con una visión renovada.

Retrospectiva del Sprint  El equipo se reúne para evaluar el desempeño durante el sprint recién terminado y como se puede aprender de lo que acaba de terminar para mejorar lo que esta por empezar.  Se responde los siguientes interrogantes: Que SI funciona para seguir haciéndolo... Que NO funciona para dejar de hacerlo y... Que podemos empezar a hacer para que funcione MEJOR

Los Artefactos  Product Backlog  Sprint Backlog  Gráfico Burndown

Product Backlog  Es un simple listado de requerimientos expresados en forma de Historias de Usuario (User Stories) y estimados en alguna unidad representativa del tiempo.  Deben estar expresadas exclusivamente en el lenguaje del negocio y deben aportar un valor real al mismo que pueda ser definido y visualizado por cualquiera que conozca el problema.  Debe incluir el mayor número de requerimientos para estimar el número de Sprints necesarios para terminar con el proyecto.  Es la herramienta principal para desarrollar y estimar el plan de liberación del producto.

Sprint Backlog  Una vez que se seleccionan los requerimientos del Product Backlog, se definen y estiman las tareas de programación para cada uno de los requerimientos aceptados para el sprint.  La duración de cada una de las tareas se puede estimar en horas o en las unidades que se estiman los elementos del backlog del producto.  Las tareas de programación deben ser tareas específicas para que puedan ser completadas en un día laboral.  Si es menor de 4 horas quizás sea necesario considerar esa tarea como parte de otra.  Si es mayor a 12 horas la tarea debe desglosarse un poco más.  El objetivo es que se desglosen tareas a las que un miembro del equipo se pueda comprometer terminar de un Sprint a otro.

Gráfica de Burndown  Este gráfico permite conocer de manera ágil y visual el progreso o no de los trabajos del proyecto.  La suma de las estimaciones de las tareas pendientes por terminar de cada día es graficada como un punto en la gráfica.  En el eje horizontal se determina un punto por cada uno de los días del sprint.

Ventajas de Scrum  Se obtiene software lo más rápido posible y este cumple con los requerimientos más importantes.  Se trabaja en iteraciones cortas.  Se acepta el cambio y se adapta el desarrollo para integrar los cambios que son importantes.  Se incentiva la creatividad de los desarrolladores haciendo que el equipo sea auto administrado.  Se mantiene la efectividad del equipo habilitando y protegiendo un entorno libre de interrupciones e interferencias.  Permite producir software de una forma consistente, sostenida y competitiva.  Las reuniones se dedican a inconvenientes recientes, evitando el estancamiento

Desventajas  Requiere delegar responsabilidades al equipo, incluso permite fallar si es necesario.  Es una metodología que difiere del resto, y esto causa cierta resistencia en su aplicación para algunas personas

¿Dudas?

¡Gracias!