UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCION DE POSGRADO

“LOS PRINCIPIOS DE LEAN Y KANBAN”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO

DE DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN I
\

POSTULANTE: ISMAEL NOEL FLORES GUTIERREZ

TUTOR: ING. EDSON ARIEL TERCEROS TORRICO

Cochabamba -Bolivia
2018
 ii

Agradezco a mi Padre Benigno Flores Ojeda, mis

hermanos y mi Esposa Elvia Nogales Escalera quienes

me apoyaron a seguir adelante para poder concluir mis

estudios y por mis dos hijos hermosos Noel y Caleb que

los tengo a mi lado cada día alentándome, en especial a

Dios por darme esas fuerzas y voluntad de seguir

luchando en plena enfermedad que tubo mi Esposa que

ahora se encuentran junto a Dios y mi Padre.

 INDICE
TABLA FIGURAS 5

TABLA ECUACIONES 6

Resumen 7

Introducción 8

1 Generalidades 9

1.1 Antecedentes Generales 9

1.2 Antecedentes Específicos 9

2 Metodología 12

3 Lean 12

4 Lean Software Development 14

4.1 Los siete principios del desarrollo de Lean Software 15

5 Kanban 20

5.1 Las propiedades de Kanban 22

5.2 Los principios de Kanban 22

6 Mapeo de Flujo de Valor 23

7 Lean Startup 25

3
 4

8 Diseñar la forma de pensamiento 28

9 Conclusiones 32

10 Bibliografía 34
 5

TABLA FIGURAS

Figura 1 Modelo Cascada ............................................................................................................. 10

Figura 2 Modelo Espiral ............................................................................................................... 11

Figura 3 Lean y Agile ................................................................................................................... 13

Figura 4 Tablero Kanban .............................................................................................................. 21

Figura 5 Mapa de flujo de valor .................................................................................................... 24

Figura 6 Lean Startup……………………………………………………………………………28

Figura 7 Plantilla de resolución de problemas de acuerdo con el diseño de pensamiento ........... 30

 6

TABLA ECUACIONES

Ecuación 1 Eficiencia del ciclo de Proceso .................................................................................. 25

Ecuación 2 Cálculo Eficiencia del ciclo de Proceso ..................................................................... 25

 7

Resumen

En este documento se verán los principios básicos de las metodologías ágiles, haciendo énfasis en

Scrum y Kanban.

El énfasis es en especial en Kanban debido a que es una metodología que más se ajusta con la

filosofía de Lean Software Development.

El mapeo de flujo de valor es una técnica que nos permite medir la eficiencia del proceso de

desarrollo de software, y otras métricas más para poder medir el estado de nuestro proceso de

desarrollo y comparar con propuestas de acción que difieren de nuestra forma actual de hacer las

cosas.

Lean Startup es un guía para poder aplicar Lean en cualquier emprendimiento, organización o

empresa de cualquier tamaño, para garantizar incrementar el valor aportado a un sistema real, de

forma que el sistema informático o software producido requiera menor cantidad de recursos por

ser su filosofía el eliminar desperdicios y concentrarse en cómo garantizar las acciones que generan

valor agregado.

Palabras clave: Lean, Lean Startup, Metodologías ágiles, Scrum, Kanban

 8

Introducción

Scrum y XP han transformado la industria del desarrollo de software, pero hubo otras ideas

derivadas de Lean Manufacturing y Six Sigma propias de la teoría de procesos que en inicio se

aplicaron a la industria y que luego comenzaron a influir en los métodos de desarrollo de software.

En este documento se cubren los conceptos Lean y algunos de los métodos y técnicas Lean

comunes como Kanban y Value Stream Mapping. Luego se ven técnicas como Lean Startup y

Design Thinking que pueden ayudar al equipo de desarrollo de software a aprender sobre el usuario

y el mercado que necesitan productos de software mucho más rápido y más barato.

De esta manera se contribuirá a que se comprendan las acciones a realizar para aplicar los

principios de Lean en proyectos ágiles para garantizar mejor productividad y tiempo de desarrollo

de productos de software.
 9

1 Generalidades

1.1 Antecedentes Generales

Los procesos de software estructuran el desarrollo de software en fases.

Los modelos tradicionales como el modelo de Proceso Unificado UP es un proceso iterativo que

organiza la línea de tiempo de un producto en ciclos de fases, donde cada fase normalmente tiene

iteraciones. Un proceso describe los resultados esperados de las actividades realizadas en las fases,

estableciendo lo que se necesita hacer en cada una.

Las prácticas de software son técnicas que indican el cómo desarrollar productos de software o

administrar proyectos de software de manera efectiva.

Las metodologías de software son grupos definidos de prácticas.

Las metodologías tradicionales generalmente se usan en contextos donde la incertidumbre es

escasa es decir en contextos bien definidos y predecibles.

Las metodologías agiles son generalmente utilizadas en contextos donde la incertidumbre es muy

grande y poco predecibles.

1.2 Antecedentes Específicos

Un principio de Agile se refiere a la entrega temprana y continua, donde existe una colaboración

cercana y comentarios de retroalimentación para mejorar el producto. Los modelos como el

Cascada se entregan al cliente al final del proceso de desarrollo, lo que significa que no se da una

integración o entrega temprana.

 10

La documentación completa no es un enfoque importante en el desarrollo Agile, pero los modelos

tradicionales como el Cascada se basan en gran medida en la documentación y su aprobación para

moverse entre fases.

La siguiente figura muestra las fases del modelo Cascada.

Figura 1 Modelo Cascada

Fuente: (Sommerville, 2011, p. 30)

Los contratos y la burocracia no es algo deseado en el enfoque ágil.

Se puede decir además que los modelos de procesos lineales no funcionan bien o no encajan con

los principios y prácticas ágiles.

Los modelos de procesos iterativos funcionan mucho mejor con las prácticas ágiles porque

permiten la reflexión y la mejora, además este tipo de procesos también permiten entregas

frecuentes y continuas para recopilar comentarios de retroalimentación.

Las versiones se refinan y mejoran cada vez en la siguiente iteración.

 11

Las iteraciones en Agile son pequeñas y permiten pequeños entregables.

El modelo en espiral con iteraciones más cortas y el modelo de proceso unificado con sus

iteraciones en fases funcionarán bien con los principios y prácticas ágiles.

Podemos ver las fases del modelo espiral junto con sus iteraciones en la siguiente figura.

Figura 2 Modelo Espiral

Fuente: (Sommerville, 2011, p. 49)

Ejemplo claro de esto es la adaptación del proceso unificado que conocido como el Proceso

Unificado Ágil.

El Proceso Unificado Agil PUA es un derivado del Proceso Unificado Racional. PUA fue

desarrollado por Scott Ambler entre 2002 y 2006 y combina algunos de los flujos de trabajo
 12

principales de RUP. PUA combina el flujo de trabajo de modelado de negocios, el flujo de trabajo

de requisitos y el flujo de trabajo de análisis y diseño en un solo flujo de trabajo modelo, que

también contiene la parte de gestión de cambios de RUP. (Stober & Hansmann, 2010, p. 56)

2 Metodología

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

 Método Bibliográfico, debido a que se realizara la lectura y compilación de libros

relacionados al tema de estudio.

 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio, para la redacción del Plan de Emergencia.

3 Lean

Lean propone que todo lo que puede construirse, cualquier producto y los pasos que tome para su

producción o servicio, debería verse desde la perspectiva del cliente y tratar de optimizar el valor

para el cliente minimizando el desperdicio en su proceso, para maximizar los resultados de valor

para el cliente con el uso de recursos mínimos.

Lean es el término occidental para lo que los japoneses llaman "TPS" (Sistema de Producción de

Toyota) que es un enfoque de fabricación que ha ayudado a hacer de Toyota el fabricante de

automóviles más exitoso del mundo. Los principios subyacentes detrás del TPS, ha resultado ser

aplicable en casi cualquier lugar, incluyendo el desarrollo de software. (Kniberg, 2011)

 13

Las metodologías ágiles como Scrum y XP sin duda han transformado la industria del desarrollo

de software, pero un conjunto de ideas derivadas de Lean Manufacturing y Six Sigma comenzó a

influir en los métodos de desarrollo de software.

Lean es como Agile es una forma de pensar, es un conjunto de principios, un conjunto de ideas y

muchísimas herramientas y técnicas como mapeo de flujo de valor o último momento responsable,

muchos tipos, muchas otras herramientas y técnicas que puedas aplicar a su proceso de desarrollo

de software o su fabricación para mejorar o para construir productos de manera más eficiente y

eficaz.

La siguiente figura muestra como es posible la coexistencia de las metodologías agiles con Lean.

Figura 3 Lean y Agile

Fuente: (Kniberg, 2011, p. 103)

 14

Lean proviene del mundo de la fabricación y especialmente muchas ideas detrás de Lean vinieron

del sistema de producción de Toyota realmente la idea central detrás de Lean es enfocarse en el

cliente. (Stober & Hansmann, 2010, pp. 35-37)

Lean, en lugar de centrarse en optimizar los pasos individuales del proceso, intenta concentrarse

en el flujo del proceso o en los pasos y así optimizar el flujo del producto o servicios lo cual se

traduce en la eliminación del desperdicio en toda la cadena de valor de su proceso. Lo que se

traduce en menos tiempo porque toma menos tiempo para construirlo y toma menos gente, menos

costo, y menos defecto. Todo esto se traduce en un cliente satisfecho gracias al bajo costo para el

cliente, y desde el punto de vista de la compañía se obtienen más ganancias.

Las herramientas y técnicas de Lean son aplicables a los servicios en otras áreas y desde el

concepto original ha evolucionado en la fabricación Lean, desarrollo de software Lean, Desarrollo

de producto Lean, Lean management, Lean startup, y muchas otras áreas.

Las personas también han comenzado a aplicar técnicas Lean en su vida personal por lo que Lean

realmente ha ganado bastante importancia en los últimos años.

4 Lean Software Development

En el año 2003, Mary y Tom Poppendieck escribieron este libro llamado "Lean Software

Development, An Agile Toolkit" que describe los principios Lean para el mundo del desarrollo de

software describiendo muchas herramientas que puede utilizar para aplicar estos métodos.

Luego hubo algunos libros más que mejoran la comprensión de cómo aplicar estos principios,

herramientas o ideas en el proceso de desarrollo de software.

 15

4.1 Los siete principios del desarrollo de Lean Software

a) Eliminar el desperdicio.

Los residuos pueden ser defectos o características adicionales. Las características

adicionales significan que los usuarios no necesitaban esas características o no las usan.

b) Amplificar el aprendizaje.

Aquí nos preguntamos cómo podemos aumentar el aprendizaje rápido para que pueda

realizar una integración continua, una prueba automatizada, explorar múltiples opciones.

Amplificar el aprendizaje significa aumentar la capacidad de un equipo para aprender de

manera rápida y efectiva las necesidades del usuario.

Es muy difícil predecir lo que necesita un usuario. A veces sabemos que algo en específico

es lo que se necesita, pero no sabemos qué solución realmente va ha satisfacer la necesidad.

Entonces, el éxito es saber cómo podemos aprender rápidamente sobre la solución.

A veces se trata del proceso de desarrollo del software del que necesitamos aprender

rápidamente para que podamos ser más productivos. El desarrollo de software es un

proceso muy creativo, es un arte. En algunos casos, no conoce las necesidades del usuario

y, en algunos casos, ni siquiera se conoce el problema que está tratando de resolver. Por lo

tanto, en estos casos en los que la solución es desconocida o el usuario desconoce las

necesidades, o el problema es desconocido, si se sigue un plan detallado y nos ajustamos

al plan, no funciona.

Lo que realmente necesita en estos casos es la capacidad de probar algo y ver si funcionó,

y aprender y ajustarse según ello.

En estos casos, cuanto más rápido se aprenda, más efectivo se podrá ser.
 16

Por este motivo si puede ampliar la capacidad del equipo para aprender, realmente

podemos hacerlo muy eficaz para que el equipo desarrolle la solución o satisfaga las

necesidades de los usuarios.

Uno de los métodos más comunes para amplificar el aprendizaje es utilizar un filtrado

donde se realice ciclos de desarrollo cortos, de forma tal que genere su producto de software

en un ciclo de desarrollo corto. Luego este se muestre al cliente, para obtener una

retroalimentación, para ver si resolvió o no el problema del cliente. Luego, en función del

aprendizaje, se ajusta en la siguiente iteración. Por lo tanto, este ciclo de desarrollo corto

de longitud fija a veces ayuda a aprender más rápido sobre su cliente.

Otra forma de aprender es la sincronización. Un ejemplo es la aplicación de expansión, en

la que crea una aplicación, o un equipo avanzado debe crear una aplicación que valide la

solución. En lugar de trabajar en todos los tipos de escenarios se puede elegir uno y

utilizarlo de principio a fin, con todas las actividades que están involucradas en ese tipo de

escenario. Esto ayuda a conocer todos los problemas posibles que puede enfrentar un

equipo, a validar su solución y a conocer todos los problemas. Una vez hecho esto, entonces

todos los otros escenarios pueden ser implementados por múltiples equipos.

Si se está construyendo una solución que requiere trabajar muchos componentes diferentes,

en lugar de permitir que todos los equipos construyan esos componentes de forma

individual, lo que se hace es comenzar con el desarrollo de las interfaces entre estos

componentes para que se pueda aprender sobre la integración de todos los componentes

antes de la implementación.
 17

También se puede hacer una compilación diaria, lo que significa que todo el sistema se

integra diariamente, y hay un pequeño conjunto de pruebas automatizadas de humo, que se

ejecutan todos los días para asegurarse de que durante el día, si hubo alguna actividad de

desarrollo o código comprometido, causará un problema en otra parte del software o algún

otro efecto secundario. Puede ser identificado dentro de las 24 horas.

Cuando en el desarrollo basado en equipos, se tiene un problema a resolver y no se sabe

cuál es la solución adecuada y hay múltiples enfoques para resolver el problema se puede

seguir estos enfoques.

c) Diferir el compromiso.

Muchas veces nos comprometemos cuando tenemos menos conocimiento. De acuerdo con

este principio, debemos intentar diferir un compromiso si no tiene toda la información y si

es posible diferir el compromiso con una tecnología específica o una arquitectura

específica.

La capacidad de comprometerse lo más tarde posible respecto a la arquitectura o alguna

decisión que tengamos que tomar es lo que debemos diferir para cuando se tenga la

información que se necesita para tomar la decisión.

A medida que se construye la solución, se comprende cada vez más las necesidades de los

usuarios y de su solución. Entonces, si se toma la decisión sobre la solución antes sin tener

la información necesaria, las posibilidades de que la decisión sea incorrecta se incrementan.

Por tanto, esto puede eliminar una gran cantidad de desperdicios si se toma la decisión en

el momento apropiado
 18

Si se codifica o desarrolla de tal forma que el desarrollo del diseño, y el resto se realicen al

mismo tiempo, y en lotes más pequeños, para que podamos obtener más conocimientos

antes de que tengamos que tomar una decisión, ayudara a tomar mejores decisiones.

Mantener la arquitectura débilmente acoplada de forma que cada uno de los módulos tiene

la separación de responsabilidades entonces si necesita realizar un cambio en el diseño,

solo afecta al módulo y no a los demás. Adicionalmente para la interacción entre los

módulos, se define las interfaces y las que están conectadas entonces, pueden hacerse

cambios en los módulos individuales sin afectar a todo el sistema.

d) Entregar rápido.

También se llama entregar lo más rápido posible. Básicamente significa entregar el

software lo más rápido posible. Aquí se analiza cuanto se puede disminuir ese tiempo.

e) Empoderar al equipo.

Así que empodera al equipo para tomar las decisiones, es decir dejar que tomen la decisión

de que están involucrados en su trabajo.

f) La calidad de construcción en todo el proceso.

A veces hacemos que la calidad sea uno de los pasos en el proceso de desarrollo de

software, pero la calidad siempre debe estar en el núcleo del software presente en todo

momento.

No es bueno diferir los controles de calidad a una fase de desarrollo específica como,

usualmente se hace luego del desarrollo recién todas las pruebas en una de fase, es decir,

deberíamos construir la calidad desde el principio y en cada paso, esto permite que cada

vez que se encuentra un defecto, es más fácil encontrarlo en el código cambiado

 19

recientemente, y también es más fácil solucionarlo. Lo mas importante es medir el

verdadero progreso de un proyecto donde la programación en pares de desarrolladores

ayuda a tener una calidad del código es muy alta, porque constantemente esta siendo

discutida y evaluada por los pares.

La automatización reduce la posibilidad de errores debido a que cada vez que se adicione

un código, se ejecutan automáticamente las pruebas y se detecta cualquier defecto creado

por código reciente.

El desarrollo basado en pruebas Test Driven Development, donde primero escribe la

prueba, se espera fallar, y luego se escribe código para que la prueba sea exitosa es muy

beneficioso porque si se sabe que las pruebas son correctas entonces el código también es

correcto.

g) Optimizar el conjunto.

En lugar de optimizar pasos inusuales del proceso de desarrollo de software, debemos

intentar optimizar el flujo completo del proceso de desarrollo de software.

Cuando intenta aumentar la efectividad de su sistema, debe tratar de considerar todo el

sistema en lugar de solo considerar el componente individual. Para esto es importante

identificar los cuellos de botella del proceso completo.

A veces optimizar solo uno de los componentes sin mirar el impacto que tiene sobre los

otros componentes produce un impacto positivo en un componente, pero podría tener un

impacto negativo en los otros componentes.

 20

La teoría de las restricciones o análisis de sensibilidad de problemas lineales ayuda a

encontrar la restricción que está causando que la productividad no aumente y entonces se

debe considerar el beneficio de aumentar el recurso de esa restricción.

5 Kanban

Kanban es una práctica que fue tomada del sistema de producción de Toyota que ayuda a optimizar

su proceso de desarrollo de software. (Anderson, 2010)

Kanban no es un proceso nuevo que se debe seguir, en si se trata de que sea cual sea el proceso

que uno tenga, lo alienta a optimizar ese flujo poniendo límites de trabajo en progreso en cada uno

de los pasos del proceso, esbozando cinco propiedades y tres principios.

Para entender tomamos como referencia a Scrum, donde se trabaja en iteraciones de una a cuatro

semanas donde se obtiene algún producto de software. A medida que se completa cada uno de sus

ciclos o Sprint, podemos obtener comentarios del cliente, por tanto, se puede cambiar lo que se

quiere construir.

Kanban no prescribe ninguna de estas iteraciones fijas ya que es solo un conjunto de propiedades

y principios que ayuda a optimizar el proceso de desarrollo de software siempre y cuando ese

proceso sea un flujo continuo, es decir que los trabajos pendientes se mueven a través de la línea

de desarrollo de software y el producto terminado sale de la otra terminación en la tubería o flujo.

 21

Cuando el primer elemento se completa, se sigue con otro, permitiendo tener un proceso de

adaptación donde, a medida que se van completando las tareas, podemos recibir comentarios del

cliente.

Kanban optimiza la línea de desarrollo del software mediante un conjunto de principios y

propiedades.

Lo primero que sugiere Kanban, o la primera propiedad es visualizar su flujo de trabajo. Para

visualizar el flujo de trabajo, se crea un tablero visual ya sea digital o físico.

Figura 4 Tablero Kanban

Fuente: (Kniberg, 2011)

Se mueve todas las columnas o estados o pasos del proceso en una columna. En algunas columnas

se puede observar tareas por hacer y tareas terminadas o hechas. Es decir que, si el ítem está siendo

procesado o analizado, entonces estará siendo trabajado. Si está terminado, entonces se lo mueve
 22

a la sub-columna de hecho. Entonces, a medida que se realiza el trabajo, el elemento de trabajo se

mueve en la pizarra para representar dónde se encuentra cada elemento.

Si los elementos en una columna se acumularán entonces se convertirán en un cuello de botella, y

ralentizará la entrega.

Kanban soporta otra propiedad llamada límite de trabajo en progreso WIP. Se debe definir, cuál

es el número máximo de elementos que pueden permanecer en un estado.

5.1 Las propiedades de Kanban

Básicamente las propiedades de Kanban son:

 Visualizar el Workflow.

 Limitar el trabajo en curso.

 Administrar el flujo.

 Hacer explícitas las políticas de proceso.

 Mejore en colaboración.

5.2 Los principios de Kanban

Los principios de Kanban son:

 Comienza con lo que sabes.

 Acordar perseguir un cambio incremental y evolutivo.

 Respetar el proceso actual, las reglas, la responsabilidad y los títulos.

 23

6 Mapeo de Flujo de Valor

Los administradores de proyectos deben ser propietarios de todo el proceso de producción y

responsables ante el cliente por la entrega oportuna de software. Si una empresa no entrega

sistemáticamente, debe verse como un problema de proceso de extremo a extremo. Este proceso

de extremo a extremo, su gente y sus procesos se denominan flujo de valor. El objetivo principal

de Lean es crear un flujo de valor, cada una de cuyas actividades agrega valor al usuario final. Con

demasiada frecuencia, la arquitectura se considera un costo incómodo en lugar de algo que

proporciona valor al usuario final. (Coplien & Bjørnvig, 2010)

Para crear un mapa de flujo de valor, se debe de trazar todas las actividades del proceso que desea

analizar, para esto es recomendable ir al lugar donde se realiza el trabajo, porque muchas veces se

pierden muchos pasos que realmente suceden en el trabajo. A medida que observa el trabajo, se

comienza a anotar las actividades y cuánto tiempo lleva realizarlas.

Se debe identificar cuáles de los pasos que agregan valor, es decir que están agregando valor al

cliente, y cuáles no agregan valor al cliente.

