IEBSchool - La Escuela de los Negocios y los Emprendedores

Contenido destacado del mes

Kanban

Kanban es una metodología que permite una mejora en el flujo de trabajo del equipo al separar un proceso productivo en varias fases que están perfectamente delimitadas. Kanban significa en japonés tarjetas visuales, que son los elementos clave de esta … [ leer más ]

Lo más leído

Kanban

30 noviembre, 2019, en Sin categoría por Miguel Angel Guinea Cabrera


1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Kanban es una metodología que permite una mejora en el flujo de trabajo del equipo al separar un proceso productivo en varias fases que están perfectamente delimitadas. Kanban significa en japonés tarjetas visuales, que son los elementos clave de esta metodología junto con el tablero.

El Método Kanban también permite a las organizaciones comenzar con su flujo de trabajo existente e impulsar el cambio evolutivo. Puede llevarse a cabo visualizando su flujo de trabajo, limitando el trabajo en progreso (WIP) y dejar de comenzar y comenzar a terminar. Kanban se puede usar en cualquier entorno de trabajo y es particularmente aplicable en situaciones en las que el trabajo llega de manera impredecible y / o cuando desea implementar el trabajo tan pronto como esté listo, en lugar de esperar otros elementos de trabajo.

Para implementar Kanban, se menciona el proceso STATIK (Systems Thinking Approach to Introducing Kanban) que significa “Enfoque de pensamiento de sistemas para presentar Kanban”.

STATIK es un proceso basado en la teoría de sistemas para implementar con éxito Kanban en una organización.

El pensamiento sistémico es una forma de entender cómo se comporta un sistema como un todo en lugar de analizar las partes componentes de forma aislada. Es la clave en el proceso de introducción de Kanban en una organización. Los servicios para tratar con STATIK pueden ser definidos a alto nivel, siempre que añadan valor directamente en la web que diseñaremos para el cliente.

El orden de los pasos en STATIK puede variar y es normal revisar los pasos constantemente para poder buscar nuevas mejoras. Este test sirve para evaluar el estado en el que se encuentran las organizaciones a la hora de integrar la metodología de Kanban.

Los pasos en este proceso no son necesariamente secuenciales, sino iterativos, y utilizan el aprendizaje de un paso para informar e influir en los demás:

Paso 0: Identificar Servicios. Y para cada servicio debemos:

Paso 1: Comprender qué hace que el servicio se ajuste al propósito del cliente

Paso 2: Comprender las fuentes de insatisfacción con el sistema actual

Paso 3: Analizar la demanda

Paso 4: Analizar la capacidad

Paso 5: Modelar el flujo de trabajo

Paso 6: Descubrir clases de servicio

Paso 7: Diseñar el Sistema Kanban

Paso 8: Socializar el diseño y negociar la implementación

El seguimiento de la implementación se puede hacer extrayendo ideas del litmus test.

Dentro de los equipos que adoptan KANBAN 2 roles clave:

  • Service request manager: Es el responsable de entender las necesidades y requisitos que demandan los clientes, además de simplificar, seleccionar y priorizar los expertos del backlog. Debe decidir qué es lo próximo que va a pasar el punto de compromiso. Este punto de compromiso es el momento en el que el trabajo debe realizarse y es donde empezaremos a medir el tiempo de respuesta del propio equipo.
  • Service delivery manager: Esta figura se encarga de ayudar al equipo de trabajo a que las tareas fluyan a lo largo del tablero de manera sostenida en el tiempo. Su misión no es coordinar al equipo o asignar tareas, sino de jugar un papel de observador y facilitador para que los equipos tomen decisiones y el sistema funcione. Para ello deberá facilitar las reuniones Kanban y las reuniones de entrega.

Acerca de las principales reuniones a establecer:

  • estrategia: en ella participarán el jefe de proyecto, el cliente y el request manager. sería la reunión inicial, y la repetiríamos con una periodicidad de una vez al mes, para analizar la estrategia del proyecto, revisar en cada una de ellas cómo va el proyecto y analizar el seguimiento de la estrategia seleccionada, para ver si es necesario pivotar o modificar parte de ella.
  • operaciones / riesgos y planificación de la entrega: en esta reunión participarán el jefe de proyecto, el request manager, el service delivery manager y el cliente. El objetivo de esta reunión es plantear una revisión inicial realizar esta reunión de nuevo cada dos semanas, para revisar así cuellos de botella en cuanto a recursos y estados, poder recopilar información de riesgos y recomendaciones sobre recursos. Al principio se marcarán con hitos en un timeline, y se volvería a realizar cada 15 días para preparar la de estrategia y adaptar los cambios que vayamos recibiendo en el plan de versiones.
  • realimentación: En ella participarán el jefe de proyecto y el request manager. Será una reunión semanal para ver prioridades en el backlog en función de bloqueos, dependencias y noticias del cliente.
  • Kanban / daily: todos los participantes del proyecto participan en esta reunión. Será diaria al principio del día con la dinámica round robin (qué se hizo ayer, qué vamos a hacer hoy e impedimentos). El tiempo de dicha reunión deberá rondar los 15 min y no sobrepasar los 30 min
  • retrospectiva / prestación de servicio: Todos los participantes del proyecto excepto el cliente: el equipo se reúne para ver qué cosas han funcionado, cuales necesitan mejorar o cambiar totalmente de cara a una mejor dinámica, pero también desde el punto de vista de efectividad.

Un ejemplo de tablero a usar con una sola calle con definición de estados y políticas asociadas:

  • Backlog: todas las ideas y tarjetas que se discutan en la reunión de estrategia que pueda son interesantes de cara a la nueva versión de la web.
  • Defined: aquí estarían todas las tarjetas que han sido discutidas en la reunión de realimentación y que el Service Request Manager ha llegado a tener una descripción inicial con una estimación inicial (high-level) por parte del equipo y donde se cuenta la Condición de Satisfacción y expectativas del cliente (el qué). La priorización es clara y ordenada en función del valor del negocio y dependencias / riesgos.
  • Ready: aquí estarían todas las tarjetas que el Service Request Manager ha discutido con el equipo para refinar. Tiene que tener asociado un checklist de accesibilidad / usabilidad, el checklist de Architectural Review y Seguridad definidos por los roles implicados en el proyecto con particularidades que esa tarjeta debe cumplir y el test asociado. Las tarjetas son divididas para intentar alcanzar un balance de duración de aproximadamente 16 horas / tarjeta. Estas tarjetas están listas para ser cogidas para su desarrollo.
  • Implementación: aquí estarán las tarjetas que estén en desarrollo, para su cierre deben cumplir que se ha implementado test unitario.
  • Test: se llevan a cabo los tests definidos durante el refinement de la tarjeta con los casos sobre usabilidad y arquitectura / seguridades adicionales.
  • Devops: se revisa el entregable para alinearlo con la configuración de despliegue, se chequean los resultados de tests de penetración, performance, así como smoke test para ver que una vez desplegado, el sistema es capaz de hacer un happy path sobre la aplicación (login, funcionalidad básica). Si hay actualizaciones de seguridad sobre los servidores, patching de vulnerabilidades, se aprovecha este paso para testearlo con el incremento de la tarjeta. El paso se cierra con un Exploratory Test Chapter de aceptación por parte del Service Request Manager. El paso a “Done” se realiza junto con los peticionarios de las tarjetas para su Aceptación.

 

 

 

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

comentarios para esta entrada