COMUNICACIÓN

Se debe recordar que la comunicación clara y precisa es una condición que permite establecer objetivos fundamentalmente transparentes y no ambiguos, y que, de no ser así, provocarían importantes errores. Es por eso que aquellos proyectos de sistemas, que requieren de una constante actualización y diseño técnico, son muy buenos candidatos a tales errores. Si se suma que los tiempos de entrega son siempre ajustados, al uso de lenguaje técnico que solo los programadores y personas ligadas a la informática conocen; y a las cualidades personales de muchos analistas y programadores que prefieren hablar con sus computadoras en vez de las personas, terminamos con el potencial de toparse con serios problemas de comunicación. De esta forma, los proyectos sufrirán retrasos, ya que se puede resolver un problema incorrecto o los integrantes del equipo de desarrollo salen o se unen a mitad del proyecto sin retroalimentación pertinente. Por otro lado las prácticas ágiles comunes, como la programación en pareja (dos programadores que colaboran entre sí), la estimación de tareas y la prueba de unidades, dependen mucho de la buena comunicación.

Al tener el equipo una buena interacción entre sus miembros los problemas se corrigen certeramente y con rapidez, y el pensamiento débil se fortalece rápidamente.

En el XP no solo importa la comunicación entre los miembros del equipo, sino también la comunicación entre los desarrolladores y los clientes. La conversación permanente y en lo posible cara a cara, está pensada para poder conocer los problemas directamente.

Sólo si todos los implicados están en contacto de forma permanente, se pueden evitar y detectar rápidamente los malentendidos que permiten reducir el tiempo destinado a reparar errores. La comunicación hace que todos trabajen con el mismo nivel de información y se sientan comprometidos con el proyecto (Kendall, 2011, pp. 166-181).

SIMPLEZA

Cuando trabajamos en un proyecto de desarrollo de software, normalmente debemos considerar de sobremanera el tamaño y complejidad que éste podría presentar. La simpleza en el desarrollo de software, significa que se tiene que empezar con la cosa más simple que pueda hacer hoy, sabiendo que mañana se tendrá que realizar algo un poco más complejo. Para ello se debe estar enfocado claramente en los objetivos del proyecto, lo cual es en realidad el propósito de todo desarrollo. Aplicar este enfoque también implica desarrollar solo las funciones necesarias en cada momento y no adelantar trabajo para posibles requisitos futuros. Así, el equipo desarrolla más rápido. Además, un producto simple es mucho más fácil de manejar, ya sea a la hora de seguir desarrollándolo o de realizar el mantenimiento. Un código de programación simple también facilita la comprensión, otra ventaja a favor del valor de la comunicación. Si todo el equipo es capaz de entender el código fuente, es más fácil intercambiar impresiones (Kendall, 2011, pp. 166-181).

LA RETROALIMENTACIÓN.

Es una acción sumamente importante cuando usamos una metodología de programación extrema. Al considerar la retroalimentación en este contexto, es bueno tener en cuenta que está muy relacionada con el concepto del tiempo. La retroalimentación concreta puede ocurrir en cualquier unidad de tiempo, (segundos, minutos, días, semanas o meses), y será útil para el equipo de desarrollo, dependiendo de lo que se informe, de quién se esté comunicando y de lo que se pretenda hacer con la retroalimentación (Kendall, 2011, pp 166-181). Por ejemplo, el equipo de Testing, podría indicar que un caso de prueba quebrantó el código que usted acaba de escribir, pero si esa retroalimentación no es entregada a tiempo, es decir, antes de que el código pase a producción, esa retroalimentación de nada servirá.

La retroalimentación es crítica sobre la programación de fechas y tiempos, y proviene de los clientes que comparan el objetivo del plan con el progreso realizado hasta ese momento.

La retroalimentación ayuda a los programadores y analistas a realizar los ajustes necesarios y permite a la empresa empezar a experimentar con mucha antelación lo que será el nuevo sistema una vez que sea completamente funcional. Este valor también va estrechamente ligado a la importancia de la comunicación directa (cara a cara).

Es importante que el cliente tenga numerosas oportunidades para expresar sus críticas.

Para poder llevar a cabo un concepto de feedback o retroalimentación como lo plantea el XP, es muy importante pensar en pasos pequeños.

El equipo trabaja en ciclos cortos, comprueba el código cada poco e incluso le presenta el avance al cliente en intervalos cortos. Así, las modificaciones y correcciones de errores se pueden llevar a cabo rápidamente (1&1 IONOS España S.L.U., s. f.).

LA VALENTÍA

Este concepto tiene que ver con la confianza, seguridad y confort que debe existir en el equipo de desarrollo. Significa no tener miedo de comenzar todo desde cero si después de analizar el trabajo realizado, nada está bien hecho. También significa poder estar en contacto con los instintos de uno mismo en relación con lo que funciona y lo que no. Valentía igualmente significa tener la capacidad de responder a la retroalimentación concreta, actuando con base en las corazonadas de sus compañeros de equipo, cuando ellos piensan que tienen una forma más simple y mejor de obtener su objetivo. Valentía significa que usted y su equipo confían entre sí y en sus clientes lo suficiente como para actuar en formas que mejoren de manera continua lo que se está llevando a cabo en el proyecto, incluso si esto implica descartar código, reformular las soluciones o simplificar más las metodologías aplicando innovación. La valentía también implica que usted, aplique con entusiasmo las prácticas de la metodología ágil. Es imprescindible tener una postura humilde durante el desarrollo de sistemas, pues, se debe hacer a la idea de que, si el usuario está expresando una dificultad, entonces hay que lidiar con ella y no se la puede ignorar, ya que para ellos, el desarrollador o programador, es quien provee las soluciones. Los modeladores ágiles hacen sugerencias, expresan opiniones, pero nunca insisten en que tienen la razón el cien por ciento del tiempo. Poseen la suficiente confianza en sí mismos como para permitir que sus clientes los cuestionen, los critiquen y, algunas veces, se quejen sobre el sistema que están desarrollando. Sin embargo, se debe considerar que el modelador debe aprender de sus clientes, quienes han estado en el negocio durante un buen tiempo, siendo ellos quienes tienen la experiencia en la operación de sus empresas (Kendall, 2011, pp. 166-181). El extreme programming entiende la valentía como la disposición a decir la verdad, incluso cuando es poco agradable. Si hay errores en el producto, hay que señalarlos, aunque sean responsabilidad de uno mismo. En un equipo que trabaja según los valores XP tampoco hace falta disculparse (1&1 IONOS España S.L.U., s. f.).

¿QUÉ ES KANBAN?.

Kanban es un método visual para gestionar y procesar el trabajo. Según el sitio Atlassian.com, coach en metodología ágil, “El objetivo del método Kanban es poder visualizar su trabajo, limitar la acumulación de tareas pendientes y maximizar la eficiencia o el flujo de trabajo. Los equipos que trabajan con Kanban se enfocan en reducir la duración de un proyecto o la intervención de cada miembro de comienzo a fin.” El sistema fue creado a finales de los años 40 por Taiichi Ohnoa, un ingeniero y empresario, que trabajaba para Toyota en Japón, quien desarrolló su metodología inspirada en una industria muy distinta a la automotriz, puesto que tomó la industria de los supermercados y cómo rellenan éstos sus estantes, puesto que los supermercados gestionan su inventario surtiendo los productos de acuerdo a la demanda del consumidor. Toyota se enfrentaba a un problema similar en cuanto la gestión de su inventario, así que Ohnoa decidió desarrollar Kanban, un sistema que le permitiera igualar la cantidad de productos en el inventario, con el material que realmente se estaba utilizando en la manufactura de los autos (Mesh, s. f.).

Dado que el desarrollo de software y de productos puede ser volátil y requiere un cambio constante con múltiples iteraciones, la metodología ágil funciona como guía para Kanban y para las estructuras de Scrum (Anderson D., 2010). La metodología Kanban sirve para visualizar el trabajo, evitar la acumulación de trabajo pendiente y maximizar la eficiencia, puesto que es un proceso que permite mejorar constantemente el flujo y la calidad del trabajo.

COMO ORGANIZAR PROYECTOS CON KANBAN

