SCRUMBAN aplicado a equipos de Soporte y
Mantenimiento
Jorge Iván Hincapié Palacio
Cristian Mauricio Velásquez Patiño
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 en Tech and Solve S.A.S.
Los ponentes
Cristian Mauricio Velá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.
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.
¿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.
¿…y el Mantenimiento?
El mantenimiento es el trabajo programado que agrega valor, ej.:
• Mejoras a los aplicativos.
• Soluciones raizales.
• Implementaciones nuevas.
• Entre otros.
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.
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.
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.
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”.
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.
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.
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).
SCRUM vs. KANBAN
• Más prescriptivo.
• Roles.
• Iteraciones con tiempo definido.
• Ceremonias.
• Limita el WIP por iteración.
• Más adaptativo.
• No requiere roles.
• No requiere iteraciones.
• No prescribe ceremonias.
• Limita el WIP por estado.
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.
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.
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:
• 3 Team Members.
• 1 Scrum Master.
• 1 Product Owner.
Flujo y límites de Soporte
INICIO
ABIERTO (9)
EN ESPERA (4)
EN PROGRESO (3)
ENTREGA (3)
INVÁLIDO
TERMINADO (30)
Roles
M S S • Un miembro especializado en Mantenimiento.
• Dos miembros encargados del Soporte.
• Rotación semanal.
• Difícil transición entre roles.
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
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.
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.
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.
Trabajo Futuro
• Mediciones de Lead Time, Cycle Time y Touch Time.
• 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.
Referencias
• Kniberg, H. (2009). Kanban vs Scrum. Crisp AB. Viitattu, 1, 2011.
• Roock, S. (2010, Marzo 2). Kanban: Definition of Lead Time and Cycle Time. 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.