Está en la página 1de 21

Metodologías Ágiles para el Desarrollo de Software Listado de los capítulos

1.- Introduciéndonos en el Desarrollo Ágil de Software
Empezamos a hablaros sobre el desarrollo ágil de proyectos: Explicación de las metodologías de gestión de proyectos y en concreto del enfoque conocido como Agile.

2.- Introducción al Desarrollo Ágil con Scrum
En este capítulo, haremos una vista general de Scrum, definiendo su enfoque y la propuesta al tiempo que lograremos un primer acercamiento a los pilares de sus pautas organizativas.

3.- Los roles en Scrum
En este capítulo, nos insertamos a fondo, en los roles propuestos por Scrum. Hablaremos sobre el Dueño de Producto, el Scrum Master y el Scrum Team. Cuáles son sus tareas y que aspectos deben cuidar cada uno de los roles.

4.- Artefactos en Scrum: claves para una organización diaria
En este capítulo hablaremos sobre las herramientas que Scrum, propone para mantener organizado un proyecto de desarrollo de Software: el backlog de producto, el backlog de sprint y Scrum Taskboar, y el incremento de funcionalidad.

5.- Ceremonias en Scrum
En este capítulo hablaremos sobre cómo llevar adelante, la planificación de un Sprint, las reuniones diarias del equipo con el Scrum Master, la revisión y la retrospectiva.

6.- Desarrollo Ágil con Kanban
Kanban, llega como metodología de gestión de proyectos, de la mano de la automotriz Toyota, representando estadísticamente, la metodología ágil que menor resistencia presenta en las compañías acostumbradas a las metodologías tradicionales.

Introduciéndonos en el Desarrollo Ágil de Software
Empezamos a hablaros sobre el desarrollo ágil de proyectos: Explicación de las metodologías de gestión de proyectos y en concreto del enfoque conocido como Agile.
¿Qué es el desarrollo ágil de software?
Así como existen métodos de gestión de proyectos tradicionales, como el propuesto por el Project Management Institute(R) más conocido como PMI(R) podemos encontrarnos con una rama diferente en la gestión de proyectos, conocida como Agile. El desarrollo ágil de software, no es más que una metodlogía de gestión adaptativa, que te permite llevar a cabo, proyectos de desarrollo de software, adaptándote a los cambios y evolucionando en forma conjunta con el software.

Un pantallazo general sobre la gestión de proyectos
Vayamos a lo básico primero... ¿para qué sirve implementar una metodología de gestión de proyectos? ¡Para garantizar infinidad de resultados! Pero te nombraré el más básico y fundamental: para organizar mejor tu proyecto y obtener un mejor resultado del software entregado a tu cliente.

Ahora bien, ¿en qué consiste una metodología de gestión de proyectos? Básicamente, consiste en la convención de prácticas, métodos, principios, técnicas y herramientas cuya principal utilidad es la de otorgar un mejor rendimiento del equipo de trabajo y por sobre todo, permitir la obtención de mejores resultados en lo que se produce durante el proyecto (en nuestro caso: software). Y entonces ¿existen solo dos formas de gestionar un proyecto? NO. Si bien las metodologías de gestión, podrían resumirse en solo dos enfoques (o tendencias): el enfoque ágil (que abordaremos aquí) y el enfoque predictivo (o tradicional, sobre el cual, no entraremos en detalles), cada una de estos enfoques, presenta diversa variedad de metodlogías que pueden aplicarse.