Recuerde que Kanban es un flujo de trabajo visual, por lo que utiliza un tablero físico o digital para planear y hacer el seguimiento de tareas, tiene en un tablero que utiliza tarjetas, columnas y lo más importante, el concepto de progreso constante.

Esto permite cierto control sobre el equipo y lo obliga a comprometerse a terminar el trabajo de manera continua. David Anderson, uno de los creadores de esta metodología, fue el que construyó la base de la estructura de un tablero Kanban, que tiene cinco componentes (Mesh, s. f.).

Uno de los flujos de trabajo Kanban más comunes y simples se compone de las listas, Por hacer, Hecho y alguna que otra lista adicional dependiendo de la complejidad del proyecto.

Para poder ejemplificar las listas de un tablero Kanban, utilizaremos una herramienta gratuita llamada Trello.

Observe las características de la siguiente tabla.

BITÁCORA BACKLOG

En esta lista se desglosa el proyecto y las partes se colocan en tarjetas individuales. También se pueden agregar tareas en las que el equipo piensa trabajar en un futuro o en las que se tendrá que trabajar eventualmente, pero que todavía no se pueden colocar en la lista “Por hacer”.

DISEÑO

Esta lista sirve para colocar las tarjetas de la bitácora que necesitan complementarse aún más. Cuando sucede esto, el equipo debe investigar o diseñar antes de moverla a la lista “En progreso”.

POR HACER

Cuando la información de la tarea se ha complementado, la tarjeta se mueve a esta lista. Esta es la señal para que el equipo empiece en trabajar en ella. En este punto, se asigna a un miembro del equipo como encargado de esa tarea y se fijan las fechas de entrega.

HACIENDO

Cuando se mueven las tarjetas a esta lista significa que se está trabajando en ellas.
Así, todo el equipo puede ver quién está trabajando y en qué. Las tarjetas de Trello también facilitan la colaboración gracias a la función ‘Comentario’, que permite hacer preguntas sobre las tareas.

REVISAR Y PROBAR

Cuando una tarea está casi terminada, se mueve a esta lista para que alguien más la revise. (En el ejemplo, se usa como plantilla la lista “Revisión de Código”, pero puede ser una revisión de cualquier trabajo).

HECHO

Cuando la tarea se ha revisado y aprobado, se puede mover a esta lista. Es tiempo de celebrar pues el equipo ha logrado el objetivo.

Hay que recordar que el objetivo principal del método Kanban es gestionar las tareas en las que se está trabajando. Esto significa que el equipo solamente debe trabajar en un número definido de tareas a la vez, para cada proyecto.

Cuando se limita la cantidad de tareas en las que se está trabajando, es mucho más fácil identificar las tareas que requieren más atención o más tiempo (Mesh, s. f.).

• “Los límites de WIP (Work In Progress) o ‘Trabajo en progreso’, en español, sirven para mejorar el rendimiento y reducir la cantidad de trabajo “incompleto”, porque obligan al equipo a enfocarse en tareas más pequeñas.
• Básicamente, los límites de WIP están para que sea fácil terminar las tareas. Y lo más importante, los límites de WIP le dan visibilidad a los obstáculos y a los problemas.”

La digitalización de los tableros de Kanban permite que todos los integrantes del equipo tengan la información actualizada de lo que sucede en el proyecto y en los hitos que se van cumpliendo.

También estas herramientas automatizadas logran detectar cuando una tarjeta lleva demasiado tiempo inerte en una lista y alerta de ello al jefe del proyecto para que tome acción.

Permite limitar el número de tarjetas que se pueden acumular en una lista. Cuando se supera el número máximo de tarjetas establecido, indica que ésta parte del flujo de trabajo se está retrasando.

En caso de no contar con estas herramientas digitalizadas, todo lo anterior tendrá que detectarse de manera visual y mejorarlo manualmente.

El método Kanban es una manera muy efectiva para lograr que los equipos sean más productivos, flexibles y claros.

• Ayudan a visualizar el flujo de trabajo.
• Aumentan significativamente los niveles de productividad.
• Maximizan la eficiencia del equipo.
• Reducen los cuellos de botella y el desperdicio.
• Mejoran la comunicacion y la tasa de éxito en los proyectos.
• Ayudan a implementar la mejora continua en los procesos

