Santiago, 10 de junio de 2014 Scrum y la realidad del software en Chile Myrleny Mancilla Morales...
-
Upload
susanita-castrejon -
Category
Documents
-
view
18 -
download
8
Transcript of Santiago, 10 de junio de 2014 Scrum y la realidad del software en Chile Myrleny Mancilla Morales...
Santiago, 10 de abril de 2023
Scrum y la realidad del software en Chile
Myrleny Mancilla Morales
Alejandro Núñez Guardia
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
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?
3
Repasando Scrum
4
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?
7
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
8
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
9
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.
10
Tradicional
Tiempos
Alcance
Costos
Ágil
Tiempos
Alcance
CostosFijas
Variables
En Scrum
• Se estiman, priorizan y distribuyen los módulos solicitados en bloques temporales fijos (sprints).
11
1. Adquisición de Libros2. Catálogo3. Reportes4. Administrador de Préstamos5. Administrador de Multas6. Baja y sustitución de
ejemplares
2
43 1 6
Fecha de Fin
Sprint 1 Sprint 2 Sprint 3 Sprint 4
• Desde esa estimación podemos ver si el alcance puede ser cumplido en los plazos• Revisamos el detalle del primer Sprint
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.
12
Actividad Estimación
Generar Pantalla Ppal 4h
Conectar a la BD 2h
Listar préstamos activos 8h
Ingreso de Ejemplares 7h
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 Sprint13
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.
14
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
15
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
16
Aplicando Scrum más allá del desarrollo
17
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.
18
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!19
Casos de éxito y facilitadores
20
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
21
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
22
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
23
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
•Argentina San Martín 575 • 2º
(C1004AAK) Buenos Aires
Tel (+54-11) 4327-1999
•EspañaLópez de Hoyos 35 • 1º
(28002) Madrid
Tel (+ 34) 91-745-9912
•ChileLuis T. Ojeda 0191 • Of. 701,
Providencia, Santiago
Tel (+56-2) 334-3361
Contáctenos: