IND611 - GP - Sesión 06.pdf

SESIÓN 06
Gestión de Proyectos
Gestión de Calidad & Lean Kanban
© Luciano Silva Alarco, 2020.
Curso de Maestría en Ingeniería Industrial. Gestión de Proyectos.
Material de enseñanza. Lima: Pontificia Universidad Católica del Perú.

3
Profesor: Luciano Silva Alarco
• Comprender la importancia de la gestión de calidad (predictiva) de
proyectos para productos y servicios.
• Definir la gestión de la calidad del proyecto y comprender cómo la
calidad se relaciona con diversos aspectos de éste.
• Describir la planificación de gestión de calidad y cómo se
relacionan la gestión de calidad y el alcance.
• Discutir la importancia del aseguramiento de la calidad.
• Explicar los principales resultados del proceso de control de
calidad.
Objetivos de Aprendizaje

4
• Comprender las herramientas y técnicas para el control de calidad,
como las Siete herramientas básicas de calidad, muestreo estadístico,
Six Sigma y pruebas.
• Resumir las contribuciones de los expertos en calidad a la gestión de
calidad moderna (historia de la calidad).
• Describir cómo el liderazgo, el costo de la calidad, las influencias
organizacionales, las expectativas, las diferencias culturales y los
modelos de madurez se relacionan con la mejora de la calidad en los
proyectos.
Objetivos de Aprendizaje

5
• Ejemplo: Mucha gente bromea sobre la mala calidad
de los productos de TI.
• La gente parece aceptar sistemas que están caídos de
vez en cuando o que necesitan reiniciar sus PC.
• Pero la calidad es muy importante en todo proyecto.
La Importancia de la Gestión de Calidad del
Proyecto

6
• La Organización Internacional de Normalización (ISO) define
la calidad como "el grado en que un conjunto de
características inherentes cumple con los requisitos"
(ISO9000: 2000).
• Otros expertos definen la calidad en función de:
Conformidad con los requisitos: los procesos y productos del
proyecto cumplen con las especificaciones escritas.
Aptitud para el uso: un producto se puede usar como se pretendía.
¿Qué es la Calidad del Proyecto?

7
• La gestión de la calidad del proyecto asegura que el proyecto
satisfaga las necesidades para las que se realizó.
• Los procesos incluyen:
Planificación de la gestión de calidad: identificación de los estándares de
calidad relevantes para el proyecto y cómo satisfacerlos; una métrica es un
estándar de medición.
Realizar el aseguramiento de calidad: evaluar periódicamente el rendimiento
general del proyecto para garantizar que éste satisfaga los estándares de
calidad relevantes.
Realizar control de calidad: monitorear resultados específicos del proyecto
para asegurar que cumplan con los estándares de calidad relevantes.
¿Qué es la Gestión de Calidad del Proyecto?

8
• Implica la capacidad de anticipar situaciones y
preparar acciones para lograr el resultado deseado.
• Importante para prevenir defectos:
Seleccionar materiales adecuados.
Entrenar y capacitar personas en calidad.
Planificar un proceso que asegure el resultado apropiado.
Planificación de la Calidad

9
• La funcionalidad es el grado en que un servicio realiza su función prevista.
• Los atributos son las características especiales del servicio que atraen a los
usuarios.
• El rendimiento trata sobre qué tan bien un producto o servicio realiza el uso
previsto por el cliente.
• La fiabilidad es la capacidad de un producto o servicio para funcionar como
se espera en condiciones normales.
• La capacidad de mantenimiento trata sobre la facilidad de realizar el
mantenimiento de un producto.
• Las salidas del sistema son las pantallas y los informes que el sistema genera.
Relación Alcance-Calidad

10
• Los gerentes de proyecto son los responsables últimos de la
gestión de la calidad en sus proyectos.
• Varias organizaciones y referencias pueden ayudar a los
gerentes de proyectos y sus equipos a entender y gestionar la
calidad.
Organización Internacional de Normalización (ISO) (www.iso.org)
Institute of Electrical and Electronics Engineers (IEEE)
(www.ieee.org)
¿Quién es Responsable de la Calidad de los
Proyectos?

11
• El aseguramiento de calidad incluye todas las actividades relacionadas con la satisfacción de
los estándares de calidad relevantes para un proyecto.
• Otro objetivo del aseguramiento de la calidad es la mejora continua de la calidad. Kaizen es
la palabra japonesa para mejorar o cambiar para mejor.
• Lean implica evaluar los procesos para maximizar el valor del cliente mientras se minimiza el
desperdicio.
• El Benchmarking (evaluación comparativa) genera ideas para mejoras de calidad al
comparar prácticas de proyectos específicos o características de productos con los de otros
proyectos o productos dentro o fuera de la organización ejecutante.
• Una auditoría de calidad es una revisión estructurada de actividades específicas de gestión
de la calidad que ayudan a identificar las lecciones aprendidas que podrían mejorar el
rendimiento en proyectos actuales o futuros.
Realizar Aseguramiento de Calidad

