Actividad P1 – Lean y Kanban – ¿Qué nos perdimos?

Las ideas de Lean son mucho más de lo que podemos dar en una clase.

Buscá principios e ideas Lean o Kanban que no hayamos explicado en la clase, y comentalos brevemente, aplicados al caso del desarrollo de software

Pueden ver un resumen acá.

5 puntos

Anuncios
Publicado en Sin categoría
46 comments on “Actividad P1 – Lean y Kanban – ¿Qué nos perdimos?
  1. Fabrizio Graffe dice:

    Si bien en la clase se vieron conceptos sobre como optimizar la eficiencia del proceso, mejorar el flujo por el cual se entrega valor, estrategias para identificar los cuellos de botella y a trabajar de manera de minimizar el desperdicio, uno de los principios que no se trató y me pareció interesante, es el concepto de Managers – Teachers.

    Este principio de Lean Thinking, estipula que los “Managers” (como podrían ser líderes de proyecto, jefes de área, etc) deben desarrollar mas una tarea de coaching para con la gente que tienen a su cargo, que una tarea de dirección.
    Se espera que los “Managers” enseñen a sus empleados como pensar o como resolver problemas, antes que decirles solo lo que tienen que hacer. Se quiere así lograr desarrollar la autonomía de cada persona en la resolución de problemas mediante el apoyo en sus actividades de mejora continua.
    Es decir que los “Managers” deberán actuar como mentores de sus empleados (durante años) en herramientas o skills (habilidades) del pensamiento como lo son la resolución de problemas, el análisis de causa raíz, la mejora contínua, el pensamiento sistémico, etc.

  2. Pablo Ascarza dice:

    Agregando a lo visto en clase se puede mencionar de los 2 pilares, el principio de respeto por la gente.
    Este se aplica de manera entera al desarrollo de software tanto en el trato del cliente, como en el equipo propio. Se puede resumir en 6 divisiones:
    -Desarrolla a la gente que va a realizar el trabajo después arma el producto.
    -No entregues problemas a tus clientes
    -Construye compañeros
    -Desarrolla a tu equipo
    -Realiza las acciones que lleven a los objetivos
    -Deja que el equipo evolucione tanto por sugerencias como desarrollo propio.

  3. Maximiliano Schultheis dice:

    A lo visto en clase, agregaría el concepto de Kaizen, asociado con el pilar de Mejora contínua. La idea tras este pensamiento es: “Mi trabajo es hacer mi trabajo y mejorar mi trabajo”. El ciclo Kaizen se resume en:
    1) Elegir una técnica de trabajo que el equipo haya aceptado y practicarla hasta que se haya entendido del todo.
    2) Experimentar hasta que se encuentre una manera mejor de hacer la tarea.
    3) Repetir

    De esta forma uno está en constante movimiento, alineándose con la ideología de la mejora contínua.

  4. Tomás Franco dice:

    Uno de los principios que encontré interesantes es el que se describle como “Build a culture of stopping and fixing problems; teach everyone to methodically study problems.” Aplicado al caso de desarrollo de software podría ponerse en práctica asegurándole a un equipo tiempo para realizar refactors sobre el código sobre el que trabajan y no utilizar la totalidad del mismo con el que cuentan para el desarrollo de nueva funcionalidad o la solución de bugs. Crear una cultura para esto puede prevenir drásticamente la aparición de errores en el futuro.

  5. Un principio que no se discutió tanto en clase es “Empower the team”.

    Tradicionalmente, la idea que se tiene de un manager es alguien que esta microgestionando a las personas, y les dicen cómo hacer su trabajo. LEAN propone
    que esto se invierta; es decir, en nuestro caso, que el manager escuche a los devs, para que puedan sugerir mejoras o explicar mejor determinadas acciones.

    Además, se enfatiza que la gente NO es un recurso. La gente necesita algo más que una lista de tareas, la gente necesita motivación, visión de una meta mayor. Para esto, se recomienda establecer contacto entre los devs y el cliente, y que el TL provea apoyo a las personas cuando tienen en sus manos situaciones difíciles.

  6. Nicolás Ortoleva dice:

    Una de las idea que me parece interesante en LEAN es la “entrega rápida”.
    La idea de entregar rapido y reducir el retrabajo, no confundir rápido con apurado. Ya que ágil es rapido no apurado. Estas entregas rápidas implican calidad. La idea de trabajar en grupos pequeños y acortando la entrega, y en cada ciclo mejorar lo que se hace bien y evitar lo que hace mal me parece una buena practica para poder llegar en termino con las entregas parciales de un producto dándole valor a lo que realmente nos aporta valor. Por ejemplo en toyota se trabaja sin stock, nada se construye de mas. Se comienza a construir cuando existe una orden de pedida. Y al estar todo el bloques estandarizados se llega en forma rapida y efectiva.

  7. Sabrina Campa dice:

    A mi entender, uno de los pilares fundamentales es ‘Respect for people’.
    Todas las metodologías ágiles tienen en común que valoran a los individuos y a su “know-how”.
    Cuando las tareas son repetitivas (como en una cadena de producción, por ejemplo) el “know-how” ya se encuentra incorporado en el proceso, porque cada producto que sale de esa línea de producción es idéntico al anterior. Sin embargo, en el ámbito del desarrollo de software, el “know-how” toma mayor importancia porque cada “producto” es diferente y, por lo tanto, son los individuos los que hacen posible llevar a cabo las tareas de manera correcta.
    Es por eso que el trabajo de las personas vuelve a ser valorado, ya que en ellas se encuentra el conocimiento y la actitud que produce resultados. Los procesos son más bien vistos como un soporte o guía.
    La resolución de problemas en el ámbito del desarrollo de software también se apoya en la comunicación y el respeto. A menudo, un líder de proyecto reconoce a sus empleados que no puede resolver un determinado problema solo por no estar lo suficientemente cerca como para conocer todos los detalles que necesita. El líder respeta los conocimientos de los integrantes de su equipo y su dedicación para encontrar una solución. Desde el otro lado, el equipo tampoco puede resolver el problema solo, ya que suele estar demasiado cerca del problema como para ver el contexto en su totalidad.
    Es así, como mostrando respetuo mutuo, es posible resolver problemas y trabajar más a gusto, aumentando el rendimiento de la organización.
    El respeto por la gente es un pilar fundamental para la vida laboral en general.

  8. Uno de los principios que encuentro que es útil pero se le presta poca atención es al de “Ir a ver por uno mismo al lugar real de trabajo para entender la situación y ayudar”. El manager no debe ser alguien que se la pase en su escritorio recibiendo llamadas y yendo a reuniones, sino que debe acompañar al equipo de trabajo, velar por su comodidad para lograr mejor eficiencia y estar con el cliente para entender mejor los problemas y llegar a soluciones que mejor ajusten.
    Esto aplica también a los trabajadores, en lugar de trabajar en forma remota, el contacto con el cliente, estar en el lugar de trabajo, que lo vean a uno es siempre un plus, mejora la relación con el cliente y la impresión que le damos, ademas que favorece a los proyectos ya que cualquier duda que se tenga se puede disipar inmediatamente.

  9. Además de los conceptos vistos en clase, me llamó la atención el concepto de Kaizen en el cuál uno debería estar en todo momento viendo de qué forma mejorar su forma de trabajo persiguiendo la mejora continua. La manera de trabajo seria identificar las posibles etapas de la metodología actual de trabajo que nos lleve demasiado tiempo, analizarlas y proponer un cambio para ver si se puede realizarlo más rápidamente.Si luego comunicamos los distintos cambios positivos a los compañeros en las retrospectivas podremos realizar una mejora importante en la forma de trabajo del equipo.

  10. Sebastian Barreña dice:

    Uno de los principios que encuentro interesantes y que no se mencionó en clase al menos en forma explícita (o no escuché) es el de los sistemas PULL. Se trata de dejar que los clientes tiren de la producción, es decir, se basa en la demanda. La aplicación del Flujo y del Pull generan una respuesta más rápida y exacta con un menor esfuerzo y menores desperdicios. Permite producir sólo lo que el cliente pide y evita la generación de un stock innecesario.
    Se refiere a construir en respuesta a una señal desde el ‘cliente’, y de lo contrario descansar o mejorar.
    Esto me hace pensar con respecto al desarrollo de software en donde no hay que ponerse a desarrollar determinada funcionalidad de un proyecto/producto pedido por un cliente sin antes haberlo validado por él, es decir, no hay que realizar gold plating (sería como acumular stock) ya que al cliente puede no gustarle la funcionalidad nueva, teniendo que hacer retrabajo y se genera desperdicio.

  11. Algo que no se comentó en la clase es el principio de “Liderazgo en todos los niveles”. En la metodología Kanban se propone que no exista un único líder en la punta de la pirámide, sino que se impulsa que cada uno, desde contribuidores individuales hasta los roles senior, actúen como tal.
    Llevado al desarrollo de software, Kanban busca que dentro del equipo de trabajo haya un pase continuo de conocimiento (de tecnología y demás) entre pares, cada uno apoyándose en el otro dependiendo de las habilidades necesarias para cada cosa.

  12. Uno de los principios no mencionados y muy interesante es el de “decide slow, implement fast” el cual propone tomarse mucho tiempo para analizar las diferentes opciones de acción, evaluar las ventajas y desventajas, iterar sobre posibles mejoras. Luego a la hora de implementarlo se debe hacer muy rápido ya que no debería quedar nada para pensar o dudar.
    Esto aplica al desarrollo de software, donde la corrección de errores tiene un costo que crece exponencialmente a medida que avanza el tiempo de desarrollo del producto. Por lo tanto, es aconsejable invertir tiempo en una solución confiable desde el comienzo, antes de ir a implementar sin pensar antes lo suficiente.

  13. Dario Seminara dice:

    Una idea no tratada en clase que me interesa a mi particularmente es “Visual Management for Queues in Knowledge Work” o “El temible WIP invisible” como esta explicado en “Lean Primer” (http://www.leanprimer.com/downloads/lean_primer.pdf) en la Pag 32

    La razon para plantear este tema, parte de la problematica implicita en la aplicacion del metodo Kanban a procesos relacionados con el conocimiento (software): al no tener indicadores fisicos de colas, piezas, materiales como en el caso de la manufactura tradicional en fabricas, existen bastante mas chances de que se generen “Invisible Queues” o colas invisibles, o tambien incluso WIP totalmente desapercibido. Esta claro: si no somos capaces de percibir el WIP/desperdicio, mucho menos vamos a ser capaces de reducirlo… y aun peor: si la visualizacion es muy mala, podriamos tener la falsa percepcion de que vamos bien, con WIP reducido, mientras que la realidad es otra

    Si en una fabrica (manufactura) podiamos ver fisicamente el stock de determinadas piezas y darnos cuenta facilmente si sobran o faltan, en el desarrollo de software, tendriamos en un principio que recurrir a tokens fisicos siendo los tableros kanban los mas usados (los “tokens” que representarian el WIP podrian ser los post-it)

    Implementar el uso de un tablero kanban es un buen comienzo para atacar el problema, pero por algunas experiencias que tuve viendo las cosas con “ojos de kanban” yo me convenci de que el solo implementarlo no es suficiente para dar el problema por resuelto, ya que falta asegurarse de que ninguna fase del proceso se queda afuera del tablero (generando WIP invisible), y que ademas ninguna tarea se quede afuera tampoco (tambien generando WIP invisible).

    Algunas fases q se suelen quedar afuera: deploys (doy por “completa” la tarea al ser aprobada por QA, pero resulta que lo que hice esta entre unas 20 features no deployadas, eso es acumulacion de WIP)

    Tarea que se queda afuera: el hotfix (tengo parar lo q estoy haciendo para fixear un bug, “no tiene sentido” reflejarla en kanban por que “sale rapido”.. sin embargo me entero q tengo 4 hotfix pendientes de desarrollo/qa/deploy, eso es WIP y quedo totalmente invisible…)

  14. Maximiliano Roitman dice:

    Un concepto que considero que esta bueno aplicar a lo que es el software es Kaizen donde se persigue la mejora continua, es decir de que forma yo puedo mejorar el trabajo en todo momento; esto trae como consecuencia que se obtiene un mayor beneficio y calidad de trabajo en el dia a dia, así como tambien se logra una mejor calidad en el producto terminado para sesr entregado al cliente.
    Lo primero que habría que hacer es encontrar una tecnica aceptada por el equipo e ir poniendola en practica dia a dia, luego ir comentando los cambios positivos al equipo, asii como tambien las cuestiones negativas para ir mejorandolas, y finalmente ir repitiendo estos pasos para luego pulir dicha tecnica donde se la termina adoptando como metodologia de trabajo

  15. Jennifer Woites dice:

    Una de las ideas de LEAN que me gustó es:

    Crear conocimiento

    * Crear equipos de diseño y construcción – el líder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los inste a buscar respuestas y volver lo más pronto posible con los problemas que surgen, o con las soluciones inventadas.
    * Mantener una cultura de mejora continua – crear un ambiente en donde las personas estén mejorando continuamente en lo que trabajan – deben saber que no son y no deben ser perfectas – y que siempre tienen algún área que pueden mejorar.
    * Enseñar métodos de resolución de problemas – los equipos de desarrollo deberían comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.

    La idea fundamental es mejorar todo el tiempo, dandole al equipo herramientas útiles para hacerlo.

    Por último, dejo unos videos sobre LEAN.

  16. gonchub dice:

    La innovación organizacional propuesta por Lean Thinking se basa en poner a las personas antes que a los sistemas. Se separa del management “mainstream” de la siguiente manera:

    – Los consumidores son individuales y no grandes mercados: lean thinking se basa en pensar en cada consumidor como un individuo y teniendo en cuenta su feedback, tanto positivo como negativo.
    – Enseñar a los empleados como aprender antes que decirles que hacer: lean thinking apunta a la autonomía de cada empleado tanto en la resolución de problemas como en su mejora en el ambiente laboral.

    Lean thinking crea empresas “lean” que aumentan las ventas a través de la satisfacción del consumidor con productos de mayor calidad.

  17. Joaquin Stankus dice:

    Me interesa este concepto que se presenta como parte del pilar Respect For People: “Develop People and Then Build Products”. No existe manera de crear un gran producto sin buscar la excelencia de las personas involucradas en el desarrollo y crecimiento del producto. Enseñar a un empleado a realizar tareas repetitivas y especificadas hasta el mas minimo detalle sin desarrollar el espiritu critico y las habilidades de resolucion de problemas no ayuda a desarrollar su habilidad para mejorar continuamente. Seguramente una persona puede realizar un aporte mucho mas significativo al objetivo de la organizacion si esta alineado con la vision de la empresa y tiene el espacio para actuar mas alla de lo que le es indicado de forma autoritaria (Teachers, no managers).

  18. Uno de los temas sobre los cuales quizás no se hizo tanto énfasis fue en cuales son los pilares de Lean.

    Lean plantea que sus 2 pilares son la “mejora continua” y el “respeto por la gente”. Le da una vuelta al modelo clásico, que plantea que si algo funciona bien no se debe modificar, planteando que siempre hay que cuestionarse porque se hacen las cosas como se hacen e intentar mejorar de alguna manera los procesos. Además, pone el énfasis no en el producto sino en el la gente que construye ese producto, proponiendo mejorar el desarrollo personal y el el trabajo en equipo

  19. Pablo Oddo dice:

    Existen una serie de claves que configuran este modelo de desarrollo. Su aplicación es condición necesaria para la existencia del ajuste y por ello se conocen como los 7 principios fundamentales del lean software development. Son los siguientes:

    1. Eliminación de desperdicios: En el ámbito del desarrollo software habría que intentar evitar:
    a) Codificaciones innecesarias.
    b) Inicio de más tareas de las que pueden ser completadas.
    c) Retrasos en el propio proceso de desarrollo de software.
    d) Requisitos poco claros o sujetos a constantes cambios.
    e) Comunicación lenta o ineficaz.
    f) Defectos y problemas de calidad.
    g) Cambios de tarea injustificados.

    2. Aseguramiento de la calidad de la estructura: cuando se parte de una base sólida y fiable se pueden evitar problemas de calidad. Una buena planificación y la aplicación de las mejores prácticas son la clave de este principio del lean software development que requiere de:
    a) Una retroalimentación constante.
    b) La minimización de plazos entre cada etapa y la siguiente.
    c) El aumento de la frecuencia de integración.
    d) La automatización.

    3. Creación de conocimiento: es la clave para dotar de mayor flexibilidad a los equipos al tiempo que se sientan las bases de la productividad a largo plazo. Algunas de las acciones que permiten generar este valor son:
    a) Las revisiones y notas sobre los códigos.
    b) La creación de documentación.
    c) La elaboración de una base de datos informativa sujeta a actualizaciones.
    d) Las puestas en común de conocimiento.
    e) Las iniciativas formativas.

    4. Aplazamiento del compromiso: lo que no tiene nada que ver con la indolencia, sino más bien con todo lo contrario, ya que busca comprometerse responsablemente para lo cual, en muchas ocasiones, es necesario retrasar la toma de decisiones por dos motivos:
    a) Mantener todas las opciones disponibles el mayor tiempo posible.
    b) No garantizar un resultado hasta que no se tiene la absoluta certeza de que se va a poder cumplir con el acuerdo.

    5. Entregar rápido: tras un inicio tan temprano como sea posible el objetivo debe ser evitar la complejidad y simplificar al máximo. El lean software development va en contra de los excesos, que tan habitualmente se cometen en términos de arquitectura y requerimientos de negocio. Para lograrlo, además de eliminar desperdicios, como recomienda el primero de los principios, hay que:
    a) Contar con personal cualificado, debidamente formado y, a ser posible con experiencia en el desarrollo software.
    b) Buscar la manera más simple de cumplir con los objetivos.
    c) Trabajar en equipo.
    d) Asegurar que se cumplen los estándares de calidad.

    6. Respetar a las personas: de esta forma se consigue una mayor motivación que tiene una traducción directa en los niveles de productividad alcanzados. Este mayor rendimiento individual responde al reconocimiento y la autonomía, dos elementos que el responsable de la gestión de proyectos de lean software development debe procurar.

    7. Optimizar el todo: hay que tratar de evitar que el foco de atención recaiga sobre un elemento en particular ya sean los plazos, los costes o los procesos. Cuando esto sucede la tendencia a compensar aumenta la carga en otras áreas que comienzan a perder ajuste. Conseguir aplicar este principio de forma correcta requiere de un modelo de liderazgo comprometido con la gestión ajustada y consciente de la necesidad de buscar un equilibrio.

  20. Uno de los principios Lean no comentados en clase es: “Respect your extended network of partners by challenging them to grow and helping them improve.”
    Basicamente plantea respetar a las personas y brindarles ayuda para que progresen y estén motivadas. De esta forma se logra un beneficio mutuo a largo plazo ya que ambos estan cómodos y se obtiene un mayor rendimiento.

    Esto es aplicable al desarrollo de software tanto en el rol de los project leaders que deben ayudar y motivar a su gente a cargo como en el vinculo entre desarrolladores, que en vez de fomentar la competencia deberían ayudarse entre ellos.

  21. Ademas de lo visto en clase me pareció muy interesante el concepto de Kaizen aplicado al desarrollo de software, puntualmente al aplicar una metodología enfocada a mejorar la calidad del trabajo y de los procesos.
    Para aplicar Kaizen hay que pasar por cuatro pasos bien definidos, llamado ciclo de Demming o PDCA.

    La utilización del circulo y su repetición iterativa se detalla en la teoría de Kata (‘forma’), que persigue la utilización a ciclo continuo y repetido de las técnicas arriba comentadas, así añadiendo valor al término “Continua” proprio del tipo de mejora que nunca alcanza su fin, sino siempre encuentra nuevas oportunidades de mejora.

    Todo estos conceptos han sido resumidos e implementados dentro del mundo de desarrollo de software gracias a la metodología eXtreme Programming y a su utilización conjunta en el marco de la metodología Scrum. Ambas metodologías, aunque siendo independientes, tienen muchos elementos comunes porque implementan los conceptos de mejora continua arriba descritos.

  22. Hugo Chavar dice:

    Principio 7: Usar una Gestión visual simple para comunicar problemas y coordinar
    Me atrajo por la sencillez de este principio de LEAN. Se enfatiza el uso de herramientas visuales simples y grandes para indicar problemas, coordinar o comunicar.
    El uso de monitores grandes en las paredes, o postits coloridos y grandes que las personas pueden ver y moverlos.
    La idea es que sea fácil de ver desde lejos, que sean simples y que resalten por su colorido.

    Este es un ejemplo:

  23. Joel Ruggieri dice:

    Kanban surge en Toyota, y como palabra de origen japonés significa “insignia visual”.
    Kanban se basa en procesar una orden de trabajo en caso de contar con capacidad para hacerlo, como es esto?? se usan unas tarjetas que acompañan a un producto, desde que inicia su producción, hasta que finaliza y está listo para entregarlos al cliente, y en ese momento es cuando la tarjeta es liberada.
    De esta forma, un nuevo pedido puede ser aceptado, sólo si se cuenta con alguna tarjeta libre.

    Tres reglas de Kanban:
    – Mostrar el proceso: Se usan tableros (esto fue una modificación hecha a la utilización de las originales tarjetas de Kanban. El reemplazo lo introdujo David Anderson de la Unidad de Negocios XIT de Microsoft, en 2004. Estos tableros se usan mucho en entornos ágiles) como el que mostró el compañero en la publicación anterior para poder ver de forma global todo el proceso de desarrollo, para entender mejor el proceso y poder mejorarlo al encontrar falencias.

    – Limitar el trabajo en curso: Determinar de antemano cuantos items simultáneos pueden estar produciéndose para evitar estancamientos por cuello de botella.(creo que esto fue mencionado en clases). También llamado work un progress (wip)

    – Optimizar el flujo de trabajo: Medir el tiempo de un ciclo completo del proyecto para obtener el cycle time. Entonces al dividir el cycle time por el wip, se obtiene el rendimiento de trabajo, es decir, la cantidad de items que un equipo puede terminar en un determinado período de tiempo.

    Con esto, con Kanban y la utilización de estas reglas se busca:

    – Minimizar el tiempo del ciclo
    – Maximizar el rendimiento
    – Lograr que estos valores no varíen demasiado entre iteración.

  24. Nicolas Javier Pantazis dice:

    Se habló poco de la administración de redes de suministro (Supply chain management) es el proceso de planificación, puesta en ejecución y control de las operaciones de la red de suministro con el propósito de satisfacer las necesidades del cliente con tanta eficacia como sea posible. La gerencia de la cadena de suministro atraviesa todo el movimiento y almacenaje de materias primas, el correspondiente inventario que resulta del proceso, y las mercancías acabadas desde el punto de origen al punto de consumo. La correcta administración de la cadena de suministro debe considerar todos los acontecimientos y factores posibles que puedan causar una interrupción.

    Ahora más que nunca las organizaciones dependen de redes de suministro efectivas para cumplir con la demanda económica del mercado mundial. El concepto de relaciones de negocio va más allá de los tradicionales límites entre empresas y busca organizar los procesos a través de esta red.

  25. Yamila Glinsek dice:

    Agregando a lo visto en la clase, el segundo pilar de Lean, “Continuous improvement”, está basado en ideas como “Go See”. Esta idea consiste en ir al lugar donde se hace el trabajo de valor para observar y después utilizar lo observado para una correcta toma de decisiones, generar acuerdos y cumplir objetivos lo más rápido posible. La idea sugiere que todas las personas, especialmente los gerentes, deberían ir frecuentemente a los lugares de trabajo para poder observar por ellos mismos la situación, en vez de trabajar en oficinas separadas recibiendo reportes escritos por otros sobre la situación del sector a cargo. De esta forma, resulta más fácil entender los problemas y poder ver oportunidades de mejora.
    En el caso de desarrollo de software sirve de la misma forma que en otros casos, ya que aplicando esta idea, se pueden realizar mejoras considerables en el ambiente de trabajo y en el producto final, gracias a que las personas que toman las decisiones observan directamente el proceso de trabajo, sin intermediarios, lo cual da una visión mucho más completa.

  26. Federico Quevedo dice:

    Se hablo sobre las bases de Lean, de como se trabaja para lograr maximizar la salida ante un pedido de productos que puede variar y como lograr esto manejando un inventario de piezas. Para lograr esto se gestiona la cantidad de desperdicios generada con la intención de minimizarla.

  27. Agustín Rojas dice:

    Un principio que me parecío interesante de destacar. Fue el siguiente

    7. Use visual controls (visual management) to reveal problems—and to coordinate.

    El uso de elementos que faciliten la visualización del trabajo es una herramienta muy buena para ayudar a mejorar el desarrollo diario de un equipo. Esto se puede ver en cosas tan sencillas como un gráfico que vaya mostrando el avance del equipo durante el proyecto

    Otro que voy a mencionar es

    10. Develop exceptional people and teams who follow your company’s philosophy.

    Donde en este principio se destaca la importancia que se le da desde Lean al factor humano para poder lograr un buen producto

  28. Dos principios importantes de Lean que no desarrollamos en clase y que me parecen importante son:

    – Bajar la responsabilidad al menor nivel posible: es decir que las decisiones pequeñas dependan de los que se ocupan de realizar esa tarea y no de un “jefe” o entidad superior. De este concepto surgen las organizaciones “auto-organizadas” (valga la redundancia).
    – Optimizar la totalidad de la entrega: entregar un producto 100% funcional y terminado, no entregar productos incompletos o finalizados a medias.

  29. Jimena Tapia dice:

    12. Go see for yourself at the real place work to thoroughly understand the situation and help. –> Propone que los managers y líderes se acerquen a los distintos equipos y vean y participen activamente de las mejoras en vez de manejar el flujo de información a través de reportes o minutas de reunión. Resalta la inversión de tiempo en esta actividad, dado que no es simplemente dar vueltas por la organización, si no, involucrarse y comprender qué está sucediendo para poder mejorar y focalizarse de cerca en las personas que llevan a cabo el trabajo.

    9. Grow leaders from within who thoroughly understand the work, live the philosophy, and teach it to others —> Aplicando este principio se sitúa al líder como mentor y responsable de enseñar y transmitir la filosofía lean dentro del equipo.

  30. 7. Use visual controls (visual management) to reveal problems—and to coordinate.
    Utilizar algo visual como por ejemplo post its en una pizarra de distintos colores para mostrar estados del proyecto, prioridades, etc. Organizar la información de la manera más simple posible para que se pueda ver rápidamente un panorama del proyecto. También se puede mostrar en qué está trabajando cada equipo.

    10. Develop exceptional people and teams who follow your company’s philosophy.
    -Organizar equipos de pocas personas.
    -Organizar equipos con especialistas de las distintas áreas.
    -Que las decisiones de los equipos se tomen por consenso y que se trabaje colaborativamente.
    -Buscar nuevos desafíos hacia los equipos para que se encuentren continuamente motivados.
    -Que los logros sean en conjunto y no individuales.

  31. Damián Arias dice:

    Uno de los principios sobre el que no se habló mucho en clase es el de “Become and sustain a learning organization through relentless reflection and kaizen”.

    La aplicabilidad de Kaizen a la Ingeniería del Software, es entendida como la Mejora Continua dentro de un entorno estable de producción.

    El papel del componente humano es crítico en el desarrollo de software y Kaizen reconoce esta circunstancia y saca partido de ella:
    cambia la perspectiva de la resolución de problemas y lo centra en las
    personas, en buscar soluciones en lugar de culpables y fomentando la
    búsqueda de los intereses colectivos en lugar de intereses individuales.

    Se pone de manifiesto que su punto fuerte es que gracias a su orientación a las personas y a los procesos, las mejoras resultado de su aplicación se incorporan en el sistema a través de las personas y mediante procesos de control.

    Se identifica la necesidad de capacitar a las personas y fomentar su participación e involucración en la organización, así como la necesidad prestar atención al componente motivacional de las personas que realizan el trabajo.

    Todo el personal involucrado en el proyecto (desarrolladores, clientes, usuarios, etc.) deben sentirse en confianza para expresar su punto de vista y poder participar en el proceso de mejora continua, disponiendo de los canales adecuados para comunicarse.

  32. Principio 8
    “Utilice solo tecnologia fiable y absolutamente probada que de servicio a su personal y a sus procesos”
    Esto aplica, en el software, a la hora de elegir tecnologías a utilizar. No deberiamos utilizar versiones beta de bibliotecas o apis ni versiones nightly de plugins ya que son propensas a cambios que nos podrian llevar a perdidas por retrabajo, investigarción de cosas que cambian o no están implementadas, etc.

    Dejo, además, un link de interez donde se explican los 14 principios:
    https://toyotaps.wordpress.com/

  33. Uciel Rodriguez dice:

    Yo quiero agregar de Kanban algo sobre el Control de Flujo: a diferencia de SCRUM, la metodología Kanban no se aplica a un único proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser desarrolladas y un seguimiento pasivo para no tener que interrumpir al trabajador en cada momento.

    Asimismo, dicha metodología de trabajo nos permite hacer un seguimiento del trabajo realizado, almacenando la información que nos proporcionan las tarjetas.

  34. Algo interesante de Kanban es que es una metodología que no se aplica sólo a al desarrollo de software y que es interesante la simpleza del uso de la misma. Simplemente con algunas columnas y un “postit” podemos ver el flujo de las tareas.
    Además hay bastantes aplicaciones que nos permiten utilizar esta metodología, como por ejemplo: http://www.thetoptens.com/online-kanban-tools-for-business/

    En un trabajo pasado usábamos esta metodología y era interesante ver como era desproporcionado para algunos. Adicionalmente sobre las filas agregábamos nombres para contabilizar al final de semana y eso nos daba una pauta de la carga de cada persona.

  35. debmarblog dice:

    Grow leaders from within who thoroughly understand the work, live the philosophy, and teach it to others
    La idea de que los que serán líderes, o jefes, deben ser educados en la metodología desde mucho antes de llegar a serlo muy interesante. Implica que deben haber visto todas sus ventajas y desventajas la práctica, que ya tienen una forma de pensar que sigue la metodología naturalmente. Además conlleva un esfuerzo por parte de los líderes actuales para participar activamente en la capacitación de dichos individuos. Esto adquiere mayor relevancia cuando se tiene en cuenta que a muchos líderes les cuesta delegar tareas a otros, lo que contribuiría a su entrenamiento.

  36. Algo muy iimportante me parece la mención que hace el paper acerca del respeto hacia las demás personas, que esta incluido dentro de la cultura de Toyota.
    Una de las cosas importantes es no asignar trabajos que hagan sentir inútiles a las personas sino que se debería incluir a la gente a trabajar en equipo y desarrollar sus habilidades

  37. nestor huallpa dice:

    El principio de Calidad Integrada, esta enfocado en que las pruebas son para prevenir errores, no para encontrarlos. Es por esto que LEAN propone que el desarrollo debe realizarse desde el primer momento con calidad. Teniendo este enfoque, pueden eliminarse perdidas de tiempo en las últimas de desarrollo.

  38. belubeltran dice:

    Un tema a mencionar puede ser el de las 5S. Ésta es una metodología que propone 5 principios:

    * Separar innecesarios
    * Situar necesarios
    * Suprimir suciedad
    * Señalizar anomalías
    * Seguir mejorando

    Es una filosofía para organizar el trabajo de una manera que minimice el desperdicio (LEAN), asegurando que las zonas de trabajo estén limpias y organizadas, mejorando la productividad, la seguridad y las bases para la implementación de procesos.

  39. Build a culture of stopping and fixing problems; teach everyone to methodically study problems.
    La idea de que hay que tomarse su tiempo cuando surge un problema y no realizar un arreglo rápido. Hay que parar y analizar las causas que ocasionaron el problema, llegar a la causa raíz y realizar el análisis de los 5 why’s para saber bien porque surgió el problema y estar seguros de que no vuelva a aparecer mas adelante y de esta manera crear un ambiente con cero problemas.
    Desde ya que es mas barato hacer un arreglo rápido, pero eso no asegura que no vuelva a aparecer ya que no nos enfocamos en la verdadera causa sino que arreglamos lo que paso en el momento para poder seguir adelante, pero seguramente mas adelante haya que realizar ese arreglo rápido nuevamente.

  40. Manuel Iglesias dice:

    Un aspecto que me resultó interesante sobre Lean es la idea de “cadencia” o “ritmo regular”. El artículo dice que nosotros los humanos generalmente buscamos que haya “cadencia” en nuestras vidas lo cual es muy real. Como ejemplo da el “ritmo” de 7 días por semana.

    En el desarrollo de software la “cadencia” se puede ver en los sprints de SCRUM, y la idea de que la gente busca esa “cadencia” se ve cuando -en general- preferimos los sprints cortos (más ritmo).

    Mantener un ritmo regular ayuda a planificar, coordinar y preveer mejor las cosas: 3 aspectos más que importante del desarrollo de software.

  41. Una de las ideas de Lean que suele ser pasada por alto y esta devaluada en el area debido a la extensa soberbia del que mas sabe: Respetar a las personas.
    Al sentirse valorados, la gente esta mas contenta y trabaja mejor, por lo tanto, mas productivamente. En cualquier proyecto que utilice lean se debe reconocer y otorgar cierta libertad de acción para mejorar la productividad.

  42. Luis arancibia dice:

    Uno de los conceptos que mas me llamo la atencion es el de Kaizen en el que cada uno vela por perseguir una mejora continua.

    “Adoptar el kaizen es asumir la cultura de mejoramiento continuo que se centra en la eliminación de los desperdicios y en los despilfarros de los sistemas productivos. Se trata de un reto continuo para mejorar los estándares, y la frase: un largo camino comienza con un pequeño paso, grafica el sentido del kaizen”

    Viendo esto en forma individual ya es bueno, pero dentro del marco de scrum por ejemplo, en las retrospectivas podemos potenciar esto mismo compartiendo experiencias con todo el equipo, mejorando la productividad en conjunto.

  43. Tobías Lichtig dice:

    Creo que es fundamental lo que dice sobre respetar a todas las personas, en todo sentido. Eso implica no solo ser respetuoso en el trato directo, sino también ser considerado a la hora de asignar tareas de forma tal que la gente no se sienta menospreciada ni ahogada, y fomentarlas a desarrollarse y a trabajar en equipo.

  44. Juan Costa dice:

    Me pareció muy importante el ‘Respect for people’. Hoy en día es muy importante para un manager o alguien que lidere equipos este punto, respatar y motivar al equipo. Hacerles entender que su “know-how” y punto de viste es importante

  45. Nahuel dice:

    Uno de los conceptos que no fueron tratados en clase sobre Lean Startup, que está dentro del Lean Canvas, que es un modelo de analisis de negocio, es un factor importante que deberia tener tu startup, se llama Unfair Advantage o “Ventaja Injusta”.
    Imagínate que un competidor lanza un producto o servicio similar y a un precio mucho mas económico que el tuyo. En ese caso, ¿Podrías mantener el negocio?
    Una ventaja injusta es una ventaja de tu producto/servicio tan grande que por mas que te copien no vas a correr peligro porque esa ventaja va a permitir ser mejor que la competencia, por eso se le dice “injusta”.
    Un ejemplo de ventaja injusta en la industria del software sería que Google saque una nueva herramienta de Oficina y la asocie a Google Drive. En ese caso va a tener una ventaja injusta con respecto a otra empresa que saque una herramienta similar ya que Google cuenta con todos los usuarios actuales de Drive que tendrían la nueva herramienta al alcance de la mano.

  46. Algo que me parece importante es la diferencia entre PULL y PUSH. LEAN se basa en PULL: Su estrategia es producir sólo la cantidad necesaria de producto según la demanda del mercado para rentabilizar la producción y evitar desperdicios.

    “La metodología Push en una planta se refiere cuando el proceso de producción elabora producto terminado o en proceso y lo sigue produciendo sin importar si el siguiente proceso lo necesita o tiene la capacidad para su respectivo consumo.”

    “El sistema Pull es diferente en varios aspectos, por ejemplo: El sistema incentiva en fabricar los productos únicamente requeridos y en la cantidad justa para la siguiente etapa de manufactura. Pull system no utiliza una demanda para su producción, utiliza el mismo pedido del cliente para saber que producir. Por ende podemos decir que las ordenes nos dice cuanto producir y que producir.”

    Referencia: http://www.manufacturainteligente.com/push-and-pull-system-lean-manufacturing/

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: