Scrum y la realidad del software en Chile

1. Scrum y la realidad del software en Chile Myrleny Mancilla Morales Alejandro Núñez Guardia Santiago, 30 de octubre de 2014

2. Agenda • Aplicación Scrum en el mercado local, yendo desde la cartas gantt hacia los gráficos de burndown. • A esta altura todos hemos escuchado de Scrum • Pasando del día a día a otro distinto • Plazos impuestos • Reunión diara una vez a la semana • De Jefe de Proyecto a Scrum Master • Cómo hacer Scrum sin apoyo • Más allá del desarrollo, aplicando SCRUM a otros contextos. • Scrum para otros proyectos • Scrum para Testing • Casos de éxito y facilitadores de la internalización del método. • Scrum para otros proyectos • Scrum para Testing

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

4. Repasando Scrum

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

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

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

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

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

10. 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 Tiempos Costos Fijas Ágil Tradicional Variables Tiempos Costos Alcance

11. En Scrum • Se estiman, priorizan y distribuyen los módulos solicitados en bloques temporales fijos (sprints). 2 Fecha de Fin 3 1 6 4 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Adquisición de Libros Catálogo Reportes Administrador de Préstamos Administrador de Multas Baja y sustitución de ejemplares • Desde esa estimación podemos ver si el alcance puede ser cumplido en los plazos • Revisamos el detalle del primer Sprint

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

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

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

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

16. Que tan de acuerdo está la organización con la implantación de Scrum? En muchas organizaciones es el equipo de desarrollo quién “decide” comenzar a trabajar con un método Ágil. Pero respetando también protocolos anteriores • Hay que trabajar para demostrar que el método funciona • Tener entregables funcionales al final de cada Sprint es la mejor demostración del avance real del proyecto • Revisar formalmente la aplicación repasando cada compromiso adquirido al inicio del Sprint • Mostrar avance diario en base a estimaciones actualizadas de cada tarea

17. Aplicando Scrum más allá del desarrollo

18. Scrum para Mantenciones • Uno de los ajustes más dificiles a la hora de implantar Scrum es el de establecer un Sprint Backlog realista. Siendo el principal problema a considerar el flujo de solicitudes de mantención • Mantenciones Lentas: • El menos complicado de los panoramas, si entre la solicitud de mantención y el release requerido hay al menos un Sprint, entonces la mantención puede entrar perfectamente en el esquema. Asignandole la prioridad necesaria para que entre al siguiente Sprint Backlog. • Mantenciones Rápidas: • Caen aquí todas las “emergencias”. Si las emergencias son la regla, considerar un tiempo reservado para estas actividades, como si fuese una tarea más que siempre entra en el Sprint Backlog. • Si la emergencia pone en riesgo el cumplimiento del Backlog comprometido, tratar de negociar elementos a “Intercambiar” entre el backlog y la emergencia.

19. Scrum para Testing • Testing Formal • La priorización del Product Backlog de testing debe sincronizarse con las entregas por parte de desarrollo (sea cual sea la metodología que usen) • Dependiendo del proyecto y basándonos en la estimación de rendimiento por caso de prueba. Podemos asignar tareas de Definición / Ejecución de agrupaciones funcionales de casos de prueba. Estas agrupaciones serán nuestras Actividades. • Con la reunión diaria se actualizarán las estimaciones de la definición / ejecución de casos de prueba. • La reunión de finalización del Sprint debiera hacer repaso de los casos de prueba más relevantes. • Testing Exploratorio • En el caso de que sólo se realice test exploratorio, calcular tareas basadas en cantidad de entradas / salidas / campos / ventanas. • Formalizar proceso de Testing. La vida será mas fácil!

20. Casos de éxito y facilitadores

21. Caso de Éxito: GamingCompany.com • Cliente local dedicado al desarrollo de videojuegos, compuesto por dos equipos claramente diferenciados: Ingenieros y Diseñadores • Adopción rápida del método. Scrum Master es a la vez parte del equipo • Mejoraron estimación , entregas comprometidas y manejo de los cambios de requerimientos • Casi 2 años utilizando el método • Totalmente institucionalizado

22. BigBank.mx • Scrum aplicado para Testing • Equipo de testing muy extenso, realizando Scrums de Scrums para soportar volumen de participantes • El gráfico de burndown se utilizó como monitor de avance de las pruebas de todo del proyecto. • Integrantes del equipo (80+ personas) no tenían experiencia con metodologías ágiles. Fueron entrenadas en sus actividades particulares, disminuyendo costos y tiempo de inicio del proyecto

23. Facilitadores para la adopción de Scrum • Alta productividad / Alta técnica • Localización común de los participantes • Sencillez del seguimiento y su reporte • Historial de retrasos en proyectos anteriores • Clientes finales que quieran ver “prototipos” • Proyectos elaborados por Fases • Proyectos de más de 6 meses • Equipos compactos de entre 5 y 12 personas • Scrum Master con espíritu de servicio. No de mando • Hacer de la demostración a fin de cada sprint un evento importante • Product Owner entrenado en el método

24. Visite nuestros WEBSITES: www.pragmaconsultores.com - Información Detallada de Servicios - Nuestra Experiencia: Clientes y Proyectos - Nuestro Compromiso y Nuestra Metodología de Trabajo www.qafactory.com - Fábrica de Aseguramiento de la Calidad - Beneficios y Detalle del Servicio Contáctenos: • España • López de Hoyos 35 • 1º • (28002) Madrid • Tel (+ 34) 91-745-9912 • practia@practia.es • Chile Luis T. Ojeda 0191 • Of. 701, Providencia, Santiago Tel (+56-2) 334-3361 practia@practia.cl • Argentina San Martín 575 • 2º (C1004AAK) Buenos Aires Tel (+54-11) 4327-1999 pragma@pragma.com.ar