La fabricación Justo a Tiempo (JIT), también conocida como producción justo a tiempo o el sistema de producción Toyota (TPS), es una metodología dirigida principalmente a reducir los tiempos de flujo dentro de la producción, así como los tiempos de respuesta de los proveedores y los clientes.
Siguiendo su origen se desarrollo en Japón, en gran parte en los años 60 y 70 y particularmente en Toyota. JIT permite reducir costos, especialmente de bodega de materias, partes para el embalaje y de los productos finales.
La esencia de JIT es que los insumos llegan a la fábrica, o los productos al cliente, "justo a tiempo", eso siendo poco antes de que se usan y solo en las cantidades necesarias. Esto reduce o hasta elimina la necesidad de almacenar y luego mover los insumos de la bodega a la línea de producción (en el caso de una fábrica).
El Sistema de Producción Toyota (SPT) (Toyota Production System o TPS en inglés), es un sistema integral de producción "Integral Production System" y gestión surgido en la empresa japonesa automotriz del mismo nombre.
En origen, el sistema se diseñó para fábricas de automóviles y sus relaciones con proveedores y consumidores, sin embargo, este se ha extendido hacia otros ámbitos. Este sistema es un gran precursor para el genérico Lean Manufacturing.
El desarrollo del sistema se atribuye fundamentalmente a tres personas: el fundador de Toyota, Sakichi
Toyoda, su hijo Kiichiro y el ingeniero Taiichi Ohno, quienes crearon este sistema entre 1946 y 1975.
Originalmente llamado "Producción Justo-a-tiempo”. Los principios principales de SPT son mencionados en el libro "La Manera de Toyota".
Kaizen, japonés para "mejora".
Cuando se utiliza en el sentido comercial y se aplica al lugar de trabajo, Kaizen se refiere a actividades que mejoran continuamente todas las funciones e implican a todos los empleados desde el CEO a los trabajadores de la línea de montaje.
También se aplica a procesos, tales como compras y logística, que cruzan los límites de la organización en la cadena de suministro. Se ha aplicado en la asistencia sanitaria, psicoterapia, entrenamiento de vida, gobierno, banca y otras industrias.

Bimodal está ocurriendo.
Si intentas aplicar los convenios de seguridad del modo 1 en las iniciativas del modo 2, serás sobrepasado y la empresa quedará expuesta a riesgos insostenibles.
Para 2019, el 30 % de CISCOs adaptará las prácticas de gestión de riesgos, apoyará la TI bimodal y mejorará las tasas de éxito del modo 2, al tiempo que reducirá los costos.
Fuente: http://www.gartner.com/it-glossary/?s=Bimodal
IT Bimodal: Dos enfoques distintos pero coherentes, bastante diferentes, ambos esenciales.

DevOps tiene una relación nada fácil con seguridad.

Si DevOps no presta atención a la seguridad puede facilitar la rápida introducción de las vulnerabilidades.



Scrum es un marco para desarrollar y mantener productos complejos. Consiste en roles Scrum, eventos, artefactos y las reglas que los unen.
Ken Schwaber y Jeff Sutherland desarrollaron Scrum.
Un límite WIP (work in progress) es una estrategia para prevenir cuellos de botella en el desarrollo de software.
Se acuerda por el equipo de desarrollo trabajar en progresos limitados antes de que un proyecto comience y sean ejecutados por el facilitador del equipo.
Por ejemplo, un equipo puede dividir las tareas que deben realizarse para una característica en el diseño, código, prueba y despliegue. Cuando se alcanza un límite WIP para una determinada tarea, el equipo se detiene y trabaja en conjunto para eliminar el cuello de botella. El objetivo de trabajar de esta manera es asegurar que todo el equipo se apropie del proyecto y produzca códigos de alta calidad.
Un Acuerdo de Nivel de Servicio (Service-level agreement o SLA) se define como un compromiso oficial que prevalece entre un proveedor de servicios y el cliente.
Aspectos particulares del servicio (calidad, disponibilidad, responsabilidades) son acordados entre el proveedor de servicios y el usuario del servicio.
Acuerdos de Nivel Operacional (Operational-level agreements u OLAs) pueden ser utilizados por grupos internos para apoyar SLAs.
PDCA (Planear-Hacer-Verificar-Actuar o Planear-Hacer-Verificar-Ajustar) es un método de gestión de cuatro pasos iterativo utilizado en los negocios para el control y la mejora continua de procesos y productos.
También se conoce como círculo/ciclo/rueda de Deming, ciclo de Shewhart, círculo/ciclo de control, o planear-hacer-estudiar-actuar (PDSA).

Otra versión de este ciclo PDCA es OPDCA. El "O" agregado para la observación o como algunas versiones dicen “Comprender la condición actual”. Este énfasis en la observación y la condición actual tiene relación con la fabricación Lean o la literatura del sistema de producción de Toyota.
Definición de “Listo” Cuando un artículo o Producto Backlog o un Incremento se describe cómo “Listo”, todo el mundo debe entender lo que significa “Listo”.
Aunque esto varía considerablemente según el Equipo Scrum, los miembros deben tener un entendimiento compartido de lo que significa que el trabajo sea completo, para asegurar la transparencia.
Esta es la definición de “Listo” para el Equipo Scrum y se utiliza para evaluar cuándo se completa el incremento del trabajo. La misma definición guía al equipo de desarrollo para saber cuántos elementos de la cartera de productos se pueden seleccionar durante una planificación de Sprint.
El propósito de cada Sprint es entregar Incrementos de funcionalidad potencialmente liberable que se adhieran a la definición actual del Equipo de Scrum de “Listo”.
El método Kanban puede ayudar a los equipos de DevOps a poner un poco de orden en su trabajo diario y la teoría Lean definitivamente puede ser apalancada para mejorar el flujo a través de los equipos de DevOps.
