INICIACIÓN A KANBAN (II) – ENTENDER EL SISTEMA

INTRODUCCIÓN

Tras el primer post donde os enseñé los conceptos básicos y la filosofía de Kanban, en este vamos a introducir algunos conceptos ya aplicados al trabajo diario y a entender como funciona un sistema Kanban. Vamos a focalizarnos en ver como trabajar con los famosos tableros Kanban, ver que significa cada elemento del tablero y una pequeña introducción a las métricas, donde veremos dos métricas muy sencillas y dos tipo de gráficas muy simples que nos permitirán hacernos una idea de las posibilidades que vamos a poder obtener.

Representación del “trabajo en curso” (WIP)

  • En primer lugar, cuando hablamos de “Kanbans”, estamos hablando de “huecos” que hay en un determinado espacio. Si trasladamos esto a un panel, donde tenemos identificadas las columnas como los diferentes estados en los que pasa una tarea, podemos decir que en nuestro sistema, en cada estado, tenemos una cantidad limitada de trabajo que podemos hacer, definido por los kanbans que tengo en cada estado. Es muy común confundir los tickets con “kanbans”, pero realmente los tickets son tareas y los kanbans son los huecos que hay para hacer estas tareas. Un hueco vacío en el panel esta emitiendo una señal “pull” para que se traiga una tarea desde el estado anterior.

  • Esta forma de mostrar la capacidad de trabajo por cada estado en forma de huecos resulta engorrosa, por lo que la forma de representar la capacidad de cada estado e incluyendo un número con la capacidad encima de cada columna. Esta capacidad es un concepto fundamental de Kanban y es el “Work In Progress” (WIP) y define los número de tickets que pueden estar a la vez en un determinado estado. En el próximo post veremos un poco más en detalle este concepto y porque debemos de tener este valor lo más bajo posible para que el trabajo fluya lo más rápido posible. Si indicamos un símbolo de infinito o un “-“, significa que no hay WIP en esas columnas.

 

Sistemas push vs sistemas pull

  • Kanban es un sistema basado en “pull”. Esto quiere decir que busca la máxima eficiencia y optimización, adaptando en tiempo real la producción a la demanda.  Mediante este sistema, sólo producimos los que sabemos que vamos a realizar. En un sistema de fabricación, no tendría un stock o tendría un stock mínimo y solo fabricaría aquellos pedidos que ya tengo confirmados (Just-In-Time). En este caso, solo voy cogiendo tickets cuando tengo huecos, de forma que el trabajo fluya más rápido.
  • Un sistema “push” consistiría en coger muchos tickets e ir pasándolos de estado a estado, de forma que pueda asegurarme que tengo tickets suficientes en el siguiente estado (tengo stock suficiente para abastecer a la siguiente fase). Esta forma de trabajar nos rompería completamente la filosofía Kanban, ya que no tendría un WIP limitado y el tiempo de finalización de cada tarea se ralentizaría.

 

Compromiso diferido y políticas

  • El compromiso sobre cuando vamos a hacer algo se retrasa (lo diferimos) hasta el punto de compromiso. En ese momento, ya podemos comprometernos a un determinado tiempo si sabemos como se comporta nuestro sistema Kanban.
  • Hasta que llegamos a ese punto de compromiso, las diferentes ideas que se tienen son opciones para realizar tareas, que deben de ser priorizadas (en Kanban se llama Upstream y en siguientes post hablaremos más en detalle de ello). Una vez se ha priorizado la idea, se pasa a un estado en el que empezamos a contar y del que no podemos tirar hacía atrás. Una vez pasamos al estado de compromiso, la tarea tiene que finalizarse o cancelarse (habría que evitar siempre la cancelación ya que suponemos que ha pasado todo los filtros necesarios para asegurarnos que hay que realizar dicha tarea)
  • Uno de los principios de Kanban es hacer las políticas explícitas. Podemos ayudarnos de esto en los paneles indicando las políticas que tenemos que aplicar en cada uno de los estados. Por ejemplo, las entregas listas, por política, siempre se grabará en un determinado registro, se almacenará en una determinada base de datos, etc. Otro ejemplo podría ser que para las pruebas de usuario solo tendremos 15 días, etc., pero si podemos indicarlas en el panel, será transparente para todo el mundo.