SERVICE REQUEST MANAGER

El “Gestor de Peticiones de Servicio” (en español) es el responsable de entender las necesidades y expectativas de los clientes, de facilitar, seleccionar y ordenar los elementos de trabajo en la Reunión de revisión de la cartera de trabajo (Replenishment Meeting).

Otros nombres para este rol, que ya podrían estar en las organizaciones, son: Gestor de Producto (Product Manager), Dueño de Producto (Product Owner) y Gestor de Servicio (Service Manager).

Por lo tanto, el Service Request Manager se encarga de gestionar la demanda y los requisitos dentro del sistema Kanban, manejando las relaciones con los Stakeholders y fomentando la transparencia dentro del sistema en torno a la priorización del trabajo.

SERVICE DELIVERY MANAGER

El “Gestor de Prestación de Servicio” (en español), es el responsable del flujo de trabajo entregando los elementos seleccionados a los clientes y facilitando la Reunión de Kanban y la planificación de la entrega (Delivery Planning).

Otros nombres para este rol, que ya podrían estar en las organizaciones, serian: Gestor del Flujo de trabajo (Flow Manager), Gestor de la Entrega, o Maestro del Flujo (Flow Master). Por lo tanto, el Service Delivery Manager es responsable del flujo de trabajo dentro de un sistema Kanban y/o determinados ítems de trabajo y facilita el Kanban Meeting y el Delivery Planning.

Los roles y funciones existentes se mantienen en Kanban, ya que los flujos de trabajo se investigan y se visualizan para proporcionar control de todo el trabajo, pero no cambian la forma en que la gente hace su trabajo o cómo interactúan con él (David J. Anderson and Andy Carmichael, 2016).

ROLES EN XP

Tracker Es el encargado de seguimiento. Proporciona retroalimentación al equipo. Debe verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.

Customer También llamado ‘cliente’, es quien escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio.

Programmer Es el programador considerado el más importante miembro del equipo, ya que escribe las pruebas unitarias y el código del sistema

Coach Es responsable del proceso global y se encarga de guiar a los miembros del equipo para seguir el proceso correctamente.

Tester Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

Big Boss Es el dueño de la tienda y el vínculo entre clientes y programadores. Su labor esencial es la coordinación.

Consultor Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto ayuda al equipo a resolver un problema específico y puede que no siempre haya un consultor como parte del equipo.

Manager Se encarga de agendar las reuniones, se asegura de que el proceso de juntas sea seguido, registra los resultados de las reuniones para futuros reportes para el Tracker. Asiste a las reuniones y trae información importante, mantiene al equipo feliz y productivo

PLANEACIÓN

La actividad de planeación comienza escuchando a los usuarios, quienes plantean a través de sus historias los requerimientos que permiten que los miembros técnicos del equipo XP, entiendan el contexto del negocio para el software y adquieran la sensibilidad de la salida y características principales y funcionalidad que se requieren.

Escuchar lleva a la creación de algunas “Historias de Usuario” que describen la salida necesaria, características y funcionalidad del software que se va a elaborar. Cada historia que es similar a definir un caso de uso, es escrita por el cliente y colocada en una tarjeta indizada.

Después de que el cliente le asigna una prioridad a la historia, los miembros del equipo XP Diseño la evalúan y le asignan un costo medido en semanas de desarrollo. Si se estima que la historia requiere más de tres semanas de desarrollo, se pide al cliente que la descomponga en historias más pequeñas y de nuevo se asigna un valor y costo.

Los clientes y desarrolladores trabajan juntos para decidir cómo agrupar las historias en el siguiente incremento de software, que desarrollará el equipo XP. Una vez que se llega a un compromiso sobre la entrega (acuerdo sobre las historias por incluir, la fecha de entrega y otros aspectos del proyecto), el equipo XP ordena las historias que serán desarrolladas por orden de importancia. (Pressman, 2010)

Historias de Usuario

Ejemplo 1.

Usuario: Como cliente deseo colocar un producto en un carrito de compras.

