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

Presentación del tema: "Ingeniería de Software Facultad de Ingeniería Septiembre 2010 Fernando Alsuyet Ariel Illio Matias Baldini."— Transcripción de la presentación:

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

2 ¿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.

3 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.

4 ¿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.

5 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

6 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.

7 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.

8 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.

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

10 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

11 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.

12 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.

13 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

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

15 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.

16 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.

17 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.

18 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

19 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

20 ¿Dudas?

21 ¡Gracias!