Se enumera o identifica quién está involucrado, qué tipo de tarea es, cuánto tiempo lleva y qué

trabajo implica.

Para entender el significado y terminología, por ejemplo, digamos que la cadena de valor involucra

cuatro actividades.
 24

La actividad A toma 5 minutos y es una actividad de valor agregado, la actividad B toma 5 días y

no genera un valor agregado, la actividad C es toma 1 hora y es una actividad de valor agregado y

la actividad D dura 1 día y no genera un valor agregado.

Se debe estandarizar la unidad de tiempo para mostrar por ejemplo en minutos, podría ser por

ejemplo asumiendo que 1 día es igual a 8 horas de trabajo. Entonces, la actividad B equivale a un

total de 2,400 minutos.

Si creamos un mapa de flujo de valor para las actividades A, B, C, D, se verá como se muestra en

la figura a continuación.

2400 480 Sin Valor Agregado SVA

Valor Agregado VA 5
60

Figura 5 Mapa de flujo de valor

Las actividades que tienen valor agregado se muestran en la parte inferior, y las actividades sin

valor agregado, se muestran en la parte superior. La primera actividad A dura 5 minutos, por lo

que se muestra los cinco minutos como el primer punto, luego la actividad B de 5 días, que es

equivalente a 2400 minutos, luego la actividad C de 1 hora equivalente a 60 minutos, y luego la

actividad D que dura 480 minutos.

 25

Una métrica clave que se usa en el flujo de valor se llama eficiencia del ciclo del proceso, que

define la eficiencia del flujo de valor y es igual al tiempo de valor agregado, dividido por el total

del tiempo de ciclo.

𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑉𝑎𝑙𝑜𝑟 𝐴𝑔𝑟𝑒𝑔𝑎𝑑𝑜

𝐸𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑖𝑎 𝑑𝑒𝑙 𝑐𝑖𝑐𝑙𝑜 𝑑𝑒 𝑃𝑟𝑜𝑐𝑒𝑠𝑜 =
𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑐𝑖𝑐𝑙𝑜

Ecuación 1 Eficiencia del ciclo de Proceso

Donde el tiempo de ciclo es el tiempo total que toma el flujo de valor.

Para el ejemplo mencionado seria:

5 + 60
𝐸𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑖𝑎 𝑑𝑒𝑙 𝑐𝑖𝑐𝑙𝑜 𝑑𝑒 𝑃𝑟𝑜𝑐𝑒𝑠𝑜 = = 0.022
5 + 60 + 2400 + 480

Ecuación 2 Cálculo Eficiencia del ciclo de Proceso

Lo que significa el 2.2 % de eficiencia.

7 Lean Startup

Eric Ries define Lean Startup como una institución humana diseñada para crear nuevos productos

y servicios en condiciones de extrema incertidumbre y que se puede aplicar a cualquier producto

o servicio en cualquier industria. Es aplicable cuando la situación es extrema incertidumbre, lo que

significa que el futuro es muy impredecible. (Kniberg, 2011)

 26

Hubo muchas propuestas de la puesta en marcha de Lean, pero muchas fracasaron y generaron una

gran cantidad de desperdicios en términos de capital.

Eric Ries aprendió de estos ejemplos o fallas y sus propias fallas y definió el concepto llamado

Lean Startup como un conjunto de principios, prácticas y herramientas en su libro: The Lean

Startup, que ayudó a gestionar la innovación no solo en una pequeña iniciativa, sino también en

grandes organizaciones donde existe una gran incertidumbre.

El primer principio es el emprendimiento es la gestión. Cuando se habla de gestión, las personas

lo asociamos a un equivalente a burocracia, por lo cual muchas empresas nuevas intentan evitar la

gestión y quieren evitar cualquier tipo de proceso que se vea como un freno, conllevando a tener

una actitud de simplemente hacer las cosas y por eso intentan sacar el producto lo antes posible

sin ningún tipo de gestión.

Todo este pensamiento equivocado lleva a muchos fracasos, por lo cual Lean Startup sugiere que

sí necesitamos gestión, pero un tipo diferente de gestión que soporta la extrema incertidumbre

donde lo primero es analizar cómo medir el progreso.

De manera tradicional se define la medida del progreso mediante la producción de productos de

alta calidad, mientras que en Lean Startup, la unidad de medida se valida aprendiendo, que es la

validación científica de cada elemento de su visión inicial mediante la ejecución de series de

experimentos.
 27

Donde sea que tenga una exención, se valida si eso es correcto o no creando experimentos

científicos.

El segundo principio de Lean Startup o aprendizaje validado está respaldado por un tipo especial

de gestión llamada gestión de innovación.

En lugar del enfoque tradicional en el que investiga a muchos usuarios, crea planes complejos y

se tiene una ejecución meticulosa para hacer que el producto funcione y luego se entrega el

producto, lo que Lean Startup propone es simplemente un ciclo de compilación, aprendizaje

iterativo rápido, en el que se aprenda de forma iterativa y rápida.

Si se va en la dirección correcta del desarrollo de software se persevera, pero si se cree que

necesitas cambiar la dirección, entonces giras.

El Lean Startup tiene una visión que está respaldada por una estrategia y la estrategia está

respaldada por el producto que se entrega.

El producto cambia con mucha frecuencia en función de ese ciclo de construcción de aprendizaje,

pero la estrategia cambia con menos frecuencia.

La visión cambia rara vez, de forma que la visión siempre es la misma casi todo el tiempo.

El quinto principio de Lean Startup, es que los emprendedores están en todas partes, lo que

significa que los emprendedores podrían estar en una organización, en una gran empresa tratando

de crear una empresa dentro de una organización establecida.

Todo el concepto, todos los principios de los que hablamos podrían ser igualmente aplicables a

una organización establecida siempre que haya innovación, mientras exista esta incertidumbre

extrema en lo que se construye.

 28

Figura. 6 Lean Startup

Fuente: (Erik Ries)

8 Diseñar la forma de pensamiento

El diseño de pensamiento es un proceso de resolución creativa de problemas, donde la palabra

clave es creativa y es para resolver problemas.

El objetivo es centrarnos en cómo se puede aplicar el diseño de pensamiento, especialmente a la

industria del software.

 29

Es la metodología para la resolución creativa y práctica de problemas muy complicados o muy

raros en la naturaleza, de los cuales no sabemos el resultado, a veces ni siquiera se tiene datos para

demostrar cuál es la solución correcta.

El diseño de pensamiento es un enfoque de la innovación centrado en el ser humano que se basa

en el conjunto de herramientas del diseñador para integrar las necesidades de las personas, las

posibilidades de la tecnología y los requisitos para el éxito empresarial.

Los tres puntos importantes son la conveniencia humana, la viabilidad comercial y la viabilidad

técnica, la unión o la intersección de estos es lo que trae la innovación.

Por lo cual para responder cómo podemos llegar a una solución que necesiten los individuos, de

modo que la conveniencia humana tenga sentido para el negocio y la viabilidad comercial y que

se pueda implementar, lo que significa factibilidad técnica, de modo que todo esto es diseño de

pensamiento. (Kniberg, 2011)

La siguiente figura muestra un ejemplo de plantilla de resolución de problemas de acuerdo con el

diseño de pensamiento.
 30

Figura 6 Plantilla de resolución de problemas de acuerdo con el diseño de pensamiento

Fuente: (Kniberg, 2011, p. 133)

El primer paso en el diseño de pensamiento es empatizar y lo que eso significa es ir al usuario,

hablar con el usuario para comprender su trabajo. Luego debemos proponernos averiguar cuál es

el problema real que debemos resolver y una vez que esto se entiende, se defina claramente cuál

es el problema que estamos tratando de resolver.

Basado en todo lo que se aprende en el paso de empatía acerca de los usuarios, se define

exactamente lo que se tiene que resolver.

 31

Una vez que se define lo que debe resolver, se presentan varias soluciones para resolver ese

problema, pero en lugar de seguir con una sola solución, hay que intentar encontrar varias

soluciones y explorarlas a fondo.

Luego, para explorar esas ideas, se crean prototipos que son la forma en que puede llevar una idea

a la vida de una manera rápida y sin mucho costo.

Los prototipos, se los muestra al usuario y se debe ver si realmente resuelve el problema.

Este es el proceso de innovación de ciclo corto para mejorar continuamente su diseño o su

solución.

Cualquiera que sea el problema que quiera resolver, se debería reunir a todos los miembros del

equipo para decirles cuál puede ser la solución potencial para este problema explorando muchas

soluciones posibles para luego elegir una que se considere adecuada.

No se deberían defender las ideas, si un usuario elige una opción diferente y uno piensa que ya que

no es así como lo hace, en lugar de hacer eso, solo se debería observar, tomar nota y seguir adelante.

Si una solución contiene algo en lo que no pensó es mejor no defender la idea y observar, anotar

y volver y sintetizar lo que se aprendió.

Los cinco pasos del diseño de pensamiento resumiendo serian empatía para aprender acerca de sus

usuarios. Definir claramente, articulando el problema que va a resolver, crear ideas, crear muchas

soluciones y elegir pocas, para luego crear prototipos y pruebas para validar las ideas.
 32

9 Conclusiones

La propuesta de Lean que asevera que todo lo que puede construirse, cualquier producto y los

pasos que tome para su producción o servicio, debería verse desde la perspectiva del cliente y tratar

de optimizar el valor para el cliente minimizando el desperdicio en su proceso, para maximizar los

resultados de valor para el cliente con el uso de recursos mínimos, es correcta porque está apoyada

en la teoría de la optimización de procesos y la teoría de las restricciones donde los recursos son

valiosos y debemos tratar de hacer un uso mínimo de estos para lograr el mejor resultado posible

como salida del proceso completo. Además, que también está de acuerdo con la teoría de

optimización sistemas donde el óptimo de un subsistema debe estar alineado con garantizar en

primer lugar el óptimo global o del proceso visto como un todo.

Lean Software nos muestra los principios Lean aplicados para el mundo del desarrollo de software

describiendo muchas herramientas que puede utilizar para aplicar estos métodos que nos permiten

garantizar una aplicación correcta y probada con éxito en proyectos de software. Los principios

vistos: eliminar el desperdicio, amplificar el aprendizaje. diferir el compromiso, entregar rápido,

empoderar al equipo, la calidad de construcción en todo el proceso, optimizar el conjunto, son sin

duda excelentes herramientas que se las ha aplicado con éxito para garantizar una mejor gestion

del flujo del proceso de software.

Kanban no es un proceso nuevo que se debe seguir, porque su fundamento se basa en que sea cual

sea el proceso que uno tenga, este se respete y más bien alienta a optimizar ese flujo poniendo

límites de trabajo en progreso en cada uno de los pasos del proceso, basado en sus cinco
 33

propiedades que son visualizar el workflow, limitar el trabajo en curso, administrar el flujo, hacer

explícitas las políticas de proceso, mejora en la colaboración. Pero también se basa en sus tres

principios que son: comenzar con lo que uno sabe, acordar perseguir un cambio incremental y

evolutivo, respetar el proceso actual, las reglas, la responsabilidad y los títulos. Gracias a estas

propiedades y principios Kanban ayuda a optimizar su proceso de desarrollo de software.

Los administradores de proyectos deben ser propietarios de todo el proceso de producción y

responsables ante el cliente por la entrega oportuna de software. El proceso de extremo a extremo

de una empresa, su gente y sus procesos involucrados son flujo de valor. El objetivo principal de

Lean es crear un flujo de valor, donde cada actividad agrega valor al usuario final. La

representación de las actividades que generan valor y las que no lo hacen más sus tiempos se

conoce como el mapeo de valor.

Lean Startup crea nuevos productos y servicios en condiciones de extrema incertidumbre y que se

puede aplicar a cualquier producto o servicio en cualquier industria, donde el futuro es muy

impredecible.

El diseño de pensamiento es un proceso de resolución creativa de problemas, es decir es un arte

para resolver problemas, de forma reflexiva.

 34

10 Bibliografía

Anderson, D. J. (2010). Kanban, Successful Evolutionary Change for Your Technology Business.

Sequim.

Coplien, J., & Bjørnvig, G. (2010). Lean Architecture for Agile Software Development. Gran

Bretaña: Wiley.

Kniberg, H. (2011). Lean from the Trenches: Managing Large-Scale Projects with Kanban. The

Pragmatic Bookshelf.

Sommerville, I. (2011). Software Engineering 9th Edition. Boston, Massachusetts, Boston:

Pearson.

Stober, T., & Hansmann, U. (2010). Agile Software Development: Best Practices for Large

Software. Springer.

Sitios WEB

https://www.leadersummaries.com/ver-resumen/el-metodo-lean-startup

Erik Ries

http://segriasec.org/wp-content/uploads/2015/01/Manual-Lean-Startup.pdf

Excelencia Empresarial por EXECyl

https://api.eoi.es/api_v1_dev.php/fedora/asset/eoi:80094/EOI_LeanManufacturing_2013.pdf

http://repositorio.udec.cl/bitstream/handle/11594/2478/Tesis_Metodologia_Lean_PMI.pdf?sequ

ence=1&isAllowed=y