Desarrollador: Facilitar al cliente el proceso de hacer clic en un botón para colocar el producto en un carrito de compras con los productos que pretende comprar.

Ejemplo 2.

Usuario: Como cliente me gustaría elegir mi asiento en el avión.

Desarrollador: Llevar al cliente a una representación visual del aeroplano y pedirle que seleccione un asiento que se encuentre disponible (Kendall, 2011, p. 170).

DISEÑO

El diseño XP sigue rigurosamente el principio “mántenlo sencillo” (MS). Un diseño sencillo siempre se prefiere sobre una representación más compleja. Además, el diseño guía la implementación de una historia conforme se escribe: nada más y nada menos.

XP estimula el uso de las tarjetas CRC (Clase – Responsabilidad - Colaborador) las cuales identifican y organizan las clases orientadas a objetos que son relevantes para el incremento actual de software.

Las tarjetas CRC son el único producto del trabajo de diseño que se genera como parte del proceso XP. Si en el diseño de una historia se encuentra un problema de diseño difícil, XP recomienda la creación inmediata de un prototipo operativo de esa porción del diseño (Pressman, 2010, p. 63).

A través de la implementación y evaluación del prototipo, se busca disminuir el riesgo cuando comience la implementación verdadera y validar las estimaciones originales para la historia que contiene el problema de diseño (Pressman, 2010).

Entonces, se puede decir que un diseño simple se implementa más rápidamente que uno complejo. Por ello XP propone implementar el diseño más simple posible que funcione.

Cuando aparecen problemas técnicos, o cuando es difícil de estimar el tiempo para implementar una historia de usuario, pueden utilizarse pequeños programas de prueba llamados Spike, para explorar diferentes soluciones.

Spike es una innovación de Extreme Programming (XP) en el desarrollo de software ágil. Ya que es una pequeña historia o trabajo que sirve para responder o recopilar información en lugar de producir el incremento en un producto.

El refactoring, consiste en escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad, a los efectos de crearlo más simple, conciso y entendible. Este procedimiento, generalmente se aplica después de efectuar las pruebas unitarias o de integración, que permiten evaluar el comportamiento del programa, detectando la posibilidad de mejorarlo a través de la reducción de líneas de código, objeto hacerlo más eficiente. Las metodologías de XP sugieren re codificar cada vez que sea necesario (Pressman, 2010).

XP sugiere utilizar el concepto metáforas, como una manera sencilla de explicar el propósito del proyecto, así como guiar la estructura del mismo. Una buena metáfora debe ser fácil de comprender para el cliente y, a su vez, debe tener suficiente contenido como para que sirva de guía a la arquitectura del proyecto.

CODIFICACIÓN

Después de que las historias han sido desarrolladas, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso (incremento de software).

Una vez creada la prueba unitaria, el desarrollador está mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba, así, cuando el código está terminado, se le aplica de inmediato una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los desarrolladores.

Un concepto clave durante la actividad de codificación es la programación por parejas. XP recomienda que dos personas trabajen juntas en una estación de trabajo con el objeto de crear código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real (es frecuente que dos cabezas piensen más que una) y para el aseguramiento de la calidad también en tiempo real.

En la programación en parejas, por ejemplo, una de ellas tal vez piense en los detalles del código de una porción particular del diseño, mientras la otra se asegura de que se siguen los estándares de codificación (parte necesaria de XP) o de que el código para la historia satisfará la prueba unitaria desarrollada a fin de validar el código confrontándolo con la historia (Pressman, 2010).

PRUEBAS

La creación de pruebas unitarias antes de que comience la codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el uso de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategia de pruebas de regresión siempre que se modifique el código (lo que ocurre con frecuencia, dada la filosofía del rediseño en XP).

A medida que se organizan las pruebas unitarias individuales en un “grupo de prueba universal”, las pruebas de la integración y validación del sistema pueden efectuarse a diario. Esto da al equipo XP una indicación continua del avance y también lanza señales de alerta si las cosas marchan mal. “Corregir pequeños problemas cada cierto número de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final” (Wells D., 1999).

