Scrum Agil

PROGRAMACION AGIL: “ SCRUM Y XP ” Funte: U Mayor. Practia Consulting

SCRUM

Gestión Ágil de Proyectos

¿Qué Es SCRUM? 







aproximación holística en la cual las fases se solapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, con el rugby, donde el equipo entero "actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro". SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. Reduce al máximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo (cada 30 días), por medio de iteraciones o Sprints. Ideal para proyectos con un rápido cambio de requerimientos.

Contexto SCRUM 





Sólo abarca prácticas de gestión sin entrar en las prácticas de desarrollo como puede hacer XP. Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles y, le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus raíces teóricas están en las teorías de la autoorganización.

Actores SCRUM Propietario del producto Representa a todos los interesados en el producto final. Sus áreas de responsabilidad son:   

Financiación del proyecto. Retorno de la inversión del proyecto. Lanzamiento del proyecto.

Ingeniería De Software

Santiago, 16 Diciembre 2005

5/30

Actores SCRUM Equipo Responsable de transformar el Backlog de la iteración en un incremento de la funcionalidad del software.   

Auto-gestionado. Auto-organizado. Multi-funcional.

Actores SCRUM Scrum Master Responsable del proceso Scrum.  



Formación y entrenamiento del proceso. Incorporación de Scrum en la cultura de la empresa. Garantía de cumplimiento de roles y responsabilidad.

Metodología De Trabajo 





Equipos de entre 6 y 10 personas revisan los requisitos, la tecnología disponible y evalúan los conocimientos para colectivamente determinar como incrementar la funcionalidad. Reuniones diarias, antes de empezar a trabajar, con una duración máxima de 4 hrs. Se llevan a cabo hasta que el proyecto este listo para ser puesto en producción o ser lanzado al mercado.

Metodología De Trabajo 





En la primera reunión se explica al equipo la forma de trabajo, especificando que son reuniones cortas para coordinar trabajo y no para solucionar problemas. Se establecen los criterios para arreglar los errores por prioridades (base del éxito del sistema). Al inicio de cada iteración se revisa el trabajo pendiente en el proyecto y se selecciona la parte a la cual se le incrementara funcionalidad, para al final de la iteración incorporarla al SW y presentársela a las partes involucradas. En cada reunión las preguntas claves a contestar son:  ¿Qué es lo que se hizo desde la última reunión?  ¿Qué es lo que se va a hacer hasta la siguiente reunión?  ¿Cómo se va a llevar a cabo?

Artefactos SCRUM Sprint   



Es la base del desarrollo Scrum. Su duración máxima es de 30 días. Se llevan a cabo las tareas pre-establecidas y no se puede modificar el trabajo acordado en el backlog. Sólo el ScrumMaster puede abortar un sprint si lo considera no viable por alguna de las sgtes. razones:   

Las circunstancias del negocio han cambiado. La tecnología acordada no funciona. El equipo ha tenido interferencias.

Artefactos SCRUM Product Backlog 





Crea un listado con los requisitos de los usuarios o propietarios del sistema para planificar el proyecto. No es una lista completa y definitiva. Es sólo una estimación inicial de los requisitos. Es un documento dinámico que incorpora las constantes necesidades del sistema y se mantiene durante todo el ciclo de vida (hasta la retirada del Sist.).

Artefactos SCRUM Sprint Backlog 







Especifica la serie de tareas que se van a desarrollar según los requisitos señalados. Estas tareas tienen una duración de entre 4 y 16 hrs. de trabajo. Las de mayor duración intentar descomponerlas en Sub-Tareas dentro de ese rango de tiempo. Al final del sprint se busca un incremento en la funcionalidad.

Ingeniería De Software

Santiago, 16 Diciembre 2005

12/30

Scrum y la realidad del software en Chile Santiago, 22 de octubre de 2008

A esta altura todos debieran haber escuchado de Scrum: Al menos una vez, ¡está en el título de esta presentación! 



Encuesta Ágil:   



Quienes son Certified Scrum Masters? Quiénes usan Scrum en sus empresas? Quienes no lo hacen pero están considerando hacerlo? Quienes no quieren usarlo? 14

Repasando Scrum

15

Ciclo de trabajo: Explicación 











Al inicio del proyecto se establece su factibilidad, visión, valor de negocio Después se listan los requerimientos creando el “Product Backlog” Al principio de cada iteración se seleccionan aquellos requerimientos que agregan mayor valor El equipo los analiza y define tareas para desarrollar cada uno de ellos, esas tareas conforman el Sprint y se registran en el Sprint Backlog (durante la reunión de Planificación) Al final de cada Sprint hay nueva funcionalidad para probar, la cual es presentada para revisión por parte de los usuarios y clientes Diariamente se revisa el estado de las tareas para detectar y remover obstáculos

Elementos de SCRUM  

Product Backlog Sprint Planificación  Revisión  Sprint Backlog  SCRUM  Retrospectiva (Reflexión) Roles  Product Owner  Scrum Master  Team Valores  Foco, apertura, coraje y respeto 





Del día a día a otro distinto



Para la gran mayoría, la adopción de Scrum para el trabajo diario no es algo que vaya a ocurrir de la noche a la mañana Para un área típica de desarrollo, hacer el cambio es relativamente simple Convencer al resto de la organización es el reto



¿Pero a qué están acostumbrados?





18

Cosas que Cambiarán al usar Scrum

Cómo se ven afectadas las prácticas de gestión de proyectos más difundidas en Chile

19

De la Carta Gantt al Gráfico de Burndown 



Tal vez el cambio más visible de la incorporación de Scrum, sea en la presentación del avance del proyecto. Examinemos el enfoque tradicional y de Scrum respecto de la planificación:    

Proyecto de Ejemplo : Administrador de Bibliotecas Fecha de Puesta en Producción 10/08/2008 Miembros del equipo: 4 personas Módulos a Desarrollar:  Adquisición de Libros  Catálogo  Reportes  Administrador de Préstamos  Administrador de Multas  Baja y sustitución de ejemplares 20

En la Gantt  

Desglose de los módulos en actividades y tareas Se fija el alcance, y se trata de ajustar a las restricciones de tiempo. Alcance

Fijas

Tiempo s

Costos

Ágil Tradicional Tiempo s

Variables Costos

Alcance

21

En Scrum 

Se estiman, priorizan y distribuyen los módulos solicitados en bloques temporales fijos (sprints). 2 4

Sprint 1 1. 2. 3. 4. 5. 6.

3

Sprint 2

Adquisición de Libros Catálogo Reportes Administrador de Préstamos Administrador de Multas Baja y sustitución de ejemplares

1

6

Sprint 3

Sprint 4

Fecha de Fin

• Desde esa estimación podemos ver si el alcance puede ser cumplido en los plazos • Revisamos el detalle del primer Sprint 22

Planificación del Sprint  



Identificación y estimación de actividades del Sprint El máximo de horas a agregar al Sprint es Horas en el Sprint x Personas en el equipo Todo exceso sobre ese número no se ve con posibilidades de éxito.

Actividad

Estimación

Generar Pantalla Ppal

4h

Conectar a la BD

2h

Listar préstamos activos

8h

Ingreso de Ejemplares

7h

23

Plazos impuestos Los muchachos de ventas / producción / gerencia seguirán imponiendo fechas de entrega del producto terminado sin haberte preguntado si es posible.  



La diferencia: Priorización del Backlog de Producto. Poner metas realistas, y cumplirlas dentro del sprint…. Si fallas, en el siguiente sprint tienes que ser cuidadoso.  Revisar optimismo de las estimaciones  Considerar complejidad de la solución de Software  Prever un porcentaje del tiempo para resolver “urgencias”  Tener considerado Testing / Documentación / Análisis Tranquilos(as): Todos fallamos en el primer Sprint 24

Reunión de Avance Seguiremos teniendo que asistir a las clásicas reuniones de avance semanal, y los niveles jerárquicos superiores seguirán conformándose con un porcentaje como indicador de avance. 



Al interior del Equipo tendremos reunión diaria en donde se planifican las actividades a realizar durante el próximo día del proyecto. En esta ocasión el Scrum master recibe problemas y devuelve soluciones. Realizar la reunión diaria de pié, en círculo y en menos de 15 minutos, puede ser todo un espectáculo para el resto de la organización. Aprovechen el marketing gratuito que eso genera para educar sobre Scrum.

25

Jefe de Proyecto o Scrum Master Si eres Jefe de Proyectos querrás ser Scrum Master, al resto de la organización le dará igual, mientras sigas recopilando requerimientos como antes… 

Ser Scrum Master no es dirigir al equipo hacia donde tú crees que deben ir, es apoyar al equipo a avanzar hacia donde ellos decidieron ir:       

Removiendo obstáculos que dificulten el avance del proyecto Consiguiendo recursos críticos Manteniendo actualizadas las estimaciones Ayudando a mantener al equipo enfocado Bloqueando interrupciones o tareas no planificadas en el Sprint Backlog Dirigiendo las actividades propias del método Educando activamente a la organización 26

XP

Programación Extrema

Ingeniería De Software

Santiago, 16 Diciembre 2005

15/30

¿Qué Es XP? 







Es un proceso ligero, ágil, de bajo riesgo, flexible, predecible, científico y divertido de desarrollar software. Esta orientado hacia quien produce y usa el software ( retroalimentación continua cliente y desarrollador). Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Combina las que han demostrado ser las mejores practicas para desarrollar software, y las lleva al extremo.

Ingeniería De Software

Santiago, 16 Diciembre 2005

16/30

Contexto XP 









Cliente bien definido y en colaboración constante. Los requisitos pueden y van a cambiar (volátiles). Reduce los tiempos de desarrollo manteniendo la calidad. Desarrollo incremental y continuo para responder a los cambios. Grupo pequeño y muy integrado.

Ingeniería De Software

Santiago, 16 Diciembre 2005

17/30

Características XP  







Metodología creada a base de prueba y error. Énfasis en el desarrollo del software mas que una buena documentación. Empieza en pequeño y añade funcionalidad con retroalimentación continua. No introduce funcionalidades antes de que sean necesarias. El cliente o el usuario se convierte en miembro del mismo equipo.

Ingeniería De Software

Santiago, 16 Diciembre 2005

18/30

Características XP 

Su utilidad es medida con cuatro valores:  Simplicidad

en las soluciones implementadas.  Comunicación.  Retroalimentación.  Coraje (si funciona … mejóralo).

Ingeniería De Software

Santiago, 16 Diciembre 2005

19/30

Roles De XP       

Programador. Cliente. Encargado de pruebas (Tester). Encargado de seguimiento (Tracker). Entrenador (Coach). Consultor. Gestor (Big boss).

Ingeniería De Software

Santiago, 16 Diciembre 2005

20/30

Prácticas De XP      



Desarrollo guiado por pruebas. Cliente presente. Integración continua. Refabricación sin piedad. Diseño simple. Propiedad colectiva del código y convenciones del mismo. Cubrir una semana de 40 horas, pues los programadores cansados son menos productivos y mas propensos a errores.

Ingeniería De Software

Santiago, 16 Diciembre 2005

21/30

Prácticas De XP

Ingeniería De Software

Santiago, 16 Diciembre 2005

22/30

Ciclo De Vida XP 

El ciclo de vida ideal de XP consta de seis fases:      

Exploración. Planificación de la Entrega (Release). Iteraciones. Producción. Mantenimiento. Muerte del Proyecto.

Ingeniería De Software

Santiago, 16 Diciembre 2005

23/30

Costo Del Cambio En El Ciclo De Vida Del Proyecto 



Ingeniería De Software

Tradicionalmente, entre mas tarde aparezca la necesidad de un cambio, el costo de implementación de este se elevara exponencialmente. La programación extrema mantiene dicho costo en un nivel prácticamente independiente con respecto a la etapa del ciclo de vida.

Santiago, 16 Diciembre 2005

24/30

Flujo De Un Proyecto XP

Ingeniería De Software

Santiago, 16 Diciembre 2005

25/30

Iteración XP

Ingeniería De Software

Santiago, 16 Diciembre 2005

26/30

Otras Metodologías Ágiles

Ingeniería De Software

Santiago, 16 Diciembre 2005

28/30

 

  

Crystal Methodologies. Dynamic Systems Development Method (DSDM). Adaptive Software Development (ASD). Feature - Driven Development (FDD). Lean Development (LD).

Ingeniería De Software

Santiago, 16 Diciembre 2005

29/30