Docsity
Docsity

Prepara tus exámenes
Prepara tus exámenes

Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity


Consigue puntos base para descargar
Consigue puntos base para descargar

Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium


Orientación Universidad
Orientación Universidad


Lean Kanban: Herramienta para mejora continua en desarrollo de software, Apuntes de Ingeniería del Software

El método lean kanban es una herramienta para el mejoramiento continuo en el desarrollo de software, basada en la filosofía del sistema de producción de toyota. Fomenta la colaboración, el compromiso de los equipos y el límite del trabajo en curso. Conocerás su origen, las reglas básicas y cómo ponerlo en práctica.

Tipo: Apuntes

2020/2021

Subido el 14/05/2021

sarasc37
sarasc37 🇪🇸

5

(1)

2 documentos

1 / 4

Toggle sidebar

Esta página no es visible en la vista previa

¡No te pierdas las partes importantes!

bg1
El método Lean Kanban
La diferencia entre Lean y el método Kanban a veces no queda muy clara. Según David J.
Anderson, Lean es el destino al que se pretende llegar a través del método Kanban (la
herramienta para llegar al destino).
Kanban no es un método de gestión de proyectos ni un método de gestión del ciclo de
vida de desarrollo de software. Kanban realmente es un catalizador del cambio en las
organizaciones (orientación a la mejora continua). Fomenta la colaboración y el
compromiso de los empleados de un modo natural y requiere de poco esfuerzo para su
puesta en marcha.
Determinadas organizaciones (normalmente grandes) que se dan cuenta de la necesidad
que tienen de incorporar métodos ágiles, pero no quieren adoptarlos, lo que hacen es
usar el método Lean Kanban, de modo que les permite realizar mejoras en la gestión y la
entrega al cliente sin realizar cambios drásticos en sus prácticas de trabajo, estructura
organizativa, funciones, responsabilidades o cargos.
Kanban se basa en la idea de que las personas tenemos un límite en el trabajo
concurrente que somos capaces de hacer “eficientemente”. Por tanto, el trabajo que
tenemos entre manos debe limitarse.
El método Lean Kanban proviene del Sistema de Producción de Toyota desde los años 50.
Pues Japón en plena postguerra consiguió crecer con gran éxito por la aplicación del
sistema de Calidad en la producción automovilística, y dentro de ese sistema de Calidad se
encontraban entre otras prácticas los tableros Kanban --> mejora significativa.
La “novedad” es aplicarlo esto al Desarrollo del Software. Pues Kanban fue trasladado al
desarrollo del software por David J. Anderson en el 2004, aunque la primera aproximación
fue en 2003 a través de la implantación de TOC mantenimiento evolutivo de aplicaciones
internas. El problema que había era la distancia, ya que los responsables del proyecto no
se encontraban en las mismas oficinas. Aplicó la teoría de las restricciones al desarrollo del
software.
Las reglas de Kanban son muy sencillas:
1. Visualiza el flujo de trabajo
Vivimos rodeados de signos visuales (señales y otros impactos) que nos hacen, sin mucho
esfuerzo, ponernos en alerta o simplemente informarnos. Sería muy difícil nuestro día a
día sin esas señales, especialmente en el ámbito del tráfico.
Los tableros Kanban nos facilitan también el trabajo porque vemos de una manera muy
visual el flujo de trabajo, en qué estado se encuentra cada tarea (Backlog, desarrollo,
revisión...), los colores de cada tarjeta, las señales que tienen las bloqueadas, los trabajos
priorizados... Intentar reducir el trabajo es lo que se pretende con esto.
pf3
pf4

Vista previa parcial del texto

¡Descarga Lean Kanban: Herramienta para mejora continua en desarrollo de software y más Apuntes en PDF de Ingeniería del Software solo en Docsity!

El método Lean Kanban

