Charla presentada en Ágiles 2014 (Medellín, Colombia) acerca de como enfrentar los retos del trabajo no planeado de forma ágil desde la experiencia de un equipo de soporte de tecnología.
SCRUMBAN aplicado a equipos de Soporte y Mantenimiento
1. SCRUMBAN aplicado a
equipos de Soporte y
Mantenimiento
Jorge Iván Hincapié Palacio
Cristian MauricioVelásquez Patiño
2. Los ponentes
Jorge Iván Hincapié Palacio
• Ingeniero de Sistemas e Informática, especialista en Gestión Empresarial de
la Universidad Nacional de Colombia.
• 6 años de experiencia en desarrollo de software.
• Experiencia en prácticas de PSP/TSP, SCRUM y KANBAN.
• Actualmente Ingeniero de Desarrollo enTech and Solve S.A.S.
3. Los ponentes
Cristian MauricioVelásquez Patiño
• Ingeniero de Sistemas y Computación de la Universidad del Quindío.
• Certified Scrum Developer.
• Experiencia de trabajo con KANBAN.
• Actualmente Analista de Arquitectura de Suramericana.
4. El equipo
• Soporte y Mantenimiento del área de Arquitectura de Aplicaciones en la
Gerencia de Bienestar y Entorno Tecnológico de Suramericana, ubicado en
Medellín, Colombia.
• Encargado de más de 20 aplicaciones que cumplen funciones transversales a
la compañía.
• Acompaña los proyectos de desarrollo en la gerencia.
6. ¿Cómo entendemos el Soporte?
El soporte es el trabajo que no se puede planear, ej.:
• Incidentes en producción.
• Reuniones.
• Permisos en herramientas
• Trabajo operativo. “CHOFEREO”
• Acompañamientos.
• Entre otros.
7. ¿…y el Mantenimiento?
El mantenimiento es el trabajo programado que agrega valor, ej.:
• Mejoras a los aplicativos.
• Soluciones raizales.
• Implementaciones nuevas.
• Entre otros.
8. Antecedentes
• Conocimiento centralizado en algunos integrantes del equipo.
• Retraso en proyectos de Arquitectura ante la aparición de casos urgentes.
• Difícil acceso de otros equipos al conocimiento del área de Arquitectura.
• Falta de un canal integral de soporte para las aplicaciones.
• Ausencia de medios para identificar las posibles mejoras en las aplicaciones.
9. En un inicio… ¿Éramos Ágiles?
• El equipo comienza sus funciones a inicios de 2013.
• Coincide con el inicio de la implementación de metodologías ágiles en
Suramericana.
• Se genera un “Product Backlog” de más de 100 elementos por atender.
• Un sólo Backlog y un sólo Sprint, sin una ventana de tiempo establecida.
• Adquiriendo experiencia para implementar metodologías ágiles.
10. Selección de herramientas
• Se selecciona Jazz Team Server de IBM,
para organizar el trabajo del equipo.
• Esta es la herramienta corporativa para el
trabajo de metodologías ágiles.
11. Primeras dificultades
• Los casos de soporte comienzan a impedir que se ejecuten los casos de
mantenimiento.
• No se puede realizar una planeación completa de las tareas.
• No es posible identificar el estado del proyecto en un momento
determinado.
• Se confunden los conceptos de “historias de usuario” y “tarea”.
• No se puede entregar una “promesa de servicio”.
12. División del enfoque
• En este caso, tener ambos proyectos mezclados introduce más complejidad.
• La estrategia es dividir el enfoque y trabajar dos metodologías:
• SCRUM para Mantenimiento.
• KANBAN para Soporte.
• Se propone definir roles dentro del equipo para dividir el trabajo de ambos
proyectos.
13. SCRUM
• División de la organización en equipos integrados auto-organizados.
• División del trabajo en entregables estimados y priorizados.
• División del tiempo en iteraciones de duración corta y fija.
• Optimización del plan de entrega.
• Optimización del proceso.
14. KANBAN
• Visualización del flujo de trabajo.
• Definición de límites sobre el trabajo en progreso (WIP).
• Medición del tiempo de entrega (lead time, cycle time, touch time).
15. SCRUM vs. KANBAN
• Más prescriptivo.
• Roles.
• Iteraciones con tiempo definido.
• Ceremonias.
• Limita elWIP por iteración.
• Más adaptativo.
• No requiere roles.
• No requiere iteraciones.
• No prescribe ceremonias.
• Limita elWIP por estado.
16. SCRUM vs. KANBAN
• El tablero se resetea por iteración.
• Equipos multi-funcionales
• Estimación y velocidad.
• Trabajo planeado.
• El tablero persiste.
• El tablero pertenece a un equipo.
• Lead time, Cycle time,Touch time.
• Flujo variable.
17. Adopción de la metodología “SCRUMBAN”
• En Soporte se implementa KANBAN con prácticas de SCRUM.
• En Mantenimiento se usa SCRUM pero no es posible cumplir todas sus
prescripciones.
• El hecho de compartir ambos proyectos lleva a tener implementaciones
ágiles híbridas - SCRUMBAN.
18. SCRUMBAN en Mantenimiento
• Ceremonias:
• Daily.
• Planning.
• Refinement.
• Retrospective.
• Review.
• Documentos:
• Sprint Plan.
• Product Backlog.
• Release Plan.
• Burn down chart.
• La historias se
dividen hasta que
midan máximo 5
pts.
• Los Sprints se
definen de una
semana.
• Roles del equipo:
• 3Team
Members.
• 1 Scrum Master.
• 1 Product Owner.
19. Flujo y límites de Soporte
INICIO ABIERTO (9)
EN ESPERA (4)
EN PROGRESO (3)
ENTREGA (3)
INVÁLIDO
TERMINADO (30)
20. Roles
M S S
• Un miembro especializado en Mantenimiento.
• Dos miembros encargados del Soporte.
• Rotación semanal.
• Difícil transición entre roles.
21. Roles
• Un miembro especializado en Mantenimiento.
• Un miembro especializado en Soporte.
• Un miembro dividido entre ambos proyectos.
• Produce mejores resultados.
• No se comparte el conocimiento.
M S
22. Roles
• Todos los miembros atienden ambos proyectos.
• Las historias de mantenimiento tienen un
responsable, pero las tareas se reparten.
• Se asegura la transferencia constante de
conocimiento.
23. Transferencia de conocimiento
Se debe tener una buena administración del conocimiento compartido, por
diferentes factores:
• Tamaño reducido del equipo.
• Alto número de aplicaciones a las que se da soporte.
• Rotación de personal.
24. Resultados
• Mayor visibilidad del área de Arquitectura en la organización.
• Mejor apoyo del área a los proyectos de desarrollo.
• Retroalimentación desde otras áreas hacia las aplicaciones transversales.
• Generación de valor en las aplicaciones transversales de la compañía.
• Difusión de la metodología para equipos de características similares.
• Generación de iniciativas para el equipo de Implementación de Metodologías
Ágiles.
25. Trabajo Futuro
• Mediciones de LeadTime, CycleTime yTouchTime.
• Generar estrategias para una atención más rápida y eficiente.
• Definir un protocolo de adaptación a la metodología del equipo.
• Implementar un framework de priorización eficiente.
26. Referencias
• Kniberg, H. (2009). Kanban vs Scrum. Crisp AB.Viitattu, 1, 2011.
• Roock, S. (2010, Marzo 2). Kanban: Definition of LeadTime and CycleTime.
Consultado en http://stefanroock.wordpress.com/2010/03/02/kanban-
definition-of-lead-time-and-cycle-time.
• Darbha, S. (2012, Febrero 22). Can Support and Maintenance Become Agile?.
Consultado en
https://www.scrumalliance.org/community/articles/2012/february/can-
support-and-maintenance-become-agile.
