Scrum y la realidad del software en Chile

Presentación del tema: "Scrum y la realidad del software en Chile"— Transcripción de la presentación:

1 Scrum y la realidad del software en Chile
Myrleny Mancilla Morales Alejandro Núñez Guardia Santiago, 23 de marzo de 2017

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.

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 Roles Valores 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 Desglose de los módulos en actividades y tareas
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 Tradicional Ágil Variables Tiempos Costos Alcance

11 Revisamos el detalle del primer Sprint
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. Actividad Estimación Generar Pantalla Ppal 4h Conectar a la BD 2h Listar préstamos activos 8h Ingreso de Ejemplares 7h

13 La diferencia: Priorización del Backlog de Producto.
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 Lo importante es definir todo lo que programaremos para llegar a la fecha comprometida. El equipo debe participar en la estimación que decide la meta de cada Sprint, y debe participar con mayor razón en la estimación de las tareas que se ejecutarán en el próximo Sprint. Deben considerarse esfuerzos reales / dedicaciones reales para no sobreestimar las capacidades del equipo. No todo el tiempo estaremos codificando, el ser Agile no significa que no documentaremos, analizaremos o diseñaremos la solución. El primer Sprint es para medirnos, y establecer el ritmo con el que continuaremos trabajando

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. Tener constancia y disciplina para llevar la reunión diaria de Scrum nos permitirá tener estimaciones frescas de cada tarea, saber que problemas han surgido y que temas se han solucionado. El Scrum Master tendrá que hacer esfuerzos especiales por mantener el foco de las reuniones, aprovechando al máximo el tiempo y guiando al resto del equipo a hacerlo. En caso de tener espectadores, mantenerlos interesados pero imposibilitados de intervenir en la reunión diaria. La presencia de espectadores junto al equipo es una invitación a recibir requerimientos que no estaban planificados.

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 El Scrum Master debe tener la fuerza para proteger y defender a su equipo. Pero debe ser flexible y apoyar las decisiones tomadas en forma colectiva. El Scrum Master no es el jefe del equipo, está al servicio del equipo. Todo el trabajo de preparación de informes, gráficos y reuniones que se alejan del aspecto técnio deben ser absorbidas por el Scrum Master

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 Tener un historial de fracasos con proyectos anteriores puede ser muy positivo, porque tenemos un excelente punto de comparación respecto de lo que estamos haciendo ahora. Para el día a día, pueden involucrar al Product Owner invitandolo a revisar el estado diario del proyecto, aprovechando su visita para aclarar dudas o recibir consejo sobre detalles no funcionales. Al finalizar el Sprint la demostración debe ser en vivo, no sirve una presentación, debe ser usada por el Product Owner, repasando en voz alta cada uno de los compromisos iniciales del Sprint.

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. Usar Scrum para mantenciones presenta un desafío mayor, ya que tenemos menos oportunidades (iteraciones) para poder depurar la aplicación. Las mantenciones lentas pueden programarse de modo de ir encolando las peticiones de soporte, priorizando desde esa lista para conformar el Sprint Backlog. Las mantenciones rápidas dificultan el uso de Scrum en su forma estandar, y podría requerir la reducción radical de la duración de cada Sprint (llegando a 2 o 3 días por Sprint). Aún así, la gran mayoría de las actividades de gestión de proyecto aplican perfectamente.

19 Scrum para Testing Testing Formal Testing Exploratorio
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! Al aplicar Scrum para Testing, dadas las características más predecibles del Testing el consejo es agrupar casos de pruebas para su definición o ejecución en base a sus características funcionales. Considerar varios ciclos de prueba dependiendo de las métricas anteriores. Para el Testing Exploratorio tomar estimaciones en base a las características de la aplicación a testear. Convencer al equipo y a la organización de los beneficios de la aplicación formal del testing.

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:
- Información Detallada de Servicios - Nuestra Experiencia: Clientes y Proyectos - Nuestro Compromiso y Nuestra Metodología de Trabajo - Fábrica de Aseguramiento de la Calidad - Beneficios y Detalle del Servicio Contáctenos: Chile Luis T. Ojeda 0191 • Of. 701, Providencia, Santiago Tel (+56-2) Argentina San Martín 575 • 2º (C1004AAK) Buenos Aires Tel (+54-11) España López de Hoyos 35 • 1º (28002) Madrid Tel (+ 34)