Las ‘pruebas de aceptación’ XP, también llamadas ‘pruebas del cliente’, son especificadas por el cliente y se centran en las características y funcionalidad generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptación se derivan de las historias de los usuarios que se han implementado como parte de la liberación del software (Pressman, 2010).

DEFINIR EL FLUJO DE TRABAJO DE LOS PROYECTOS

Se debe crear un tablero de trabajo, este deberá ser visible y accesible para todos los miembros del equipo, deberá contar con varias columnas, cada una representando los distintos estados por los que pasa una tarea antes de ser completada, de esta manera se tendrá pleno conocimiento del estado en la cual se encuentra.

El modelo de ciclo de vida Kanban, define que el tablero más básico utilizado está conformado por tres columnas: por hacer, en proceso y finalizado. A su vez, puede ser personalizado a gusto, como por ejemplo: diagnostico, definición, clasificación, desarrollo y testeo (Metodología Kanban: El método japonés que agilizara tu negocio - Mente Diamante, s. f.)

VISUALIZAR LAS FASES DEL CICLO DE PRODUCCIÓN

Se divide el trabajo en distintas secciones para una mejor ejecución, por lo que dentro de la metodología Kanban no se habla de una tarea como tal, sino de muchas partes que la conforman y, de esta forma, se agiliza el proceso de producción.

Generalmente, cada una de las partes recibe un post-it o tarjeta, que se pega en el tablero según su fase correspondiente, donde se escribe la información básica, una pequeña descripción o el lapso estimado para su realización, de esta manera el equipo tendrá pleno conocimiento de la carga total que supone el trabajo.

El tablero se puede personalizar, añadiéndole fotos de los responsables asignados para cada labor o también designando un color del post-it a cada uno de ellos; añadir también distintos elementos que complementen las tareas (por ejemplo, una cinta que una a dos post-it a modo de puente, como indicativo de que una tarea depende de otra para finalizarse).

Lo que se consigue con la visualización, es tener un panorama claro y preciso sobre el trabajo a realizar, sean las tareas que se encuentren pendientes asignadas a los miembros del equipo, las prioridades o los objetivos a lograr.

STOP STARTING, START FINISHING

Este es el lema de la metodología Kanban y significa que se debe priorizar el trabajo que se encuentra en ejecución, antes de comenzar con nuevas tareas.

El sistema indica que el trabajo en curso debe ser limitado, para evitar perder innecesariamente tiempo realizando muchas tareas a la vez y que sea más difícil ejecutarlas correctamente.

Por otro lado, cada miembro del equipo debe tener una cantidad máxima de actividades asignadas por fase, como forma de evitar la saturación del proceso. Para ello, se deberá definir cuál será el número máximo de tareas en cada una de las fases (Work in Progress, WIP), además, se debe recordar que no se debe iniciar ninguna nueva tarea sin antes haber finalizado la anterior.

CONTROL DE FLUJO

Se pueden mezclar tareas y proyectos, por lo que los miembros del equipo tendrán un constante flujo de trabajo. Esto permite tener un seguimiento pasivo de las tareas más importantes que se encuentran en desarrollo. A su vez, se tiene a disposición la posibilidad de vaciar información actualizada sustraída del seguimiento del trabajo realizado.

Pase a ser un método originado en los años 40, la vigencia del modelo de ciclo de vida Kanban sigue siendo una medida ventajosa para particulares, negocios o compañías, en razón de que la posibilidad de cambiar flexiblemente de prioridades en cualquier momento del proceso, brinda nuevas formas de llegar a los objetivos establecidos.

Estas particularidades, sumada a la facilidad de su implementación y a los fundamentos de la metodología Kanban de no dejar nada a medias tintas, es la manera ideal para organizar ágilmente los procesos internos.

En este sentido, se recomienda aplicar los valores Kanban especialmente en compañías que ameriten una reestructuración basada en la priorización de entregas de tareas o en la supervisión del trabajo de los miembros del equipo, medidas que les servirán para eliminar distracciones, finalizar ágil y correctamente los procesos, así como disminuir sobreproducciones que generen pérdidas de tiempo y capital (Metodología Kanban: El método japonés que agilizara tu negocio - Mente Diamante, s. f.).