supone la entrega de un software 100% funcional). Esto. las más utilizadas y estadísticamente con mejores resultados son Scrum (se pronuncia "scram"). plantea los proyectos desde el cumplimiento de un objetivo más amplio: entregar software con el mayor valor posible. comprendiendo los cuatro valores del Manifiesto:     Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Individuos e iteraciones sobre procesos y herramientas Las metodologías predictivas se basan en una serie de procesos y herramientas. plantea la definición de un alcanse global al comienzo. como serán gestionadas. básicamente por la forma de abordaje de un proyecto. puede explicarse sino. costo y tiempo. Esto. para luego ir incrementándolo en las diversas iteraciones (cada una de las cuales. lleva a que no sea . propone la definición detallada del alcance del proyecto. Entendiendo el concepto de agilismo El agilismo se base en 4 valores y 12 principios. sobre la base del cumplimiento de tres aspectos predefinidos al comienzo del proyecto: alcance. diversas áreas de conocimiento y su correspondiente predicción. Puede sintetizarse este concepto. el enfoque ágil. Y ¿cuál es la diferencia entre los enfoques ágiles y predictivos? Los enfoques ágiles se diferencian (y también guardan ciertos aspectos en común) de los predictivos. y la estipulación precisa de tiempo y costo. que se desprenden del Manifiesto Ágil. Kanban (se pronuncia tal cual se escribe) y eXtreme Programming. existen (he perdido la cuenta) cuantiosas metodlogías. mientras que el enfoque ágil. más conocida como XP (se pronuncia por sus siglas en inglés "ex-pi"). de las cuales. comentando que la principal diferencia es que el enfoque predictivo. mientras tanto. El enfoque predictivo. es decir. es aquel que plantea el abordaje estricto de un proyecto. tendientes a abarcar de manera exhaustiva.En lo que respecta al enfoque ágil.

sino que por el contrario. supone implícitamente. Se adapta. veremos más de lleno el desarrollo ágil introduciéndonos en. Esto. de forma iterativa. arquitectos. incluso cuando las funcionalidades requeridas se hayan cumplimentado según lo pactado. diseñadores. puesto que entre cliente y desarrollador. estarán a cargo de decidir cómo se desarrollarán las funcionalidades solicitadas por el cliente en períodos de entre 2 a 4 semanas. lo es el seguir detalladamente el plan de alcance. Participando al cliente del desarrollo. cuyos integrantes. el software finalmente entregado. Respuesta ante el cambio sobre seguir un plan Si bien el enfoque predicto. es la participación activa del cliente en el proyecto en contacto con desarrolladores. a fin de sumar valor al producto. y a ello se refiere el manifiesto con individuos e iteraciones sobre los procesos y herramientas propuestos en los enfoques predictivos. al utilizarlas . el cliente y/o usuario final. sumado a las entregas parciales 100% funcionales. propone la autogestión de los equipos de desarrollo. En un próximo artículo. ¡Éxitos! Scrum. priorizar la calidad de los profesionales. no existen intermediarios al momento de definir las funcionalidades del software en cada iteración. Esto marca una diferencia sustancial con el enfoque predictivo. por el contrario. puesto que el enfoque predictivo plantea. los requerimientos van cambiando sobre la marcha. etc. Software funcionando sobre documentación extensiva Mientras que las metodologías predictivas se inician planificando en detalle cada una de las etapas del proyecto. .tan importante la calidad de los profesionales que ejecutarán el proyecto (desarrolladores. un exhaustivo proceso de monitoreo y control. los cambios no suelen ser lo más frecuente. Esto conlleva a que muchas veces.). El agilismo. se da cuenta de que no es precisamente lo que se esperaba. lo cual requiere una extensa documentación. Colaboración con el cliente sobre negociación contractual Un valor fundamental en el agilismo. "predice" como se debe actuar ante una solicitud de cambio en los requerimientos. entre otras. el agilismo prefiere lograr la entrega de software 100% funcional en cada iteración. a medida que lo entregado se va utilizando. El agilismo se encuentra abierto al cambio de requerimientos y prioridades.

.

es la más utilizada. según una encuesta publicada por VersionOne en 2010 realizada a 4770 entrevistados de 91 países.       Definición de Roles Dueño de producto Scrum Master Scrum Team Herramientas de trabajo: artefactos Backlog de producto Backlog de Sprint . consiste en realizar entregas potencialmente utilizables de forma iterativa e incremental. Pautas organizativas de Scrum A modo de guía. propone una serie de características que deben guardarse a fin de lograr resultados óptimos en el desarrollo de sistemas de alta complejidad. Creada por Jeff Sutherland en 1993. a simple modo de guía y no de reglamento invasivo. basada en un proceso de trabajo constante. La propuesta de Scrum. en períodos de 2 a 4 semanas denominados "Sprints". La propuesta de Scrum Como metodología para el desarrollo de Software. establece ciertas pautas organizativas. iterativo e incremental. Scrum. Para lograrlo. haremos una vista general de Scrum. definiendo su enfoque y la propuesta al tiempo que lograremos un primer acercamiento a los pilares de sus pautas organizativas. Scrum propone organizar el trabajo como se describe a continuación. revela que el 58% de los encuestados. ¿Qué es Scrum? Scrum es una metodología ágil de gestión de proyectos de desarrollo de software. de las metodologías ágiles.Introducción al Desarrollo Ágil con Scrum En este capítulo. La misma. utiliza Scrum como metodología para la gestión de proyectos de desarrollo de Software.

Para organizar cada Sprint. denominados Sprints. de duración fija. en Scrum. Incremento de funcionalidad potencialmente utilizable Organización del trabajo: ceremonias Como hemos comentado anteriormente. se trabaja en período de tiempo iterativos. las ceremonias propuestas por Scrum son las siguientes:     Planificación Reunión diaria Revisión Retrospectiva .

Veamos entonces las características. participando como audiencia. nos insertamos a fondo. y demás. usuarios del software y todas aquellas partes interesadas en el producto. Hablaremos sobre el Dueño de Producto.  Revisar el producto e ir adaptándole sus funcionalidades. Cuáles son sus tareas y que aspectos deben cuidar cada uno de los roles. Scrum Master y Scrum Team. que todas aquellas personas que. sabiendo "escuchar" a las partes interesadas en el producto y transmitirlas en "objetivos de valor para el producto". en los roles propuestos por Scrum. analizando las mejoras que éstas puedan otorgar un mayor valor para el negocio. Scrum permite además. respetando los roles formales. abogando por los intereses del negocio. Aptitudes que debe tener un Dueño de Producto:     Excelente facilicidad de comunicación en las relaciones interpersonales Excelente conocimiento del negocio Facilidad para análisis de relaciones costo/beneficio Visión de negocios . interesados en el producto como usuarios. funciones y aptitudes de cada rol en Scrum. ya sean inversores. al scrum team. no termina.Los roles en Scrum En este capítulo. Pero allí. Funciones y responsabilidades:  Canalizar las necesidades del del negocio.  Maximizar el valor para el negocio con respecto al Retorno de Inversión (ROI). El Dueño de Producto (Product Owner) en Scrum Características: El Dueño de Producto es la única persona autorizada para decidir sobre cuáles funcionalidades y características funcionales tendrá el producto. formen parte del proyecto. Es quien representa al cliente. Introducción Comentamos en el capítulo anterior que Scrum propone tres roles diferenciados que deben formalizarse: Dueño de Producto (o Product Owner). el Scrum Master y el Scrum Team.

Un error frecuente es llamarlo "líder". es el equipo de desarrolladores multidisciplinario.El Scrum Master Características: El Scrum Master es el alma mater de Scrum. Funciones y responsabilidades:  Garantizar la correcta aplicación de Scrum. será los encargados de desarrollar el producto. creando un clima de trabajo colaborativo. Esto incluye. diseñadores. sino que es un un auténtico Servidor neutral. guardar especial cuidado en que el dueño de producto no actúe en nombre del Scrum Team y viceversa. a desarrollos potencialmente funcionales y operativos. o que la audencia se inmiscuya en tareas que no le son propicias)   Resolver los conflictos que entorpezcan el progreso del proyecto. que será el encargado de fomentar e instruir sobre los principios ágiles de Scrum. Aptitudes que deben tener los integrantes de un Scrum Team: Ser profesionales expertos o avanzados en su disciplina Tener "vocación" (la buena predisposición no alcanza) para trabajar en equipo Capacidad de auto-gestión . hasta la prevención de la inversión roles (es decir. Incentivar y motivar al Scrum Team. que en forma auto-organizada. desde la correcta trasmición de sus principios a las altas gerencias. puesto que el Scrum Master no es un líder típico. integrado por programadores. testers y demás.          Aptitudes que debe tener un Scrum Master: Excelentes conocimientos de Scrum Amplia vocación de servicio Tendencia altruista Amplia capacidad para la resolución de problemas Analítico y observador Saber incentivar y motivar Capacidad docente e instructiva Buen carisma para las negociaciones El Scrum Team Características: El Scrum Team (o simplemente "equipo"). fomentar la auto-gestión del equipo e impedir la intervensión de terceros en la gestión del equipo. Funciones y responsabilidades:      Llevar el Backlog de producto. arquitectos.

como vimos en el capítulo anterior. su definición e importancia para Scrum. es una lista de items que representan los requerimientos funcionales esperados para el software. Durante la ceremonia de planificación. aportando medios ineludibles para efectuar cada una de las ceremonias que veremos en un siguiente capítulo. y el incremento de funcionalidad. ya que esta última. el Dueño de Producto. . será tarea del Scrum Team. Backlog de Producto El Backlog de Producto es un listado dinámico y públicamente visible para todos los involucrados en el proyecto. que nos dan las claves para una organización diaria. Esta nueva entrega del Manual de Metodologías Ágiles para el Desarrollo de Software. Esta lista. El Backlog de Producto. En él. Introducción Scrum. Describiremos ahora. el backlog de sprint y Scrum Taskboar. cada uno de los artefactos. ayudan a planificar y revisar cada uno de los Sprints. que deberá desarrollar durante el Sprint. la vamos a dedicar a los Artefactos en Scrum. propone para mantener organizado un proyecto de desarrollo de Software: el backlog de producto. mantiene una lista actualizada de requerimientos funcionales para el software. es creado y modificado únicamente por el Dueño de Producto. representa "qué es lo que se pretende" pero sin mencionar "cómo hacerlo". el Scrum Team obtendrá los items del producto. Estos artefactos. propone tres herramientas o "artefactos" para mantener organizados nuestros proyectos.Artefactos en Scrum: claves para una organización diaria En este capítulo hablaremos sobre las herramientas que Scrum. Formato del Backlog de Producto El Backlog de producto.

cuya base se apoye en:      Beneficios de implementar una funcionalidad Pérdida o costo que demande posponer la implementación de una funcionalidad Riesgos de implementarla Coherencia con los intereses del negocio Valor diferencial con respecto a productos de la competencia Estimación de esfuerzo A diferencia de las metodologías tradicionales. de negro a rojo". se evita la pérdida de tiempo en estimaciones irrelevantes. . deben guardar un orden de prioridad. Estas estimaciones.Para cada uno de estos ítem. Granulidad de los ítems Los items del Backlog de Producto no necesariamente deben tener una granulidad pareja. Es posible encontrar ítems tales como "es necesario contar con un módulo de control de stock y logística" o uno tan pequeño como "Modificar el color de fondo de los mensajes de error del sistema. no se efectúan sobre items poco prioritarios ni tampoco sobre aquellos donde exista un alto grado de incertidumbre. solo para aquellas cuyo orden sea prioritario. De esta manera. será necesario especificar:     El grado de prioridad Esfuerzo que demanda Granulidad Criterios de aceptación Priorización de los ítems del Backlog de Producto Los items del backlog de producto. Ítems de tan baja granulidad. suelen agruparse en un formato denominado "Historias de Usuario" mientras que los de alta granulidad. Scrum. son los denominados Temas o Epics. propone la estimación de esfuerzo y complejidad que demanda el desarrollo de las funcionalidades. postergándolas para el momento en el cual realmente sea necesario comenzar a desarrollarlas.

para considerar cumplido el requisito. puedo cargar un voucher para calcular mi descuento en la compra. Ejemplo: Backlog de Sprint El Backlog de Sprint es la recopilación sintética de items del Backlog de Producto. Criterios de Aceptación Cada ítem del Backlog de Producto. que durante la planificación ha sido propuesta por el Dueño de Producto y ya negociada. puedo [una funcionalidad] para [un beneficio] Como usuario registrado.Una historia de usuario es aquella que puede escribirse con la siguiente frase: Como [un usuario]. reunión que se realiza al comienzo del Sprint. es necesario que especifique cuales son los criterios de aceptación (o test de aceptación que debe superar). . Esta recopilación. es aquella que el Scrum Team se compromete a construir durante el Sprint en curso. negociados entre el Dueño de Producto y el Scrum Team en la ceremonia de planificación.

generalmente (y muy recomendado). por ejemplo. un test. intentaremos desmembrar. Dividiendo un ítem del Backlog de producto en tareas La estrategia consiste en desmembrar el item a la mínima expresión posible. Diseñar el layout de las vistas ? actividad: diseñar . serán divididas en pendientes. Para armar el Backlog de Sprint. divide los items en tareas – tasks – de que no demanden una labor superar a una jornada de trabajo. en curso y terminadas y cada una de ellas.lógica y layot . como mínimo.y controladores. no debería superar las 8 horas de trabajo. Es decir. Crear la lógica de las vistas ? actividad: programar 3.que hacen visible el proceso de construcción. el Scrum Team. el esfuerzo que demanda su construcción y el nombre del miembro del equipo que se ha asignado dicha tarea. debe permitir visualizar. a toda persona que ingrese al área de desarrollo. cuando representa un bug. El desmembramiento debe hacerse "de lo general a lo particular. vistas . Crear modelos ? actividad: programar 2. y de lo particular al detalle". a la vez de ser una práctica recomendada. diferenciando. el primer ítem del Backlog de Producto: Como administrador quiero poder administrar las secciones del sistema para poder establecer el orden de visualización de las mismas Yendo de lo general (un ABM de secciones) a lo particular (hacer los modelos. Retomando el ejemplo anterior. una tarea de diseño. etc. que una tarea. encuadrada en un mismo tipo de actividad. se visualiza mediante tableros físicos – también llamados Scrum Taskboard . "etiquetada". que cada tarea sea a la vez.El Backlog de Sprint. Estas tareas. Es muy frecuente. integrarlo y documentarlo). obtenemos una lista de tareas tentativa: 1. testearlo.

Entonces. Un Scrum Taskboard.4. Correr los test ? actividad: testear 6. tras crear los nuevos modelos. son aquellas restricciones que deberán considerarse para todo lo anterior. en curso y terminadas y se complementa la información con un Diagrama de Burndown que mostrará el esfuerzo restante para concluir el Sprint.ar/visualmanagement/ Incremento de Funcionalidad El incremento de funcionalidad. pues no puede ser considerado una única tarea. Por ejemplo. Otro detalle a considerar. . de lo particular. la creación del modelo.com. puede "sumarse como detalle" a la tarea "crear modelos". se irá al detalle. Existen decenas de tableros que pueden implementarse. visitar http://www. Los detalles. De manera contraria. permitiendo implementarse operativamente sin restricciones en un ambiente productivo.xqa. Integrar el ABM al sistema ? actividad: integrar 7. Por lo cual. es el que el equipo entrega al finalizar el Sprint. es el tiempo que demanda cada tarea. Tableros de Scrum Con la lista de tareas ya armada. estamos en condiciones de crear el tablero. Por lo cual. Documentar el ABM en el manual del usuario ? actividad: documentar Luego. Por ejemplo. debe asignarse a una única tarea. básicamente se divide en 3 columnas: pendientes. Crear los controladores ? actividad: programar 5. habrá que correr el ORM para que modifique las tablas. llevará todo un día de trabajo. documentar en el manual del usuario. correr un ORM lleva solo algunos minutos. El mismo debe asemejarse a un "software funcionando". repercutirá en la base de datos. Recomiendo para ello.

comprendidas en el Backlog de producto. . que en el ambiente IT se suele rumorear. Durante esta ceremonia. llegamos a la ceremonia clave de un Sprint: la planificación. Planificación 2. el equipo dividirá cada historia de usuario. las reuniones diarias del equipo con el Scrum Master. Reunión diaria 3.Ceremonias en Scrum En este capítulo hablaremos sobre cómo llevar adelante. Seguimos avanzando en el Manual de las Metodologías Ágiles para el Desarrollo. Una vez definido el alcance del sprint. las historias de usuario prioritarias. que el equipo comprenda el alcance de las mismas mediante preguntas. Éstas son: 1. participan el Dueño de Producto. Revisión y 4. Retrospectiva Veamos en qué consiste cada una de ellas. y que ambos negocien cuáles pueden ser desarrolladas en el Sprint que se está planificando. las cuales serán necesarias para desarrollar la funcionalidad descrita en la historia. Introducción Scrum propone realizar cuatro "ceremonias". y como llevarlas a la práctica. el Scrum Master y el Scrum Team. de que en las metodologías ágiles no existe una planificación ni definición precisa del alcance. la planificación de un Sprint. La planificación es lo primero que debe hacerse al comienzo de cada Sprint. El objetivo de esta ceremonia. en tareas. es que el Dueño de Producto pueda presentar al equipo. en esta nueva entrega que nos hablará sobre las ceremonias en Scrum. en cada iteración (Sprint). Cremonia de Planificación en Scrum Rompiendo con el mito. la revisión y la retrospectiva.

realizar un análisis de lo que se ha hecho y sus resultados correspondientes. también rechazarlas. lo que hará en la fecha actual. son "conversaciones" de no más de 5-15 minutos. En esta conversación. La planificación puede demandar solo unas horas. a fin de mejorar esos resultados. Reuniones diarias en Scrum Las reuniones diarias para Scrum. sin preocupaciones. con cada miembro del equipo.Estas tareas. aprobarlas por completo o porque no. jamás lo he visto en la práctica. como su nombre lo indica. el equipo presentará al Dueño de Producto las funcionalidades desarrolladas. En la ceremonia de revisión es donde el Dueño de Producto podrá sugerir mejoras a las funcionalidades desarrolladas. es "mirar hacia atrás". Scrum propone efectuar al equipo. el Scrum Master deberá ponerse al día de lo que cada miembro ha desarrollado (en la jornada previa). tendrán un esfuerzo de desarrollo estimado (generalmente mediante técnicas como Planning Poker). tras lo cual. . Como última ceremonia del Sprint. o toda una jornada laboral completa. que el Scrum Master tendrá al comienzo de cada día. a fin de que. tanto Dueño de Producto como la audencia. serán pasadas al backlog de Sprint y de allí se visualizarán en el tablero una vez que cada miembro se haya asignado aquellas que considere puede realizar. aunque esto último. Las explicará y hará una demostración de ellas. En la práctica. a fin de resolverlos y que el Scrum Team pueda continuar sus labores. La ceremonia de revisión se lleva a cabo el último día del Sprint. una retrospectiva en forma conjunta con el Scrum Master y opcionalmente. pero por sobre todo. Revisiones en Scrum Durante la ceremonia de revisión en Scrum. y decidir que medidas concretas emplear. puedan experimentarlas. conocer cuáles impedimentos estén surgiendo. el Dueño de Producto. El objetivo de esta retrospectiva. y no tiene una duración fija. se utiliza el tiempo que sea necesario. Retrospectiva en Scrum: en la búsqueda de la perfección No es en vano la frase "en la búsqueda de la perfección".

de los errores y mejorar todo aquello que sea factible". . donde la finalidad es "aprender de los aciertos.La retrospectiva en Scrum suele ser vista como una "terapia de aprendizaje".

Orígenes: De Toyota al Software Kanban se basa en un sistema de producción que dispara trabajo solo cuando existe capacidad para procesarlo.Desarrollo Ágil con Kanban Kanban. donde un trabajo se introduce al sistema solo cuando existe disponibilidad para procesarlo. Cada tarjeta Kanban acompaña a un item de trabajo durante todo el proceso de producción. La palabra Kanban. El disparador de trabajo es representado por tarjetas kanban de las cuales se dispone de una cantidad limitada. liberando una tarjeta. Un nuevo ítem de trabajo. Kanban demuestra ser una de las metodologías adaptativas que menos resistencia al cambio presenta. hasta que éste. es empujado fuera del sistema. Este proceso de producción. pero con características extendidas que veremos a continuación. de la mano de la automotriz Toyota. se denomina pull (tirar) en contrapartida al mecanismo push (empujar). donde el trabajo se introduce en función de la demanda. de origen japonés. Las tres reglas de Kanban Con tan solo tres simples reglas. se compone de dos términos: Kan que puede traducirse como "visual" y ban. En el desarrollo de Software. reemplazando el sistemas de tarjetas por un tablero visual similar al de Scrum. Mostrar el proceso . Kanban fue introducido por David Anderson de la Unidad de Negocios XIT de Microsoft. "insignia visual". llega como metodología de gestión de proyectos. Dichas reglas son: 1. la metodología ágil que menor resistencia presenta en las compañías acostumbradas a las metodologías tradicionales. representando estadísticamente. solo podrá ser ingresado/aceptado si se dispone de una tarjeta kanban libre. en 2004. siendo una traducción aproximada. como "insignia".

El principal objetivo de establecer estos límites. éstas. se divide en columnas las cuales representan un proceso de trabajo. son subdivididas en dos columnas: cola de espera y en curso Regla #2: Limitar el trabajo en curso (WIP) Los límites del WIP (work in progress – trabajo en curso -) consisten en acordar anticipadamente. Un tablero Kanban. Optimizar el flujo de trabajo Veamos cada una de ellas. mediante un tablero físico. Conocer los problemas que puedan surgir y tomar decisiones. se puede comprender mejor: . generalmente. Mejorar la comunicación entre todos los interesados/participantes del proyecto. consiste en:     Entender mejor el proceso de trabajo actual. sería el siguiente: Cola de entrada | Análisis | Desarrollo | Test | Deploy | Producción La cantidad y nombre de las columnas. Los cuellos de botella representan el estancamiento de un proceso determinado. Limitar el trabajo en curso 3. Un ejemplo clásico de columnas para dividir un tablero Kanaban. por columnas del tablero). varía de acuerdo a las necesidades de cada equipo y en la mayoría de los casos. públicamente asequible. Hacer los futuros procesos más predecibles. Regla #1: Mostrar el proceso Consiste en la visualización de todo el proceso de desarrollo. es el de detectar cuellos de botella.2. la cantidad de ítems que pueden abordarse por cada proceso (es decir. El objetivo de mostrar el proceso. Viendo el siguiente tablero ficticio.

Midiendo el tiempo que el ciclo completo de ejecución del proyecto demanda (por ejemplo. que la resolución de cuellos de botella. la optimización del flujo de trabajo consistirá en la búsqueda de: . cantidad de días desde el inicio del análisis hasta el fin del deploy – según el ejemplo del tablero anterior). que en la columna "pruebas" se produce un cuello de botella. el CycleTime por el WIP. mientras que el proceso siguiente (deploy). El cuello de botella ha generado un estancamiento. es decir. claramente marca un problema a resolver en el proceso correspondiente a las pruebas.En el tablero anterior. Throughput = CycleTime/WIP Con estos valores. procesos libres para aceptar nuevos ítems. Regla #3: Optimizar el flujo de trabajo El objetivo una la producción estable. pueden ayudar a "desetancar" a los procesos colapsados. la mayoría de las veces. denominado Throughput. y los procesos libres. la cantidad de ítems que un equipo puede terminar en un determinado período de tiempo. se obtiene el "rendimiento de trabajo". Pues mientras existen procesos colapsados. se obtiene el CycleTime. continua y previsible. Esto. podemos visualizar claramente. está totalmente libre. existen a la vez. motiva la colaboración del equipo entre los diferentes procesos. Al dividir. pues el límite WIP está cubierto. Es un valor a tener en cuenta.

Obteniendo lo mejor de ambos" de Henrik Kniberg y Mattias Skarin.pdf . Aún nos queda eXtreme Programming. Puedes acceder a la versión traducida al castellano por Agile Spain en: http://www. es "Kanban y Scrum. hemos visto sobre Scrum y Kanban.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed. un buen libro para "agilizarnos" con Scrum y Kanban. Pero. mientras tanto.   Minimizar el CycleTime Maximizar el Throughput Lograr una variabilidad mínima entre CycleTime y Throughput Lectura recomendada: A lo largo del manual de Desarrollo Ágil.