jueves, 13 de abril de 2017

Scrumban en DevOps



¿Qué metodología ágil podemos usar en operaciones para que funcione con Equipos de desarrollo Scrum? Pues, podemo usar Scrumban.

Scrumban se trata de una metodología mixta y flexible entre Scrum y Kanban. Combina las la flexibilidad de Kanban y las características básicas de Scrum. Por un lado, se toma de Kanban lo de mantener un trabajo continuo, exponer el flujo de trabajo, el tablero de trabajo persistente, auto-asignaciones de tareas solamente por el sistema del tomar y jalar (pull), limitar el trabajo en curso y buscar optimizar el flujo teniendo en cuenta la métrica “cycle time”. Por otro, se agrega de Scrum la ceremonia de planning (principalmente bajo demanda), la retrospectiva como reunión de mejora contínua (Kaizen), el trabajo en ciclos o iteraciones sin ser limitativo o restrictivo de trabajo y la priorización, que se recomienda hacer en cada planificación. Dentro de la flexibilidad que brinda, hace optativo el usar otras partes o prácticas de Scrum. Bajo esta metodología no es necesario estimar, puede ser algo optativo, ya que no se necesita calcular el trabajo que entra en una iteración porque el trabajo es continuo. Aunque sí se pueden estimar tiempos de entrega y/o tamaños de paquetes de trabajo. Por otro lado, al ser el trabajo contínuo y no tener un compromiso formal de trabajo comprometido en una iteración, los cambios y re-priorizaciones pueden hacerse en cualquier momento. También es muy flexible el tipo de roles de los miembros del equipo debido a que no prescribe roles específicos ni es necesaria la multidisciplinariedad que recomienda Scrum. Además, como se mencionó antes y al igual que en Kanban, el tablero permanece persistente, mientras que sólo cambian las tareas y sus prioridades. A diferencia de Scrum que el tablero de sprint se renueva en cada iteración. Relacionado a la planificación, en Scrumban se planifica focalizados en los releases y no es obligadamente necesario hacerse en la planning de cada iteración; pues, la planificación se puede realizar solo bajo demanda. 

Ámbito de aplicación


 Este método se muy útil principalmente para procesos de ritmo rápido, para startups, proyectos que requieren fabricación de productos constante, equipos y proyectos con ambientes muy dinámicos y cambiantes, equipos de solución de problemas de contingencias en producción, equipos de mantenimiento, soporte o desarrollo de infraestructura. También es útil para integrar (coordinar y sincronizar) otros equipos de soporte a los equipos Scrum, por ejemplo bajo el marco DevOps. En estos casos, los equipos soporte pueden usar Scrumban y los de desarrollo Scrum.


Valores y principios


Los principios principales de Scrumban son: mostrar el flujo de trabajo, cuidarlo y mejorarlo. Aunque para seguir el marco Ágil de trabajo con mindset DevOps se puede usar el manifiesto ágil disciplinado (Ver the Disciplined Agile Manifesto) o tener en cuenta los aspectos principales del manifiesto ágil. También se pueden incluir los valores de Scrum y/o principios Lean. Esto es bastante flexible y depende de cada equipo.

Integración Development con Operaciones


Las transformaciones en la organización clásica de TI a menudo son difíciles; Inicialmente, un pequeño equipo o conjunto de equipos multifuncionales haciendo Scrum, compuesto por desarrolladores y por otro lado equipos de especialistas en operaciones. Para integrarlos bajo el marco ágil no se suele usar Scrum en operaciones, complejiza la coordinación entre Dev y Ops. A lo que sí recurrimos es a Lean, Kanban o Scrumban. Mientras los equipos “Dev Scrum” cubren la demanda de necesidades de negocio de la organización (desarrollando y desplegando), los equipos “Ops Scrumban” cubren la demanda de los equipos Dev para soporte del continuous Delivery, infraestructura u otras dependencias técnicas. Por ejemplo, grupos como Infraestructura o Soporte, gestionan un flujo continuo de solicitudes de los usuarios Devs o de clientes internos de la organización. Estos equipos encuentran difícil calzar su trabajo dentro de iteraciones Sprint de tiempo fijo, con cierta rigidez, cuando su trabajo tiene dependencias que pueden no ser satisfechas dentro de una iteración definida o sus clientes no pueden esperar al final de una iteración para recibir una corrección de software.
 

Roles

Kanban no prescribe roles como títulos pero se sugieren los siguientes [D. A.]:
  1. Service Request Manager o Product Owner: es el encargado de la priorización del backlog y entender las necesidades del cliente. Si el cliente es interno a la organización como el sector de producción, el PO se encarga de tratarlos como stakeholder y ser el único punto de entrada para los requerimientos que hace la organización al equipo.
  2. Service Delivery Manager o Flow Master: es un facilitador (equivalente a un Scrum Master en Scrum). Se encarga de facilitar las ceremonias, el flujo de trabajo y propiciar la mejora continua.

Flujo de trabajo y tablero kanban


Estos equipos pueden usar tableros kanban para exponer sus flujos de trabajo. Estos tableros no necesariamente tienen alta cohesión a un objetivo como si se suele hacer en Scrum. Aunque, sí deben tener objetivos para el trabajo en curso. Estos tableros están más orientados a entrega de soluciones out-come en releases, en vez de tiempo fijos. Deben permitir flexibilidad para adaptarse a la demanda de Dev y de la organización.
(Nota: lo ideal es que en la columna in progress se coloquen los estado del flujo de trabajo)

Métrica


 En Scrumban se usan las métricas de Kanban para medir el valor, proceso y flujo relacionados con el propósito. En este sentido, el rendimiento (Throughput) es el más relevante y se mide a través de indicadores de tiempos de duración promedio de actividades o trabajo sobre elementos. También se usa el Cycle Time, que es el tiempo período requerido para completar un ciclo de trabajo u operación desde que se inició; O para completar una función o tarea desde el principio del trabajo hasta el final (El tiempo total que transcurre desde el momento en que el trabajo se inicia en una tarea hasta su finalización). También se usan herramientas de monitoreo como "Histograma de Lead Time", o de cycle time, y el "Cumulative Flow Diagram" (CFD). El CDF o diagrama de flujo acumulados muestra el total de elementos que están en curso, así como el tiempo que tarda en completarse. La estimación promedio del tiempo de ciclo de avance muestra cuánto tiempo, en promedio, se tarda en completar un elemento. También se puede usar un indicador de eficiencia de flujo: Flow efficiency = [work time / (work time + wait time)] × 100%.

Mejora continua


 En Scrumban se busca tener ciclos de mejora continua y que se pueden implementar mediante reuniones frecuentes de retrospectiva como en Scrum. El foco principal, en la mejora continua, es mejorar el flujo de trabajo prestando atención a los cuellos de botella y a la optimización del flujo de trabajo. Para ello también se buscan resolver impedimentos del flujo y solución de causas raíces.



Referencias:





Publicado por en
Etiquetas:

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)