La diferencia entre Lean y el método Kanban a veces no queda muy clara. Según David J. Anderson, Lean es el destino al que se pretende llegar a través del método Kanban (la herramienta para llegar al destino). Kanban no es un método de gestión de proyectos ni un método de gestión del ciclo de vida de desarrollo de software. Kanban realmente es un catalizador del cambio en las organizaciones (orientación a la mejora continua). Fomenta la colaboración y el compromiso de los empleados de un modo natural y requiere de poco esfuerzo para su puesta en marcha. Determinadas organizaciones (normalmente grandes) que se dan cuenta de la necesidad que tienen de incorporar métodos ágiles, pero no quieren adoptarlos, lo que hacen es usar el método Lean Kanban, de modo que les permite realizar mejoras en la gestión y la entrega al cliente sin realizar cambios drásticos en sus prácticas de trabajo, estructura organizativa, funciones, responsabilidades o cargos. Kanban se basa en la idea de que las personas tenemos un límite en el trabajo concurrente que somos capaces de hacer “eficientemente”. Por tanto, el trabajo que tenemos entre manos debe limitarse. El método Lean Kanban proviene del Sistema de Producción de Toyota desde los años 50. Pues Japón en plena postguerra consiguió crecer con gran éxito por la aplicación del sistema de Calidad en la producción automovilística, y dentro de ese sistema de Calidad se encontraban entre otras prácticas los tableros Kanban --> mejora significativa. La “novedad” es aplicarlo esto al Desarrollo del Software. Pues Kanban fue trasladado al desarrollo del software por David J. Anderson en el 2004, aunque la primera aproximación fue en 2003 a través de la implantación de TOC mantenimiento evolutivo de aplicaciones internas. El problema que había era la distancia, ya que los responsables del proyecto no se encontraban en las mismas oficinas. Aplicó la teoría de las restricciones al desarrollo del software. Las reglas de Kanban son muy sencillas:

  1. Visualiza el flujo de trabajo Vivimos rodeados de signos visuales (señales y otros impactos) que nos hacen, sin mucho esfuerzo, ponernos en alerta o simplemente informarnos. Sería muy difícil nuestro día a día sin esas señales, especialmente en el ámbito del tráfico. Los tableros Kanban nos facilitan también el trabajo porque vemos de una manera muy visual el flujo de trabajo, en qué estado se encuentra cada tarea (Backlog, desarrollo, revisión...), los colores de cada tarjeta, las señales que tienen las bloqueadas, los trabajos priorizados... Intentar reducir el trabajo es lo que se pretende con esto.
  1. Limita el trabajo en curso El método Lean Kanban quiere que cada miembro del equipo solo tenga una tarea y no se le acumula para evitar incidencias, de modo que hasta que no termine una no empiece con la siguiente. Por tanto, asigna límites concretos a cuántos elementos pueden estar en curso en cada estado del flujo de trabajo. Poniendo límites se potencia el trabajo en equipo, no se pueden acumular las tareas en curso o donde sea, así todo fluye mejor.
  2. Mide y optimiza Conocer la evolución que está teniendo el proyecto nos permitirá tomar medidas que optimicen los procesos. Así podrán compararse los resultados indicadores del rendimiento. Una vez conocidas las reglas ya podemos arrancar con el proyecto, pero no sin antes visualizar el flujo de trabajo y apuntar todas las actividades/tareas/casos de uso/historias de usuario que conforman el proyecto para que así todo el equipo las conozca. El tablero en un inicio debe ser lo más sencillo posible y debe ajustarse al proceso. Luego, se limitará el trabajo en curso en cada fase del proyecto (principal característica Kanban). Respecto al límite adecuado que debe ponerse a cada columna, no hay reglas, por lo que se debe probar, observar y corregir, aunque un autor propone la fórmula de WIP = 2n – 1 (2 tareas por persona pero le quita 1 al conjunto), por tanto 9 sería el número de tarjetas máximo que nos interesaría en un equipo de 5 personas. Tras ello, es muy importante conocer los tiempos desde que un “trabajo” entra en nuestro flujo hasta que sale, y a ese tiempo le llamamos Lead Time. También es importante el Tiempo de Ciclo, que es aquel que se tarda en completarlo una vez comenzamos a trabajar en él. La diferencia entre estos dos tiempos es la siguiente. El Tiempo de Ciclo afecta únicamente a la parte del proceso en la que ya estamos trabajando con las tareas, sin embargo, el Lead Time empieza a contar desde que las tareas se introducen en el Backlog (cuando el usuario pide una tarea) y termina una vez el trabajo ha finalizado. Otra diferencia es lo que mide cada tiempo, ya que el tiempo de ciclo mide más la eficiencia del proceso de desarrollo, mientras que el Lead Time mide elementos más genéricos puesto que la eficiencia global del equipo se verá en esta parte. Entre las métricas fundamentales del método Lean Kanban están los diagramas de flujo acumulado, que permite verificar si el sistema está funcionando correctamente y muestra cada etapa/fase del proceso. El hecho de que las columnas sean tan finas quiere decir que el equipo está trabajando en cortos plazos de tiempo y al no haber saltos podemos asegurarnos de que el flujo de trabajo está siendo uniforme y no hay grandes problemas. Si funciona correctamente el flujo debe de ser suave y el ancho de las bandas estable. El Lead Time permite medir la previsibilidad del equipo frente a los compromisos de las diferentes clases de servicio. El descenso indica que el proyecto se está acercando al tiempo de entrega, entonces se va estabilizando.

CLASES DE SERVICIO

El método Lean Kanban permite establecer acuerdos de nivel de servicio para diferentes grupos de trabajo, diferenciando el trabajo y el consecuente acuerdo de nivel de servicio. Por ejemplo, las aerolíneas son un claro ejemplo de que según lo que pagues tendrás unos servicios mejores o peores. Al igual, en el desarrollo y mantenimiento de software, así como en operaciones estamos acostumbrados con estos conceptos. La resolución de incidencias, y en concreto las incidencias en producción tienen habitualmente un tratamiento diferente del resto de trabajos. Estas incidencias de alta prioridad reciben habitualmente una superior al resto, y resolverlas requerirá asignar todo el personal disponible y detener todo el trabajo en curso para conseguir solucionarlo. Por ejemplo, si la plataforma de pago de una web se cae, habrá que poner todos los recursos posibles en ese momento para solucionarlo lo antes posible porque viven de esos pagos, por tanto, es la prioridad máxima. Este concepto de clase de servicio puede ser aplicado de forma más genérica, ofreciendo ventajas tanto en para la gestión de riesgos como para la agilidad del negocio. Podremos ofrecer a nuestro cliente/usuario mayor flexibilidad mientras optimizamos los resultados económicos. No se recomienda tener más de 6 servicios porque hay problemas a la hora de clasificar los recursos por parte del equipo de desarrollo.