TEMA 4 - Apuntes 4 PDF

Preview

Summary

INGENIERIA DEL SOFTWARE CIENCIA GESTION E INGENIERIA DE SERVICIOS...

Description

TEMA 4.1 LEAN MANAGEMENT & LEAN SOFTWARE DEVELOPMENT El termino Lean tiene su origen en Japón de la postguerra, en concreto en el fabricante de coches Toyota. “Lean” es la visión occidental del Toyota Production System (TPS)

LOS PRINCIPIOS LEAN. DEFINIR EL VALOR, desde la perspectiva de los clientes y expresar el valor en términos de un producto o servicio específico. ESQUEMATIZAR TODOS LOS PASOS, (tanto los de valor añadido como los que no) que hacen llegar un producto o servicio al cliente. ESTABLECER UN FLUJO CONTINUO, de productos, servicios e información a través del proceso. Nada se realiza “aguas arriba” en el proceso hasta que “aguas abajo” se indique la necesidad. La demanda real TIRA del producto o servicio a través de la cadena de valor La eliminación completa de DESPERDICIO para descubrir todas las actividades creadoras de valor para el cliente emergiendo una cultura de MEJORA CONTINUA PRINCIPIOS LEAN: VALOR ¿Qué entendemos por valor? Valor: Beneficio (tangible o intangible) obtenido por el cliente. El valor lo debe crear el productor. Pero es muy difícil especificar el valor de modo preciso por parte de los productores. Solo puede definirlo el consumidor final. La especificación de valor de forma precisa es el primer paso fundamental en el Pensamiento Lean. Proporcionar el bien o servicio incorrecto de forma correcta es MUDA (cualquier desperdicio que la empresa esta llevando acabo en un proyecto productivo). PRINCIPIOS LEAN: IDENTIFICAR EL FLUJO DE VALOR. El flujo de valor es el conjunto de todas las acciones requeridas para pasar un producto específico (un bien o servicio) por las tres tareas de gestión críticas de cualquier empresa: » » »

Solución de problemas Gestión de la información Transformación física

PRINCIPIOS LEAN: FLUJO Una vez identificado el valor y el flujo de valor (eliminando las etapas que generan desperdicio) el siguiente paso en el concepto Lean es hacer que fluyan las etapas creadoras de valor. Para ello es necesario la reorganización de la arquitectura mental. Todos hemos nacido en un mundo mental de funciones y departamentos, en el que la lógica nos indica que para conseguir que las tareas se realicen de un modo eficiente dentro de los departamentos, parece que sea de sentido común el realizarlas en lotes. La forma de pensar tradicional en lotes y colas está tremendamente equivocada… el sentido común nos lleva a un grave error. Las tareas pueden realizarse casi siempre de forma mucho más eficiente y precisa cuando se trabaja sobre el producto de forma continua, desde la materia prima al producto acabado. Debemos centrarnos en el producto y sus necesidades en lugar de la organización y su infraestructura. El RETO es conseguir que todas las actividades necesarias (las que aportan valor) sucedan en un flujo continuo (aunque es verdaderamente difícil). Por tanto, el verdadero desafío es la creación de flujo continuo en la producción en pequeñas cantidades, cuando se necesitaban docenas o cientos de unidades de un producto, NO MILLONES.

La iniciativa Lean pretende redefinir la operativa de funciones, departamentos y empresas, de modo que puedan hacer una contribución positiva a la creación de valor y dirigirse a las necesidades reales de los empleados en cada punto del flujo, de forma que sea realmente de su interés hacer que el valor fluya. Esto requiere una iniciativa Lean para cada producto y replantearse la organización en su conjunto, los departamentos e incluso las carreras profesionales convencionales PRINCIPIOS LEAN: PULL (ATRACCION) La fabricación Lean ajusta la cantidad de producto fabricado a la demanda existente de forma inmediata. Esto genera una ganancia imprevista por la reducción de existencias y acelera el retorno de la inversión (Si somos capaz de producir lo que el cliente pide exactamente quiere decir que no tenemos que almacenar nada, por lo que no tenemos almacén y así podemos ser lo suficientemente rápidos para cubrir la demanda y la empresa no gasta dinero en tener productos almacenados en un almacén) El hecho de diseñar, programar y hacer exactamente lo que cliente desea en cada momento exige un sistema PULL, en el que el cliente atrae el producto según sus necesidades. PRINCIPIOS LEAN: PERFECCION. A medida que se van aplicando los principios anteriores las personas involucradas caen en la cuenta de que no hay límite en el proceso de reducción de esfuerzo, tiempo, espacio, coste y fallos, además, ofrecen un producto que cada vez está más cerca de lo que el consumidor verdaderamente desea. ¿Por qué se consigue todo esto? Porque los 4 principios anteriores generan un círculo virtuoso: » » »

Al hacer que el valor fluya más rápidamente →deja al descubierto muda oculto. A más Pull, más se verán los obstáculos del flujo→ por lo que se tenderá a eliminarlos Los Equipos de producto al habla con el consumidor→ afinarán más el concepto de valor encontrando o inventando nuevas formas de intensificar el flujo

En ocasiones la eliminación de muda requiere de nueva tecnología… pero no siempre, en muchas ocasiones las soluciones son de fácil implementación. Shigeo Shingo introdujo en la década de 1960 el Poka-Yoke (en japonés ポカヨケ, literalmente a prueba de errores) es una técnica de calidad que se aplica con el fin de evitar errores en la operación de un sistema. El estímulo más importante para la perfección es la transparencia, el hecho de que en un sistema Lean todo el mundo pueda ver todo facilita el descubrimiento de mejores metodologías para la creación de valor. Además, disponer de un feedback prácticamente inmediato genera un estímulo positivo en los empleados que proponen y ponen en marcha las mejoras

DESPERDICIO (MUDA) Toda aquella actividad humana que absorbe recursos, pero no crea valor. Los 7 tipos de MUDA. 1. 2. 3. 4. 5. 6.

Fallos que precisan rectificación Sobre producción de artículos que nadie desea. Amontonamiento de existencias sobrantes (stocks) Pasos en el proceso que realmente no son necesarios Movimientos de empleados y transporte de productos de un lugar a otro sin ningún propósito. Grupos de personas en una actividad aguas abajo bloqueadas porque aguas arriba no se ha entregado a tiempo 7. Bienes y servicios que no satisfacen las necesidades del cliente.

LEAN SOFTWARE DEVELOPMENT.

Lean Software Development es la traslación al mundo del desarrollo del software del Sistema de Producción de Toyota (TPS). Los siete principios del Lean Software Development. 1. 2. 3. 4. 5. 6. 7. 8.

Eliminar desperdicios Construir con calidad Amplificar el aprendizaje Decidir lo más tarde posible Decidir lo mas tarde posible Entregar lo más tarde posible Capacitar y potenciar al equipo Ver el todo.

1er. PRINCIPIO ELIMINAR DEL DESPERDICIO: PRIEDRA ANGULAR DEL TPS. El TPS era un sistema de gestión para la eliminación absoluta del desperdicio. Lo que hacemos es mirar la línea de tiempo desde que recibimos un pedido hasta que lo cobramos. Nuestro objetivo es reducir este tiempo eliminando los desperdicios que no añaden valor. En Lean Software Development esta línea de tiempo cambia ligeramente: iniciamos el reloj cuando recibimos una petición de un cliente/usuario y lo paramos cuando desplegamos una versión de software que satisface su necesidad. Al igual que a Taiichien Toyota, nuestro objetivo es reducir este tiempo mediante la eliminación de desperdicio ¿Qué es desperdicio? TODO LO QUE NO APORTA VALOR AL CLIENTE. DESPERDICIOS DEL DESARROLLO SOFTWARE (MARY&TOM POPPENDIECK) Hay que empezar identificando el desperdicio generado desde que un usuario realiza una petición hasta que se despliega la versión del sistema que la satisface LEAN MANUFACTURING Inventario Sobreproducción Procesamiento extra Transporte Movimiento Esperas Defectos

LEAN SOFTWARE DEVELOPMENT Trabajo parcialmente hecho Funcionalidades extra Reaprendizaje Traspasos Cambio de tareas Retrasos Defectos

TRABAJO PARCIALMENTE HECHO » » »

Documentación que tardamos meses en elaborar pero que quedó sin codificar. Los requisitos y las historias de usuario obsoletas. Código en local durante mucho tiempo, tanto que integrarlo ya es complicadísimo.

En fabricación uno de los mayores desperdicios es el inventario: se debe almacenar, asegurar, mover, se desfasa… Equivalente en Software→ Kanban en su fase inicial potencia la generación de buffers (almacenes) de modo que permitan mejorar la cadencia en el flujo de trabajo, pero posteriormente busca es estresar el proceso, descubrir los cuellos de botella, solucionarlos y minimizar el uso de los buffers. Objetivo final: eliminarlos por completo FUNCIONALIDADES EXTRA. Aquello que creemos que el Cliente va a necesitar pero que no ha pedido. Cuando un comercial, cliente, etc., insiste en incluir cosas en el producto, que al final no se usan… La funcionalidad que ha quedado obsoleta es un desperdicio. Características introducidas sólo para probar la última moda. REAPRENDIZAJE

Muchas veces no preguntamos, ni hacemos caso a expertos, y trabajamos en solitario. Cada minuto que pasamos redescubriendo cosas que rápidamente nos podrían haber contado… es tiempo perdido. Y también encontraremos código mal escrito o indocumentado que conduce a una incalculable cantidad de reaprendizaje, desperdiciando tiempo. Desarrolladores que están constantemente siendo reasignados a funciones diferentes, dejando sin terminar su trabajo actual. TRASPASOS. Documentos de análisis de requisitos, que luego pasan a las manos de un diseñador. El diseñador elabora un diseño y entonces pasa a manos de los programadores. Ciclo de vida en “cascada”: Por desgracia, poco conocimiento puede transmitirse SOLO con documentos y diagramas, por lo que mucho papel acaba siendo un desperdicio. CAMBIOS DE TAREAS. El coste de cambiar de tarea durante el desarrollo de software ha sido un problema de siempre. RETRASOS. Empezar a trabajar en el desarrollo de un proyecto mucho tiempo después del contacto inicial con el cliente. Esperar a que el equipo esté disponible para empezar a trabajar. Largas fases de documentación de requisitos que pretenden detallar todos los aspectos de un producto. DEFECTOS. Todo aquello que no se hace bien, es un desperdicio, no aporta valor, y consume tiempo a la hora de repararlo. 2º PRINCIPIO: CONSTRUIR CON CALIDAD. El enfoque principal es construir con calidad y descubrir los errores lo antes posible: test unitarios, test de integración, test de sistemas…¡Automatizados! Evitar mantener “vivos” los errores en el sistema de seguimiento. Sí, es importante identificar y “realizar el seguimiento” de los errores, pero en el enfoque LEAN un error “detiene” la línea de producción para solucionar el problema. Desde una perspectiva LEAN un error apuntado en el sistema de seguimiento de tareas es trabajo “parcialmente hecho” (Waste) En TPS hay dos tipos de inspecciones de calidad: 1. Inspecciones después de que los defectos ocurran→ testing. 2. Inspecciones para prevenir defectos, esto implica probar antes de crear→ TDD 3er PRINCIPIO: AMPLIFICAR EL APRENDIZAJE. El proceso de desarrollo del software se acerca al desarrollo de productos(segunda derivada del TPS) ambos tienen en común que son procesos basados en el conocimiento. Es importante aprender sobre el producto en sí: desarrollo iterativo con una retro-alimientación alta. Igualmente, importante es aprender sobre el propio proceso. Lean asigna la responsabilidad de la mejora del proceso al equipo de trabajo, justificando la dedicación de tiempo para la mejora del proceso.

4º PRINCIPIO: DECIDIR LO MAS TARDE POSIBLE.