12
• Las principales salidas del control de calidad son:
Decisiones de aceptación.
Retrabajo.
Ajustes de proceso.
• Hay siete herramientas básicas de calidad que
ayudan a realizar el control de calidad.
Control de Calidad

13
• Diagramas de causa y efecto rastrean quejas sobre problemas de
calidad hasta las operaciones responsables.
• Ayudan a encontrar la causa raíz de un problema.
• También conocido como espina de pescado o diagramas
Ishikawa.
• También se puede usar la técnica de los 5 “por qué” donde se
repite la pregunta "¿Por qué?" (Cinco es una buena regla general)
para despegar las capas de síntomas que pueden conducir a la
causa raíz.
Diagramas de Causa y Efecto

14
Ejemplo: Diagrama Causa-Efecto

15
• Un gráfico de control es una visualización gráfica de datos que ilustra los
resultados de un proceso a lo largo del tiempo.
• El uso principal de los gráficos de control es para prevenir defectos, en lugar
de detectarlos o rechazarlos.
• Los diagramas de control de calidad le permiten determinar si un proceso está
bajo control o fuera de control:
Cuando un proceso está bajo control, cualquier variación en los resultados del proceso es
creada por eventos aleatorios; los procesos que están bajo control no necesitan ser
ajustados.
Cuando un proceso está fuera de control, las variaciones en los resultados del proceso son
causadas por eventos no aleatorios; se necesita identificar las causas de esos eventos y
ajustar el proceso para corregirlos o eliminarlos.
Gráficos de Control de Calidad

16
• Se puede usar gráficos de control de calidad y la regla
de siete corridas para buscar patrones en los datos.
• La regla de siete corridas establece que si siete puntos
de datos en una fila están todos por debajo de la
media, por encima de la media, o todos están
aumentando o disminuyendo, entonces el proceso
debe examinarse para detectar problemas no
aleatorios.
La Regla de las Siete Corridas

17
Ejemplo: Gráfica de Control

18
• Se usa una hoja de verificación para recopilar y analizar datos
(número de incidencias).
• A veces se denomina hoja de conteo o lista de verificación,
dependiendo de su formato.
• En el ejemplo (a continuación), la mayoría de las quejas llegan
por mensaje de texto, y hay más quejas el lunes y el martes
que en otros días de la semana.
• Esta información puede ser útil para mejorar el proceso de
manejo de quejas.
Hoja de Control

19
Ejemplo: Número de Incidencias

20
• Un diagrama de dispersión ayuda a mostrar si existe una
relación entre dos variables.
• Cuanto más cerca estén los puntos de datos de una línea
diagonal, más se relacionarán las dos variables.
Diagrama de Dispersión

21
Ejemplo: Diagrama de Dispersión

22
• Un histograma es un gráfico de barras de una distribución
de variables.
• Cada barra representa un atributo o característica de un
problema o situación, y la altura de la barra representa su
frecuencia.
Histogramas

23
Ejemplo: Histograma

24
• Un diagrama de Pareto es un histograma que puede
ayudar a identificar y priorizar áreas problemáticas
(ordenado por tamaño).
• El análisis de Pareto también se conoce como la regla 80-
20, lo que significa que el 80 por ciento de los problemas a
menudo se deben al 20 por ciento de las causas.
Gráficos de Pareto

25
Ejemplo: Gráfico de Pareto

26
• Los diagramas de flujo son visualizaciones gráficas de la
lógica y el flujo de procesos que ayudan a analizar cómo
ocurren los problemas y cómo se pueden mejorar los
procesos.
• Muestran actividades, puntos de decisión y el orden de
cómo se procesa la información.
Diagramas de Flujo

27
Ejemplo: Diagramas de Flujo

28
• Además de los diagramas de flujo, los gráficos de ejecución
también se utilizan para la estratificación, una técnica que
muestra datos de una variedad de fuentes para ver si surge un
patrón.
• Un gráfico de ejecución muestra el historial y el patrón de
variación de un proceso a lo largo del tiempo.
• Se pueden utilizar los gráficos de ejecución para realizar análisis
de tendencias y pronosticar los resultados futuros en función de
los resultados históricos.
Gráficos de Ejecución

29
Ejemplo: Gráfico de Ejecución

30
• El muestreo estadístico implica elegir parte de una población
de interés para la inspección.
• El tamaño de una muestra depende de qué tan representativa
se requiera que esta sea.
• Fórmula de tamaño de muestra (aproximada):
• Asegurar de consultar con un experto cuando se usen análisis
estadísticos.
Muestreo Estadístico
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑑𝑑𝑑𝑑 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = 0.25 ×
𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑑𝑑𝑑𝑑 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐
𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎
2

31
Factores de Confianza Usados con Frecuencia

32
• Six Sigma es “un sistema completo y flexible para lograr,
mantener y maximizar el éxito empresarial. Six Sigma se basa
exclusivamente en la comprensión profunda de las necesidades
del cliente, el uso disciplinado de los datos, el análisis estadístico,
y una atención diligente a la gestión, mejora y reinvención de los
procesos comerciales” *
Six Sigma
*Pande, Peter S., Robert P. Neuman, and Roland R. Cavanagh, The Six Sigma Way, 2000.

33
• El objetivo para la perfección es el logro de no más de 3.4
defectos por millón de oportunidades.
• Los principios pueden aplicarse a una amplia variedad de
procesos.
• Los proyectos Six Sigma normalmente siguen un proceso
de mejora de cinco fases llamado DMAIC.
• Define – Measure – Analyze – Improve – Control
Información Básica sobre Six Sigma

34
• DMAIC es un proceso sistemático y de ciclo cerrado para la mejora
continua basada en hechos científicos.
• DMAIC significa:
Definir: definir el problema / oportunidad, el proceso y los requisitos del
cliente.
Medir: definir medidas, luego recopilar, compilar y visualizar datos.
Analizar: analizar detalles del proceso para encontrar oportunidades de
mejora.
Mejorar: generar soluciones e ideas para mejorar el problema.
Control: rastrear y verificar la estabilidad de las mejoras y la previsibilidad de
la solución.
DMAIC

35
• Requiere un compromiso de toda la organización.
• La capacitación sigue el sistema “Belt”.
• Las organizaciones Six Sigma tienen la capacidad y la voluntad de
adoptar objetivos contrarios, como reducir los errores y hacer las
cosas más rápido.
• Es una filosofía operativa que se centra en los clientes y se
esfuerza por eliminar el desperdicio, aumentar los niveles de
calidad y mejorar el rendimiento financiero a niveles
innovadores.
¿Cómo es el Control de Calidad Six Sigma?

36
• Joseph M. Juran dijo: “Toda mejora se lleva a cabo, proyecto por proyecto, y de
ninguna otra manera.” *
• Es importante seleccionar proyectos cuidadosamente y aplicar mayor calidad
donde tenga sentido; las empresas que usan Six Sigma no siempre aumentan sus
valores de inventario.
• Como dice Mikel Harry, “podría diseñar genéticamente una cabra Six Sigma, pero
si el mercado es un rodeo, la gente va a comprar un caballo de cuatro Sigma”. **
• Los proyectos Six Sigma deben enfocarse en un problema de calidad o brecha entre
el rendimiento actual y el deseado y no tener un problema claramente entendido
o una solución predeterminada.
Six Sigma y Gestión de Proyectos
*“What You Need to Know About Six Sigma,” Productivity Digest (December 2001), p. 38.
**Clifford, Lee, “Why You Can Safely Ignore Six Sigma,” Fortune (January 22, 2001), p. 140.

37
• La capacitación para Six Sigma incluye muchos conceptos,
herramientas y técnicas de administración de proyectos.
• Por ejemplo, los proyectos de Six Sigma a menudo usan casos
de negocios, Project Charters, cronogramas, presupuestos, etc.
• Los proyectos Six Sigma se realizan en equipos; el gerente de
proyecto generalmente se le llama líder del equipo, y el
patrocinador se le llama el campeón.
Los Proyectos Six Sigma Usan Gestión de
Proyectos

38
• El término sigma significa desviación estándar.
• La desviación estándar mide la cantidad de variación que
existe en una distribución de datos.
• La desviación estándar es un factor clave para determinar el
número aceptable de unidades defectuosas encontradas en
una población.
• Los proyectos Six Sigma luchan por no más de 3.4 defectos por
millón de oportunidades, sin embargo, este número es confuso
para muchos estadísticos.
Six Sigma y Estadísticas

39
• Usando una curva normal, si un proceso está en seis sigma, no habría más de
dos unidades defectuosas por billón (americano) producido.
• Six Sigma utiliza un sistema de puntuación que representa el tiempo, un
factor importante para determinar las variaciones del proceso.
• El rendimiento representa el número de unidades manejadas correctamente
a través de los pasos del proceso.
• Un defecto es cualquier instancia donde el producto o servicio no cumple
con los requisitos del cliente.
• Puede haber varias oportunidades para cometer un defecto.
Six Sigma Usa una Tabla de Conversión

40
Distribución Normal y Desviación Estándar

41
Sigma y Unidades Defectuosas

42
Tabla de Conversión Sigma
https://planetcalc.com/4986/
Se castiga con ± 1.5 σ

43
• Los seis 9s de calidad son una medida de control de calidad
igual a 1 falla en 1 millón de oportunidades.
• En la industria de las telecomunicaciones, significa 99.9999 %
de disponibilidad de servicio ó 30 segundos de tiempo de
caída al año.
• Este nivel de calidad también se ha establecido como objetivo
de la cantidad de errores en un circuito de comunicaciones,
fallas del sistema o errores en las líneas de código.
Los Seis 9s de la Calidad

44
• Muchos profesionales piensan en las pruebas como una
etapa que se acerca al final del desarrollo o
implementación del productos o servicio.
• Las pruebas deben realizarse durante todas las fases del
ciclo de vida del producto y del proyecto.
Pruebas

45
Tareas de Prueba
en el Ciclo de Vida
de Desarrollo de
Software

46
• En la prueba unitaria se prueba cada componente individual (puede
ser un módulo) para garantizar que esté lo más libre de defectos
posible.
• Se realizan pruebas de integración entre la unidad y las pruebas del
sistema para probar componentes funcionalmente integrados.
• La prueba del sistema prueba todo el sistema como una sola
entidad.
• La prueba de aceptación del usuario es una prueba independiente
realizada por los usuarios finales antes de aceptar el sistema
entregado.
Tipos de Pruebas

47
• Watts S. Humphrey, un reconocido experto en calidad de software, define un
defecto de software como algo que debe cambiarse antes de la entrega del
programa.
• Las pruebas no previenen los defectos del software porque:
La cantidad de formas de probar un sistema complejo es enorme.
Los usuarios continuarán inventando nuevas formas de utilizar un sistema que sus
desarrolladores nunca consideraron.
• Humphrey sugiere que las personas reconsideren el proceso de desarrollo de
software para no presentar posibles defectos cuando ingrese a las pruebas del
sistema; los desarrolladores deben ser responsables de proporcionar código
libre de errores en cada etapa de prueba.
La Prueba Sola No Es Suficiente

48
• Gestión de calidad moderna:
Requiere la satisfacción del cliente.
Prefiere la prevención a la inspección.
Reconoce la responsabilidad de la gestión por la calidad.
• Los expertos en calidad dignos de mención incluyen:
Deming, Juran, Crosby, Ishikawa, Taguchi y Feigenbaum.
Gestión de Calidad Moderna

49
Deming fue famoso por su trabajo en la reconstrucción de Japón y sus 14 puntos para
la gestión.
Juran escribió el Manual de Control de Calidad y 10 pasos para la mejora de la calidad.
Crosby escribió La Calidad es Gratuita y sugirió que las organizaciones luchan por cero
defectos.
Ishikawa desarrolló los conceptos de círculos de calidad y diagramas de espina de
pescado.
Taguchi desarrolló métodos para optimizar el proceso de experimentación de
ingeniería.
Feigenbaum desarrolló el concepto de control de calidad total (TQC).
Expertos en Calidad

50
• El Premio Nacional de Calidad Malcolm Baldrige se originó en 1987 para
reconocer a las empresas que han alcanzado un nivel de competencia de clase
mundial a través de la gestión de la calidad.
• Dado por el Presidente de los Estados Unidos a las empresas de EE. UU.
• Tres premios cada año en diferentes categorías:
Fabricación
Servicio
Pequeños negocios
Educación y cuidado de la salud
Ganadores 2019:
https://www.nist.gov/news-events/news/2019/11/six-health-care-nonprofit-and-education-organizations-
win-baldrige-awards
Premio Malcolm Baldrige

51
• ISO 9000 es un estándar de sistema de calidad que:
Es un ciclo continuo de tres partes para planear, controlar y
documentar la calidad en una organización.
Proporciona los requisitos mínimos necesarios para que una
organización cumpla con sus estándares de certificación de calidad.
Ayuda a organizaciones de todo el mundo a reducir costos y mejorar la
satisfacción del cliente.
• Visitar: www.iso.org para más información.
Estándares ISO

52
• Varias sugerencias para mejorar la calidad de los proyectos
incluyen:
1. Establecer un liderazgo que promueva la calidad.
2. Comprender el costo de la calidad.
3. Enfocarse en las influencias organizacionales y los factores del
lugar de trabajo que afectan la calidad.
4. Seguir los modelos de madurez.
Mejorar la Calidad de Proyectos

53
• Como dijo Joseph M. Juran en 1945: “Es muy importante que
la alta dirección tenga una mentalidad de calidad. En ausencia
de una manifestación sincera de interés en la parte superior,
poco sucederá debajo” *
• Un gran porcentaje de problemas de calidad están asociados
a la gestión, no a problemas técnicos.
Liderazgo
*American Society for Quality (ASQ), (www.asqc.org/about/history/juran.html).

54
• El costo de la calidad es el costo de la conformidad más el costo de la
no conformidad.
Conformidad significa entregar productos que cumplen con los requisitos y la
aptitud para el uso.
El costo de no conformidad significa tomar responsabilidad por fallas o no
cumplir con las expectativas de calidad.
• Un estudio informó que los errores de software le cuestan a la
economía de EE. UU. $ 59.6 mil millones cada año y que un tercio de
los errores podría eliminarse mediante una infraestructura de prueba
mejorada.
El Costo de la Calidad

55
• Costo de prevención: el costo de planificar y ejecutar un proyecto para que
esté libre de errores o dentro de un rango de error aceptable.
• Costo de la evaluación: costo de evaluar los procesos y sus productos para
garantizar la calidad.
• Costo de falla interna: costo incurrido para corregir un defecto identificado
antes de que el cliente reciba el producto.
• Costo de falla externa: costo que se relaciona con todos los errores no
detectados y no corregidos antes de la entrega al cliente.
• Costos del equipo de medición y prueba: costo de capital del equipo
utilizado para realizar actividades de prevención y evaluación.
Cinco Conceptos de Costos Relacionados con la
Calidad

56
• Los virus informáticos y el software malicioso han sido una
preocupación de calidad durante años.
• En un nuevo giro, los consumidores ahora están siendo advertidos de
que los cigarrillos electrónicos pueden ser malos para las
computadoras.
• Cualquier cosa puede infectar tu computadora si se puede insertar en
un puerto USB.
• Otros productos de consumo como los televisores inteligentes pueden
invadir la privacidad.
Actualidad

57
• El estudio de DeMarco y Lister mostró que los problemas organizacionales
tenían una influencia mucho mayor en la productividad del programador
que el entorno técnico o los lenguajes de programación.
• La productividad del programador varió en un factor de uno a diez entre
todas las organizaciones, pero solo en un 21 % dentro de la misma
organización.
• El estudio no encontró correlación entre la productividad y el lenguaje de
programación, los años de experiencia o el salario.
• Un espacio de trabajo dedicado y un entorno de trabajo silencioso fueron
factores clave para mejorar la productividad del programador.
Influencias Organizacionales, Factores de
Lugar de Trabajo y Calidad

58
• Los gerentes de proyecto deben comprender y gestionar las
expectativas de las partes interesadas.
• Las expectativas también varían según:
Cultura de la organización.
Regiones geográficas.
Expectativas y Diferencias Culturales en la
Calidad

59
• Los modelos de madurez son marcos para ayudar a las
organizaciones a mejorar sus procesos y sistemas.
El modelo de implementación de la función de calidad se centra
en la definición de los requisitos del cliente y la planificación de
proyectos.
La integración del modelo de madurez de capacidades del
Instituto de Ingeniería es un enfoque de mejora de procesos que
proporciona a las organizaciones los elementos esenciales de
procesos efectivos.
Modelos de Madurez

60
• Los niveles de CMMI, de menor a mayor, son:
Incompleto
Realizado
Administrado
Definido
Gestionado cuantitativamente
Optimizando
• Es posible que las empresas no puedan presentar ofertas en
proyectos del gobierno a menos que tengan un Nivel 3 de CMMI.
Niveles de CMMI

61
• PMI lanzó el Modelo de Madurez de Gestión de Proyectos
Organizacionales (OPM3) en diciembre de 2003.
• El modelo se basa en encuestas de investigación de mercado enviadas
a más de 30,000 profesionales de gestión de proyectos e incorpora
180 mejores prácticas y más de 2,400 capacidades, resultados e
indicadores clave de rendimiento.
• Aborda los estándares de excelencia en las mejores prácticas de
administración de proyectos, programas y portafolios y explica las
capacidades necesarias para lograr esas mejores prácticas.
Modelo de Madurez del PMI

62
• OPM3 proporciona ejemplos para ilustrar una mejor práctica,
capacidad, resultado e indicador de rendimiento clave:
Buenas prácticas: establecer comunidades internas de gestión de proyectos.
Capacidad: facilitar las actividades de gestión de proyectos.
Resultado: iniciativas locales, lo que significa que la organización desarrolle
focos de consenso en torno a áreas de interés.
Indicador de rendimiento clave: la comunidad aborda problemas locales.
Best Practice

63
• La gestión de la calidad del proyecto garantiza que el proyecto
satisfaga las necesidades para las que se realizó.
• Los principales procesos incluyen:
Planificar la Calidad
Realizar el aseguramiento de la Calidad
Realizar el control de calidad
Resumen

64
Planificación Ágil
Lean Kanban

65
Lean Kanban
1. Visión general de Lean Agile.
2. Visión general del método Kanban.
3. Estudio de caso.

66
Lean Thinking
Los principios ágiles se originan en
el enfoque del lean manufacturing,
también conocido como
“producción just-in-time”, iniciado
por Toyota, que transformó el
enfoque del fabricante de
automóviles para la fabricación de
vehículos.
La “Casa" Lean que se muestra aquí
representa los elementos de un
sistema de apoyo.

67
Lean Thinking

68
Entrega de Valor en Semanas Versus Meses
VS
En Proyectos Tradicionales:
• El valor solo se entrega al final
de la última fase del proyecto
• El valor real no puede
reconocerse durante la mayor
parte del proceso de desarrollo.
• El valor máximo se alcanza en el
lanzamiento del producto
Meses
En Proyectos Agile:
• Cada iteración ofrece una funcionalidad
incremental destinada a reflejar
continuamente la dirección elegida por el
cliente (dueño del producto).
• El cliente se da cuenta del valor tan pronto
como se completa la primera iteración.
• La integración frecuente al final de cada
iteración asegura la calidad del producto al
principio del ciclo de vida del producto.
Semanas

69
La Triple Restricción

70
Lean Thinking

71
Maestría
• Mejorar las habilidades y la competencia.
• Dominar los métodos y pensar Agile de forma
natural.
Autonomía
• Establecer metas.
• Creer en la competitividad y la confianza.
Propósito
• Cómo el empleado a través de la organización
hace del mundo un lugar mejor.
Respecto por las Personas
• La cultura fomenta la
mejora, el dominio
continuo y el
crecimiento.
• Coordinación centralizada.
• Control descentralizado.
• Equipos autodirigidos y
autoorganizados.
• Uno necesita sentir que su
trabajo tiene un significado.
• Emocionado salir a trabajar
cada mañana y pertenecer a
un equipo con una misión
que importa.

72
Lean Thinking

73
Profesor: Luciano Silva Alarco 10
Siete Principios de Desarrollo De Software Lean
1. Eliminar los desperdicios.
2. Amplificar el aprendizaje.
3. Compromiso con las
demora.
4. Entregar rápido.
5. Empoderar al equipo.
6. Construir con calidad.
7. Optimizar el conjunto.

74
Lean Thinking

75
Kaizen

76
La “Iteración” construye un “Incremento” del producto, se verifica y se
valida, luego lentamente se va construyendo la calidad entregando
“Valor” de manera incremental.
Construir para
algunos requisitos
Conjunto inicial de requisitos,
input a la primera iteración.
Incremento
en el
producto
V
A
L
O
R
V
A
L
O
R
V
A
L
O
R
Mejora Continua del Producto
Incremento
en el
producto
Incremento
en el
producto
Construir para
algunos requisitos
Construir para
algunos requisitos

77
Lean Thinking

78
8 Principios de Liderazgo Agile y Lean
Lean
Agile
Principios
1
2
3
4
5
6
7
8
Construir equipos de alto
rendimiento
Implementar el flujo de
desarrollo de software
Desbloquear la motivación intrínseca de
los trabajadores.
Adoptar una visión económica
de toda la cadena de valor.
Adoptar el Manifiesto Ágil
Desarrollar a las personas, no a
las cosas
Poseer el sistema del que hablas.
Descentralizar el control

79
El Método Kanban
http://net1.ist.psu.edu/chu/wcm/vc/toyota1.gif
Kanban es una palabra
japonesa que literalmente
significa tarjeta de signos o
tablero de signos.

80
Prácticas Básicas para una Adopción Exitosa
1. Visualizar.
2. Limitar el trabajo en curso.
3. Manejar el flujo.
4. Hacer que las políticas sean
explícitas.
5. Implementar los bucles de
retroalimentación.
6. Mejorar en colaboración,
evolucionar experimentalmente
(utilizando modelos y métodos
científicos).

81
Visualizar

82
¿Qué es la Gestión Visual?
• La información se comunica
mediante el uso de señales
visuales en lugar de textos u
otras instrucciones escritas.
• El diseño está pensado para
permitir un reconocimiento
rápido de la información
que se comunica, a fin de
aumentar la eficiencia y la
claridad.

83
No Es lo Mismo

84
No Es lo Mismo

85
No Es lo Mismo

86
No Es lo Mismo

87
No Es lo Mismo

88
Task Status
Acceptance Criteria Samples Ongoing
Gantt Plan Samples Ongoing
Status Report A6 Template Pending
Role Information Updated Pending
Risk A6 Template Ongoing
Risk Samples Done
Initiative Form Fulfilled Pending
Core Exercise Decided Ongoing
Review Team Deliverables Done
Requisite Sample Template Ongoing
No Es lo Mismo

89
Pending Ongoing Done
No Es lo Mismo

90
To Do Done
Doing
No Es lo Mismo

91
Done
Release
Ready
Stage Prod.
Doing Done
Development
Analysis
6
Input
Queue
4 3
Dev
Ready Doing
4 2 2
Build Test
Ready
Legend:
No Es lo Mismo

92
Limitar el WIP

