Archivos de la categoría: PRODUCTIVIDAD COLECTIVA
PRODUCT OWNER
El Dueño de Producto es el responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. El cómo se lleva a cabo esto podría variar ampliamente entre distintas organizaciones, Equipos Scrum e individuos.
El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye:
• Expresar claramente los elementos de la Lista del Producto;
• Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegurar que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y,
• Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo. El Dueño de Producto es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiar la prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
Para que el Dueño de Producto pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Dueño de Producto se reflejan en el contenido y en la priorización de la Lista del Producto. Nadie puede forzar al Equipo de Desarrollo a que trabaje con base en un conjunto diferente de requisitos.
SCRUM TEAM
El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. El equipo de Scrum ha demostrado ser cada vez más efectivo para todos los usos anteriores y cualquier trabajo complejo. Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
ARTEFACTOS
Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.
Nos referimos concretamente a los siguientes:
Transparencia de los Artefactos
Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar. El Scrum Master debe trabajar con el Dueño de Producto, el Equipo de Desarrollo y otras partes involucradas para entender si los artefactos son completamente transparentes. Hay prácticas para hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas si no hay una transparencia completa. Un Scrum Master puede detectar la falta de transparencia inspeccionando artefactos, reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los reales. La labor del Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la
transparencia de los artefactos. Este trabajo usualmente incluye aprendizaje, convicción y cambio. La transparencia no ocurre de la noche a la mañana, sino que es un camino.
Definición de “Terminado” (Definition of “Done”)
Cuando un elemento de la Lista de Producto o un Incremento se describe como “Terminado”, todo el mundo debe entender lo que significa “Terminado”. Aunque esto puede variar significativamente para cada Equipo Scrum, los miembros del Equipo deben tener un entendimiento compartido de lo que significa que el trabajo esté completado para asegurar la transparencia. Esta es la definición de “Terminado” para el Equipo Scrum y se utiliza para evaluar cuándo se ha completado el trabajo sobre el Incremento de producto. Esta misma definición guía al Equipo de Desarrollo en saber cuántos elementos de la Lista de Producto puede seleccionar durante la Planificación del Sprint. El propósito de cada Sprint es entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción y que se ajustan a la Definición de “Terminado” actual del Equipo Scrum. Los Equipos de Desarrollo entregan un Incremento de funcionalidad de producto en cada Sprint. Este Incremento es utilizable, de modo que el Dueño de Producto podría elegir liberarlo inmediatamente. Si la definición de “Terminado” para un incremento es parte de las convenciones, estándares o guías de la organización de desarrollo, al menos todos los Equipos Scrum deben seguirla. Si “Terminado” para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe especificar una definición de “Terminado” apropiada para el producto. Si hay múltiples Equipos Scrum trabajando en la entrega del sistema o producto, los Equipos de Desarrollo en todos los Equipos Scrum deben definir en conjunto la definición de “Terminado”. Cada Incremento se integra con todos los Incrementos anteriores y es probado de manera exhaustiva, asegurando que todos los Incrementos funcionan en conjunto.
EVENTOS
En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.
Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos de Scrum constituye una oportunidad formal para la inspección y adaptación de algún aspecto. Estos eventos se diseñaron específicamente para habilitar los pilares vitales de transparencia e inspección. La falta de alguno de estos eventos da como resultado una reducción de la transparencia y constituye una oportunidad perdida de inspección y adaptación.
Objetivo del Sprint (Sprint Goal)
El Objetivo del Sprint es una meta establecida para el Sprint que puede lograrse mediante la implementación de la Lista de Producto. Proporciona una guía al Equipo de Desarrollo acerca de por qué está construyendo el incremento. Se crea durante la Planificación del Sprint. El objetivo del Sprint brinda al equipo de desarrollo cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint. Los elementos de la Lista del Producto seleccionados ofrecen una función coherente que puede ser el objetivo del Sprint. El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas.
A medida que el equipo de desarrollo trabaja mantiene el objetivo del Sprint en mente. Con el fin de satisfacer el objetivo del Sprint, el equipo implementa funcionalidad y tecnología. Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo espera, ellos colaboran con el Dueño del Producto para negociar el alcance de la Lista de pendientes del Sprint (Sprint Backlog).
ROLES
Scrum prescribe tres roles:
- PRODUCT OWNER («dueño del producto»)
- SCRUM MASTER («entrenador SCRUM»)
- DEVELOPMENT TEAM («equipo de desarrollo»)
La suma de todos los roles de Scrum es el Equipo Scrum o SCRUM TEAM. Cada uno de estos roles tiene responsabilidades muy definidas y rinde cuentas por distintos motivos.
SCRUM
Antecedentes históricos
En 1985, Hirotaka Takeuchi y Ikujiro Nonaka iniciaron una investigación de los procesos productivos de empresas tecnológicas japonesas y estadounidenses. En sus análisis, observaron que algunas fases se solapaban, por lo que plantearon la creación de grupos multidisciplinares y auto-organizados, dotados de poder para provocar avances trabajando en un mismo espacio físico, todos a una de principio a fin.
Un año más tarde publicaron conjuntamente un artículo en la Harvard Business Review titulado «The new new product development game» (que puede traducirse como “El nuevo juego para el desarrollo de nuevos productos”) y que se considera el punto de arranque de esta metodología. Toman como ejemplo la melé en el rugby y establecen que este tipo de enfoque puede servir mejor a los requisitos competitivos del momento.
Guía
Años más tarde, Jeff Sutherland (en Easel Corporation -1993-) y Ken Schwaber (en Delphi -1995-), desarrollaron SCRUM y la Guía que lo define y que aquí queda resumida. Este marco de trabajo hace uso de una nomenclatura propia con la que, necesariamente, hay que familiarizarse. A cambio, resulta ideal para abordar problemas complejos de forma creativa y adaptativa, a la vez que se entrega producto con un valor cada vez mayor siguiendo una frecuencia temporal breve. Scrum es fácil de entender pero difícil de dominar. El significado que transmite su denominación es claro: el equipo es un bloque unido, todo un equipo está contra otro equipo, o ganamos todos o perdemos todos.
Podría considerarse como un conjunto de buenas prácticas que fomentan el trabajo en equipo buscando obtener el mejor resultado mediante entregas parciales y regulares. Se compone de una serie de roles, eventos (reuniones, ceremonias o rituales) y artefactos (herramientas).
Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los roles, eventos y artefactos y rigen las relaciones e interacciones entre ellos.
Valores
El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con estos cinco valores. Las personas se comprometen de manera individual a alcanzar las metas del Equipo Scrum. Los miembros del Equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles. Todos se enfocan en el trabajo del Sprint y en las metas del Equipo Scrum. El Equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo. Los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes.
Usos
Scrum fue desarrollado inicialmente para gestionar y desarrollar productos. Desde principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para desarrollar software, hardware, software embebido, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para gestionar la operación de organizaciones y casi todo lo que usamos en nuestra vida diaria, como individuo y como sociedad. Dado que la complejidad de la tecnología, el mercado y del entorno y sus interacciones aumentan rápidamente, la utilidad de Scrum para tratar con la complejidad está a prueba diariamente.
Pilares
Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo. Tres pilares soportan toda la implementación del control de procesos empírico:
Transparencia
Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar común,de tal modo que los observadores compartan un entendimiento común de lo que se está viendo. Por ejemplo:
- Todos los participantes deben compartir un lenguaje común para referirse al proceso; y
- Aquellos que desempeñan el trabajo y quienes inspeccionan el incremento resultante deben compartir una definición común de “Terminado”.
Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo para detectar variaciones indeseadas. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables y que el producto resultante será inaceptable, el proceso o el material que está siendo procesado deben ajustarse. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
Cuando el Equipo Scrum incorpora y vivencia los valores de compromiso, coraje, foco, apertura y respeto, los pilares Scrum de transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el mundo. Los miembros del Equipo Scrum aprenden y exploran estos valores a medida que trabajan en los eventos, roles y artefactos de Scrum.
SEIS SIGMA
La letra griega minúscula sigma «σ», en estadística, hace referencia a la desviación estándar (también conocido por sus siglas en inglés: SD) . Es una medida que se usa para cuantificar la variación o dispersión respecto a la media (average) o valor esperado de un conjunto de datos numéricos. En este gráfico observamos una mayor dispersión en la variable azul que en la roja.
Definición
SEIS SIGMA (6σ) es una metodología de mejora de procesos. Fue creada en Motorola por el ingeniero Bill Smith en la década de los ’80, aunque su origen se remonta a las teorías sobre gestión de procesos desarrolladas después de la 2ª Guerra Mundial. Se centra en la reducción de la variabilidad de los mismos. Busca reducir al máximo los defectos o fallos en la entrega de un producto o servicio al cliente reforzando y optimizando cada parte de proceso consiguiendo.
Establecer que un proceso tiene un rango de efectividad dentro de los 6 sigma es una forma técnica estadística de decir que la desviación típica respecto al valor desado es muy pequeña.
Etapas del proceso
- DEFINE: Definir, concretando el objetivo del problema o defecto y validarlo, a la vez que se definen los integrantes del proceso.
- MEASURE: Medir, entendiendo el funcionamiento actual del problema o defecto.
- ANALYZE: Analizar, averiguando sus causas reales.
- IMPROVE: Mejorar, minimizando la inversión a realizar.
- CONTROL: Controlar, tomando medidas con el fin de garantizar la continuidad de la mejora.
Principios
- Liderazgo comprometido de arriba hacia abajo.
- La estructura directiva incluye personal a tiempo completo.
- Entrenamiento.
- Acreditación orientada al cliente y enfocada a los procesos.
- Dirigida con datos.
- Metodología robusta.
- Los proyectos generan ahorros o aumento en ventas.
- El trabajo se reconoce.
- Los proyectos son largos.
- SEIS SIGMA (6σ) se comunica.
Con el paso del tiempo, han ido surgiendo variantes de la metodología SEIS SIGMA (6σ). Una de las más populares el Lean Sigma, programa que pone el foco en la reducción del tiempo necesario para la producción de productos y servicios, evitando los sobrecostes y la utilización inadecuada de recursos técnicos y operativos.
LEAN
Definición
Lean es una filosofía de trabajo y gestión de proyectos que busca agilizar al máximo las operaciones a través del compromiso de la dirección con la estrategia a largo plazo y la implicación total con los objetivos. Sirve como caja de herramientas para resolver problemas y mejorar situaciones. Tiene como objetivo la mejora de la calidad pero sobre todo de la eficiencia de los sistemas productivos (reducir el tiempo de ciclo y los costos). Sus puntos clave son:
- Entrega de valor continuo
- Minimizar desperdicio (eliminar tareas que no aporten valor)
- Mejora continua (Kaizen)
Esta cultura surgió ligada a la evolución histórica del sector del automóvil y el impacto que tuvo sobre ella la situación de crisis vivida tras la 2ª Guerra Mundial. Taiichi Ohno, ingeniero industrial japonés, consiguió diseñar e implantar en Toyota durante la décadas ’50 el sistema de producción Just In Time (JIT). Esta ventaja competitiva la convirtió rápidamente en líder mundial en su sector.
El planteamiento del Just-In-Time es muy simple en apariencia. Se basa en tener a la mano los elementos que se necesitan, en las cantidades que se necesitan, en el momento en que se necesitan. En un principio, se pensaba que sería exclusivo del país nipón, por las vinculaciones con sus tradiciones culturales. Con el tiempo se ha constatado que es un modelo perfectamente exportable, no sólo a cualquier lugar del mundo sino a otros sectores de actividad.
En 1987, un equipo de investigadores del Sistema de Producción de Toyota (TPS), capitaneados por James Womack y Daniel Jones, desarrollaron el término “Lean” en su libro sobre él, «La máquina que cambió el mundo». En este libro se confrontan los sistemas de producción Lean vs producción en masa, dos formas de pensar muy diferentes acerca del modo en que los seres humanos colaboran para crear valor.
Esta redenominación fue acompañada de una serie de artículos que permitieron desvincular esta nueva filosofía del sector de la automoción. A partir de los ’90 se produjo una expansión del concepto al mundo de la gestión, servicios, etc… hasta tal punto que podemos decir que en la actualidad la cultura Lean se halla implementada con éxito en la gran mayoría de sectores de actividad.
Principios
- Pregunta al usuario final para especificar con precisión el concepto de valor en cada producto específico
- Identificar el flujo de valor para cada producto eliminando todo lo que no aporta
- Hacer que el valor fluya sin interrupciones: trabaja sin prisa pero sin pausa
- Dejar que el consumidor atraiga hacia sí (‘pull‘) el valor procedente del fabricante: actúa en el momento adecuado
- Perseguir la perfección: mejora continua
Enemigos: 3Ms
Así pues, los tres enemigos que el pensamiento ‘lean’ tiene identificados son las llamadas «3Ms»:
1) Muda, el desperdicio o despilfarro, lo que supone hacer cosas que no aportan valor. Podríamos identificar distintos tipos distintos de desperdicios: en sobreproducción, tiempo, procesos, movimientos, transporte, inventario, defectos y hasta en infrautilizar el talento de las personas. La eliminación de desperdicios, Muda, basa su éxito en gestionar adecuadamente el Muri y el Mura
2) Mura, el desnivel, la variación o el desequilibrio ocasionado por las diferentes cargas de trabajo (ir unas veces desbordado y otras sentirnos ociosos). Se manifiesta en los tiempos muertos, la irregularidad, los imprevistos, malas praxis como dejarlo todo para el final que provocan picos de trabajo incontrolados…
3) Muri, la sobrecarga, la presión innecesaria que provoca cuellos de botella y estrés o esfuerzo no razonable. A veces, viene motivado por la existencia de personas que trabajan en exceso creando dependencias nocivas para el equipo
Para combatir el Muri se propone utilizar:
- el método 5S
- la estandarizarización de tareas
- la polivalencia
KANBAN
Kanban es un método de gestión de procesos que se basa en organizar el flujo de trabajo y la información de un modo muy visual. Se lleva a la práctica desplazando tarjetas sobre un tablero. Es una manera de tomar conciencia de algo tan intangible como es saber si lo que hacemos lo estamos haciendo «bien», es decir, conforme el cliente espera y maximizando nuestras capacidades.
Se puede utilizar para gestionar proyectos a nivel individual, aunque donde despliega su mayor potencial es a nivel de equipo. Es sencillo de adaptar a cualquier sistema de producción porque no requiere de grandes cambios organizativos. Además, su implantación es compatible con la existencia de otras metodologías ágiles como Scrum.
La visualización del proceso de producción permite identificar el valor para el cliente y organizar los flujos de tareas en curso de modo que se consiga la entrega «justo a tiempo» (JIT). Ello permite aumentar la calidad y enfocarse en la mejora continua del proceso. Debido a su impacto positivo en la eficiencia del flujo de trabajo, su uso está ampliamente extendido en multitud de sectores de actividad.
El método Kanban fue ideado originariamente por el ingeniero industrial Taiichi Ohno en la década de los ’50 para optimizar la producción de automóviles en Toyota en el marco del TPS (Sistema de Producción Toyota). La reformulación de esta herramienta llevada a cabo por David J. Anderson ha permitido que este sistema se adapte al trabajo de conocimiento y el desarrollo de productos complejos de cualquier naturaleza.
El tablero Kanban
La herramienta que sirve de soporte para visualizar el flujo de trabajo nos permite detectar cuellos de botella y debilidades en el flujo de trabajo, focalizarse en el trabajo en curso y reducir notoriamente el número de reuniones necesarias para actualizar información.
En las etapas iniciales de implantación del método en una organización se recomienda el uso de tableros físicos para que el equipo comience a familiarizarse con el hábito de mover tarjetas a medida que se producen avances en el proceso. No obstante, cuando el flujo de trabajo ya es abundante, el equipo es numeroso y hay muchas tarjetas sobre el tablero, las notas adhesivas corren el peligro de mezclarse o perjudicarse en el desorden.
A medida que el proceso empiece a complicarse y mantener el orden se haga difícil, nos veremos obligados a acudir a soluciones digitales. Existen múltiples opciones de software adaptado que nos permiten trabajar con tableros Kanban en la nube disfrutando de un alto grado de transparencia y operatividad.
Las tarjetas Kanban
El elemento clave de cada tablero Kanban es la tarjeta. En su versión más simple, una tarjeta Kanban no es más que una nota adhesiva pegada en un tablero representando una tarea de trabajo que debe realizarse. Por su posición en él nos informa en qué estado se encuentra. El número de tarjetas en un tablero debe ser limitado. Reducen la necesidad de reuniones de equipo pues son, en sí mismas, un canal de comunicación entre sus miembros ya que sirven como centros de información. Nos permiten visualizar con transparencia el progreso de las tareas desde que se solicitan hasta el momento en que se consideran finalizadas.
Cuando trabajamos en entornos digitales, tenemos la posibilidad de incorporar de manera sintética los datos clave de la tarea: prioridad, tiempo del ciclo, fecha límite, responsable de ejecución, etc… De hecho, con la irrupción de las TIC el alcance del sistema Kanban en la gestión de inventarios es de una envergadura enorme en la industria, el transporte y la distribución.
Etapas para configurar el método
- Identifica y visualiza las fases del ciclo de tareas para comprender cómo avanza el trabajo. La manera en la que Kanban permite visualizar la evolución del proceso es haciendo público un tablero donde las columnas representan los diferentes estados o pasos en el flujo de trabajo buscando el desarrollo incremental. Luego, marcando en él dónde se ubica cada tarea (tarjeta con descripción de tarea, asignación de responsable y estimación de horas).
- Establece límites al trabajo en curso (Work In Progress: WIP) para eliminar las interrupciones. Éste es uno de los elementos clave que hace posible crear un flujo ininterrumpido. No se puede iniciar una tarea sin concluir otra. En cada columna se establecerá un límite de tareas según la capacidad de trabajo del equipo, lo que asegurará que su equipo mantiene un ritmo de trabajo óptimo sin exceder su capacidad de trabajo.
- Optimiza el flujo de trabajo a través de la gestión de cada estado. Es necesario priorizar determinadas tareas para poder concentrar recursos en resolver las sobrecargas de trabajo evitando los cuellos de botella y los tiempos muertos. Al supervisar, medir y reportar activamente el flujo, los cambios continuos del sistema pueden ser evaluados para actuar sobre ellos. Se recomienda usar un indicador visual claro de «tarea completada» para evitar que una acción no se ejecute por falta de información sobre su estado.
- Fomenta la visibilidad haciendo explícitas las políticas. Poner por escrito las normas que gobiernan el proceso y publicitarlas. No se puede mejorar algo que no se entiende. Nadie se apuntará a un juego cuyas reglas no están claras para todos. Al final, son las personas que deben manejar la herramienta las que deben estar familiarizadas con sus particularidades. Por ello, el proceso debe estar bien definido, publicado y promovido.
- Crea métricas relevantes y fomenta los feedback regulares. Para que el sistema se implante con éxito duradero, se necesita diseñar y ejecutar un ritual de reuniones de equipo. Unas cortas diarias de seguimiento y otras con periodicidad mensual de revisión de procedimientos, en base métricas y resultados que ayuden a entender qué está pasando. Todas, con el ánimo de que fomenten la transparencia del proceso y la trasferencia de conocimiento entre los miembros del equipo.
Push VS Pull
A la hora de organizar el flujo de trabajo existen dos modos de incorporar material en el circuito:
- PUSH / EMPUJE (Ejemplo: Comedor self-service) ideal para aquellos sistemas en los que existen productos genéricos de los que se sabe que sí o sí van a demandarse. También cuando se precisa de una fabricación anterior para poder atender la demanda.
- PULL / ARRASTRE (Ejemplo: Restaurante a la carta) se ajusta en todo momento a la demanda. No se produce nada hasta que no hay una demanda real del producto. Esto suele darse en productos que son bajo demanda o totalmente personalizados.
Kanban, en tanto que funciona como una herramienta del sistema Just In Time (JIT), que busca eliminar inventarios, utiliza el sistema PULL (ARRASTRE). De este modo, se consigue no producir jamás en exceso.
Kanban VS Scrum
Scrum es un sistema iterativo, mientras que Kanban se basa en un flujo continuo. Ya se ha dicho anteriormente que no son sistemas incompatibles sino que pueden ser usados a la vez. Sin embargo, es frecuente el debate que contrapone Kanban al método Scrum. ¿Cuáles son sus grandes diferencias?
No podemos decir que exista una metodología mejor que otra sino que dependerá de los requerimientos de la empresa y la complejidad de sus procesos internos así como de lo más o menos predecible que sea la tecnología a utilizar (matriz de Stacey y modelo Cynefin).
En este sentido, el método Kanban está especialmente indicado para aquellas organizaciones que requieran de flexibilidad especialmente en la entrada de tareas. Es ideal para entorno complicados donde existe un cierto grado de complejidad y de incertidumbre. Kanban es un método para optimizar y gestionar flujos de trabajo siguiendo un conjunto de principios. En un tablero Kanban no hay restricciones de tiempo y se pueden agregar nuevas tarjetas (tareas) en cualquier momento si los WIP lo permiten.
Scrum pone más acento en la rapidez de los procesos y en el control por parte del equipo. Control que exige emplear un tiempo en reuniones, discusiones y verificaciones internas que Kanban no necesita. Es ideal para entorno complejos con un grado tanto de complejidad como de incertidumbre superior. Scrum requiere una planificación detallada y restrictiva, con procesos y roles predefinidos. en un tablero Scrum las restricciones de tiempo vienen marcadas por la longitud del sprint y no se pueden agregar nuevas tarjetas una vez iniciado el sprint. Tras la finalización de cada sprint, el tablero debe reiniciarse.
METODOLOGÍAS ÁGILES
Manifiesto Agile
Agile es un término acuñado en el Manifiesto por el desarrollo ágil de software, declaración formulada en 2001 por un grupo de profesionales del sector. Su intención era poner en común sus experiencias respecto a las formas mejores de trabajar y extraer conclusiones válidas que pudieran resultar de ayuda a terceros. Supuso una manera muy explícita de marcar distancias con las técnicas tradicionales de gestión de proyectos (metodología en cascada o Waterfall), por su falta de adecuación a los nuevos modelos de negocio, nacidos al amparo de la era digital.
Fue llevado a cabo por un grupo de 17 personas con un perfil técnico, algunos de los cuales ya habían formulado propuestas propias:
- Kent Beck, Ward Cunningham y Ron Jeffries (fundadores de la metodología de desarrollo de la ingeniería de software Programación Extrema XP, 1999)
- Ken Schwaber y Jeff Sutherland (creadores de Scrum, presentado en OOPSLA 1995)
Valores del Manifiesto Ágil
1.- Individuos e interacciones sobre procesos y herramientas
De todos los valores Agile, éste es el más importante. Considerar a las personas como el activo más importante que tiene cualquier organización, en cualquier nivel de su estructura, y sin importar el tipo de proyecto en el que estén trabajando. Las personas son las que aportan creatividad y capacidad de innovación. Las empresas deben entender y valorar la capacidad de autoorganizarse de sus empleados. Ello no implica que se prescinda de los procesos establecidos y se instaure la anarquía a nivel interno. Los procedimientos y las herramientas pero como elemento de apoyo para que las personas puedan lograr sus objetivos.
2.- Software funcionando sobre documentación extensiva
No se pone en cuestión que la documentación sea un elemento fundamental en cualquier proyecto. Sin embargo, se establece que lo que realmente prima es que las cosas funcionen. Y que se consiga hacerlo de un modo sencillo e intuitivo. Las nuevas tecnologías son un medio para conseguir productos más funcionales.
3.- Colaboración con el cliente sobre negociación contractual
En un mundo en constante evolución, la comunicación entre las partes es un elemento clave para que la ejecución de los proyectos conduzca al resultado esperado. Es la manera más efectiva de evitar la obsolescencia. Más allá de lo establecido en un contrato, lo que realmente permite conseguir que el producto final se corresponda con las necesidades del mercado en el momento de su lanzamiento es recabar el feedback continuo del cliente.
4.- Respuesta ante el cambio sobre seguir un plan
La capacidad de evolución y adaptación al mercado está por encima de cualquier plan establecido. Ser capaz de activar una respuesta rápida ante cualquier imprevisto genera una ventaja competitiva incuestionable que, a la postre, marca la diferencia. Planificar está muy (y es necesario hacerlo), pero los planes no sirven de nada si no se es capaz de reaccionar ante una circunstancia sobrevenida. El cambio se ha de entender en positivo, como una oportunidad de mejora.
Reflexión final
Que la balanza se decante por la parte de la izquierda no implica que tengamos que renunciar a la parte de la derecha. Ser Agile no significa renunciar a las herramientas, pues son elementos necesarios que facilitan nuestro trabajo, pero teniendo claro que son sólo eso. Ni que vayamos a dejar de documentar, pero sí que esta documentación sea la estrictamente necesaria. Tampoco vamos a renunciar a los contratos, pero debemos saber que los contratos ágiles deben ser más abiertos al cambio y estar más basados en la colaboración. En último término, huelga emplearse a fondo en elaborar un plan sabiendo que vamos a tener que gestionar el cambio para adaptarnos a nuevas necesidades.
Principios del Manifiesto Agile
Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continuada de software con valor
No va a resultar fácil conseguir la satisfacción del cliente sin adaptarnos a sus requerimientos cambiantes. La solución es la de realizar entregas tempranas y continuas de producto que funcione.
Principio 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Estar abiertos al cambio tiene que ser un modo de trabajar y hasta un modo de vida. No existe nada que no cambie continuamente y es imprescindible para sobrevivir acoger el cambio en positivo.
Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia por periodos de tiempo lo más corto posibles.
Necesitamos el feedback continuo por parte del cliente para saber si vamos en la buena dirección o no. El modo mejor de obtenerlo es entregando muchas veces y muy a menudo versiones de producto en funcionamiento de valor incremental.
Principio 4: Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto
Cuando nos manejamos en entorno cambiantes y modelos adaptativos, el equipo de trabajo tiene que actuar bajo la premisa de coordinación total y mantener hilo directo con el cliente a lo largo de todo el proceso.
Principio 5: Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
Una vez conformado el equipo adecuado -multifuncional- para llevar a cabo el proceso, la confianza debe ser plena. La gente debe ser respetada y valorada para que se organice por sí misma sin necesidad de recibir órdenes. La responsabilidad genera el compromiso y la motivación que hacen falta para que las cosas salgan.
Principio 6: El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara
Ningún canal de comunicación es mejor que una conversación cara a cara. Si las circunstancias lo permiten, será la manera de comunicarse entre los miembros del equipo. Y si no es posible, echaremos mano de la tecnología para reducir al mínimo la falta comunicación cara a cara.
Principio 7: El software funcionando es la principal medida progreso
Sólo existen dos formas de etiquetar un producto: completo (hecho) o incompleto (no hecho). Mantener esta idea en la cabeza, nos permitirá trabajar de modo iterativo e incremental, eliminando todo aquello que no aporte valor para conseguir producto acabado en funcionamiento.
Principio 8: Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La cadencia marcada se ha de mantener en el tiempo. De nada vale echar horas si no se consigue el objetivo de alcanzar el producto.
Principio 9: La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad
El diseño en los proyectos ágiles se lleva a cabo en cada sprint y para cada elemento del Backlog de Producto. Buscar el producto mínimamente viable no implica que no se busque la excelencia técnica y el buen diseño.
Principio 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Si un proyecto aspira a ser Ágil debe gestionarse de un modo sencillo y entregarse de manera simple. Es la mejor manera de relacionarse con el cliente.
Principio 11: Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
Existe una relación directa entre felicidad y productividad. Cuando la gente percibe aprecio y confianza se siente en la responsabilidad de sacar lo mejor que lleva dentro. En este sentido, es fundamental que todos los miembros de un equipo sientan que todo es responsabilidad de todos y no actúen de manera aislada.
Principio 12: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
Siempre todo es mejorable. La conciencia autocrítica y la humildad nos permiten transitar la senda de la mejora continua. Este análisis se debe emplear tanto en el producto como en los procesos que conducen a su elaboración. Debemos dotarnos de reuniones para llevar a cabo estos análisis.