Scrum II

Gestin flexible de proyectos
Scrum II
Rev. 2.2
Scrum II
Gestin flexible de proyectos con Scrum
Rev. 2.2 Agosto 2013
Diseo de cubierta: Scrum Manager. Imagen derivada de la original: The Albert Bridge 04 Belfast de William Murphy (http://www.streetsofdublin.com/)
2013 Juan Palacio De la edicin: Scrum Manager Informacin de derechos y licencia de uso:
Ms informacin: http://www.safecreative.org/work/1308225627323
Scrum Manager es marca registrada propiedad de Iubaris Info 4 Media S.L. El marco y plataforma de formacin abierta ScrumManager es propiedad de Iubaris info 4 Media S.L.
Contenido
Contenido Formacin Scrum Manager Servicios de formacin y asesora presencial Scrum Manager Evaluacin para mejora continua y control de calidad de Scrum Manager SCRUM II Principios de Scrum Manager 1.- Conocimiento en continua evolucin 2.- Empresa como sistema 3.- Flexibilidad Metodologas Coordenadas del mapa de metodologas. Conceptos Patrones de gestin del proyecto Personas, Procesos y Tecnologa Procesos Personas FLEXIBILIDAD Incremento continuo con gestin visual kanban Introduccin: De la artesana a la produccin Lean Lean Lean Software Development Kanban Origen y definicin Trabajando con tableros kanban: conceptos Trabajando con tableros kanban: operativa Casos prcticos de formatos de tableros kanban Kanban Box Muda, Mura y Muri y algunos consejos para ajustar el flujo. Responsabilidades con Scrum a nivel de gestin Responsabilidades de producto. Responsabilidades del equipo Responsabilidad de funcionamiento de Scrum en el proyecto Bibliografa Tabla de ilustraciones ndice 4 5 5 7 9 10 10 12 13 14 14 14 15 16 16 17 19 20 21 23 24 26 28 30 33 38 41 43 44 45 46 47 49 50
2005-2013 ScrumManager - http://www.scrummanager.net
Sobre la formacin de Scrum Manager
Formacin Scrum Manager

Este es el material de formacin del curso de Scrum desarrollado e impartido por Scrum Manager Los contenidos de formacin de Scrum Manager se mantienen regularmente actualizados. Puede descargar la ltima versin de este libro de apuntes, o consultar on-line la ltima revisin de sus contenidos en la direccin: http://www.scrummanager.net/bok La formacin de Scrum Manager es un recurso educativo abierto (OER): Materiales: Los materiales son de acceso y uso gratuito para consulta y 1 autoformacin de carcter personal . Cursos: Los cursos de Scrum Manager se ofrecen gratuitamente en la plataforma de e-learning: http://www.scrummanger.net/oks Acreditacin acadmica: Incluida en los cursos OER de la plataforma de elearning, para los alumnos que desean realizar el examen de evaluacin correspondiente.
La formacin libre de Scrum Manager es posible gracias a la subvencin y soporte de los:
Servicios de formacin y asesora presencial Scrum Manager

Cursos en convocatorias presenciales, o contratados a medida para empresas o a grupos de estudiantes. o Puede consultar el calendario de convocatorias en diferentes ciudades en la pgina de cursos de http://www.scrummanager.net: o Para informacin de cursos a medida: contacte con un Centro Oficial de Formacin Scrum Manager (http://scrummanager.net/centros) o en la direccin admin@scrummanager.net Exmenes de certificacin (nivel de certificacin, que incluye la supervisin presencial de la prueba e identificacin del alumno): Los cursos presenciales incluyen examen de certificacin. Tambin se pueden realizar los exmenes de certificacin en los Centros Oficiales de Formacin Scrum Manager: http://scrummanager.net/centros Puede localizar profesionales y empresas certificadas para servicios profesionales de formacin y asesora en la implantacin y mejora de Scrum Management, en el directorio de centros de formacin autorizados Scrum Manager http://scrummanager.net/ o solicitar informacin en la direccin admin@scrummanager.net Ms informacin:
http://www.scrummanager.net http://www.scrummanager.net/oks admin@scrummanager.net
Para impartir cursos de Scrum Manager: puedes consultar cmo hacerlo en Preguntas Frecuentes de scrummanager.net o contactando en admin@scrummanager.net
Evaluacin para control de calidad y mejora de Scrum Manager
Evaluacin para mejora continua y control de calidad de Scrum Manager

Gracias por haber elegido los servicios de formacin de Scrum Manager La valoracin de los alumnos es el criterio de control de calidad empleado por Scrum Manager para decidir la validez o no de los servicios de formacin, y en su caso la continuidad de los cursos, profesores y partners. Su valoracin es importante, porque hace posible la garanta de calidad de Scrum Manager. Si ha participado en una actividad de formacin auditada por Scrum Manager, le rogamos y agradecemos que valore la calidad del material, profesor, temario, etc. as como tus comentarios y sugerencias. Scrum Manager anonimiza la informacin, de forma que comparte con los profesores, partners y centros autorizados las valoraciones y aspectos de mejora, pero en ningn caso los nombres de los alumnos que las han realizado. Puede realizar la valoracin en la pgina de acceso restringido a miembros de Scrum Manager: http://scrummanager.net/qa.
SCRUM II
Scrum flexible.
Gestin flexible con Scrum
Principios de Scrum Manager

1.- Conocimiento en continua evolucin
Los marcos de prcticas giles no surgen en los proyectos TIC como tesis sino como anttesis del conocimiento de Ingeniera del Software que se vena empleando. Comenzaremos viendo qu significa esto para tomar la distancia y conseguir la perspectiva que revela las razones de la agilidad y sus diferencias con la ingeniera de procesos, no desde las prcticas concretas sino desde los principios en los que se basan, y con ello comprender las fortalezas y debilidades de la agilidad. Esta visin desde las razones y los principios de los diferentes marcos y metodologas, ms all de la visin enfocada en las diferencias entre metodologas y prcticas concretas es clave para dar el salto de gestin tcnica a gestin experta.
El patrn dialctico
La evolucin y mejora del conocimiento se produce al cuestionar el conocimiento actual, siguiendo de este modo un patrn dialctico de tesis, anttesis y sntesis. De manera esquemtica el patrn dialctico puede definirse como la evolucin que contrapone una anttesis a una determinada concepcin, entendida como tesis. Esta anttesis muestra los problemas y contradicciones de la tesis. De la confrontacin surge un tercer momento llamado sntesis, una resolucin o una nueva comprensin del problema.
Ilustracin 1: Patrn dialctico
De esta forma la estrategia de aplicar ingeniera de procesos para atajar los retos de los proyectos de software es la tesis a cuyos problemas y contradicciones se contrapone la agilidad. El reto de los proyectos TIC se identific por primera vez en 1968 en la primera conferencia sobre desarrollo de software celebrada por la organizacin OTAN, en la que se acu el trmino crisis del software para definir los problemas comunes y recurrentes de los proyectos de software que siempre desbordaban las agendas y los presupuestos de sus planes iniciales, adems de no conseguir resultados con la calidad esperada. La conclusin de la conferencia de la OTAN de 1968 (Bauer, Bolliet, & Helms, 1969)fue la necesidad de crear una disciplina cientfica que como ocurra en otras reas, permitiera aplicar un enfoque sistemtico disciplinado y cuantificable al desarrollo, operacin y mantenimiento de los sistemas del software, es decir, la aplicacin de la ingeniera de procesos al software. Fue el nacimiento de la Ingeniera del Software. La primera estrategia de la Ingeniera del software (tesis) se ha basado en dos pilares: Ingeniera de procesos: Gestin predictiva: El primero para aplicar el principio bsico de calidad contrastado con xito en los entornos de produccin industrial: la calidad del resultado depende de la calidad de los procesos empleados. El segundo para garantizar el cumplimiento de agendas y presupuestos.
10
Mientras este conocimiento iba evolucionando y perfeccionndose a travs de diferentes modelos de procesos y cuerpos de conocimiento de gestin de proyectos (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE, SW-CMM) en la industria del software surgan dudas y se cuestionaba esta estrategia. La planificacin predictiva es apropiada para cualquier proyecto? Los criterios de xito son siempre el cumplimiento fechas, costes y funcionalidades preestablecidas? Empiezan a surgir proyectos que no tienen como finalidad construir un sistema que previamente se ha definido y planificado en su totalidad, y para los que no es realista trazar un plan cerrado desde su inicio. Proyectos en los que no interesa saber si el sistema final tendr 20 o 200 funcionalidades y conocer cmo sern stas en detalle: Su inters es poner un nuevo sistema en el mercado lo antes posible y desde ese momento evolucionar la visin y mejora el valor de forma continua. Por otra parte se le cuestiona tambin a la tesis el considerar al desarrollo de software como un proceso industrial. Se empieza a aceptar que puede ser ms importante para la calidad del resultado, el conocimiento tcito de la persona que lo realiza que la calidad del proceso que emplea.
Ilustracin 2: Evolucin de los primeros modelos de mejora
Desde los orgenes de la agilidad, mediados de los 90, hasta 2005-2010 han sido habituales las posturas radicales entre los defensores de los modelos de procesos y de los marcos giles, posiblemente ms enfocados en descalificar al otro que en revisar y depurar los propios mtodos. Algunos ejemplos de esta tensin: "La diferencia entre un atracador de bancos y un terico de CMM es que con el atracador se puede negociar" "La evaluacin en CMM depende ms de una buena presentacin en papel que da la calidad real del producto de software. Tiene que ver ms con el seguimiento a ciegas de una metodologa que con el desarrollo y puesta en produccin de un sistema en el panorama tecnolgico". (Orr., 2003) "Si uno pregunta a un ingeniero de software tpico si cree que CMM se puede aplicar a los mtodos giles, responder o con una mirada de sorpresa o con una carcajada histrica" .
2005 - 2013 ScrumManager Project http://www.scrummanager.net
11
(Turner & Jain, 2002)
Espiral dialctica del conocimiento.

El conocimiento profesional evoluciona de forma continua porque la realidad en la que se aplica est en permanente movimiento, y tambin porque siempre es posible mejorar los mtodos actuales. La aplicacin de nuevas tcnicas, procesos o modelos genera sus propias anttesis que revelan las debilidades, contradicciones y puntos de mejora que conducen el avance hacia una sntesis, que pasar a ser una nueva tesis que con su uso generar su anttesis, desarrollando a travs de este patrn dialctico una espiral de evolucin continua del conocimiento (Nonaka & Takeuchi, 2004)
Ilustracin 3: Espiral dialctica del conocimiento
En disciplinas no tcnicas y en generaciones anteriores el ritmo de avance sobre esta espiral dialctica permita a los profesionales desempearse con los conocimientos adquiridos en su licenciatura durante toda su carrera profesional. Sin embargo hoy esto no es posible, especialmente en el sector TIC No hay mtodos, prcticas o modelos de trabajo que nos ayuden con solvencia durante mucho tiempo, sino conocimiento en evolucin. Esta es una consideracin clave en el marco de Scrum Manager y la razn por la que no define un modelo fijo, sino un conocimiento actualizado como base para una gestin ms experta que tcnica. Ms basada en el criterio documentado y experto del gestor que en la aplicacin de prcticas o procesos.
2.- Empresa como sistema

Las empresas no estn formadas por departamentos o reas ms o menos independientes. Son realidades sistmicas y su eficiencia es proporcional a la armona de los modos de trabajo de los diferentes departamentos. La consideracin de Scrum como el marco de trabajo propio del mbito de gestin de proyectos, cuyas prcticas se pueden adoptar sin implicaciones en el resto de la organizacin produce resultados limitados e incluso contraproducentes.
12
Ilustracin 4: La empresa como sistema
Por ejemplo, en una organizacin cuya gerencia dirige con orientacin a modelos de produccin industrial, y el rea de ingeniera en consecuencia trabaja con modelos basados en procesos con ciclos de vida secuenciales o de cascada, la adopcin de prcticas giles en el rea de gestin de proyectos generar problemas de funcionamiento.
3.- Flexibilidad
El objetivo no es implantar el modelo estndar de Scrum, o cualquier otro. El objetivo es lograr los mejores resultados en escenarios de trabajo que evolucionan rpidamente, o tienen dosis altas de incertidumbre por las que no cuentan con requisitos estables al concebir nuevos productos o servicios. Se trata de clientes que necesitan empezar a usar un producto lo antes posible y mejorarlo de forma continua. De productos en los que la innovacin es un valor clave. Por esta razn, el principio de flexibilidad de Scrum Manager se refiere a adaptar las prcticas de trabajo a la organizacin y no al revs. Se trata en definitiva de realizar una gestin experta ms que una gestin tcnica. Una gestin dirigida desde el conocimiento, experiencia y criterio del gestor y no tanto una gestin orientada a la bsqueda e implantacin del mejor modelo. Una gestin basada en la persona antes que en el modelo. El conocimiento de las distintas tcnicas y metodologas amplia el criterio y el fondo de recursos del gestor. Para seguir la evolucin del conocimiento profesional y para ampliar y mejorar de forma continua el criterio e inventario de recursos profesionales propios es aconsejable Vencer la resistencia al cambio y evitar actitudes de aceptacin o defensa dogmtica de un modelo. Espritu crtico-constructivo: Cuestionar continuamente de forma antittica los modos actuales, con el conocimiento y criterio profesional adecuar el sistema de trabajo propio a las caractersticas del proyecto, equipo y organizacin.
13
Metodologas
Coordenadas del mapa de metodologas.
Desde los 80 se han desarrollado tantos modelos de procesos, marcos y prcticas de trabajo para mejorar la calidad y eficiencia en los proyectos de software, que resulta til trascender las etiquetas y llegar a la base de los principios que subyacen, y las estrategias con las que los desarrollan; de forma que con tres conceptos (desarrollo, trabajo y conocimiento) y dos modelos de gestin (predictiva y evolutiva) se despeja y simplifica el aparente laberinto de modelos de procesos, marcos o prcticas de trabajo a los que nos referimos: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, LEAN, KANBAN, TDD, etc..
Las diferentes prcticas y metodologas responden a combinaciones de tres conceptos y dos patrones de gestin de proyectos.
Ilustracin 5: Diagrama de conceptos de la gestin de proyectos
Conceptos
1.- Desarrollo
Completo: La descripcin de lo que se desea obtener est disponible al inicio del proyecto, es completa y detallada, sirve de base para estimar el plan del proyecto: tareas, recursos y agenda de trabajo. Durante la ejecucin se gestiona su cumplimiento. Incremental: La descripcin de lo que se desea obtener no est disponible de forma completa y detallada al inicio: se complementa y evoluciona en paralelo al desarrollo, que genera el resultado de forma incremental y que se puede gestionar con dos tcticas diferentes:
14
Desarrollo incremental continuo: Empleando tcnicas para lograr y mantener un flujo continuo de desarrollo de funcionalidades o partes del producto que entrega de forma continua al cliente. Desarrollo iterativo: El marco de produccin emplea tcnicas de tiempo prefijado o timeboxing para mantener la produccin de incrementos del producto de forma cclica y continua. Este es el marco de produccin empleado en scrum estndar, que define como sprint a cada iteracin de desarrollo al final de la cual se produce un incremento del producto.
2.- Trabajo
Secuencial (cascada): Secuencia las tareas en fases, cada una de las cuales comienza al terminar la anterior y con el resultado que se ha obtenido en ella. El ejemplo ms habitual es el ciclo de cascada definido en Ingeniera del software con las fases de requisitos, anlisis, diseo, codificacin, pruebas e implementacin. Concurrente: Solapa en el tiempo los diferentes tipos de tareas. Siguiendo con el ejemplo de ingenera de software, la definicin de requisitos, el anlisis, la codificacin y el despliegue del resultado se realiza y revisa de forma simultnea y continua.
3.- Conocimiento
Principal conocimiento empleado, protagonista de la calidad del resultado. El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en los procesos y la tecnologa empleada. La calidad del resultado depende de la calidad de los procesos empleados. El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en el conocimiento tcito de las personas que lo consltruyen.
Patrones de gestin del proyecto

Gestin predictiva
Modelo de gestin de proyectos cuyo objetivo es ofrecer resultados predecibles: desarrollo del producto previsto en el tiempo previsto e invirtiendo los recursos previstos. Emplea una estrategia de desarrollo completo con prcticas de planificacin tradicional los principales referentes en el desarrollo de conocimiento para este tipo de gestin son PMI e IPMA y los modelos desarrollados (CMMI, ISO 15504, SPICE entre otros) emplean ingeniera secuencial y produccin basada en procesos.
Gestin evolutiva
Modelo de gestin de proyectos cuyo objetivo es la entrega en el menor tiempo posible un producto mnimo viable, e incrementar su valor de forma iterativa y continua. Emplea una estrategia de desarrollo incremental, que puede obtener con tcticas iterativas o de mantenimiento de flujo continuo, y un modelo de trabajo de fases solapadas. Puede emplearse con produccin basada en procesos (ingeniera concurrente) o con produccin basada en personas (agilidad). Es importante esta distincin porque sin ella se generan situaciones confusas que llegan a considerar agilidad a la simple aplicacin de un marco de desarrollo estndar de scrum (ciclo de incremento iterativo con roles y artefactos definidos), o al simple uso de tcnicas de gestin visual kanban para mantener un flujo continuo de tareas.
15
Personas, Procesos y Tecnologa

Scrum Manager reconsidera dos vrtices del tringulo clsico de los factores de produccin: Personas Procesos y Tecnologa. El de procesos y el de personas.
Procesos
A fin de poder diferenciar distintos tipos de procesos procedimientos podemos decir que en unos, las personas ayudan al proceso, y en otros son los procesos las prcticas las que ayudan a las personas. En el primer caso el proceso es el protagonista, el que sabe cmo hacer el trabajo, y la persona se integra en el sistema como instrumento, como operario de apoyo. En el segundo, el artfice es la persona y el proceso la prctica una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr ms eficiencia y no diluir el esfuerzo en rutinas mecnicas.
La principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. El conocimiento pueden ser: Explcito: contenido en los procesos y la tecnologa Tcito: que es contenido por la persona Scrum Manager aporta una consideracin sobre el tringulo tradicional personas-procesos-tecnologa, considerando que los procedimientos de trabajo pueden ser: procesos: cuando el conocimiento clave para lograr el resultado est en su mayor parte explicitado en el proceso y la tecnologa empleada. prcticas: cuando los procedimientos ayudan a las personas, que son quienes tienen el conocimiento clave, y por tanto operan en sistemas aportando su conocimiento tcito. Se puede decir que en los primeros la persona ayuda al procedimiento, y en los segundos es el procedimiento el que ayuda a la persona.
Ilustracin 6: Personas, procedimientos y tecnologa
Los modelos de gestin y mejora basados en procesos, centran el foco de la produccin en los procesos y la tecnologa, como los elementos ms valiosos de la produccin. Su anttesis, las prcticas giles, focalizan el valor de la produccin en las personas.
16
Desde el punto de vista de Scrum Manager, ambas opciones son posibles, pero cada una para un entorno diferente. En entornos de produccin industrial que centran el conocimiento en los procesos y tecnologa empleada, las personas aportan trabajo para auxiliar a los procesos y la tecnologa, y el valor del resultado depende principalmente de los primeros. Sin embargo para las empresas del conocimiento que trabajan en escenarios rpidos e innovadores, el principal valor es el talento de las personas.
Personas
Las organizaciones que necesitan imprimir un componente innovador importante y frecuente, o se mueven en sectores de innovacin muy rpido, obtienen mejores resultados si hacen responsables de esa innovacin al talento de las personas ms que a la ejecucin de procesos. En este tipo de organizaciones es importante asegurar, adems del nivel de creatividad del equipo, su capacidad para aprehender. El modelo de conversin del conocimiento definido por Nonaka y Takeuchi (Nonaka & Takeuchi, The Knowledge-Creating Company, 1995) define con sus 4 fases el proceso para la adquisicin de las personas del conocimiento tcito a travs de compartir experiencias, comunicacin directa, documentos, manuales y tradiciones, que aade conocimiento novedoso a la base colectiva de la organizacin.
17
FLEXIBILIDAD
Adaptacin de las prcticas a la organizacin.
Flexibilidad
Incremento continuo con gestin visual kanban

El marco estndar de scrum realiza desarrollo incremental: iterativo, basado en el conocimiento tcito de las personas que realizan el trabajo con un criterio multidisciplinar, sin divisin de fases. La imagen siguiente lo representa visualmente sobre el esquema descrito en el captulo anterior:
Ilustracin 7: Agilidad con desarrollo incremental iterativo
La caracterstica principal del marco estndar de Scrum es el uso de pulsos de sprint, para emplear la tcnica de tiempo prefijado (timeboxing) y mantener as un avance continuo gracias al ritmo marcado por la secuencia de sprints. La tctica de timeboxing muestra al equipo el avance de forma pragmtica, al tiempo que mitiga la tendencia habitual a dilatar los tiempos de entrega previstos. Los equipos originales de Scrum observados y descritos por Nonaka y Takeuchi (Nonaka & Takeuchi, The New New Product Development Game, 1986) y los principios de la agilidad no prescriben el uso de una determinada tctica para lograr un desarrollo incremental. Tambin es posible trabajar con un avance constante de las tareas una tras otra, sin empaquetar en incrementos para hacer en pulsos de timeboxing. Lograr un flujo continuo de tareas no es fcil porque suelen formarse zonas con cuellos de botella que bloquean el avance, mientras en otras reas del equipo se producen tiempos muertos sin tareas que realizar. La gestin visual kanban es la tcnica ms empleada actualmente para regular el flujo continuo en proyectos TIC y de servicios del conocimiento gestionados evolutivamente.
20
Flexibilidad
Introduccin: De la artesana a la produccin Lean

Las tcnicas de gestin visual que vamos a ver se inspiran en la produccin Lean. Esta introduccin muestra de forma breve cules han sido los principales hitos en la produccin industrial hasta llegar a Lean.
Ilustracin 8: De la artesana a la produccin lean
Divisin del trabajo

La riqueza de las naciones es la obra ms clebre de Adam Smith. Fue publicada en 1776 y se considera el primer libro moderno de economa. En l desarrolla la teora econmica sobre la divisin del trabajo.
Para Smith el principal factor para mejorar la productividad del trabajo es su divisin, que ilustr en su clebre ejemplo de la manufactura de alfileres, en el que comparaba la produccin que puede alcanzar un herrero realizando todas las tareas necesarias, con la obtenida en un sistema con divisin del trabajo entre obreros especializados en cada tipo de tarea (estirado del alambre, cortado, afilado, etc.). Como demostr, la divisin del trabajo hace posible producir 5.000 alfileres diarios por obrero, frente a los 50 que producira un artesano.
Organizacin cientfica del trabajo

Frederick W. Taylor fue el primero en analizar y estudiar el trabajo de forma sistemtica.
Taylorismo es el nombre dado al mtodo de produccin cuyo principal objetivo fue el aumento de la productividad basado en la divisin y especializacin del trabajo. Al taylorismo se le denomina tambin organizacin cientfica del trabajo o gestin cientfica del trabajo por aplicar principios bsicos del mtodo cientfico en el diseo de los procesos de trabajo. Taylor expuso su sistema de organizacin racional del trabajo en su obra Principles of Scientific Management (1912) que de forma somera se puede condensar en cuatro principios: Reemplazar los mtodos artesanales por mtodos basados en el anlisis cientfico del trabajo. Seleccionar y formar a los empleados con criterios cientficos, en lugar de dejar que aprendan de forma autnoma.
2005 - 2013 ScrumManager Project http://www.scrummanager.net 21
Flexibilidad
Dividir las tareas en gestin y trabajo, de forma que los gerentes puedan gestionar los principios de planificacin y ejecucin del trabajo. Proporcionar instrucciones y supervisin detallada a cada trabajador.
Produccin en cadena
La produccin en cadena, tambin denominada fordismo, es el sistema de produccin desarrollado por el fabricante de automviles Henry Ford para la fabricacin de los primeros automviles de su factora en la primera dcada del siglo XX. Pone en prctica los principios de la divisin y la organizacin cientfica del trabajo, y ha sido ampliamente utilizado para la produccin industrial hasta que en la dcada de los 70 comenz a ser reemplazada por el toyotismo. El fordismo hizo posible: Reduccin significativa del costo de produccin. (El precio del Ford T pas de $850 en 1908 a 250$ cuando se produjo en cadena en 1927). Flujo constante de la produccin. Ingeniera de procesos: la calidad del resultado depende de la calidad del proceso empleado en su fabricacin.
Sistema de produccin Toyota

El fundador de Toyota, Sakichi Toyoda, su hijo Kiichiro Toyoda y el ingeniero Taiichi Ohno, evolucionaron los sistemas de produccin de sus factoras transformando el fordismo hasta llegar a principios de los 70 en lo que acabara siendo y denominndose Sistema de Produccin Toyota o toyotismo. Cuando intentaron importar los sistemas de produccin masiva norteamericanos, para rehacer su industria tras la segunda guerra mundial, se dieron cuenta de que el fordismo no les vala, porque creaba empresas para producir grandes cantidades del mismo producto, pero no serva para producir pequeas cantidades de productos diferentes. El sistema fordista generaba muchas existencias del producto que acababa con sobreproduccin y almacenes llenos por falta de clientes. Necesitaban un sistema que produjera con costos reducidos, pero no en base a un incremento de la produccin, puesto que no tenan gran demanda. Estas circunstancias evolucionaron la produccin hacia un sistema que elimina las existencias del proceso de produccin y el sobreefectivo tanto de personal como de equipo para lograr la fbrica mnima, capaz de producir lo necesario: lo que un cliente est esperando. El sistema fordista es un sistema de empuje (push) mientras que el toyotismo es un sistema de arrastre (pull). En el fordismo cada puesto empuja continuamente al siguiente, envindole trabajo de forma sistemtica. Sobre la estimacin de consumo, se pone en marcha la cadena y se produce al ritmo previsto. El toyotismo es un sistema de arrastre: un puesto no empuja al siguiente sino que tira del anterior, pidindole trabajo por la demanda de un cliente. Para lograr la simplicidad organizativa y flexibilidad que permitan al sistema adaptarse a variaciones del flujo de demanda y diferencias en el producto, el toyotismo emplea diversas tcnicas de apoyo: Informacin y control visual KANBAN. Informacin y control visual ANDON. Sistemas de prevencin de errores Poka-yoke. Herramientas polivalentes y de cambio rpido.
El toyotismo o Sistema de Produccin Toyota es conocido actualmente como Lean.
22
Flexibilidad
Lean
La palabra lean en ingls significa magra, es decir, sin grasa.
Lean es un sistema de mejoramiento de procesos de manufactura basado en la eliminacin de desperdicios y actividades que no agregan valor al proceso.
14 principios Lean
1. Las decisiones del negocio estn basadas en una filosofa de largo plazo, an a expensas de las prdidas financieras a corto plazo. 2. Los ciclos son cortos y rpidos. 3. Se prefieren los sistemas pull, que evitan la sobreproduccin 4. La carga de trabajo debe ser balanceada (Heijunka) 5. La cultura est basada en detener la produccin para arreglar problemas, as como en ensear el estudio metdico de los problemas (Jidoka) 6. Las tareas se estandarizan para lograr la mejora continua (Kaizen) 7. La gestin visual simple revela problemas y permite la coordinacin 8. Se utiliza solamente tecnologa probada que pueda ser provechosa para la gente y su proceso. 9. Se forman lderes que comprendan el trabajo, vivan la filosofa de la empresa y la enseen a otros. 10. Se desarrollan equipos y personas excepcionales que siguen la filosofa de la compaa 11. Se respeta la red de colaboradores y proveedores (Keiretsu) , desafindolos a crecer y ayudndolos a la mejora. 12. Se valora que los responsables vayan y miren las situaciones en el lugar de trabajo, para entenderlas y poder ayudar. 13. Tome tiempo para decidir, basndose en el consenso y considerando minuciosamente todas las opciones. Implemente rpidamente. 14. Convierta y mantenga a su empresa en una organizacin que aprende a travs de la reflexin constante (Hansei) y de la mejora continua (Kaizen)
23
Flexibilidad
Algunas prcticas comunes en la produccin lean

He aqu algunas de las prcticas que se utilizan en entornos Lean: Kanban: o presentacin de informacin visual relativa a la produccin (identificacin de componentes, estado del proceso, etc) presentada fsicamente en el lugar de trabajo implicado y permanentemente actualizada. 5S: Metodologa de trabajo cuyo nombre procede de las 5 palabras japonesas que la configuran: seiri, sieton, seiso, siketsu and shitsuke (clasificar, ordenar, limpiar, estandarizar y sostener) Pokayoke: o sistema a prueba de error, que busca crear mecanismos que slo permiten hacer el trabajo de la forma adecuada. JIT (Just in time): producir en el momento que es requerido. Andon: Sistemas visuales de alertas sobre anomalas, fallos o problemas en el momento y lugar de la produccin. Jidoka. Instalcin en el proceso de sistemas que verifican su calidad. Heijunka. Tcnicas para adaptar la produccin a una demanda fluctuante del cliente.
Lean Software Development

Este trmino se refiere a la aplicacin de los principios Lean en el desarrollo del software. Mary y Tom Poppendieck (Poppendieck & Poppendieck, 2003)fueron quienes lo acuaron. Gracias a sus aportes y los de la comunidad gil, Lean Software Development est desarrollando un inventario de prcticas tiles para el desarrollo gil de software. . Se basa en 7 principios: 1. Eliminar el desperdicio Las actividades que no crean valor no sirven y deben ser eliminadas. Algunos ejemplos: Tareas que no fueron solicitadas por el cliente. Sobre documentacin del proyecto Procesos de desarrollo que se ejecutan sin analizar su nivel de eficiencia o vigencia. Mayor nmero de lneas de cdigo no siempre es mejor, y adems requiere mayor esfuerzo de testeo y de mantenimiento. Los errores, bugs y fallos del software son verdadero desperdicio que debe ser minimizado y eliminado. Construir con calidad Calidad en el proceso y en el producto. Un proceso que respeta la calidad es aquel que es conocido, entendido y mejorado por los propios participantes. Para lograrlo es necesario compromiso y respeto. Algunos ejemplos de prcticas que debe contemplar el proceso de desarrollo de software. Tcnicas como TDD (Test Driven Development) permiten que usuarios (clientes), programadores y tester definan claramente los requerimientos y confeccionen pruebas de aceptacin antes de escribir el cdigo. Ayuda a la comprensin de los programadores y mejora el entendimiento de los requerimientos. El programador es responsable de su propio desarrollo. No debe esperar a que Testing o QA descubra los errores. Fomentar el desarrollo de pruebas automatizadas. Refactorizacin del cdigo, para lograr simplicidad y eliminar duplicidades. 3. Compartir conocimiento Conocer la necesidad del cliente requiere dedicacin y esfuerzo. Debe convertirse en el aspecto principal, porque desarrollar un producto que no es til, es desperdicio.
2.
24
Flexibilidad
El desarrollo de software implica un proceso de aprendizaje: entender qu es lo que el cliente quiere y cmo entregar la mejor solucin posible. El desarrollo incremental proporciona cuantiosa y frecuente retro-informacin. 4. Diferir el compromiso Lean sostiene que el compromiso no puede hacerse con el cliente no se puede asumir hasta que los mismos no se encuentran claramente expresados y entendidos. Comenzar con requisitos incompletos, inestables e incoherentes es augura el fracaso del proyecto. En los proyectos giles que parten con una visin definida que evolucionar durante el desarrollo el compromiso con el cliente se asienta y evoluciona en la misma medida que se van concretando y comprometiendo los incrementos del producto.
5. Entregar rpido El desarrollo incremental realiza entregas rpidas a los clientes, quienes se encuentran con cdigo operativo desde etapas tempranas. Dicho cdigo debe ser desarrollado con calidad ya que no se puede mantener una velocidad importante de entrega si no se cuenta con calidad y un equipo disciplinado, comprometido y confiable. La entrega rpida permite a la organizacin ser competitiva respecto a otras, posicionarse en el mercado, y obtener ingresos de manera ms temprana. 6. Respetar a las personas Lean se basa en el respecto por las personas que son el elemento nico y diferenciador de cada organizacin. Deben estar suficientemente capacitadas y ser responsables de los procesos en los que intervienen, de modo que cuando resultan necesarios cambios y mejoras, cada persona colabora en su desarrollo. Optimizar el todo Lean invita a contemplar el proceso completo, es decir todo el flujo de valor, en lugar de hacerlo en cada etapa. El problema de optimizar cada fase por separado es que genera inventarios grandes en los puntos de transicin. En el mundo del software, estos "inventarios" representan al trabajo parcialmente terminado (por ejemplo, requisitos completos, pero sin disear, codificar o probar). Lean demostr que un flujo de "una pieza" (por ejemplo, enfocarse en construir un tem de manera completa) es un proceso ms eficiente que concentrarse en construir las partes separadas de forma rpida.
7.
25
Flexibilidad
Kanban Origen y definicin

El trmino japons Kanban, acuado por Taiichi Onho (Toyota), se puede traducir como tablero o tarjeta de sealizacin, y su origen se remonta finales de los cuarenta o principio de los cincuenta. Hace referencia a un sistema de visualizacin empleado en los procesos de produccin para coordinar en una cadena de montaje la entrega a tiempo de cada parte que cada parte, y slo cuando se necesita, reduciendo al mismo tiempo la sobreproduccin o almacenamientos innecesarios.
El trmino kanban aplicado a la gestin gil de proyectos se refiere a tcnicas de representacin visual de la informacin para mejorar la eficiencia en la ejecucin de las tareas de un proyecto
Su aplicacin en el sector TIC

El uso de tableros kanban facilita la visualizacin y gestin del flujo constante de avance y entrega evitando los dos problemas ms importantes: cuellos de botella y tiempos muertos. El desarrollo gil de software emplea prcticas de gestin visual por ser las que mejor sirven a los principios de comunicacin directa y simplicidad en la documentacin y gestin. Desde 2005 es cada vez ms frecuente reemplazar los formatos de lista para las pilas de producto y de sprint por notas adhesivas, que resultan ms verstiles al poder cambiar su posicin: para reordenar las prioridades de las historias de una pila de producto, e informar desde su posicin cules se estn programando, o probando, o ya se han terminado. Las prcticas kanban son una ayuda especialmente til en la gestin de proyectos evolutivos con entregas continuas. Como herramienta de control visual debe emplearse con criterios de flexibilidad, sin considerar prescripciones ni excepciones en el mtodo de trabajo, para lograr la implementacin personalizada, que de la mejor respuesta a los principios giles, de ingeniera concurrente o de sntesis de ambos, con los que trabaje la organizacin.
Gestin tcnica vs. gestin experta

Algunos autores consideran a Scrum y Kanban marcos o mtodologas que prescriben prcticas, artefactos y roles concretos. Segn Kniberg & Skarin se dibujan las siguientes diferencias entre ellos(Kniberg & Skarin, 2009): Scrum prescribe roles, kanban no. Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, mltiples o dirigidas por eventos). Scrum limita el wip por iteracin, kanban limita el wip por estado del flujo de trabajo. Los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas. Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en el flujo. En scrum la pila de producto debe tener la longitud de al menos un sprint. En kanban se debe atender al ritmo de arrastre de tareas. En scrum se deben estimar las historias y las tareas y calcular la velocidad, kanban no mide tareas ni velocidad. Scrum necesita una pila de producto priorizada, en kanban es la siguiente historia o tarea arrastrada desde el cliente. Scrum prescribe reuniones diarias, kanban no. Scrum emplea diagramas burndown, kanban no. Los tableros scrum se resetean al final de cada sprint.
26
Flexibilidad
Al entrar en un modelo de gestin basado en la experiencia y conocimiento propio, y abandonar el modelo de gestin tcnica, se flexibilizando las prcticas, y pierden relevancia cuestiones tcnico -metodolgicas como las siguientes: Situacin A: Por un lado se desea usar kanban, pero por otro se quiere estimar las tareas (por ejemplo para registrar la velocidad por razones organizativas de mi empresa) Situacin B: La empresa gestiona proyectos simultneos con una organizacin de oficina de proyectos y por eso encaja mejor el establecimiento de roles; pero sin embargo se quiere trabajar con kanban en lugar de con scrum Debera hacer scrumban? qu es eso? o lo que se va a hacer es Scrumbut? es la solucin de un mal gestor?. El uso de kanban como metodologa definida es una opcin de trabajo para la gestin tcnica, pero no para la autogestin y la gestin experta, porque limita la flexibilidad en la implantacin
27
Flexibilidad
Trabajando con tableros kanban: conceptos

Las prcticas de gestin visual kanban resultan tiles para: 1. Trazar la gestin de un procedimiento y controlar el flujo de ejecucin. 2. Radiar informacin. Un tablero kanban puede emplearse con una de estas finalidades, o ambas a la vez; aunque en realidad si se usa con la finalidad de control de flujo, siempre acompaa el hecho de mostrar la informacin del trabajo que se est controlando.
1.- Kanban para trazar la Gestin y Controlar el flujo.

Kanban como herramienta para la gestin del proyecto ofrece adems de informacin, pautas para el control del flujo de avance de las tareas. Monitorizacin y regulacin del flujo y la carga de trabajo La posicin de cada tarjeta sobre el tablero refleja el estado en el que se encuentra el trabajo correspondiente Los estados bsicos que se suelen representar en un tablero kanban son pendiente, en curso y terminado.
Ilustracin 9 Estructura bsica de un tablero kanban
En algunos casos puede resultar conveniente marcar sub-estados (por ejemplo: Testeado, Validado). El orden de los trabajos desde el rea pendiente, indica ya en el inicio la secuencia de las tareas segn sus prioridades. Los trabajos monitorizados puede ser del tamao de tareas, historias de usuario o epics, segn el uso que interese en cada tablero. Lleva a la superficie la informacin de los problemas. Los conflictos en la priorizacin de los trabajos, los problemas en el flujo por impedimentos o cargas de trabajo, las incidencias en el desarrollo, etc. se ponen de manifiesto de forma inmediata en la actualizacin continua sobre el tablero del estado de los trabajos. Facilita un ritmo sostenido y evita la ley de Parkinson Genera un avance continuo de trabajo cuyo ritmo no est marcado por una planificacin temporal: Gantt o Sprint (incremento iterativo).
28
Flexibilidad
La ausencia de hitos temporales evita la tendencia habitual de alargar el tiempo de trabajo hasta completar el tiempo estimado (ley de Parkinson).
El trabajo se expande hasta llenar el tiempo que se haba previsto

Ley de Parkinson.
Por otra parte, la ausencia de hitos temporales, sin tcnicas de monitorizacin y gestin del avance generara alargamiento de tiempos y retrasos por procrastinacin y perfeccionismo.
Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
Principio del Manifiesto gil
Facilita el incremento continuo Dando respuesta de esta forma al principio gil imprescindible: entrega frecuente de valor. Tareas que se completan con un ritmo sostenido y de forma continua, y con ellas historias de usuario que se van sumando al producto, proporcionndole un incremento continuo de valor segn las prioridades de negocio marcadas por el propietario del producto.
2.- Radiador de informacin.

Los principios giles a los que se puede dar un soporte adecuado usando kanban en su dimensin de radiador de informacin son: Favorece la comunicacin directa o Facilita la comunicacin directa del equipo al actualizar la informacin en reuniones enfrente de un tablero kanban. o Comparte la visibilidad de la evolucin del proyecto entre todos los implicados. Deteccin temprana de problemas o Kanban monotoriza continuamente la evolucin del proyecto. La actualizacin de la informacin just-in-time, ayuda a identificar en un primer momento los posibles impedimentos, problemas y riesgos, que de otra forma pasan desapercibidos hasta que empiezan a producir retrasos o repercusiones ya inevitables. Favorece una cultura de colaboracin y resolucin. o Es un medio de comunicacin abierto y transparente para el equipo y todos los participantes.
Secuencia y polivalencia
Al disear la estructura y el funcionamiento de un tablero kanban adecuado a un entorno determinado, dos son las variables de ese entorno a las que debe dar respuesta: Secuencia (del trabajo). Polivalencia (de las personas).
Secuencia.
Los trabajos reflejados en las tarjetas del tablero tienen que ejecutarse en un orden determinado o pueden realizarse en cualquier orden.?
29
Flexibilidad
No es lo mismo disear un tablero para el equipo de programadores de un sistema, que para el de mantenimiento de los sistemas informticos de una empresa. Para los primeros los trabajos se deben hacer en un orden de secuencia determinado. As por ejemplo, no es posible realizar la tarea de pruebas si antes no se ha hecho la de programacin. Sin embargo las siguientes podran ser las tareas de un equipo de mantenimiento: instalacin de nueva impresora en el equipo de direccin actualizacin del sistema operativo en el servidor web, etc. Este tipo de tareas se pueden realizar en cualquier orden. No hay una relacin de dependencia entre ellas de forma que no se pueda realizar una si la otra no se ha completado.
Polivalencia
Es un equipo polivalente o de especialistas? Por el tipo de trabajo y el perfil de los integrantes del equipo, cualquier miembro puede realizar cualquier tarea? Siguiendo con los ejemplos anteriores, es posible que en el equipo de mantenimiento una persona pueda indistintamente instalar una impresora, o un sistema operativo; o es posible que no: que haya tcnicos de hardware y tcnicos de software. De forma similar un proyecto de programacin puede incluir tareas especficas de diseo grfico, o programacin integracin testing, etc que pueden realizar slo determinados miembros del equipo.
Trabajando con tableros kanban: operativa

La imagen siguiente sintetiza grficamente que el valor clave de kanban es gestin de un flujo continuo de avance, y muestra las variables que se deben considerar para personalizar las prcticas kanban a las caractersticas de un trabajo y equipo concreto.
Ilustracin 10: Fortaleza y variables clave de los tableros kanban
Cuatro son los patrones posibles segn se combinen un tipo de trabajo secuencial o libre, con un equipo polivalente o de especialstas:
30
Flexibilidad
Ilustracin 11: reas de informacin y mejora reveladas por los tableros kanban
1.- Equipo polivalente realizando tareas que no requieren secuenciamiento.

Este es el entorno ms fcil de gestionar: cualquier persona del equipo puede realizar cualquier tipo de tarea, y las tareas se pueden tomar en cualquier orden. Si presenta problemas de saturacin de trabajo o tiempos muertos son la dimensin del equipo y / o la optimizacin del sistema las reas que se deben ajustar y mejorar.
2.- Equipo de especialistas realizando tareas que no requieren secuenciamiento.

La especializacin del equipo aporta un factor de complejidad para solucionar los posibles problemas de cuellos de botella y tiempos muertos. Si se producen cuellos de botella, la estrategia con el tipo de tareas que los provocan debe encaminarse en una o en ambas de las siguientes lneas: Dimensionamiento: bien del nmero de personas capacitadas para realizar ese tipo de tareas, bien en el nmero de tareas de ese tipo que se pueden comprometer, o en el tiempo de respuesta al cliente. Optimizacin del proceso de ejecucin de ese tipo de tareas. La presencia de tiempos muertos debe cuestionar el dimensionamiento, de la demanda o so distribucin no homognea.
3.- Equipo polivalente realizando tareas secuenciales

En este caso es la dependencia que unas tareas tienen de otras tiende a generar tensiones en el flujo y producir cuellos de botella en puntos determinados de la secuencia. La primera lnea de mejora en estos casos es el ajuste del WIP de cada fase, antes de antes de analizar el dimensionamiento del equipo y el compromiso.
31
Flexibilidad
WIP es un trmino ingls que en el campo de la manufactura lean, de donde proviene, se emplea para designer la cantidad de productos a medio fabricar que ann no estn terminados. En el uso de tableros kanban, por analoga se emplea este trmino para indicar las tareas que se encuentran en una fase del proyecto pendientes de pasar a la siguiente o de completarse, y en este entorno el trmino WIP se suele emplear con la acepcin de lmite o nmero mximo de tareas que pueden llegar a acumularse en un rea determinada. As por ejemplo, decir que en un tablero kanban para programacin de software el rea de testing o pruebas tiene un WIP de 3 quiere decir que no puede haber ms de tres tareas simultneamente en esa fase.
4.- Equipo de especialistas y trabajo que requiere un orden secuenciado.

Este es el entorno ms complejo porque requiere el ajuste y revisin en todas las lneas de mejora posible: dimensin y equilibrio de especialistas en el equipo, dimensin o equilibrio de tiempos de respuesta en el compromiso, y ajuste de lmites WIP en cada fase. En cada una de estas cuatro situaciones posibles el tablero saca en la superficie los problemas, y el equipo o gestor puede realizar los ajustes en las lneas de trabajo posibles segn cada caso y en funcin de su criterio y las circunstancias de su organizacin.
32
Flexibilidad
Casos prcticos de formatos de tableros kanban

En este apartado se muestran algunos ejemplos posibles de tableros para las distintas posibilidades y configuraciones vistas en el captulo anterior.
Ejemplo de tablero para ofrecer informacin relativa al estado de desarrollo del producto.
El ejemplo muestra un posible tablero instalado en la oficina de responsable de producto para reflejar el estado en el que se encuentra la construccin del producto. En este caso no se emplea la faceta de herramienta de gestin visual, sino solamente la de radiador de informacin visual. Tablero para mostrar visualmente la siguiente informacin relativa al estado de desarrollo del producto: Posibles historias de usuario sugeridas, que se encuentran en evaluacin sin determinar an si se incorporarn al producto. Historias de usuario aprobadas: se incorporarn al producto. Historias de usuario ya valoradas y priorizadas, previstas para ser programadas. Historias de usuario que se estn programando actualmente. Historias de usuario ya programadas que se pueden evaluar en el servidor de pruebas. Historias de usuario ya evaluadas, pendientes de desplegar. Historias de usuario desplegadas en las dos ltimas versiones.
Ilustracin 12: Ejemplo de tablero kanban para monitorizar el estado del producto
33
Flexibilidad
Ejemplos de tableros para desarrollo evolutivo, en incremento continuo y en incremento iterativo.
Ilustracin 13 Tableros: incremento continuo incremento iterativo
Este es un buen ejemplo del principio de flexibilidad o adecuacin de las prcticas a la organizacin y no al revs. Kanban, adems de ofrecer informacin visual, permite aplicar tcnicas como limitacin del wip y muestra las lneas de mejora para ajustar la cadencia del flujo. Resulta por tanto til, como ya hemos visto para trabajar con incremento continuo. Pero puede emplear kanban un equipo que haga scrum con incremento iterativo para emplear la representacin visual del avance de las tasreas en lugar de usar un grfico de avance? (por ejemplo)?. Por supuesto. Este apartado muestra ejemplos de tableros para ambos casos.
Caso 1: Incremento continuo.

Las siguientes imgenes representan posibles tableros para guiar la gestin de trabajo de un equipo que est desarrollando un producto en incremento continuo y en el que se refleja la siguiente informacin:
Pila de tareas. Tareas ya estimadas y preparadas para entrar a desarrollo. Tareas en anlisis. Tareas en codificacin. Tareas terminadas. Tareas integradas en el servidor de desarrollo (labs). Tareas integradas en produccin.
34
Flexibilidad
Ilustracin 14: Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo.
Ilustracin 15 Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo.
35
Flexibilidad
Ilustracin 16 Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo
Caso 2: Incremento iterativo.

Tablero configurado para representar y guiar la gestin de trabajo de un equipo que trabaja en incrementos iterativo (sprints) y que muestra: Pila de tareas. Tareas ya estimadas y preparadas para entrar en desarrollo. Tareas en anlisis. Tareas en codificacin. Tareas terminadas. Tareas integradas en el servidor de desarrollo (labs) Tareas integradas en produccin.
Ilustracin 17: Ejemplo de tablero kanban para monitorizar y gestionar incremento iterativo
Ejemplo de tableros para un equipo de operacin y mantenimiento.

Tablero que representa y gua la gestin de un equipo de operacin y mantenimiento que refleja:
36
Flexibilidad
Estado de las tareas programadas para la semana y persona que est trabajando con cada una. Estado de incidencias no previstas y urgentes, y personas que estn trabajando en cada una.
Ilustracin 18: : Ejemplo de tablero kanban para monitorizar y gestionar tareas de mantenimiento
37
Flexibilidad
Kanban Box
Una prctica diseada para responder a las dificultades de gestionar tareas de varios proyectos en el mismo departamento de produccin de software es una implementacin Kanban diseada en Scrum Manager, denominada Kanban Box. La configuracin es la siguiente: La organizacin mantiene una pila de produccin o lista de historias de usuario, pendientes, estimadas y priorizadas. Si la organizacin trabaja en un nico producto, la pila de produccin es en definitiva la pila del producto o product backlog. Si lleva a cabo el desarrollo o mantenimiento simultneo de varios sistemas, la pila de produccin es gestionada por los propietarios de producto, o la oficina de proyectos; en definitiva quienes sean responsables segn la estructura de la organizacin.
Ilustracin 19: Ejemplo de pila de producto con tarjetas kanban
En la pila de produccin las tareas estn estimadas y ordenadas segn los criterios de prioridad compartidos entre los intereses de los diferentes proyectos y de la organizacin en conjunto. El equipo que va a hacerse cargo de una historia, la descompone en tareas que representa en una caja kanban:
Ilustracin 20: Ejemplo de implementacin: kanban box
38
Flexibilidad
(1) (2)
Estimacin temprana de la historia, realizada por juicio de experto por el propietario del producto. Estimacin de la tarea realizada por el equipo al descomponer la historia en tareas.
En cada caja se representa:

(1) (2) (3) (4) (5) (6) Puntos totales de esfuerzo estimados Tarjetas con las tareas Un fondo de escala graduado con los puntos totales de esfuerzo estimados Barra dibujada con rotulador borrable que representa la velocidad prevista Barra de velocidad real Una descripcin de la historia de usuario.
Ilustracin 21: Ejemplo de implementacin: kanban box
De esta forma se van encajando las historias de usuario, o preparando para pasar a produccin.
Ilustracin 22 : Ejemplo de implementacin: kanban box
Las cajas preparadas van entrando en los slots disponibles en la columna pendiente del tablero general de la organizacin.
39
Flexibilidad
Ilustracin 23 : Ejemplo de implementacin: kanban box
A diario, cada equipo realiza la reunin de seguimiento o reunin de pie frente al tablero, actualizando el estado de cada tarea (pendiente -> en curso -> hecho), y la actualizacin de las barras de velocidad: La barra de velocidad prevista (1) se actualiza todos los das considerando la velocidad media de la organizacin y el n de miembros del equipo. Si por ejemplo se trata de un equipo de 3 personas y la velocidad media es de 3 puntos por persona/da, cada da la barra de velocidad prevista disminuye e 9 puntos. La barra de velocidad real (2) representa la suma del esfuerzo de las tareas que an se encuentran en estado pendiente y en curso. La diferencia de altura entre las barras de velocidad muestra desviaciones del esfuerzo previsto, en uno u otro sentido, de forma visual y rpida, de forma similar a un grfico burn-down.
40
Flexibilidad
Muda, Mura y Muri y algunos consejos para ajustar el flujo.

Muda, Mura y Muri son tres conceptos claves de la mejora continua Kaizen, que la produccin Lean incorpora como variables protagonistas para incrementar la eficiencia. Muda: Desperdicio Mura: Discrepancia. Variabilidad del flujo de trabajo. Interrupciones en el flujo de trabajo. Tiempo muerto. Muri: Tensin. Sobrecarga de trabajo que produce cuellos de botella.
Mudas
Las mudas o razones de desperdicio ms habituales en los proyectos TIC son: Burocracia: Procedimientos, documentacin y papeleo innecesario que no aportan valor al resultado. Sobreproduccin: Desarrollar ms caractersticas de las necesarias. Multiproyecto: Alternar el tiempo de trabajo entre varios proyectos e interrupciones del flujo de trabajo. Esperas: Tiempos de espera por falta de cadencia en el flujo de trabajo. Ir haciendo: Encargar trabajo para ir avanzando algo no definido y as no tener paradas a las personas. Desajustes de capacidad: Personas de gran talento asignadas a tareas rutinarias, y viceversa. Errores: Retrabajo por bugs. Los tableros kanban resultan especialmente tiles para detectar y gestionar las otras dos variables kaizen: Mura y Muri.
Factores determinantes de Mura y Muri

Cada organizacin tiene sus propias caractersticas en cuanto a: Secuencia de las tareas. Polivalencia de los miembros del equipo. Y estos son los factores que en cada caso determinan la dificultad o no para lograr un flujo continuo de desarrollo. Como ya se ha visto, los equipos que trabajan con tareas no secuenciales y en proyectos en los que pueden trabajar de forma polivalente, son los que ms fcilmente pueden conseguir un flujo de entrega constante. Cuando surgen las dificultades las variables que se deben combinar, segn las posibilidades en cada caso, son: Volumen de demanda. Orden del backlog o pila de historias de usuario: si se va a producir un cuello de botella en una fase, procurar que la prxima historia que va a entrar al tablero requiera poco esfuerzo de esa fase. WIP o lmite de tareas en una determinada fase. Staffing: Tamao del equipo y especializacin o polivalencia.
Muri
Analicemos cmo el WIP se convierte en un mtodo para ajustar los cuellos de botella (Muri): Al emplear kanban como tcnica con la que regular un incremento continuo desaparece el concepto de sprint. El incremento no es en este caso el resultado de un sprint, sino cada historia de usuario que se termina y entrega. Para lograr un flujo continuo de funcionalidades que, una a una van aportando incrementos de forma sostenida, es necesario evitar la aparicin de cuellos de botella (Muri): la acumulacin de tareas en una determinada fase del proceso. Una tcnica muy til es limitar la cantidad de trabajo que puede acumularse en las fases y generan cuellos de botella.
41
Flexibilidad
Al parmetro que indica el nmero mximo de tareas en un rea del tablero kanban se le denomina WIP: Work In Process, o bien in-process inventory (inventario en el proceso). No se debe confundir con Work in progress (trabajo en progreso) trmino que designa un trabajo que ha comenzado pero an no est terminado. Un valor WIP demasiado bajo puede producir cuellos de botella en otras fases, en especial si el sistema es demasiado rgido (tareas secuenciales y equipo de especialistas). La experiencia ayuda al equipo a ir ajustndolo para lograr un flujo continuo, o lo ms continuo posible. Si no se cuenta con experiencia previa, y considerando que las tareas no deberan tener tamaos mayores de 4 horas ideales, el equipo debe establecer un criterio de inicio, y a partir de l ir ajustando. En este sentido una recomendacin generalmente til (en equipos de personas polivalentes) es empezar con un WIP igual al n de miembros del equipo x 1.5, redondeando el resultado por exceso, x 2. No es aconsejable trabajar con tareas de tamao que se prevea superior a un da de trabajo, y si esto ocurre lo aconsejable es dividirlas en otras de menor tamao. Ejemplo: La figura siguiente presenta una implementacin kanban con lmite de trabajo en los estados Producto analizado y En curso.
Ilustracin 24 WIP
En este ejemplo, el propietario de producto tiene una zona para registrar y ordenar de forma priorizada el backlog (A). Es el rea en la que el responsable de producto aade, modifica, y reordena la prioridad de cada historia de forma continua. Pero slo son tres las historias que pueden estar en estado decididas para pasar a produccin. Tres con la que ya est previsto analizar y revisar la estimacin con el equipo. De igual forma, el rea en curso tiene un lmite de tres historias. Hasta que una no pasa a HECHO, no puede entrar ninguna a produccin, y de igual forma mient ras haya tres en la zona ANALIZADO no se decide cul ser la prxima historia del backlog. De esta forma se crea un flujo de trabajo sin cuellos de botella, continuo y enfocado.
Mura
Los principales factores responsables de la variabilidad del flujo y la aparicin de Mura o tiempos muertos son: Grado de multifuncionalidad de los miembros del equipo Flexibilidad en el orden en el que se deben hacer las diferentes fases de cada tarea Flexibilidad para alterar el orden de entrada de las historias de usuario desde la pila de producto Cuanto mayores sean estos aspectos, ms fcil resulta evitar la aparicin de tiempos muertos.
42
Flexibilidad
Responsabilidades con Scrum a nivel de gestin

Al escalar scrum de gestin tcnica de proyectos a gestin experta de la organizacin, el mbito de responsabilidades que se deben cubrir va ms all de los roles de proyecto: La organizacin es una realidad sistmica y para considerar la agilildad con mbito global se debe dar respuesta de forma coordinada y alineada con la visin de la organizacin a responsabilidades en tres reas: Gerencia, procesos y produccin.
Ilustracin 25: reas de responsabilidad Scrum Manager
De gerencia
Equilibrio sistmico de la organizacin Coherencia del modelo Medios y formacin
De procesos
Configuracin flexible de Scrum Mejora continua Garanta de funcionamiento de Scrum en cada proyecto (en Scrum estndar asignada al rol de Scrum Master)
De produccin
Producto(en Scrum estndar asignada al rol de Propietario del producto) Auto-organizacin (en Scrum estndar asignada al equipo) Tecnologa gil (en Scrum estndar asignada al equipo) El uso de prcticas y tecnologas giles, el trabajo en equipos autoorganizados, disponer de una visin de producto definida y gestionada durante todo el proyecto y garantizar el funcionamiento de scrum durante la ejecucin, son responsabilidades que pertenecen al mbito del proyecto. Que las diferentes reas de la empresa se encuentren comunicadas y alineadas con una visin comn, coherente con un modelo de trabajo gil, disponga de medios para el diseo e implantacin de una implantacin gil adecuada a la empresa, mejora continua del modelo y formacin a las personas, son responsabilidades en el mbito de la organizacin.
43
Flexibilidad
Ilustracin 26: mbitos de responsabilidad Scrum Manager
En un marco estndar de Scrum las responsabilidades del mbito del proyecto las asumen roles definidos: La responsabilidad de funcionamiento de Scrum se asigna a un rol de gestor especfico para el funcionamiento de Scrum: Scrum Master. La responsabilidad de visin y gestin del producto al rol especfico de propietario del producto, o product owner. La responsabilidad de autoorganizacin y uso de prcticas y tecnologas giles es propia del equipo. Lo ms comn y aconsejable en fases de implantacin, en equipos no familiarizados con desarrollo gil es la adopcin de este modelo de roles estndar de Scrum. En la evolucin hacia un nivel ms maduro y global de agilidad en la organizacin es aconsejable adaptar el marco de scrum a la realidad de la organizacin, de forma que lo relevante no es la adopcin de determinados roles, sino dar respuesta adecuadamente a todas las responsabilidades. Un ejemplo de asignacin flexible de las responsabilidades del mbito de poroyecto sobre los roles ya existentes en la organizacin podra ser: Garanta de funcionamiento de Scrum => Calidad o procesos Garanta de gestin de producto => Product manager Auto-organizacin y tecnologa gil = Equipo Tanto si en la implantacin de agilidad en la organizacin, las responsabilidades necesarias se asignan a roles de la estructura de la empresa, o se crean nuevos puestos (Product Owner o Scrum Master), lo importante es que las personas que los desempean tengan la experiencia y conocimiento profesional necesario.
Responsabilidades de producto.
Para simplificar la comunicacin y toma de decisiones es necesario que las responsabilidades de gestin del producto las asuma una nica persona. Si se trata de organizaciones cliente grandes o con varios departamentos, stas pueden tener la forma de comunicacin interna que consideren oportuna, pero en el equipo de desarrollo slo se debe incorporar a una persona representando al cliente y con las responsabilidades de producto. Esta persona debe tener el conocimiento suficiente del producto y las atribuciones necesarias para tomar las decisiones que le corresponden.
44
Flexibilidad
Implicaciones de la responsabilidad de producto:

Conocer perfectamente el entorno de negocio del cliente, las necesidades y el objetivo que se persigue con el sistema que se est construyendo. Atribuciones suficientes para tomar las decisiones necesarias durante el proyecto. Conocer el marco estndar de Scrum para realizar con solvencia las tareas que le corresponden: o Desarrollo y administracin de la pila del producto. o Presentacin y participacin en la planificacin de cada sprint. Recibir y analizar de forma continua retroinformacin del negocio (evolucin del mercado, competencia, alternativas, etc. ) y del proyecto (sugerencias del equipo, alternativas tcnicas, pruebas y evaluacin de cada incremento, etc.). Es recomendable conocer y haber trabajado previamente con el mismo equipo. Es quien decide en ltima instancia cmo ser el resultado final, y el orden en el que se van construyendo los sucesivos incrementos: qu se pone y qu se quita de la pila del producto, y cul es la prioridad de las funcionalidades. Es responsable de las decisiones sobre fechas y funcionalidades de las diferentes versiones del producto, y el retorno de la inversin del proyecto. En los desarrollos internos para la propia empresa, suele asumir este rol el product manager o el responsable de marketing. En desarrollos para clientes externos: el responsable del proceso de adquisicin del cliente.
Responsabilidades del equipo

Se recomienda un tamao de equipo entre 4 y 8 personas. Ms all de 8 resulta ms difcil mantener la agilidad en la comunicacin directa, y se manifiestan con ms intensidad las rigideces habituales de la dinmica de grupos (que comienzan a aparecer a partir de 6 personas). Las principales responsabilidades, ms all de la auto-organizacin y uso de tecnologas giles, son las que se derivan de la diferencia entre grupo de trabajo y equipo.
Un grupo de trabajo es un conjunto de personas que realizan un trabajo, con una asignacin especfica de tareas, responsabilidades y siguiendo un proceso o pautas de ejecucin. Los operarios de una cadena, forman un grupo de trabajo: aunque tienen un jefe comn, y trabajan en la misma organizacin, cada uno responde por su trabajo. El equipo tiene espritu de colaboracin, y un propsito comn: conseguir el mayor valor posible para la visin del cliente. Un equipo Scrum responde en su conjunto. Trabaja de forma cohesionada y autoorganizada. No hay un gestor que delimita, asigna y coordina las tareas. Son los propios componentes del equipo los que lo realizan. En el equipo: Todos conocen y comprenden la visin del propietario del producto. Aportan y colaboran con el propietario del producto en el desarrollo de la pila del producto. Comparten de forma conjunta el objetivo de cada sprint y la responsabilidad del logro. Todos los miembros participan en las decisiones. Se respetan las opiniones y aportaciones de todos Todos conocen el modelo de trabajo con Scrum.
45
Flexibilidad
Hay un responsable o lder del equipo que asume las responsabilidades de garanta de funcionamiento del campo de Scrum en el proyecto. En las fases de implementacin de Scrum, con equipos sin demasiada experiencia en desarrollo gil con Scrum, y en organizaciones con demasiada rotacin de personas de los equipos entre proyectos, es recomendable la figura de un Scrum Master para asumir estas responsabilidades.
Responsabilidad de funcionamiento de Scrum en el proyecto

Es el responsable del funcionamiento de Scrum en el proyecto, cubriendo los aspectos siguientes que la organizacin necesite segn el conocimiento, experiencia con el modelo y nivel de institucionalizacin al que se encuentran asentadas las prcticas y cutura gil.
Asesora y formacin al Propietario del producto. Asesora y formacin al equipo. Revisin y validacin de la pila del producto. Moderacin de las reuniones. Resolucin de impedimentos que en el sprint pueden entorpecer la ejecucin de las tareas. Gestin de la dinmica de grupo en el equipo Respeto de la organizacin y los implicados, con las pautas de tiempos y formas de Scrum Configuracin, diseo y mejora continua de las prcticas de Scrum en la organizacin.
Cuanto ms institucionalizada se encuentra la cultura gil en la organizacin menos necesaria es la asignacin de esta responsabilidad a un rol especfico, por estar implcitamente asumidas por los implicados en el proyecto. En casos intermedios es habitual la figura de un team leader en el equipo para cubrir las responsabilidades anteriores con nuevos miembros o propietarios de producto.
46
Bibliografa
Bauer, F., Bolliet, L., & Helms, H. (1969). Software Engineering. Report on a conference sponsored by the NATO SCIENCE COMITEE. Software Engineering (pg. 136). Garmisch: Peter Naur & Brian Randell. Hino, S. (2006). Inside the Mind of Toyota: Management Principles for Enduring Growth. Productivity Press. Kniberg, H., & Skarin, M. (2009). Kanban and Scrum, making the most of both. crisp. Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. University Press. Nonaka, I., & Takeuchi, H. (1986). The New New Product Development Game. Harvard Business Review . Nonaka, I., & Takeuchi, I. (2004). Hitotsubashi on Knowledge Management. Singapore: John Wiley & Sons. Ohno, T. (1988). The Toyota Production System: Beyond Large-scale Production. Productivity Press. Orr., K. (2003). CMM versus Agile Development: Religious wars and software development. Cutter Consortium, Executive Reports 3(7) . Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit for Software Development Managers. Addison Wesley. Schwaber, K. (1995). SCRUM Development Process. Burlington: OOPSLA 95. Turner, R., & Jain, A. (2002). Agile Meets CMMI: Culture Clash or Common Cause? XP/Agile Universe 2002 , 153-165.
Tabla de ilustraciones
Ilustracin 1: Patrn dialctico ......................................................................................................................... 10 Ilustracin 2: Evolucin de los primeros modelos de mejora .......................................................................... 11 Ilustracin 3: Espiral dialctica del conocimiento ............................................................................................ 12 Ilustracin 4: La empresa como sistema ......................................................................................................... 13 Ilustracin 5: Diagrama de conceptos de la gestin de proyectos .................................................................. 14 Ilustracin 6: Personas, procedimientos y tecnologa ..................................................................................... 16 Ilustracin 7: Agilidad con desarrollo incremental iterativo ............................................................................. 20 Ilustracin 8: De la artesana a la produccin lean ......................................................................................... 21 Ilustracin 9 Estructura bsica de un tablero kanban .................................................................................. 28 Ilustracin 10: Fortaleza y variables clave de los tableros kanban ................................................................. 30 Ilustracin 11: reas de informacin y mejora reveladas por los tableros kanban ......................................... 31 Ilustracin 12: Ejemplo de tablero kanban para monitorizar el estado del producto ...................................... 33 Ilustracin 13 Tableros: incremento continuo incremento iterativo ........................................................... 34 Ilustracin 14: Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo. ...................... 35 Ilustracin 15 Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo. .................... 35 Ilustracin 16 Ejemplo de tablero kanban para monitorizar y gestionar incremento continuo ..................... 36 Ilustracin 17: Ejemplo de tablero kanban para monitorizar y gestionar incremento iterativo ....................... 36 Ilustracin 18: : Ejemplo de tablero kanban para monitorizar y gestionar tareas de mantenimiento ............ 37 Ilustracin 19: Ejemplo de pila de producto con tarjetas kanban .................................................................... 38 Ilustracin 20: Ejemplo de implementacin: kanban box ................................................................................ 38 Ilustracin 21: Ejemplo de implementacin: kanban box ................................................................................ 39 Ilustracin 22 : Ejemplo de implementacin: kanban box ............................................................................... 39 Ilustracin 23 : Ejemplo de implementacin: kanban box ............................................................................... 40 Ilustracin 24 WIP........................................................................................................................................ 42 Ilustracin 25: reas de responsabilidad Scrum Manager .............................................................................. 43 Ilustracin 26: mbitos de responsabilidad Scrum Manager .......................................................................... 44
ndice
Cascada, 15 Conocimiento explcito, 16 tcito, 16 Conocimiento tcito, 15 Crisis del software, 10 Desarrollo completo, 14 Desarrollo incremental, 14 Desarrollo incremental continuo, 15 Desarrollo incremental iterativo, 15 Divisin del trabajo, 21 Ejemplo de tablero kanban para ofrecer informacin, 33 Ejemplo detablaro kanban para operacin y mantenimiento, 37 Empresa como sistema, 12 Equipo Caractersticas, 45 Equipo (rol), 45 Espiral dialctica del conocimiento, 12 Flexibilidad, 13, 27 Fordismo, 22 Gestin evolutiva, 15 Gestin experta, 10, 12, 13, 27 Gestin predictiva, 10, 15 Gestin tcnica, 10, 12, 13, 27 Incremento Continuo Ejemplo de tableros kanban, 34 Iterativo Ejemplo de tableros kanban, 36 Incremento iterativo, 20 Ingeniera concurrente, 15 Ingeniera de procesos, 10 Ingeniera del software, 10 Kanban Aplicacin en el sector TIC, 26 Definicin, 26 Kanban Box, 38 Origen y definicin, 26 Lean 14 principios, 23 Definicin, 23 Lean Software Development, 24 Ley de Parkinson, 28 Muda, 41 Mura, 41, 42 Muri, 41 Organizacin cienttica del trabajo, 21 Patrn dialctico, 10 Polivalencia, 30 Procesos, 16 Produccin en cadena, 22 Responsabilidades Scrum Manager, 43 Scrum estndar, 20 Scrum Manager Prcticas, 16 Procedimientos, 16 Secuencia, 29 Tablero kanban conceptos, 28 estructura bsica, 28 lneas de informacin y mejora, 31 operativa, 30 Toyotismo, 22

Scrum II

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Scrum II

Загружено:

Авторское право:

Доступные форматы

Gestin flexible de proyectos

2005-2013 ScrumManager - http://www.scrummanager.net

Sobre la formacin de Scrum Manager

Formacin Scrum Manager

La formacin libre de Scrum Manager es posible gracias a la subvencin y soporte de los:

Servicios de formacin y asesora presencial Scrum Manager

http://www.scrummanager.net http://www.scrummanager.net/oks admin@scrummanager.net

2005-2013 ScrumManager - http://www.scrummanager.net

Evaluacin para control de calidad y mejora de Scrum Manager

Evaluacin para mejora continua y control de calidad de Scrum Manager

2005-2013 ScrumManager - http://www.scrummanager.net

Gestin flexible con Scrum

Principios de Scrum Manager

Ilustracin 1: Patrn dialctico

2005-2013 ScrumManager - http://www.scrummanager.net

Gestin flexible con Scrum

Ilustracin 2: Evolucin de los primeros modelos de mejora

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Gestin flexible con Scrum

(Turner & Jain, 2002)

Espiral dialctica del conocimiento.

Ilustracin 3: Espiral dialctica del conocimiento

2.- Empresa como sistema

2005-2013 ScrumManager - http://www.scrummanager.net

Gestin flexible con Scrum

Ilustracin 4: La empresa como sistema

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Gestin flexible con Scrum

Ilustracin 5: Diagrama de conceptos de la gestin de proyectos

2005-2013 ScrumManager - http://www.scrummanager.net

Gestin flexible con Scrum

Patrones de gestin del proyecto

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Gestin flexible con Scrum

Personas, Procesos y Tecnologa

Ilustracin 6: Personas, procedimientos y tecnologa

2005-2013 ScrumManager - http://www.scrummanager.net

Gestin flexible con Scrum

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Incremento continuo con gestin visual kanban

Ilustracin 7: Agilidad con desarrollo incremental iterativo

2005-2013 ScrumManager - http://www.scrummanager.net

Introduccin: De la artesana a la produccin Lean

Ilustracin 8: De la artesana a la produccin lean

Divisin del trabajo

Organizacin cientfica del trabajo

Sistema de produccin Toyota

El toyotismo o Sistema de Produccin Toyota es conocido actualmente como Lean.

2005-2013 ScrumManager - http://www.scrummanager.net

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Algunas prcticas comunes en la produccin lean

Lean Software Development

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Kanban Origen y definicin

Su aplicacin en el sector TIC

Gestin tcnica vs. gestin experta

2005-2013 ScrumManager - http://www.scrummanager.net

2005 - 2013 ScrumManager Project http://www.scrummanager.net

Trabajando con tableros kanban: conceptos

1.- Kanban para trazar la Gestin y Controlar el flujo.

Ilustracin 9 Estructura bsica de un tablero kanban

2005-2013 ScrumManager - http://www.scrummanager.net

El trabajo se expande hasta llenar el tiempo que se haba previsto