93
Cada actividad sólo puede tener un
número limitado de elementos de
trabajo
Los artículos de trabajo son llevados al
siguiente estado solo cuando hay
espacio.
Limitar el WIP

94
Políticas
Hacer que las Políticas Sean Explícitas

95
Muestra de un Kanban Board

96
• El Lead Time mide la tasa de llegada. El reloj del Lead Time
comienza cuando se hace la solicitud y termina en la entrega.
El Lead Time es lo que el cliente ve.
• El Lead Time se mide por el tiempo transcurrido (minutos,
horas, etc.).
* Wikipedia
Ticket
Emitido
Lead Time
Manejar el Flujo – Lead Time

97
• El Tiempo de Ciclo mide la tasa de finalización.
• El reloj del Tiempo de Ciclo comienza cuando se empieza el trabajo y se termina
cuando el ítem está listo para su entrega.
• WIP = 100 elementos de trabajo en progreso
• Rendimiento = 2 artículos de trabajo por semana
• Tiempo de ciclo = 100 / 2 = 50 semanas
Esto significa que el tiempo del ciclo para acabar con todo este WIP va a ser
de 50 semanas, o aproximadamente un año.
Ticket
Terminado
Ticket
Emitido
Empieza el
Trabajo
Tiempo de Cilco
Manejar el Flujo – Lead Time

98
• El reloj del Lead Time comienza cuando se hace la solicitud y termina en
la entrega.
• El reloj del Tiempo de Ciclo comienza cuando se empieza a trabajar en
el pedido y termina cuando el artículo está listo para ser entregado.
Ticket
Terminado
Ticket
Emitido
Empieza el
Trabajo
Lead Time
Tiempo de Ciclo
Resumen - Lead Time y Tiempo de Ciclo

99
Implementar los Bucles de
Retroalimentación

100
Reuniones de Kanban y Bucles de
Retroalimentación

101
Mejorar la Colaboración y Evolucionar
A
B

102
Experimento del Equipo de Infraestructura Kanban
• Este ejemplo de la vida real abarca la forma en que un grupo de infraestructura
recientemente formado aplicó un híbrido de Lean Agile y Kanban dentro de una
corporación multinacional estadounidense que se dedica al diseño, desarrollo,
fabricación y comercialización y venta a nivel mundial de calzado, prendas de
vestir, equipos, accesorios y servicios.
• Este equipo fue parte de un programa estratégico de tres años de 700.000 dólares
que permitió a la Compañía ABC crear, transformar y liderar el mercado con nuevas
habilidades organizativas, procesos y herramientas.
Desde Hasta
Enfoque funcional de ventas. Soluciones empresariales.
Arreglos independientes. Entorno integrado de personas,
procesos y tecnología.
Herramientas de Ventas Inestables 1.0. Ecosistema robusto de ventas 2.0.

103
Setup, Soporte y Mantenimiento de un
Entorno de Integración Continua
Local
Workstation
DEV QA STAGE PROD
Purpose
Design & Code
Purpose
Support
Development
This is the
Team Integration
Environment
Purpose
System Testing
1st testing outside
of Dev. Team
Demos
Purpose
Final Qualification
in PROD-like
environment
Purpose
Live & accessible
to End Users
Generate Sales
Gate to DEV
• Commit to
Source Control
• Compile
• Unit Test
• Analysis (Sonar)
• Component Test
• Package
• Deployment and
Configuration
Automation
Gate to QA
• Automated
Functional Test
(eg. Sauce)
Gate to STAGE
• Manual
AcceptanceTest
• Manual PCI
scans
Gate to PROD
• Automated
Performance
Test
• Auto. Security
Test (PCI
Compliance)
• UAT
• PMO/Release
Man. Approval
• Business
Approval
Go live criteria
• Technical
Validation
• Business
Validation

104
Su Realidad - La Mayoría de su Trabajo Es Impulsado por
Eventos
Russell: How are things going now that you are being agile and using Scrum?
Carol: On this Program we’ve finally gone all-out being Agile and Scrum!
Russell: So how’s it going?
Carol: Well, it’s a lot better overall than what we had before...
Russell: ...but?
Carol: ... but we are a support & maintenance team. Russell: yes,
and?
Carol: Well, we love the whole thing about setting priorities in a product backlog,self- organizing
teams, daily scrums, retrospectives, etc....
Russell: So what’s the problem?
Carol: We keep failing our sprints.
Russell: Why?
Carol: Because we find it hard to commit to a 2 week plan. Sprints don’t make too much sense to us,
we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?
Russell: Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1
week?