Posponer las decisiones irreversibles hasta el último momento responsable: justo antes de que la decisión sea demasiado tarde. También muy relacionado con el desarrollo de producto lo que facilita su aplicación al software. Toyota lo aplica al diseño de coches…en el software no debe ser más complejo No implica no tomar decisiones, sino identificar aquellas que son irreversibles o costosamente reversibles (1:N o N:M) y tomar la decisión la más tarde posible. Diseñar los sistemas lo suficientemente flexibles. En esto los Patrones de diseño pueden ayudar. Ojo, no todo el software necesita el mismo grado de flexibilidad… puesto que la flexibilidad es cara (ej. implementar interrelaciones N:M son más costosas en capa de datos, interfaz, mantenimiento futuro…) 5º PRINCIPIO: ENTREGA LO MAS RAPIDO POSIBLE. Los requisitos cambian, por lo que necesitamos desarrollar el software tan rápido como nos sea posible para que no tengan tiempo a cambiarlos. De acuerdo… aun así los requisitos cambian…, tenemos que entregarles el producto lo antes posible para que los cambios puedan corregir los diseños y desarrollos que estamos haciendo en este momento: ¡eliminamos desperdicio! • El flujo continuo en Kanban o las iteraciones cortas facilitan este principio. Por otra parte, evitar el trabajo “parcialmente hecho” facilita entregar más rápido →LeadTime más cortos. • Continuous Delivery también atiende a este principio. 6º PRINCIPIO: CAPACITAR Y POTENCIAR AL EQUIPO. Toyota Product Development se centra en los siguientes aspectos: »

» » »

Liderazgo emprendedor. Una organización que respeta a sus personas desarrolla buenos líderes y se asegura de que los equipos tienen el tipo de liderazgo que fomenta el compromiso focalizando a su gente en crear productos de calidad. Personal técnico experto. Una organización Lean debe desarrollar y nutrir experiencia técnica en el área/tecnología en que trabaja. Responsabilidad en la planificación y el control. En lugar de decirle a la gente qué tiene que hacer y cómo ha de hacerlo se promueve la auto-organización que permita la consecución de unos objetivos razonables. Potenciar la flexibilidad necesaria para que la gente solucione por sí mismos los problemas.

7º PRINCIPIO: VER EL TODO. Cuando se piensa en la optimización desde una perspectiva Lean se piensa en la optimización del conjunto de la cadena de valor, traspasando las fronteras internas por las que dicha cadena atraviesa

TEMA 4.2 EL METODO LEAN KANBAN. ¿QUE NO ES KABAN? Kaban no es un método de gestión de proyectos. Kaban no es un método de gestión del ciclo de vida de desarrollo de software

¿QUE ES KANBAN? Kaban es un sistema de información visual que controla de modo armónico la fabricación de los productos necesarios en la cantidad y tiempo necesarios en cada uno de los procesos. Kaban es un catalizador del cambio en las organizaciones. El método Kanban es un método ligero basado en los principios Lean, enfocado en una transformación gradual y continua de las organizaciones, centrados en proporcionar valor al cliente.

Las practicas del Método Kanban ayudan a:

» » » » » » »

Acelerar el desarrollo de software y las operaciones de TI Reducir el tiempo de entrega Optimizar la utilización de recursos Reducir los desperdicios en los procesos Fortalecer la colaboración de las partes interesadas Equilibrar la demanda y la capacidad del equipo Aumentar la calidad de productos y servicios

Kanban fomenta la colaboración y el compromiso de los empleados de una manera natural. Requiere relativamente poco esfuerzo para ponerlo en uso y es adecuado tanto para equipos pequeños como para grandes. Kanban es popular entre las organizaciones que buscan más la agilidad del negocio, pero no están dispuestos a adoptar métodos ágiles de desarrollo de software. Kanban 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. Se basa en una idea muy simple: las personas (y los grupos de trabajo) tenemos un límite en el trabajo concurrente que somos capaces de hacer “eficientemente”. Por lo tanto, el trabajo que “tenemos entre manos” debe limitarse y no debemos asumir más trabajo hasta que hayamos terminado/entregado lo que estábamos haciendo o lo hemos pasado a otra persona del equipo (siguiente eslabón de la cadena). La “novedad” es aplicarlo al Desarrollo el Software. Kanban fue trasladado al desarrollo del software (David J. Anderson) en el 2004… aunque la primera aproximación fue en 2003 a través de la implantación de TOC (Theoryof Constraints) a un equipo de mantenimiento evolutivo de aplicaciones internas.

KANBAN ES UN “JUEGO CON REGLAS MUY SIMPLES. 1. Visualiza el flujo de trabajo (Tablero Kanban). Lo que tenemos oculto en el software es el propio flujo de trabajo y eso lo que un tablero kanbal no va a permitir hacer. En este tablero se encuentran muchas señales que me facilitan las cosas. Con este tablero buscamos visualizar cual es el flujo de trabajo. 2. Limita el trabajo en curso. Asigna límites concretos a cuántos elementos pueden estar en curso en cada estado del flujo de trabajo. 3. Mide y optimiza. Una vez que ya conozco las reglas me pregunto ¿Dónde empiezo el cambio? No hay que cambiar nada, el primer paso es visualizar el trabajo tal se hace en la actualidad. VISUALIZA EL FLUJO DE TRABAJO ( TABLERO KANBAN) Es imprescindible descomponer el flujo de trabajo que se realiza para llevar a cabo las actividades/tareas/casos de uso/historias de usuario/”lo que sea” que conforma nuestro proyecto. No hay que cambiar nada de la forma de trabar. Solo se ha de visualizar como se trabaja. El objeto es visualizar que queda por hacer y en que se esta trabajando . LIMITA EL TRABAJO EN CURSO. La principal característica de Kanban es limitar el trabajo en curso en cada fase del proceso. El WIP me indica el máximo de tareas que puedo realizar simultáneamente. ¿Cómo se cual es el limite adecuado para cada columna? La respuesta es que no hay reglas, hay que probar observar y corregir.

MIDE Y OPTIMIZA Es muy importante conocer los tiempos desde que un “trabajo” entra en nuestro flujo hasta que sale: Lead Time

También es importante el tiempo de ciclo: tiempo que se tarda en completarlo una vez comenzamos a trabajar en él. METRICAS. Probablemente la métrica. Fundamentalmente estriba en mostrar que el sistema funciona correctamente. Para ello utilizamos un diagrama de flujo acumulado que muestra la cantidad de trabajo en curso en cada etapa del sistema Si funciona correctamente el flujo debe ser suave y el ancho de las bandas estable. Lead- time. Generalmente la siguiente métrica con mayor interés. Muestra como de previsible es nuestro equipo/organización frente a los compromisos de las diferentes clases de servicio. Tiempo de ciclo: Me permitirá conocer la tendencia de la eficiencia de los procesos internos y evaluar el resultado de incluir determinadas mejoras.

ESTABLECER UN ACUERDO DE NIVEL DE SERVICIO. CLASES DE SERVICIO. Igualmente, 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 clase de servicio superior al resto. Resolver una incidencia de alta prioridad requerirá asignar todo el personal disponible y detener todo el trabajo en curso para conseguir solucionarlo. Este concepto 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 CLASE URGENTE. Trabajos urgentes que deben ser tratados de inmediato »

SLA: se salta todas las normas del tablero

CLASE BUG. Defecto detectado en fase de Aceptación »

SLA: Se corregirá en el momento de la detección, devolviendo a EN DESASARROLLO el trabajo. Estimación por defecto =0,5 puntos.

CLASE TECNICA O CALIDAD. Trabajos derivados de cambios de infraestructura (ej. Servidores 64 bits) o temas relacionados con la calidad de producto (ej. Refactorizar parte de código propenso a errores) »

SLA: Al tratarse de asuntos que generalmente no aportan valor a los usuarios, sacrificaremos su LeadTime en favor de la Clase estándar. Excepto fuerza mayor, no incluir mas de un trabajo ToQ simultá...