Trabajo por lotes

  • Kanban también permite el trabajo por lotes (push). Estos se suele utilizar cuando realizamos tareas de priorización periódicas donde indicamos las tareas que están listas para desarrollarse. Por ejemplo, cada dos semanas se traspasa una carga de trabajo a la columna de listo con las tareas que ya están aprobadas para realizar. Es importante señalar que cuanto más largo en el tiempo sea esta carga de tareas, menos flexibilidad tendrá el sistema (ver el punto de replanificaciones y entregas frecuentes)

 

Descartes

  • Es importante tener en cuenta que debemos descartar ideas. Las ideas son opciones que tenemos para elegir y tenemos que seleccionar la que más valor aporta a la compañía. Si descartamos muchas y hacemos pocas, quiere decir que nuestra capacidad no es la adecuada ya que hay muchas necesidades pero poca capacidad. Un ratio muy bajo de descartes quieres decir que hacemos prácticamente todo lo que pedimos, sean ideas buenas o tal vez ideas que no aporten el beneficio esperado. Hay que tener en cuenta que el futuro es incierto, no sabemos si una idea va a acabar teniendo éxito o no. Un ratio equilibrado sería un 50% de descartes.

Replanificaciones y entregas frecuentes

  • Esta característica es una de las principales diferencias con respecto a Scrum. Mientras que en Scrum, tenemos un Sprint donde no se puede replanificar nada y no se entrega nada hasta el final del Sprint (normalmente 15 días), en Kanban tenemos más flexibilidad para gestionar las replanificaciones y las entregas. Lo ideal sería replanificar a demanda, es decir, en cuanto el sistema requiera una tarea, que en ese momento se pueda evaluar que tarea realizar y seleccionarla (planificación a demanda). Una mala idea es hacer una planificación a largo plazo (por ejemplo mensual) ya que en determinados sistemas, siempre surgen necesidades no planificadas que hacer que no se pueda cumplir dicha planificación. Kanban recomienda realizar reuniones de planificación semanales, para adecuar las tareas a las necesidades actuales.
  • El mismo criterio se aplica a las entregas. Si podemos realizar una entrega lo más rápido posible, antes se podrá aportar valor a la compañía. Una entrega a demanda es lo más ágil, aunque esto también tiene un coste, ya que no es lo mismo hacer 10 entregas en 10 días distintos que hacer una entrega un día de 10 tareas.
  • El concepto de agilidad consisten en entregar el trabajo correcto en el tiempo correcto, ni antes ni después.

Compromisos de entrega

  • Los compromisos de entrega se pueden retrasar hasta una fase posterior. Muchas veces, sobre todo si durante el proceso tenemos factores externos al sistema que no controlamos, no podremos tener un compromiso de entrega fiable. Por poner un ejemplo, en equipo de desarrollo de Software que una vez termine su desarrollo y sus pruebas, necesite otro equipo que realice pruebas de usuario. En este caso, Kanban permite crear compromisos de dos fases, con lo cual podremos medir el tiempo de nuestro sistema y su eficiencia por fases.

Métricas

En este punto vamos a ver dos tipos de métricas muy sencillas que podemos obtener de nuestro sistema, además de dos tipos de gráficas para medir, por ejemplo, las dos métricas que vamos a ver y poder estudiarlas.

Tiempo de espera del sistema y del cliente e Histogramas

  • Las primeras métricas que vamos a tener son los tiempos de espera del sistema y tiempo de espera del cliente. Mediante estas métricas, vamos a poder medir la velocidad de nuestro flujo de trabajo. Muy utilizadas para poder definir SLAs (acuerdos de niveles de servicio)
  • Tiempo de espera del sistema: Es el tiempo que transcurre desde que pasa el punto de compromiso hasta que pasa al primer estado con un WIP infinito. Con esto, podemos medir el tiempo que tarda una tarea desde que se empieza a trabajar en la tarea hasta que llegamos a un estado que no controlamos. Es importante avanzar que mediante el WIP de los estados vamos a poder controlar la velocidad del sistema y ajustarlo a nuestras necesidades, aunque lo veremos en el siguiente post.
  • Tiempo de espera del cliente: Es el tiempo desde el punto de compromiso hasta que ya lo tiene listo el cliente para utilizar. Con esta métrica, podemos indicar al cliente cuando tardará en tener disponible la petición.
  • Mediante un Histograma, vamos a poder visualizar de forma clara, por ejemplo, los días que tarda el cliente en tener la tarea disponible. En el siguiente ejemplo, podemos ver en primer lugar una tabla con todas las tareas realizadas y los días que hemos tardado en finalizarla. Si transformamos esta tabla desde el punto de vista de los días de espera, podemos ver la cantidad de tareas que se han realizado en unos determinados días. En este ejemplo, podemos ver que lo normal es que tardemos entre 3 y 4 días en realizar las tareas. Este estudio podemos ampliarlo añadiendo tipología de tareas para saber cuando tarda el sistema en realizar determinados tipos de tareas e ir dando aproximaciones de nuestra velocidad del flujo de trabajo.

Rendimiento y Run-Chart

  • En la métrica de rendimiento vamos a poder medir las tareas terminadas por unidad de tiempo, midiendo el ratio de tareas completadas.
  • Es una métrica muy útil para medir la productividad de un equipo. Por ejemplo, vamos a poder medir que un equipo hace, por ejemplo, 10 tareas a la semana o 30 tareas al mes y podremos ver como evoluciona el sistema.
  • Mediante un Run-Chart, podemos buscar tendencias o impactos en nuestro rendimiento. Por ejemplo, podemos incorporar nuevas acciones para mejorar nuestro sistema (mejora continua) y medir dicho impacto para saber si estamos mejorando por el contrario, estamos empeorando nuestro rendimiento.

Conclusiones

En este post hemos visto algunos conceptos claves de Kanban para poder diseñar los primeros paneles Kanban y un par de métricas muy sencillas de calcular para poder medir nuestro sistema. Recordar que no podemos mejorar lo que no medimos.

Próximo post

En el próximo post hablaremos de lo siguiente:

  • Diseño de los paneles: Algunas ideas para crear un buen panel Kanban
  • Diseño de tarjetas para ponerlas en el panel
  • La Ley de Little: Como mediante el WIP vamos a poder controlar nuestro flujo de trabajo
  • Métricas: Vamos a ver varias métricas más y entender un Diagrama Acumulativo de Flujo (CFD) para poder estudiar nuestro sistema.

 

 

CERTIFICACION PRINCE2 PRACTITIONER

¿QUÉ ES PRINCE2?

Después de haber realizado la certificación de Scrum Level y para cerrar el círculo de las metodologías, me propuse conocer lo que me podía aportar Prince2 Practitioner a la gestión de proyectos.

Para superar los exámenes de Prince2 no es obligatorio pasar un curso en un preparador oficial (como se exige en la certificación PMP) pero es muy recomendable realizarlo. Asi que, junto con un compañero de trabajo, me matriculé en un curso de preparación de la certificación Prince2. El examen de certificación se planificó para enero de 2017.

¿Que es Prince2?. La web de QRP lo define así:  “Es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está “basado en los productos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.”

Más que un conjunto de buenas practicas (como es el PMBOK de PMI), PRINCE2 propone una metodología específica de gestión de proyectos, es decir, cubre todas las temáticas y propone cómo llevarlas a la práctica.

PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas privadas y organizaciones, especialmente en el Reino Unido. Es la metodología seguida, por ejemplo, por la EUIPO.

CERTIFICACIONES:

Existen dos niveles de certificación:

  • Foundation: certifica el conocimiento de la terminología y metodología de gestión de proyectos con PRINCE2
  • Practitioner: certifica la capacidad para gestionar proyectos según la metodología PRINCE2. Se necesita aprobar el nivel Foundation para presentarse a este nivel.

Un apunte, si ya dispones de uno de estos certificados: CAPM, PMP o IPMA no es necesario examinarse previamente del nivel Foundation, pues se convalida automáticamente.

Adicionalmente, Prince2 también dispone de una solución enfocada al mundo Agile. Esta certificación proporciona la guía para adaptar PRINCE2 en un contexto ágil e incluye:

  • Cómo adaptar el conjunto integrado de principios, temáticas y procesos de PRINCE2
  • La forma de crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • La manera de incorporar los comportamientos, conceptos y técnicas ágiles fundamentales dentro de PRINCE2

Durante el año 2017 se produjo una gran actualización de Prince2, tanto a nivel de guía como de exámenes. Una de las consecuencias de este cambio es que los exámenes ya no están disponibles en español.

FUNDAMENTOS:

No es mi intención hablar en detalle de la metodología, pues existen otros blogs donde detallan este punto, solo destacar que Prince2 se basa fundamentalmente en:

  • Siete temáticas:
    1. Caso de negocio: manera en que se desarrolla una idea hasta convertirse en un proyecto viable para la organización.
    2. Organización: puestos, funciones y responsabilidades del equipo encargado de ejecutar el proyecto.
    3. Calidad: Se ocupa de desarrollar la comprensión de los interesados respecto a los atributos de calidad de los productos a entregar.
    4. Planes: Describe los pasos requeridos para desarrollar los planes establecidos y las técnicas de PRINCE2 que se deben aplicar.
    5. Riesgo: gestión de las incertidumbres en sus planes.
    6. Cambio: cómo se evalúa y actúa para incorporar los posibles cambios a la línea base del proyecto
    7. Progreso: proceso de toma de decisiones para aprobar planes, seguimiento del avance real y el manejo de excepciones cuando los planes no se cumplen.
  • Siete procesos:

    1. Puesta en Marcha de un Proyecto.
    2. Dirección del Proyecto.
    3. Inicio del Proyecto.
    4. Control de Fase.
    5. Gestión de la Entrega de Productos.
    6. Gestión de los Límites de Fase
    7. Cierre de Proyecto
  • Siete  principios (que se deben seguir obligatoriamente):
    1. Justificación comercial continua
    2. Aprender de la experiencia
    3. Roles y Responsabilidades definidos
    4. Gestión por Fases
    5. Gestión por excepción
    6. Orientación a productos
    7. Adaptación al entorno del proyecto (un proyecto de PRINCE2 se debe adaptar al tamaño, el entorno, la complejidad, la importancia, la capacidad de la empresa y el riesgo del proyecto).

EXÁMENES:

Ahora vamos a hablar de los exámenes de las dos certificaciones:

  • El examen Foundation:
    • Se puede hacer on line.
    • Duración: una hora
    • Nivel de dificultad: es bastante sencillo
    • Material permitido: ninguno
    • Son 75 preguntas. Se necesitan 35 aciertos para aprobar
    • Renovación: no es necesario
  • El examen Practitioner:
    • Duración: son dos horas y media. Os aseguro que no sobra ni un minuto de tiempo. Se debe gestionar bien el tiempo para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el examen PMP de PMI  el Practitioner es mucho más sencillo pero exige dedicación y conocer los tipos de preguntas de las que se compone el examen.
    • Se basa en un escenario. Por eso es muy interesante poder realizar el examen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta y también del escenario propuesto.
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial del año 2017: “Éxito en la gestión de proyectos con Prince2
    • Son 80 preguntas. Se deben conseguir 44 aciertos
    • Renovación: cada 5 años
    • En 48 horas ya se proporciona la nota del examen

En este sitio web puedes encontrar unos excelentes Consejos para aprobar.

CONCLUSIÓN:

Lo que me ha gustado de Prince2:

  • El enfoque basado en el Business Case. Un proyecto debe tener una justificación comercial continua.  Esto significa que la razón para iniciar el proyecto debe tener sentido desde un punto de vista empresarial y debe haber un claro retorno de la inversión. El “Business Case” se debe revisar periódicamente durante toda la vida del proyecto para comprobar su continua justificación para el negocio. Si la justificación desaparece,  el proyecto debe cerrarse.
  • La gestión por excepción. Las tolerancias a los cambios están perfectamente definidas. Esto proporciona cierta independencia al director de proyectos para tomar decisiones, siempre que se esté dentro de las tolerancias establecidas dentros de las normas de gestión del proyecto.
  • Al ser una metodología (y no un conjunto de buenas prácticas como el PMBOK) si no se dispone de experiencia en proyectos, aporta una guía y un marco para gestionar el proyecto, que es aplicable desde el primer momento. Esto es una gran ayuda para los que se inician en la gestión de proyectos, pues Price2 les va a guiar punto por punto desde el principio hasta el final del proyecto.
  • Prince2 prefiere que el Project Manager se centre en el producto/proyecto y no se implique en la realización de tareas técnicas (se separan las capas técnica y de gestión).

Lo que veo mejorable:

  • El responsable del proyecto y del éxito del mismo es la Junta del Proyecto (Directivo, Usuario Principal y Proveedor Principal) . El Project Manager es responsable de dirigir el día a día del proyecto. Puede parecer un “secretario de lujo” de la Junta de Proyecto.
  • No incluye la administración o desarrollo de los Requerimientos. Estarían incluidos dentro de la temática de “Calidad”.
  • Da por sentado que se conocen conceptos que requieren tener conocimientos previos en materia de proyectos. Por ejemplo, el WBS (Work Breakdown Structure) o el PBS (Product Breakdown Structure)

RECURSOS: