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.

Soporte y Mantenimiento de Arquitectura

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

GRACIAS!