105
Carol: Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints...
Russell: Do your issues take less than a day to fix?
Carol: No, they sometimes take several days.
Russell: So 1-day sprints wouldn’t work either. Have you considered ditching sprints
entirely?
Carol: Well, frankly, we would like that. But isn’t that against Scrum?
Russell: One size does not fit all. You choose when and how to be agile or useScrum.
Carol: So what should we do then?
Russell: Have you heard of Lean Software Development and the Kanban Method?
Carol: What’s that? What’s the difference between that and Scrum? And I really like the rest of
Scrum though, do I have to switch now?
Russell: No, you can combine the techniques! Lets collaborate on how.
Carol: Great where do we start?
Su Realidad - La Mayoría de su Trabajo Es Impulsado por
Eventos

106
•Experimentar con un proceso que se ajuste mejor a
nuestra mezcla de trabajo planificado y no planificado
(impulsado por eventos).
•Una mejor visibilidad de lo que el equipo está haciendo
y necesita hacer a continuación.
•Ver si los límites de trabajo en proceso del Kanban
ayudarán a mejorar la efectividad del equipo.
•Ver si la medición y optimización del tiempo del ciclo
ayudará a mejorar nuestra eficacia.
La Meta

107
• Backlog: El dueño del producto tiene 8 cosas para que el equipo se ocupe. Max = 8 Min = 3. Este estado
nunca debería agotarse.
• Ready: Historias preparadas para ser trabajadas. Max = 8 Min = 3
• Pending External Dependency: Bloqueado debido a la dependencia de un ticket, reunión, información, etc.
• Done: No hay límite.
• Accepted: Una celebración del trabajo recientemente terminado. Desaparece cada dos semanas.
• Expedite: Las emergencias (tarjetas amarillas) - pueden exceder los límites del WIP.
Corte Inicial: Infraestructura del Kanban Board
Backlog
(3-8)
Ready
(Tasked)
(3-8)
Pending
External
Dependency
(8)
In Progress
(6)
Done Accepted
Expedir

108
• Cuando estás disponible pero se alcanza el límite de WIP, en lugar de empezar algo,
¿puedes colaborar para que se haga algo?
 Si no, consulta con el resto del equipo y luego sigue adelante y excede el límite de WIP si esa
es la única manera de hacer un trabajo valioso. Esperamos que eso sea raro.
• Si identificas la necesidad de emitir un ticket, organizar una reunión, solicitar información,
etc. Inicie esa solicitud durante la tarea y ponga la tarjeta en Pending External
Dependency. Eso nos da una ventaja en las cosas que requieren esperar. Ponga una
pegatina (post-it) en la tarjeta para identificar la dependencia.
• Usa el proceso en beneficio del equipo, pero el proceso no debe impedirte hacer lo
correcto.
• Las peticiones de ayuda de alguien se convierten en historias de planificación rápida,
agrupadas en un consulta épica.
• La emergencia es algo roto y son expediciones de la tarjeta amarilla. Esperemos que sea
raro.
Políticas Explícitas

109
• Planificación continua: No hay planificación de Sprint / Reuniones de cierre de Sprint.
 El dueño del producto prioriza el atraso y mantiene llenos los 8 espacios en la columna de
atraso del producto.
 El Equipo resuelve las historias cuando hay un espacio disponible en la columna "Listo".
• Límites WIP: Cuando se alcanza el límite de trabajo en curso, ayudar a alguien a terminar
algo en lugar de empezar algo nuevo (tanto como sea posible).
• Menos divisiones: No hay necesidad de dividir artificialmente una historia para hacerla
encajar en un Sprint. Sin embargo, sigue siendo una buena idea entregar el valor en
trozos pequeños y manejables.
• Versión Uno: Nuevo estado Pendiente de (Pendiente de dependencia externa).
• Tiempo de Ciclo: Midiendo y optimizando el tiempo del ciclo, qué tan rápido podemos
hacer las tareas.
• Historias de consulta: Ayudar a alguien que consulta (> 1 hora) - crear una historia y
trabajar con el dueño del producto para planearlo al estilo Kanban.
¿Qué es lo que Cambia?

110
• Stand Up diario.
• El dueño del producto prioriza el atraso.
• Retrospectivas cada dos semanas.
• El backlog del propietario del producto se refina a diario.
• Time box para la investigación de historias.
• Rastrear el trabajo impulsado por eventos como tareas.
• Mantener el Kanban Board y la Versión Uno sincronizados.
¿Qué se Mantiene Igual?

111
•¿Cuáles son las limitaciones de Trabajo (si las hubiere) en
el proceso correcto para la columna de dependencia
externa?
•¿Si tu trabajo en curso se interrumpe, debería salir la
tarjeta de la barra?¿A dónde debería ir?¿Cómo
empezamos de nuevo?
Se Necesita Saber/Analizar

112
¿Preguntas?

IND611 - GP - Sesión 06.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a IND611 - GP - Sesión 06.pdf

Similar a IND611 - GP - Sesión 06.pdf (20)

Último

Último (20)

IND611 - GP - Sesión 06.pdf