Source: https://proyectosii.wordpress.com/2015/11/12/actividad-p1-lean-y-kanban-que-nos-perdimos/
Timestamp: 2018-01-17 05:14:04+00:00

Document:
Actividad P1 – Lean y Kanban – ¿Qué nos perdimos? | Administración y Control de Proyectos II
Inicio › Sin categoría › Actividad P1 – Lean y Kanban – ¿Qué nos perdimos?
Actividad P1 – Lean y Kanban – ¿Qué nos perdimos?
Posted on 12 noviembre, 2015 by jgabardini — 46 comentarios
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á.
‹ Actividad P0 – Kanban by Ezequiel 15 Oct – Asistencia
Actividad Q0 – Retrospectivas by Rodrigo 29 Oct – Asistencia ›
46 comments on “Actividad P1 – Lean y Kanban – ¿Qué nos perdimos?”
12 noviembre, 2015 en 22:53
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.
13 noviembre, 2015 en 12:01
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.
Maximiliano Schultheis dice:
13 noviembre, 2015 en 16:21
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.
De esta forma uno está en constante movimiento, alineándose con la ideología de la mejora contínua.
13 noviembre, 2015 en 16:32
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.
Lucas Simonelli dice:
14 noviembre, 2015 en 19:07
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.
Nicolás Ortoleva dice:
14 noviembre, 2015 en 19:29
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.
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.
19 noviembre, 2015 en 14:25
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.
19 noviembre, 2015 en 20:48
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.
20 noviembre, 2015 en 12:53
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.
22 noviembre, 2015 en 1:59
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.
22 noviembre, 2015 en 11:46
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.
22 noviembre, 2015 en 12:39
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…)
Maximiliano Roitman dice:
22 noviembre, 2015 en 17:07
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
Jennifer Woites dice:
23 noviembre, 2015 en 0:29
Una de las ideas de LEAN que me gustó es:
* 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.
23 noviembre, 2015 en 20:46
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.
24 noviembre, 2015 en 1:55
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).
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
25 noviembre, 2015 en 13:33
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.
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.
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.
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.
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.
25 noviembre, 2015 en 17:37
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.
27 noviembre, 2015 en 14:25
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.
27 noviembre, 2015 en 18:04
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.
28 noviembre, 2015 en 4:02
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.
Nicolas Javier Pantazis dice:
29 noviembre, 2015 en 11:05
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.
29 noviembre, 2015 en 20:32
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.
30 noviembre, 2015 en 3:44
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.
Agustín Rojas dice:
2 diciembre, 2015 en 0:37
Un principio que me parecío interesante de destacar. Fue el siguiente
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
Donde en este principio se destaca la importancia que se le da desde Lean al factor humano para poder lograr un buen producto
3 diciembre, 2015 en 14:52
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.
4 diciembre, 2015 en 21:10
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.
5 diciembre, 2015 en 11:20
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.
-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.
Damián Arias dice:
5 diciembre, 2015 en 19:17
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.
9 diciembre, 2015 en 2:14
“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/
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.
14 noviembre, 2016 en 15:53
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.
16 noviembre, 2016 en 16:22
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.
16 noviembre, 2016 en 17:39
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
17 noviembre, 2016 en 1:11
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.
17 noviembre, 2016 en 13:36
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.
20 noviembre, 2016 en 18:12
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.
25 noviembre, 2016 en 13:30
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.
1 diciembre, 2016 en 10:49
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.
Luis arancibia dice:
3 diciembre, 2016 en 3:07
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.
3 diciembre, 2016 en 17:09
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.
4 diciembre, 2016 en 18:21
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
5 diciembre, 2016 en 0:02
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.
Ezequiel Paez dice:
5 diciembre, 2016 en 3:23
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/

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución