Plan de Metodologías para Vernelabs

Análisis de la situación actual

Estilo de la metodología empleada actualmente

Tablero tipo kanban, con actividades autogestionadas por cada uno de sus responsables.

No existen roles fijos para la ejecución de la metodologías.

Reuniones semanales (weekly meetings)

Ventajas encontradas

Entorno flexible y en busca de mejoras

Autogestión de los integrantes

Tablero ya generado y conocimiento de cómo usarlo

Deficiencias encontradas

No existe un plan claro de cómo trabajar

No existe documentación de procesos

Se desconoce en qué está trabajando el resto del equipo

No existen roles de organización. (solo de proyectos)

Falta de calendarización de actividades.

Implementación de una Fase 1, con fácil adaptación y fomentación al aprendizaje

Introducción

Kanban es una metodología ágil de fácil adaptación con oportunidades con muchas oportunidades de crecimientos.

Los 6 principios claves son:

·         Limitar el trabajo en progreso

·         Hacer las reglas explicitas

·         Implementar políticas de feedback

·         Mejora continua

·         Foco en el flujo de trabajo

·         Visualización de trabajo y actividades.

Tiene 4 cualidades importantes son:

·         Empezar con lo que se hace.

·         Comprometerse a buscar e implementar cambios incrementales y evolutivos.

·         Respetar los procesos, las responsabilidades y los cargos actuales.

·         Animar liderazgo en todos los niveles.

Explicación base de la metodología

Kanban es una metodología visual y adaptativa en la que te recomiendan el uso de ciertas reglas o parámetros, pero en todo momento se busca que cada equipo y/o organización se encargue de personalizar las reglas a aplicar en esta metodología.

La principal cualidad de Kanban es el uso de su tablero, para tener la visualización de las actividades que se estaban realizando, como mínimo el tablero debe tener columnas de por hacer, haciendo y hechas; cualquier columna que se desee agregar y sea práctica para el equipo se coloca. Las actividades deben ordenarse con respecto a su prioridad de más alta, verticalmente hacia arriba, más baja verticalmente hacia abajo.

Kanban fomenta la metodología Pull, esta es la realización de actividades por deseo propio y no por imposición.

Se parte por explicar en líneas generales los roles y responsables dentro de la metodología, así como las reuniones que se deberán tener en con cierta frecuencia de tiempo.

Esta metodología está basada en la reducción de desperdicios y el aumento de la calidad, por lo que el flujo de trabajo también juega un papel importante para que cada actividad sea realizada con la calidad que esta debe tener. Un flujo de trabajo muy alto puede hacer que actividades no estén realizadas con el suficiente cuidado y un flujo de trabajo muy bajo puede causar tener mucho tiempo muerto

Previo a la implementación de la metodología se crean normas entre todo el equipo para que el trabajo sea adaptado al proyecto en el que se está manejando.

La metodología evoluciona constantemente, ya que busca la retroalimentación constante, de esta manera ir mejorando los cuellos de botella en la realización de actividades y la mejora en procesos.

La entrega de productos no es cíclica, es decir no depende de una fecha en particular para entregar, son entregas constantes mientras se vaya realizando las actividades.

Roles y responsables

Kanban no tiene imposición de ningún rol, puede en todo momento trabajarse sin ellos, pero existen documentaciones que indican que existen 2 roles que se ajustan muy bien al uso de la metodología, estos son:

·         Service Delivery Manager (SDM)

·         Service Request Manager (SRM)

El Service Delivery Manager es el encargado de que las actividades fluyan y facilita la realización de las mismas.

El Service Request Manager es responsable de entender las necesidades y requisitos que demandan los clientes, además de simplificar, seleccionar y priorizar los elementos del backlog. Es el encargado de mantener la relación con los diferentes stakeholders, y hacer revisiones de planificación para poder cumplir con los desarrollos que son requeridos realizar.  Este rol es conocido como product owner en sistemas de metodologías Scrum.

Reuniones Base

·         Revisión de la estrategia

·         Revisión de las operaciones

·         Revisión de los riesgos

·         Revisión de la prestación de servicio

·         Reunión de realimentación *

·         La reunión de Kanban (Daily meetings)*

·         Reunión de planificación de la entrega

Revisión de la estrategia, es importante revisar que los elementos que están priorizados en los tableros Kanban estén alineados con la estrategia de la compañía.

Revisión de las operaciones, en esta reunión revisamos si tenemos los recursos adecuados para poder acometer y desarrollar las funcionalidades en las próximas semanas.

Revisión de los riesgos, detectar posibles bloques que impacten en la productividad. Los temas bloqueantes normalmente se agrupan y se trabajan para que no impacten en los desarrollos.

Revisión de la prestación de servicio, se hace para examinar y mejorar la efectividad de las funcionalidades que se están realizando.

Reunión de realimentación, esta reunión sirve para priorizar los elementos del backlog dentro de un Kanban board.

La reunión de Kanban, es una reunión diaria para ver los elementos que pueden estar bloqueados y buscar soluciones.

Reunión de planificación de la entrega, se utiliza para supervisar y planificar entregas a los clientes.

Reglas base y reglas propuestas por equipo

Al ser una metodología adaptativa, Kanban busca que el equipo desarrolle sus propias reglas, estas deben quedar claras y ser en consenso por todo el equipo.

Deben estar en un lugar visible y son clave para el correcto funcionamiento de la metodología.

En el desarrollo de las reglas deben participar todos los miembros del equipo, buscando que se tome en cuenta a cada integrante y cada petición que se tenga.

Todos los roles, métricas, reuniones de la metodología son opcionales, estos el equipo evaluará si desean usarlos, agregar más o eliminarlos, todo esto dependiendo de la lógica que tenga el negocio.

Las características importantes a definir aquí son:

·         Estructura del tablero

·         Roles

·         Reuniones

·         WIP

·         Métricas

·         Compromisos

Métricas y flujos de trabajo

WIP (Work in progress):  es la cantidad de tareas en las que un equipo está trabajando actualmente. Delimita la capacidad de los flujos de trabajo de sus equipos en cualquier momento.

Lead Time: es el tiempo que transcurre entre que una funcionalidad de trabajo llega al punto de compromiso hasta que se entrega. Esta métrica se mide en días de trabajo y se empieza a contabilizar en el momento en que el proyecto se solicita y se cuelga la tarjeta en el tablero Kanban.

Cycle time: es el tiempo de realización de la tarjeta podemos prever fácilmente cuanto vamos a tardar en entregar un producto al cliente. Además, viendo la diferencia con el Lead time, podemos ver si tenemos cuellos de botella o no. En el momento en el que el lead time es mayor, sabremos que hay cuellos de botella y que tenemos que revisar el flujo. El Lead time depende del Cycle time, pero añade la necesidad de hacer una buena gestión del backlog.

Retroalimentación y aprendizaje continuo

Kaizen es una filosofía japonesa que busca la mejora continua, esto se basa en 4 principios

·         Planear

·         Realizar

·         Revisar

·         Actuar

La secuencia es lógica, primero con respecto a algún problema se realiza una planificación para buscar una resolución efectiva, posteriormente realizamos las actividades realizadas, al obtener resultados comparamos estos con nuestra planificación y finalmente actuamos en buscar de mejorar aún más o establecer una solución parametrizada.

Pros y contras

Pro

·         Se mejora la visibilidad y comunicación del equipo

·         Se busca la mejora continua

·         Uso de métricas para evaluar rendimiento

·         Busca determinar en donde se producen cuellos de botella

·         Abraza al cambio

·         Fácil de implementar

Contra

·         Las órdenes no frecuentes vuelven ineficientes a Kanban

·         No funciona para todos los proyectos

Personalización VerneLabs

Las tarjetas deben hacer referencia al mapa de experiencia, ya que cada actividad debe ser parte de una parte expresada del plan de trabajo mostrado al cliente. En el siguiente ejemplo se puede demostrar como una actividad perteneciente al Discovery y dentro del grupo Service Discovery tiene el nombre de planificacion viaje.

Mapa de experiencia:

Actividad:

Con un mapa de experiencia fijo y que no debe cambiar se pueden colocar alias que permitan la practicidad de tener menos escrito dentro de la actividad.

Mapa de experiencia con guia:

Actividad con Alias:

Toda actividad debe tener un responsable, esta es referenciada con una etiqueta de color, cada color hará referencia a unica persona, esta información debe mostrarse en una tarjeta en el tablero con el nombre de la persona y el color asignado.

Lo mismo aplica en el tablero cuando aparece el nombre del proyecto, la etiqueta que aparezca sobre la tarjeta del proyecto es el Service Request Manager del mismo.

 Para este caso el referente al color verde es el SRM de el proyecto mostrado.

Reuniones diarias de máximo 20 min

Tema #1 Client Daily Meeting (Max 5 min todos):

•        Que juntas o compromisos se tienen hoy y mañana con los clientes

Tema #2 Activity Daily Meeting (Max 15 min todos):

•        ¿Qué hiciste Ayer?

•        ¿Qué problemas encontraste que dificultan tu entrega?

•        ¿Qué harás hoy?

Reglas propuestas:

• Los daily meetings deben ser todos los días presencialmente a las 10:00am en las oficinas de VerneLabs, posterior a la reunión se debe colocar documentar en el canal de Slack llamado Daily los puntos clave de cada uno en la reunión, en el caso de tener compromisos que dificulten la asistencia, se colocar dichas actividades antes de las 10:00am en el mismo canal para que el resto del equipo conozca que está haciendo el otro.
• Toda petición interna de un integrante a otro debe colocarla en el tablero como una actividad para realizar próximamente por el solicitante, haciendo referencia al solicitado y notificándole al mismo sobre la actividad de manera escrita por un canal de Slack llamado Solicitudes

• Todos los viernes en fin de mes se debe tener una reunión con todos los involucrados por proyecto para determinar las lecciones aprendidas del mismo, este se debe documentar y buscar generar nuevas reglas que permitan mejorar la operación.
• Toda reunión con clientes debe tener a al menos una persona designada previamente como secretario, este se encargará de colocar los acuerdos, compromisos de ambas partes y comentarios o aclaraciones tratadas, enviándolas después con el mismo cliente para garantizar una efectiva comunicación con ellos el mismo dia.
• Existirá por proyecto un SDM y un SRM principal y uno secundario, esto será para lograr cumplir con las actividades del otro en el caso que alguno no pueda cumplirlas, el reemplazo de dichas labores tiene en un periodo parcial o total de tiempo tiene que ser comunicado a todo el equipo y debe quedar constancia escrita.

Metas que se desean tener

Tener un plan claro de cómo trabajar

Conocer en qué está trabajando el resto del equipo

Mejora de comunicación interna

Implementación de Fase 2

Introducción

Scrum es una metodología ágil, fácil de entender, pero difícil de aplicar ya que requiere de mucha disciplina por cada uno de los integrantes del equipo.

Se basa en ciclos de desarrollo de proyectos, buscando entregas constantes en períodos de tiempo

Scrum es una metodología más estructurada que Kanban ya que si obliga a tener roles y reuniones periódicas, pero permite la adaptabilidad con la lógica de negocio de la empresa; de hecho, es posible combinar cualidades de Scrum con Kanban, esto se llama Scrumban.

Explicación base de la metodología

Scrum parte con la idea de que el cliente no sabe lo que desea obtener en el principio del proyecto, por lo que busca la adaptabilidad a los cambios constantes. La metodología consta de actividades con frecuencias de tiempo para la organización, planificación y acoplamiento de las tareas.

Se comienza por definir los periodos de tiempos en los que se darán resultados, estos llamados sprints, cada sprint tiene actividades internas como planificación, desarrollo y evaluación de las actividades con una retrospectiva al final de cada sprint para determinar que se hizo bien y que se puede mejorar. Un sprint no puede durar más de 4 semanas

Reuniones:

·         Sprint planning

·         Daily Scrums

·         Sprint Review

·         Retrospectiva

·         Refinament*

Roles y responsables

Scrum Master: es el facilitador de la metodología, está encargado de que el equipo tenga las herramientas para cumplir su trabajo al igual que es el garante de que la metodología se cumpla

Product Owner: es el dueño del producto en sus características funcionales, es el encargado de desglosar y definir las HU. Toda la comunicación con los stakeholders debe pasar por él y es el garante de las funcionalidades de que las funcionalidades del proyecto estén alineadas con los requerimientos del cliente.

Scrum Team: Son todos los involucrados en el desarrollo de las actividades para realizar el producto.

Artefactos y documentos

Historias de Usuario (HU): yo como XXX tengo que YYY para lograr ZZZ

Product Backlog: Elementos a desarrollar, con prioridades altas en la parte superior y más desarrolladas sus HU, las que falten definición serán más bajas y sin mucho detalle.

Sprint Backlog: Actividades a realizar durante ese sprint sectorizadas y con orden de importancia.

Burn down charts: es una gráfica que analiza el estado de las actividades realizadas contra lo planificado dentro del mismo sprint

Métricas y flujos de trabajo

Dod (Definition of Done): conjuntos de reglas que determinan que una actividad está realizada.

Métricas de productividad y efectividad de la entrega

Métricas de resultados del proyecto

Métricas de situación financiera

Métricas de calidad

Métricas de riesgos, impedimentos, proceso y mejora continua

Flujo de Scrum:

Se comienza partiendo de un product backlog general en el que se tienen todas las actividades macro, el product owner les da prioridad a dichas actividades y las vuelve lo más atómicas posibles para que su desarrollo no se preste a malas interpretaciones.

Al tener un plazo determinado cada sprint, se procede a comenzar uno con el sprint planning, aquí el Scrum Team determinará las actividades que realizará el sprint, estas serán evaluadas y analizadas por el esfuerzo y tiempo que tendrá cada una de las actividades y se verá si estas son posibles de realizar dentro del periodo de tiempo marcado por el sprint. (El producto owner no asigna las actividades, solo pone la prioridad que tiene cada una de ellas)

Como resultado del planning sprint, sale el sprint backlog, estas serán las actividades que se deben realizar en el sprint con sus prioridades asignadas.

Durante el desarrollo de las actividades diariamente se tendrán reuniones, esto para la revisión constante del estado de las actividades. Durante el sprint se debe actualizar el Burndown chart para saber el avance del mismo.

Al finalizar el sprint se realiza un sprint review en el que se comparan las actividades planificadas con las realizadas y se revisa el rendimiento del equipo.

Finalmente se entrega al cliente lo realizado del producto en dicho sprint, esto es llamado increment.

Por último, se realiza una reunión retrospectiva para determinar qué actividades fueron realizadas correctamente, que se debe apartar y que tiene oportunidades de mejora.

Pros y contras

Pros

·         Flexibilidad al cambio

·         Predicción de tiempos

·         Productos de calidad en tiempos programados.

·         Alineación entre cliente y actividades desarrolladas.

Contras

·         Dificultad de aplicación en primer momento

·         Es necesario tener un equipo auto organizado

·         Depende mucho de la interacción con el cliente.

Metas que se desean tener

Tener plan claro de cómo trabajar

Documentación de procesos

Conocer en qué está trabajando el resto del equipo

Roles internos de ejecución.