mejora continua en la gestión de una unidad de ti ... · producto 6 incluye además consultoría,...

Técnica Federico Santa María

Departamento De Informática

Magíster En Tecnologías De La Información

1

Mejora continua en la gestión de una unidad de TI implantando prácticas ágiles guiada por TUNE-UP

Juan Pablo Arriagada Cancino

Área de Infotecnologías, Facultad de Ciencias Físicas y Matemáticas, Universidad de Chile Avenida Beaucheff 850, Biblioteca Central, 5º Piso, ADI

[email protected]

Resumen: La división de el Área de Infotecnologías (ADI) para la creación del Centro Tecnológico Ucampus impactó en la capacidad del equipo principalmente en temas de experiencia, transmisión de conocimiento, estándares y comunicación. La propuesta de solución consistió en la evaluación e implantación de prácticas ágiles guiadas por el enfoque TUNE-UP para mejorar la experiencia y comunicación del equipo de desarrollo, además de mejorar el seguimiento, priorización y visibilidad de los proyectos. Para la validación de la propuesta se crearon medios tangibles como tableros o herramientas de software, además de una encuesta estandarizada para medir el nivel de agilismo. El resultado a la fecha es un equipo de desarrollo auto-gestionado cuyo espíritu es la mejora continua en todos los aspectos de la realización de su trabajo. Palabras Clave: Agilidad, Agile Roadmap+, TUNE-UP, Mejora Continua.

1 Introducción

1.1 Contexto y definición del problema

El Área de Infotecnologías1 (ADI) de la Facultad de Ciencias Físicas y Matemáticas (FCFM) ha sido responsable por casi dos décadas de la mejora de los procesos académicos de la Universidad de Chile a través de técnicas de reingeniería y desarrollo de software. La culminación de esta labor se plasma hoy en dos servicios de software: Ucampus y U-Cursos que a partir del año 2017 se ofrecen a todas las Universidades públicas y privadas a través del Centro Tecnológico Ucampus. La reciente reestructuración del área producto de la formación del Centro Tecnológico Ucampus impacta directamente en la capacidad del equipo del ADI. A la fecha en que se escribe este documento trabajan en el área cinco personas dando soporte y mantención a más de una treintena de APIs2, módulos3 y workflows4 de diversa complejidad. De igual forma se sigue realizando reingeniería de procesos y desarrollo de software para la Dirección Económica y Administrativa, Escuela de Pregrado y Escuela de Postgrado de la FCFM, además de proyectos de Investigación y Desarrollo internos. El ADI, según la opinión de los funcionarios de la FCFM y de la Universidad de Chile, se ha caracterizado históricamente por la excelencia en la entrega de soluciones con una mirada crítica en la mejora de los procesos. Se vuelve fundamental en este contexto analizar y optimizar los procesos internos del área, así como también

1 http://adi.ing.uchile.cl 2 Interfaces de desarrollo de aplicaciones para facilitar la integración o extraer información. 3 Paquetes de funcionalidad que funcionan sobre Ucampus, por ejemplo: Rebajas de Arancel de Postgrado, Overheads,

Facturación Electrónica, Gestión de Resoluciones, Cometidos Funcionarios, etc. 4 Flujos de trabajo automatizados, modelados y soportados mediante el uso de un módulo propio.

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

2

comprender y potenciar los factores motivacionales del equipo. Este trabajo se centra principalmente en el equipo de trabajo ligado al proceso de desarrollo y gestión de los proyectos de software. Los problemas observados se suceden principalmente debido a la disminución del equipo de desarrollo, pasando de un equipo de dos arquitectos de software y siete desarrolladores a sólo cinco desarrolladores, llevándose los arquitectos gran parte del conocimiento técnico del área. Estos problemas pueden agruparse según: • Seguimiento y priorización de los proyectos: previo a la re estructuración, la mayor parte del trabajo se

centraba en la mantención del software existente, esto era la prioridad. Dado que el negocio principal era la continuidad operativa, no existían plazos rígidos para la entrega de los nuevos desarrollos; debido a esto el seguimiento a los proyectos era básico. En el contexto actual es necesario conocer el estado de avance y prioridad de cada uno de los proyectos.

• Visibilidad de los proyectos: previo a la re estructuración, cada desarrollador trabajaba de forma aislada con un jefe de proyectos debido a la existencia de estos dos los arquitectos de software que tenían un conocimiento holístico del sistema, no era necesario comunicar a los demás desarrolladores sobre las decisiones, tratándose cada nuevo desarrollo como un silo. En contexto actual es necesario que todo el equipo tenga conocimiento sobre lo que se está trabajando con la finalidad de cohesionar y potenciar de forma transversal los desarrollos.

• Experiencia y comunicación del equipo: previo a la re estructuración, se valoraba e idolatraba la capacidad de solucionar problemas complejos, muchas veces comunes, de forma autónoma. De esta forma el conocimiento quedaba focalizado y si bien no existía egoísmo de por medio, el ego muchas veces era más fuerte. En el contexto actual no es posible perder tiempo “reinventando la rueda”, es necesario hacer fluir el conocimiento en el equipo; privilegiar la colaboración por sobre el heroísmo.

• Estándares y estilos de desarrollo: previo a la re estructuración, si bien existía un documento titulado “estándar de desarrollo de software ADI” y el mismo era difundido, cada uno de los desarrolladores tomaba de forma parcial partes del mismo y el resto se realizaba bajo el propio estilo de cada uno pues, era muy poco probable que otro desarrollador tuviese que intervenir el código. En el contexto actual, cada miembro del equipo debe tener la capacidad de interactuar con código de otras personas, cobrando importancia el contar con un estándar adoptado así como también estilos similares de desarrollo.

Las necesidades del contexto actual definen el problema en su totalidad: ¿Cómo lograr estos cambios en el contexto actual del ADI?

1.2 Propuesta de solución, objetivos y marco teórico

En la experiencia laboral del autor de este trabajo en empresas especializadas en desarrollo de soluciones de software o fábricas de software, es posible suponer que los problemas anteriormente mencionados suceden, entre otras cosas, debido a la inexistencia de un proceso riguroso para la gestión de los proyectos y de soporte para el proceso de desarrollo de software. No obstante, es el hecho anteriormente mencionado unido al éxito del equipo lo que más le fascino y llamó la atención inicialmente. ¿Cómo es posible que a pesar de esto pudiese crearse Software que aportara valor? Agustín Villena, Docente del Departamento de Ciencias de la Computación (DCC) de la FCFM de la Universidad de Chile y Fundador de Chile Ágil define Agilidad Esencial como “la Capacidad que permite a las Organizaciones Aprender continuamente para Adaptar su oferta de valor frente a la Alta Incertidumbre” [1]. Ésta es, según el autor, la respuesta a la pregunta. ADI se ha caracterizado por aprender continuamente, adaptándose para entregar valor de forma continua. Debido a las características particulares de la forma de trabajo del área y del equipo de desarrollo, no es factible la adopción rigurosa de normas para la gestión de proyectos como PMBOK de la PMI o metodologías de desarrollo de software como RUP. En el curso optativo “Gestión Ágil de Proyectos de Software” dictado por Patricio Letelier, académico de la Universidad Politécnica de Valencia (UPV) y Doctor en Informática de la misma casa de estudios, se tuvo un primer acercamiento a la solución de esta problemática.




3

El enfoque TUNE-UP es fruto del trabajo realizado desde el año 2000 con métodos ágiles por parte de Patricio Letelier y su equipo en la UPV. Este enfoque global permite abordar la implantación de prácticas5 ágiles recogidas desde métodos ágiles como Kanban, Lean, Scrum y Extreme Programming. TUNE-UP como producto6 incluye además consultoría, formación y un software de apoyo para la gestión ágil de proyectos. La definición más cercana de práctica asociada al concepto utilizado por TUNE-UP es: “Ejercicio o realización de una actividad de forma continuada y conforme a sus reglas”. Una práctica ágil corresponde entonces a la realización de una actividad de forma continuada perteneciente a alguna metodología ágil como XP, Scrum, Lean o Kanban conforme a sus propias reglas. La posibilidad de descomponer una o muchas metodologías en prácticas con la finalidad de encontrar el mejor subconjunto de ellas que permite potenciar un equipo en un contexto particular está alineado con los principios de la Comunidad Ágil Latinoamericana que habla de la necesidad de hacer “Agilidad con Propósito” 7, no por moda. En este contexto se puede hacer un paralelo con las Artes Marciales, entra el concepto de shuhari. Si bien, un concepto Japonés, en el entrenamiento de diversas artes y disciplinas marciales el camino desde ser aprendiz hasta llegar a ser un maestro involucra básicamente tres estados o etapas: obedecer (shu, sabiduría tradicional), desprenderse (ha, ruptura con la tradición) y finalmente trascender (ri , fluir naturalmente sin aferrarse a la forma). El estudio, práctica y fiel obediencia de metodologías ágiles tradicionales como Scrum y XP corresponden en esta analogía al Shu. Para el enfoque TUNE-UP lo importante son las prácticas ágiles y la sinergia que generaría la aplicación de más prácticas8 y en mayor profundidad [2] de esta manera rompe la tradición metodológica siendo una aproximación al Ha. El estado Ri, el más elevado, es aquel que han alcanzado aquellas personas capaces de aplicar los principios esenciales de la agilidad en cualquier contexto y situación. No existe una receta milagrosa para llegar a este punto, sólo existe práctica en la forma de casos de éxito y fracasos. No obstante existen detractores9 de esta descomposición y adaptación de metodologías cuya máxima es que, al adaptarla, no se puede obtener el potencial completo de la misma. Efectivamente, según la opinión del autor, están en lo correcto. No obstante, es factible también implantar de forma incremental de manera que a largo plazo pueda ir alcanzándose el potencial completo del uso de una metodología de forma canónica, sin generar rechazo en el equipo de trabajo. El enfoque TUNE-UP identifica cuarenta y dos prácticas ágiles relacionadas con el producto, el cliente, el equipo y la definición y mejora continua del proceso que a su vez están asociadas a cuatro metodologías ágiles (XP, Scrum, Lean y Kanban). Para la realización de este trabajo se utilizará el enfoque TUNE-UP para seleccionar y priorizar las prácticas ágiles a implantar en el equipo, así como también evaluar de forma más objetiva el impacto que el proceso de implantación tuvo sobre el mismo. No se utilizará la herramienta de software que provee el enfoque. El proceso de implantación requerirá además la evaluación de piezas de software que permitan dar soporte a aquellas prácticas que las requieran. En este sentido, no es factible seguir el modelo de implantación provisto por TUNE-UP donde se realiza una

5 Habilidad o experiencia que se consigue o se adquiere con la realización continuada de una actividad. 6 El trabajo se basa en TUNE-UP como enfoque metodológico, no existe factibilidad de adquirir la licencia del software. 7 Según el consenso de más de 800 profesionales que participaron en las “X Jornadas Latinoamericanas de Agilidad”

celebradas el 12, 13 y 14 de Octubre en Chile. http://agiles2017.agiles.org 8 El listado completo de las prácticas ágiles definidas en el enfoque TUNE-UP puede ser encontrado en el Anexo 1. 9 Scrum.org es un detractor. Define “ScrumBut” a la implementación no canónica de su metodología; por ejemplo: “(We

use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have one per week.)” . https://www.scrum.org/resources/what-scrumbut




4

capacitación de todas las prácticas al inicio del proceso de implantación para luego evaluar después de 4 meses, el proceso debe ser iterativo e incremental. Los pasos a seguir son los siguientes:

1. Evaluación del nivel de agilismo: con la finalidad de contar con una medición más objetiva del impacto de las prácticas implantadas se aplicará una encuesta que permite establecer el “nivel de agilidad” del equipo además de ayudar a identificar los objetivos de mejora relevantes.

2. Selección y priorización de prácticas ágiles: utilizando la información obtenida a partir del punto anterior en conjunto con la herramienta AgileRoadmap de TUNE-UP, se realizará la selección y priorización de las prácticas a implantar, priorizándolas de forma tal que permitan maximizar su impacto sobre los objetivos de mejora.

3. Evaluación e implantación iterativa e incremental de prácticas ágiles: En base a la priorización anterior se evalúa el estado actual de la práctica en el equipo, espacio para mejorar, factibilidad de implantación, etc., si la práctica es factible de implantar se evalúa la estrategia de implantación. En caso de que la práctica requiera soporte de una herramienta de software, se evalúan las alternativas.

4. Asistencia y seguimiento: se evaluará con frecuencia regular cada práctica implantada, realizando ajustes para maximizar su aporte o desechándolas.

5. Evaluación del nivel de agilismo: al finalizar el proyecto de implantación se realizará nuevamente la encuesta inicial.

1.3 Objetivos específicos

Los objetivos específicos de este trabajo son los siguientes:

Seleccionar e implantar prácticas ágiles en ADI que permitan:

• Mejorar la experiencia y comunicación en el equipo de desarrollo. • Mejorar el seguimiento, priorización y visibilidad de los proyectos.

1.4 Hipótesis y metodología de validación

Es posible identificar e implantar prácticas ágiles alineadas con los objetivos de mejora y contexto del ADI que permitan:

1. Potenciar la comunicación, capacidad y experiencia del equipo. 2. Dar visibilidad interna del estado de avance de los proyectos y actividades realizadas. 3. Mejorar la gestión de los proyectos y actividades pendientes.

Para validar si la hipótesis planteada se pudo cumplir se evaluarán los siguientes factores:

1. Incorporación de medios tangibles como planes de trabajo, tableros kanban, instancias como reuniones y otros a partir de las prácticas seleccionadas.

2. Realización de una encuesta estandarizada al equipo, al inicio y al final del proyecto, para medir el impacto que tuvo la implantación.

3. Se evaluará en conjunto con los jefes de proyecto el impacto percibido en el equipo y el proceso de desarrollo respecto a la motivación, compromiso y productividad.

1.5 Breve descripción de la organización del informe en capítulos

En el capítulo 2 de este documento se describe el marco teórico y el estado del arte abordando las metodologías base del enfoque TUNE-UP, el movimiento ágil y el mismo enfoque TUNE-UP. En el capítulo 3 se describe la realización del trabajo, comenzando por la evaluación del nivel de agilismo, selección de prácticas candidatas, evaluación de las prácticas y ejecución del plan de implantación.




5

En el capítulo 4 se encuentra la conclusión del trabajo además de las referencias consultadas para la realización del mismo. A continuación se encuentra la sección de anexos al trabajo que cuenta con información más detallada sobre las encuestas y datos propios de la metodología TUNE-UP utilizados.

2 Marco Teórico y Estado del Arte

Según Aristóteles, “todos los hombres tienen por naturaleza el deseo de saber”. El origen de esta expresión se atribuye al libro primero de Metafísica, donde clasifica el conocimiento en ciencia, arte y experiencia.

En este contexto el marco teórico es provisto por el estudio y comprensión de cada una de las metodologías involucradas (Scrum, XP, Lean, kanban), el estado del arte está dado por las últimas tendencias (como TUNE-UP).

2.1 El movimiento ágil

La historia cuenta que en febrero del 2001 se reunieron 17 personas, representantes de Extreme Programming, Scrum, DSDM, Adaptative Software Development, Crystal, Feature-Driven Development, Pragmatic Programming y otras tendencias de la época; lo que emergió de esta reunión fue lo que hoy conocemos como “The Agile Manifesto” o Manifiesto Ágil [7]. El Manifiesto Ágil [17] ha sido desde entonces la referencia para todo lo que hoy llamamos Agilidad:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda

2.2 Metodologías ágiles

2.2.1 Scrum

Scrum es un marco de trabajo para la gestión y desarrollo de software basado en un proceso iterativo e incremental. La palabra proviene de una de las formaciones más reconocibles del Rugby; es una puja frente a frente, de un grupo de cada equipo. Los jugadores se presentan agachados y agarrados, para comenzar a empujar con el fin de obtener el balón que ha sido lanzado en medio de ellos sin tocarlo con la mano. Ésta analogía representa al equipo de desarrollo de software alineado con un único fin, entregar valor al negocio del cliente a través del software desarrollado.

Scrum presenta cuatro roles:

1. El Scrum Mater quien es el encargado de que el equipo sea funcional y productivo. 2. El Product Owner quien es responsable por el valor de negocio del proyecto; es la contraparte encargada de

la toma de decisiones que afecten al software y representa al grupo de Stakeholders. 3. El Equipo de trabajo que se auto organiza y gestiona para realizar el trabajo necesario. 4. Los Stakeholders10 que son los interesados en el proyecto.

10 Stakeholder es un término en inglés para referirse a “quienes pueda afectar o son afectados por las actividades de una

empresa” – Strategid Management: A Stakeholder Approach (Pitman, 1984).




6

La unidad básica de Scrum es el Sprint. Durante el Sprint, un periodo de entre una a cuatro semanas, el equipo crea un incremento de software potencialmente entregable. Las características deseadas para el producto de software se especifican en el Product Backlog, artefacto que contiene una lista priorizada de los requerimientos. Esta lista se realiza en conjunto con el Product Owner. Se considera un artefacto dinámico pues puede ser modificado o retroalimentado por la experiencia ganada por el equipo durante el Sprint.

Figura 1. Estructura de un Sprint en Scrum.

El ciclo de vida de un proyecto bajo el marco de trabajo Scrum tiene cuatro actividades:

1. Reunión de planeación del Sprint en la cual el equipo se reúne con el Product Owner antes de iniciar el Sprint para elegir cuales requerimientos serán atendidos durante la duración del mismo. Como resultado de esta reunión se obtiene el Sprint Backlog que es una lista con el conjunto detallado de actividades a realizar durante el Sprint y sus responsables.

2. Reuniones diarias en la cual el equipo se reúne a compartir avances y dificultades en la realización de sus tareas. Se recomienda que sea la primera actividad del día, en no más de 15 minutos y todos de pie.

3. Reunión de revisión del Sprint en la cual nuevamente se reúne el equipo para mostrar al Product Owner que se ha completado durante la realización del Sprint. Es la oportunidad para retroalimentar el Product Backlog. Se debe entregar en esta reunión un incremento o pieza de software funcional al Product Owner.

4. Reunión de retrospectiva que se realiza al final del Sprint en la que participa todo el equipo de trabajo. En esta reunión el equipo busca maneras de mejorar el producto y los procesos internos en base a la experiencia adquirida.

2.2.2 Extreme Programming (XP)

Programación extrema o XP es un enfoque de la Ingeniería de Software formulado por Kent Beck11. XP pone más énfasis en la adaptabilidad que en la previsibilidad lo cual la convierte en una excelente combinación para Scrum.

XP valora la capacidad de adaptarse a los cambios de requisitos en cualquier punto del ciclo de vida del proyecto, permitiendo una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos luego en controlar los cambios en los requisitos. Para XP los cambios de requisitos sobre la marcha es un aspecto natural, inevitable e incluso deseable.

Al igual que Scrum, XP se basa en valores fundamentales del equipo de trabajo:

• Simplicidad: se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Esto se realiza principalmente mediante Refactoring12. También se aplica simplicidad en la documentación y disciplina en la codificación.

11 Extreme Programming Explained: Embrace Change (1999) – Kent Beck. 12 La refactorización es una técnica de la Ingeniería de Software para reestructurar un código fuente, alterando su estructura

interna sin cambiar su comportamiento externo.




7

• Coraje/Valentía: es común en XP que los programadores deban reconstruir o desechar código cuando sea necesario por lo cual es necesario que tengan el coraje para hacerlo.

• Respeto: los miembros del equipo respetan el trabajo del resto dando lo mejor de sí, siempre luchando por la calidad del producto y elevando el ritmo de producción.

Las características fundamentales de XP son:

• Desarrollo iterativo e incremental: pequeñas mejoras, una tras otra. • Pruebas unitarias continuas: frecuentemente repetidas y automatizadas. • Programación en pares: se recomienda que la codificación se realice por dos personas utilizando un único

teclado. Esto supone una mayor calidad del código. Ambas personas deberían tener idealmente el mismo conocimiento y nivel sobre el lenguaje. Cada uno de ellos toma indistintamente el rol de codificador y revisor.

• Frecuente integración del equipo con el cliente/usuario: es recomendable que un representante del cliente trabaje en conjunto con el equipo de desarrollo.

• Corrección de todos los errores antes de añadir una nueva funcionalidad. • Refactoring del código completo o de alguna de sus partes. Las pruebas han de garantizar que el Refactoring

no ha introducido ningún comportamiento anómalo. • Código compartido: todos los miembros del equipo tienen acceso a todo el código de fuente. Esto promueve

que toda persona pueda corregir y extender cualquier parte del código. • Simplicidad en el código: es mejor hacer algo simple y luego extenderlo si es necesario, que crear un código

complicado que quizás sea necesario desechar.

2.2.3 Lean Software Development

Lean es un adjetivo que en inglés significa magro o libre de grasa. Su origen se atribuye a Taiichi Ohno, director y consultor de Toyota. Ohno buscaba eliminar la muda, palabra de origen Japonés que hace referencia a cualquier actividad humana que consume recursos y no crea valor. En este contexto se identifican siete tipos de desperdicios: sobreproducción, tiempo de espera, transporte, exceso de procedimientos, inventario, movimientos (inventario, humanos), defectos. Lean está definido como un conjunto de principios, no es un proceso que pueda ser directamente adaptado a distintos entornos. Los principios que definen un sistema Lean son los siguientes [9]:

• Calidad perfecta a la primera: búsqueda de cero defectos, detección y solución de los problemas en su origen. Todo lo que se hace, debe intentar hacerse bien, no rápido, ya que cuesta más tiempo hacer algo rápido y tener que arreglarlo después, que hacerlo bien desde el principio.

• Minimización del desperdicio: eliminación de todas las actividades que no son de valor añadido y la optimización del uso de los recursos escasos (capital, gente y espacio). Hacer lo justo y necesario y no entretenerse en otras tareas secundarias o no necesarias (principio YAGNI13).

• Mejora continua: reducción de costos, mejora de la calidad, aumento de la productividad y compartir información. Ir mejorando continuamente los desarrollos, según los objetivos a lograr.

• Procesos “pull”: los productos deben ser solicitados por el cliente final, no empujados al mercado desde la fabrica hacia el cliente.

• Flexibilidad: producir rápidamente diferentes mezclas de gran variedad de productos, sin sacrificar la eficiencia debido a volúmenes menores de producción. Lo siguiente a realizar se decide del backlog pendiente, con lo que las tareas entrantes se pueden priorizar y condicionar según las necesidades puntuales.

• Construcción y mantenimiento de una relación a largo plazo: con los proveedores tomando acuerdos para compartir el riesgo, los costos y la información.

13 No vas a necesitarlo, por sus sigas en inglés YAGNI: You Aren´t Gonna Need It es un principio que consiste en que no se

debe nunca agregar una funcionalidad excepto que sea necesario.




8

Éstas prácticas tienen por objetivo generar el máximo valor lo más rápidamente posible, en forma sostenida y sustentable.

2.2.4 Kanban

Kanban es una palabra japonesa que significa tarjeta o tablero visual. Kanban se basa en la idea de que el trabajo en curso o WIP14 debería limitarse y sólo se debería empezar con algo nuevo cuando un bloque de trabajo anterior haya sido entregado [10]. Los principios de Kanban son: comience por lo que va a hacer ahora; persiga el cambio incremental y evolutivo; respete el proceso actual, roles, responsabilidades y cargos; liderazgo en todos los niveles. Dados estos principios, Kanban armoniza perfectamente con la metodología Scrum por lo cual es frecuente encontrar su uso conjunto.

Figura 2. Ejemplo de tablero kanban.

El tablero kanban es una aplicación de la metodología, un sistema de información visual y se construye en base a una variedad de criterios. Lo más frecuente es que cuente con al menos tres columnas: ToDo (pendiente), Doing (haciendo), Done (terminado). Las tarjetas representan unidades de trabajo, dependiendo del enfoque del tablero las mismas pueden ser proyectos completos, módulos e incluso tareas específicas; es importante que las tarjetas de un mismo tablero sean del mismo “peso”. El flujo de las tarjetas que se desplazan por el tablero es de izquierda a derecha. Comienzan en ToDo, al Doing y luego al Done. Es importante que una persona se haga responsable de la tarjeta y su avance (físico por el tablero, así como también las actividades que la misma involucra) [8]. Los objetivos del tablero kanban son:

• Balancear la demanda con la capacidad. • Limitar el trabajo en proceso, mejorar el flujo de trabajo, descubrir problemas tempranamente y lograr un

ritmo sostenible. • Controlar el trabajo (no la gente), coordinar y sincronizar, descubrir los cuellos de botella y tomar decisiones

que generen valor. • Equipos auto-organizados. • Lograr una cultura de optimización incremental.

2.3 El Enfoque TUNE-UP

El enfoque TUNE-UP recopila una serie de herramientas, capacitación y consultoría para la implantación de prácticas ágiles [12]. TUNE-UP identifica 42 prácticas ágiles relacionadas con el producto, el cliente, el equipo y la definición y mejora continua del proceso que a su vez están asociadas a 4 metodologías ágiles. Cada práctica contribuye en distinta medida a la consecución de un determinado objetivo. En la siguiente imagen se muestra la aportación que cada una hace a los objetivos considerados. 14 WIP o Work In Progress.




9

Figura 3. Gráfico radial de aporte de cada práctica por cada objetivo de mejora. Fuente: TUNE-UP Process.

Se incluyen 16 objetivos de mejora, cada uno de ellos en el ámbito de Productividad (P), Satisfacción del Cliente (S) o Motivación y compromiso del equipo (M). Las prácticas ágiles tienen diferente contribución al objetivo lo cual se representa con círculos concéntricos, el grado de contribución es mayor desde el centro hacia afuera.

Figura 4. Solape de prácticas ágiles entre XP, Lean, Kanban y Scrum – Fuente: Enfoque TuneUP [1]




10

Figura 5. Agrupación de prácticas ágiles según ámbitos específicos de mejora – Fuente: Enfoque TuneUP [1]

Agile Roadmap+ es parte del enfoque TUNE-UP y permite crear una hoja de ruta para la implantación de prácticas ágiles en un equipo de trabajo [14]. Los pasos para elaborarlo son los siguientes [15]:

1. Seleccionar el equipo de trabajo en el cual se aplicarán las prácticas ágiles. La recomendación es implantar prácticas ágiles trabajando muy estrechamente con cada equipo. Si bien es necesario hacer un trabajo previo de promoción hasta un determinado nivel directivo (para conseguir apoyo para la iniciativa), el trabajo de implantación se hace con el equipo, no debe ser impuesto desde “arriba” ni debe dejarse a la motivación y esfuerzo heroico de algunos integrantes del equipo.

2. Estudiar los productos, servicios y/o proyectos encargados al equipo seleccionado. Obviamente lo ideal sería que el equipo sólo trabajase en un producto, servicio o proyecto, pero desgraciadamente suele ocurrir que el equipo es responsable de varios trabajos diferentes.

3. Establecer un conjunto de objetivos que motivan la iniciativa de mejora de proceso. Este paso obliga a una reflexión respecto del desempeño actual del equipo en contexto de los productos/servicios o proyectos estudiados. Ordenar dichos objetivos según prioridad de consecución.

4. Determinar un conjunto de prácticas candidatas que contribuyen en mayor medida a los objetivos seleccionados. Cada práctica ágil contribuye en cierta medida a algunos objetivos, con lo cual, para un determinado objetivo se pueden seleccionar prácticas candidatas según su contribución a dicho objetivo.

5. Establecer el nivel de aplicación de cada práctica candidata. Es importante conocer si una práctica está ya completamente aplicada, no aplicada, o si se aplica parcialmente. Una práctica no aplicada tendrá un mayor efecto que una práctica que se está ya aplicando de forma parcial. Descartar de las candidatas aquellas ya aplicadas.

6. Considerar el esfuerzo de implantación que podría suponer cada práctica candidata. Dependiendo de la práctica y del contexto de trabajo, el esfuerzo de implantación asociado a la preparación y puesta en marcha de la práctica nos puede obligar a postergarla o incluso descartarla. Cada práctica conlleva ciertos desafíos que es importante evaluar.

7. Con la información recopilada establecer un orden de aplicación para las prácticas candidatas (lista de prácticas que formarían el roadmap). Algunas directrices para establecer el orden son: valorar positivamente la prioridad de los objetivos a los que contribuye la práctica, valorar el grado de contribución de la práctica a cada objetivo, valorar positivamente el nivel de aplicación actual de la práctica (mayor si la práctica no está siendo aplicada), y valorar el esfuerzo de implantación de la práctica (mientras menos mejor) y los posibles desafíos.

8. Probablemente no se podrán aplicar todas las prácticas deseadas a la vez ni en su total intensidad, con lo cual el Roadmap de prácticas ágiles deberá evaluarse periódicamente, en la medida que se vayan implantando prácticas y considerando posibles cambios en los objetivos o en el contexto de trabajo.




11

3 Desarrollo del proyecto

3.1 Definición de la solución

Para el desarrollo de este proyecto se utilizará el enfoque TUNE-UP, para esto se seguirá el protocolo establecido por Agile.

3.1.1 Evaluación de nivel de agilismo

La evaluación del nivel de agilismo se realizó en junio del año 2017 utilizando la versión descargable del formulario de evaluación [16]. El cuestionario permite medir el nivel de agilismo en base a dos perspectivas: el nivel de aplicación de las prácticas ágiles agrupadas por categorías o dimensiones, y los objetivos de mejora que se desean alcanzar (teniendo en cuenta que cada práctica contribuye en cierta medida al cumplimiento de algunos objetivos) [Anexo A]. Se decidió aplicar la encuesta a todo el equipo de trabajo con la finalidad de tener una visión individual y grupal del nivel de agilismo y los objetivos a mejorar, teniendo más peso en este último punto la priorización de la Dirección. El detalle de la evaluación puede ser revisado en el [Anexo B]. El gráfico de la Figura 6 muestra 10 dimensiones, una por cada área de prácticas. El área delimitada mide el nivel promedio de aplicación del total de las prácticas para dicha área.

Figura 6. Evaluación por Áreas15 – Fuente: Elaboración propia, basado en [Anexo D].

El gráfico de la Figura 7 muestra 16 dimensiones, una por cada objetivo. En función de las prácticas consideradas, de su nivel de aplicación y de su contribución a determinado objetivo, se calcula el nivel de agilismo asociado a la consecución del mismo.

15 (1) Muy bajo, (2) Bajo, (3) Medio, (4) Alto, (5) Muy alto.

1

2

3

4

5Fundamento ágil

Producto

Técnicas

Cliente

Equipo

Dinámica

Reuniones

Espacio trabajo

Liderazgo

Proceso




12

Figura 7. Evaluación por Objetivos16 – Fuente: Elaboración propia, basado en [Anexo D].

Mientras más cercano a 5 más importante es el objetivo de mejora para el equipo de trabajo. Es importante indicar que los objetivos de mejora son una fotografía de las necesidades – en ese momento – para el equipo, son variantes en el tiempo.

3.1.2 El equipo de trabajo

El primer paso para la confección de la hoja de ruta para la implantación de prácticas ágiles del enfoque TUNE-UP corresponde a la selección del equipo de trabajo. Con el apoyo completo de la Dirección de ADI, se definieron los siguientes participantes y roles:

• Jefes de Diseño (2): encargados de proporcionar una visión transversal a los desarrollos. Su rol principal es un híbrido entre un Arquitecto de Software y un experto en el negocio. No obstante éste es su rol principal, también funcionarán como Ingenieros de Desarrollo.

• Ingenieros de Desarrollo (3): encargados del desarrollo de software como función principal, apoyan a los Jefes de Diseño e Ingenieros de Proyecto a definir características técnicas, factibilidad y plazos de los proyectos.

• Ingeniero de Proyectos (1): encargado del levantamiento de información y seguimiento de los proyectos.

3.1.3 Productos, servicios o proyectos encargados al equipo

El principal servicio entregado por el equipo es la reingeniería de procesos. Producto de este servicio puede darse la creación de módulos de software, reportes o estadísticas, que son incluidas dentro de la plataforma Ucampus que son entregadas en modalidad de servicio. Los proyectos son inicialmente abordados por el Ingeniero de Proyectos en conjunto con un Jefe de Diseño. Entre ambos realizan un primer levantamiento de información para establecer la factibilidad, dependencias y contexto. Una vez establecida la factibilidad, el Jefe de Diseño en conjunto con el Ingeniero de Proyectos realizan un análisis y diseño detallado del proceso y todas sus aristas involucradas (actores, subprocesos, documentación, software, fuentes de datos, etc.). En esta etapa, dependiendo de la complejidad, el análisis y diseño detallado puede ser realizado por un Ingeniero de Desarrollo.

16 (1) Muy bajo, (2) Bajo, (3) Medio, (4) Alto, (5) Muy alto.

1

2

3

4

5Evitar retrasos

Gestionar cambios

Reducir horas extra

Reducir defectos

Visibilidad trabajo

Decisiones oportunas

Gestión RRHH

Mejora comunicaciónAlineación negocio

Involucrar cliente

Evitar sobre-proceso

Sistematizar trabajo

Mejora Continua

Reducir re-trabajo

Time to market

Gestión multi-…




13

Los Ingenieros de Desarrollo, de forma directa, interactúan con el Cliente con el apoyo del Ingeniero de Proyectos y el Jefe de Diseño, para encontrar la mejor alternativa de solución, mejora o reproceso para el proyecto. Todas las tareas asociadas al desarrollo son de responsabilidad del Ingeniero de Desarrollo (desarrollo, pruebas, marcha blanca, puesta en producción, mantención).

Los proyectos son de diversa complejidad, todos ellos ligados a las necesidades comunes de la Facultad o específicas de cada Dirección o Escuela.

3.1.4 Objetivos de mejora seleccionados

Para el proceso de implantación se considerarán las prácticas asociadas a los objetivos de mejora con una evaluación de 4 o más:

Tabla 1. Objetivos de mejora.

Código Objetivo Prioridad OBJ7 Hacer más visible el trabajo del equipo 4 - Alto OBJ3 Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades 5 - Muy alto OBJ5 Reducir defectos en el trabajo entregado al cliente 5 - Muy alto OBJ22 Gestionar eficazmente el contexto multi-proyecto 5 - Muy alto OBJ10 Mejorar la comunicación dentro del equipo y con el cliente 4 - Alto OBJ15 Mejorar la sistematización del trabajo 4 - Alto OBJ19 Promover la mejora continua del proceso empleado por el equipo 4 - Alto OBJ20 Reducir el re-trabajo debido a trabajos defectuoso o incompleto detectado por el

equipo 4 - Alto

OBJ8 Tomar decisiones en el momento oportuno 4 - Alto OBJ11 Alineación del trabajo del equipo con los objetivos del negocio 4 - Alto

3.1.5 Selección de prácticas candidatas

En base a los objetivos de mejora, se seleccionan las prácticas que aportan individualmente al cumplimiento de cada uno de ellos. En la siguiente tabla se lista el aporte individual de las prácticas a cada objetivo y la suma total de su aporte en base a los objetivos seleccionados. El aporte individual de cada práctica está valuado de 1 (bajo) a 5 (muy alto).

Tabla 2. Aporte de las prácticas a los objetivos de mejora

OBJ7 OBJ3 OBJ5 OBJ22 OBJ10 OBJ15 OBJ19 OBJ20 OBJ8 OBJ11 TOTAL PRA2 4 1 5 PRA3 1 1 2 PRA4 3 1 1 5 PRA6 3 3 PRA7 1 1 PRA8 4 4 PRA9 5 5 10 PRA10 4 4 PRA11 1 3 1 5 PRA13 4 4 8 PRA14 4 3 3 10 PRA15 5 5 5 15 PRA16 5 4 5 14 PRA17 3 4 7




14

PRA18 3 3 PRA19 3 3 PRA22 3 4 7 PRA23 4 4 PRA24 1 1 PRA27 4 4 8 PRA28 4 4 PRA30 3 4 7 PRA31 3 3 PRA32 4 4 PRA33 4 3 7 PRA42 1 1

3.1.6 Evaluación de nivel de aplicación y esfuerzo de implantación

Se realizó una evaluación en conjunto con el equipo de trabajo respecto del nivel de aplicación, esfuerzo de implantación y orden en que serán implantadas las prácticas. El detalle de las prácticas seleccionadas puede ser encontrado en el [Anexo B]. Se descartaron aquellas prácticas cuyo nivel de aplicación era medio, alto y muy alto; así como también aquellas prácticas cuyo esfuerzo de implantación era muy alto. Las prácticas seleccionadas son las siguientes:

Tabla 3. Prácticas seleccionadas para implantación

Código Descripción Orden Esfuerzo de

Implantación Nivel de Aplicación

PRA2 Abordar y entregar trabajo terminado de forma incremental.

12 Medio Bajo

PRA3 Realizar entregas frecuentes de unidades de trabajo terminadas.

13 Medio Muy bajo

PRA4 Realizar reuniones de planificación frecuentemente (frecuencia de pocas semanas, no meses).

3 Muy bajo Muy bajo

PRA6

Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista.

10 Medio Bajo

PRA8 Organizar el trabajo del equipo con el foco en la generación de un buen flujo de trabajo terminado.

9 Alto Bajo

PRA10

Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad.

11 Medio Muy bajo

PRA13 Seguimiento continuo (frecuencia de días, no semanas).

1 Muy bajo Bajo

PRA14 Realizar una reunión diaria del equipo al completo, cara a cara y muy breve.

2 Bajo Muy bajo

PRA15 Visualización de todo el trabajo pendiente encargado al equipo.

6 Medio Muy bajo




15

PRA16 Gestión integrada de todo el trabajo asignado, tanto a nivel del equipo como a nivel de cada miembro.

8 Alto Muy bajo

PRA30 Que exista un líder de mejora de proceso disponible para el equipo.

7 Alto Muy bajo

PRA31 Establecimiento de estándares para el trabajo técnico del equipo.

14 Alto Muy bajo

PRA32

Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua del proceso.

4 Medio Muy bajo

3.1.7 Implantación de Prácticas Ágiles

Es en el proceso de implantación donde la metodología utilizada se distancia de TUNE-UP debido a que no se utilizará la herramienta de software provista por el enfoque y, por tanto, no puede realizarse una única capacitación y puesta en marcha. El proceso debía ser iterativo e incremental. El proceso se realizó desde agosto del 2017 a julio del 2018. A partir de este proceso se implementaron nuevos mecanismos de trabajo al interior del área. A continuación se relata algunas de las actividades, experiencia y avances realizados en la implantación de cada una de ellas.

PRA13 - Seguimiento continuo (frecuencia de días, no semanas).

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Muy alto En este contexto de trabajo la demanda de trabajo es en cierta medida planificable. Si bien cada desarrollador tiene a cargo un proyecto nuevo o mantención a un proyecto antiguo, es posible que deba realizar trabajos correctivos en proyectos anteriores, este último no es planificable. Debido a esto, los Jefes de Diseño toman responsabilidad de hacer seguimiento diario respecto a si el trabajo que se está realizando corresponde a trabajo planificado o correctivo no planificado. Esto, mediante el monitoreo periódico del Kanban del equipo. En este contexto un Jefe de Diseño, en compañía del Ingeniero de Proyectos, pueden decidir la criticidad de la tarea de corrección, pudiendo postergarla. No obstante, es responsabilidad de los mismos desarrolladores el informar de forma oportuna si la realización de tareas críticas de corrección está tomando más tiempo del estimado, retrasando la entrega de las unidades de trabajo planificadas.

PRA14 – Realizar una reunión diaria de equipo al completo, cara a cara y muy breve.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Muy alto Fue sumamente complejo encontrar el equilibrio entre el tiempo empleado para la reunión y que la misma significara un aporte significativo para todos los involucrados. Se inició con reuniones diarias las cuales inicialmente bordeaban los 15 minutos o menos. Tener reuniones diarias podía volverse algo monótono debido a que no habían temas significativos que reportar pero a la vez permitía al equipo detectar rápidamente quienes estaban en posición de apoyar en otras tareas más prioritarias. Una reunión en particular tuvo una duración de 63 minutos. Desde la perspectiva del equipo de trabajo, ésta fue una de las reuniones más significativas que se ha tenido en meses, no obstante desde el punto de vista de la dirección la misma fue un fracaso pues duró más de una hora. A partir de este punto se acordó realizar dos




16

reuniones semanales de 15 minutos. Las cuales fueron luego suspendidas debido a que, en percepción de la dirección, no eran un aporte. Luego algo sucedió. El mismo equipo se vio en la necesidad de comunicarse y restableció las reuniones diarias de forma informal, para luego establecerse formalmente. Hoy las reuniones duran alrededor de 5 minutos, es la primera actividad que se realiza en el día y son sumamente importantes para alinear el trabajo que realiza el equipo. Las reuniones se realizan a la misma hora todos los días, con los miembros del equipo que se encuentren presentes. Actualmente estas reuniones permiten reducir los tiempos ociosos y desbloquear los factores que pudiesen estar retrasando el normal avance de los desarrollos.

PRA4 – Realizar reuniones de planificación frecuentemente (frecuencia de pocas semanas, no meses).

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Alto Se establece una reunión semanal, todos los miércoles a las 11 am, en la cual participa todo el equipo además de la Directora del área. En esta reunión se revisa el estado de avance de todos los proyectos, así como también aquellas tareas correctivas que estén demandando más tiempo al equipo. Es en esta instancia donde se re prioriza y define el trabajo a realizar hasta la próxima reunión de seguimiento. Ésta práctica, si bien generó rechazo inicialmente, es altamente valorada por el equipo de trabajo pues permite trabajar en lo que realmente se necesita.

Figura 8. Calendario de reuniones mes de agosto de 2017. – Fuente: Calendario de trabajo.

PRA32 – Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua del proceso.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Medio Inicialmente se realizaban reuniones de retrospectiva semanalmente, como última actividad a realizar los días viernes. Si bien la elección del horario para realizarlas no fue el adecuado (justo después de almorzar), el principal desafío fue lograr que se transformara en una reunión de retrospectiva y no una reunión diaria extendida. Actualmente se realizan dos reuniones de retrospectiva al mes los días viernes a las 11 de la mañana. Típicamente los días viernes a esa hora la carga de trabajo tiende a disminuir por lo cual es un momento adecuado para que todo el equipo pueda reunirse. Para la realización de las mismas se utilizó la guía de Atlassian llamada “Retrospectives”[18] para este tipo de reuniones. Nuestra versión adaptada contempla:




17

1. Se prepara la reunión con 15 minutos de anticipación (lugar, materiales, etc.). 2. Se recibe al equipo y se les transmite el espíritu de mejora continua (5 min): No hacerlo personal, no

tomárselo personal. Escuchar con mente abierta, recordando que todas las experiencias son validas (inclusive las que no se comparten). Establecer los límites de la discusión: última semana, último mes, último año. Adoptar la mentalidad de mejora continua por sobre la búsqueda de culpables.

3. Discutir lo que ha funcionado bien (10 min). 4. Discutir qué necesita ser mejorado (10 min): Se debe recordar que es sobre acciones y resultados, no sobre

personas específicas. 5. Próximos pasos (5 min): Teniendo identificado que ha salido mal, identificar acciones concretas que

permitan al equipo mejorarlas. En adición a esto, se utilizó la técnica de reflexión “Keep, Fix, Try”: • Keep (mantener): lo que se hizo y se debería seguir haciendo. • Fix (reparar): lo que se hizo o no y deberíamos corregir en el futuro. • Try (intentar): lo que se hará en el futuro.

Figura 9. Imagen de tablero KFT – Fuente: Elaboración propia.

En la imagen anterior se ve el tablero KFT utilizado para las primeras retrospectivas.

PRA15 – Visualización de todo el trabajo pendiente encargado al equipo.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Muy Alto

Debido a las características propias de las líneas de trabajo y el equipo, no es factible organizar el trabajo en Sprints, lo cual hubiese sido lo ideal para ayudar a planificar el trabajo. No obstante, dado que la finalidad es la visualización del trabajo pendiente encargado al equipo, se definió inicialmente 3 líneas de trabajo: proyectos, sistemas y desarrollo, cada una de ellas con su propio flujo y unidades de trabajo. Las unidades de trabajo para la línea de proyectos son proyectos pues lo importante es la visualización del estado global de todos los proyectos. Para la línea de sistemas las tareas eran más atómicas, por ejemplo, instalar una actualización o realizar cableado. Para la línea de desarrollo las unidades van desde análisis de requerimientos, pruebas de aceptación, desarrollo, testing, corrección de bugs, etc. La herramienta seleccionada para las primeras versiones fue Trello, dada las características que ofrecía de forma gratuita. Las siguientes imágenes muestran las versiones iniciales de los tableros Kanban realizados.




18

Figura 10. Tablero Kanban de Proyectos – Fuente: Elaboración propia.

Figura 11. Tablero Kanban Desarrollo y Mantención– Fuente: Elaboración propia.

Kanban es una herramienta de visualización del trabajo y por tanto es útil para poder priorizar el mismo de forma visual. No obstante, muchas veces se quiere hacer métricas sobre él, una tarea para la cual no está diseñado. Con la finalidad de que la Dirección tuviese una visión más sencilla de las tareas en curso y la priorización del trabajo, se diseño un módulo utilizando las APIs propias de Trello para mostrar el trabajo en curso (WIP) y el trabajo priorizado.

Figura 12. Módulo Trello, visualización del WIP – Fuente: Elaboración propia.




19

Figura 13. Módulo Trello, Visualización Tareas Priorizadas – Fuente: Elaboración propia.

No obstante la herramienta funcionaba bien para la Dirección por cuanto permite la visualización del trabajo en curso y la priorización, la misma se estaba volviendo un problema para el equipo de desarrollo pues además de tener que realizar su trabajo habitual debían mantener actualizadas las informaciones en sus tarjetas. Por este motivo se comenzó a experimentar con la suite de herramienta de JetBrains, particularmente en este contexto: • Upsource: para el análisis y revisión del código en los repositorios. • YouTrack: para el análisis de incidencias (kanban). • PhpStorm: IDE con integración con sistemas de versionamiento y las herramientas anteriores, permitiendo

gestionar las tarjetas en el kanban desde la misma interfaz desde la cual se suben los cambios al repositorio. Esta es la herramienta que se está ocupando en la actualidad. La siguiente imagen muestra la vista del tablero kanban desde YouTrack:

Figura 14. YouTrack, Kanban Desarrollo y Mantención – Fuente: Elaboración propia.

El principal desafío estuvo en definir y consensuar las unidades de trabajo e intentar que las mismas tuviesen pesos similares.

PRA30 – Que exista un líder de mejora de proceso disponible para el equipo.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Muy alta Uno de los requerimientos para la factibilidad este trabajo inicialmente fue adquirir, oficialmente, el rol de Scrum Master dentro de la organización. Fue de esta forma que se obtuvo dicho rol sin conocer realmente lo que esto significaba.




20

El Scrum Master es un facilitador. Se encarga de conseguir que el equipo conozca y sienta los principios y valores de la Agilidad, así como la teoría y prácticas de Scrum, con el objetivo de que los usen en sus procesos de toma de decisiones [19]. Es en este sentido que el Scrum Master es un referente de la agilidad. La agilidad es una cultura profesional y como tal debe ser parte del que-hacer profesional de cada uno [20]. No obstante el nombre del rol, al igual que muchos otros inventados por las metodologías ágiles, causa resistencia por cuanto el equipo se puede cuestionar si la persona es la más adecuada para ese rol. Es por este motivo que actualmente se enfrenta la responsabilidad de ser un referente de la agilidad para el equipo desde la posición de desarrollador, buscando, proponiendo y probando nuevas formas de mejorar el trabajo que se realiza día a día. Este enfoque es el que ha ganado más aceptación dentro del equipo y la Dirección y además, ha generado un cambio cultural en el mismo. La facilitación no debería ser un rol asignable dentro de un equipo ágil, debería ser responsabilidad de todos y cada uno de los profesionales del equipo. Los nuevos deben aprender viendo a los más experimentados tomar decisiones durante las complejidades del proyecto en vez de ser lanzados al fuego todos juntos solo con un ‘coach’ y esperar que las cosas resulten bien por la magia de la agilidad [20]. Nuevas propuestas e inquietudes para mejorar nuestro flujo de trabajo nacen hoy de todos los integrantes del equipo, lo cual demuestra un cambio cultural por querer hacer mejor las cosas.

PRA16 – Gestión integrada de todo el trabajo asignado, tanto a nivel del equipo como a nivel de cada miembro.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Medio Es necesario un poco de contexto en este punto. Durante la separación de el Centro Tecnológico Ucampus y ADI, la persona que era Jefe de Proyectos asumió el cargo de Directora del área, junto con todas sus responsabilidades. Es por este motivo que en varias ocasiones se habla de que la Dirección solicita tener visibilidad de los proyectos, dada la inexistencia formal de un Jefe de Proyectos. Por este motivo se contrató un Ingeniero de Proyectos con la finalidad de que realice la gestión integrada del trabajo asignado a nivel de equipo y a nivel de personas y sea él, quien defina las prioridades con la Dirección. El tablero Kanban ha sido de gran ayuda en este proceso, permitiendo al Ingeniero de Proyectos tener una visión en tiempo real de lo que se está realizando, pudiendo detectar rápidamente desvíos en el trabajo.

PRA8 – Organizar el trabajo del equipo con el foco en la generación de un buen flujo de trabajo terminado.

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Medio Cuando no se puede anticipar cuál es el trabajo que recibirá el equipo y no se quiere acumular trabajo para ser agrupado y establecer un plazo de entrega, o bien cuando se quiere dar una rápida respuesta a las solicitudes del cliente, especialmente a las pequeñas (que en caso de planificarse podrían verse aplazadas), en estos casos, el equipo se debería centrar en generar un buen flujo de trabajo terminado. Así pues, con esta práctica el trabajo en la medida que se recibe se ordena con respecto del resto del trabajo pendiente, y respetando dicho orden se va abordando. [21] Se definió que se realizarían sprints de 2 semanas los cuales servirían como agrupadores de trabajo planificado para ese periodo. No obstante debido a requerimientos críticos o errores en los módulos, es necesario incluir nuevas tareas en los sprints, lo cual según la metodología no debería hacerse. No obstante esto ha permitido conocer la velocidad con que el equipo es capaz de ir terminar unidades de trabajo.




21

Figura 15. YouTrack, Gráfico de Estado del Sprint – Fuente: Elaboración propia.

En la imagen anterior se puede apreciar que el sprint inició con 14 tareas planificadas y terminaron realizándose 21.

PRA6 – Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista.

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Medio Si bien el trabajo se está realizando en sprints de dos semanas, debido a que aún se está trabajando para poder definir un modelo incremental de despliegue de los módulos a producción, no necesariamente se puede esperar que al final del mismo exista un incremento. No obstante en la mayoría de los casos los incrementos pasan a producción de forma anticipada a la fecha prevista, generando la sensación de entrega continua de valor al cliente. Aún se está trabajando en esta práctica para poder establecer formalmente el concepto de sprint y la necesidad de que, al término del mismo, necesariamente existan incrementos de software disponibles para los proyectos.

PRA10 – Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad.

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Alto El concepto detrás de limitar el WIP es simple. Si una persona hace demasiadas cosas a la vez, esta pierde bastante tiempo realizando cambios de contexto para realizar las diferentes tareas por lo cual avanzarlas en paralelo generalmente es más lento que hacerlas en forma secuencial. Se establece por tanto que el WIP máximo para cada desarrollador es 1. En el contexto ideal, un desarrollador sólo estará atendiendo tareas relacionadas con nuevos proyectos, de forma secuencial en base a la priorización realizada anteriormente por el Ingeniero de Proyectos. No obstante de ser necesario un desarrollador puede “postergar” esa tarea por un tiempo indefinido ante la necesidad de resolver un error de codificación u otro urgente de la línea de mantención. Se está trabajando para que existan equipos diferenciados para desarrollo de nuevos productos y mantención, pero es una apuesta a largo plazo pues requiere la contratación y capacitación de nuevos miembros para el equipo.




22

PRA2 – Abordar y entregar trabajo terminado de forma incremental

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Alto En los proyectos que ha sido factible se ha utilizado la técnica del MVP o Minimum Viable Product (producto mínimo viable), con esta técnica se busca en este contexto, que el primer incremento contenga únicamente aquellas características que permitan validar el concepto o requerimiento base del cliente y permita aprender del producto y del contexto en la medida de los sucesivos incrementos. La siguiente imagen ilustra el proceso. El MVP busca validación temprana sobre las necesidades del cliente, en el ejemplo, si lo que se busca es transportarse, bajo un enfoque tradicional el cliente no estaría contento hasta tener el producto final. No obstante, mediante el uso de MVP, a partir del primer incremento el cliente ya satisface su necesidad de transporte, aunque no en la forma que quería; pero como el incremento es pequeño, es posible encontrar lo que realmente satisface la necesidad de forma temprana.

Figura 16. Ejemplo MVP – Fuente: Henrik Kniberg.

Utilizar esta técnica nos ha permitido validar de forma temprana requerimientos complejos de los cuales se contaba con muy poca información inicial, sin sacrificar horas de desarrollo en funcionalidades que no se van a utilizar.

PRA3 – Realizar entregas frecuentes de unidades de trabajo terminadas.

Nivel de aplicación inicial: Bajo Nivel de aplicación actual: Alto Esta práctica es uno de los pilares de la agilidad y es la culminación del trabajo de las demás prácticas. Justamente el objetivo de este proceso de implantación desencadena la entrega continua de valor hacia el negocio. Ésta entrega continua se ve reflejada en que los usuarios constantemente tienen nuevas funcionalidades disponibles en los módulos existentes y nuevos módulos disponibles para dar soporte a sus actividades diarias. Se define que está a un nivel medio de aplicación debido a que si bien las entregas son frecuentes, suele pasar que hay paquetes de funcionalidades listos para los usuarios que no son entregados debido a factores externos. Como se mencionó anteriormente se está trabajando para llegar a un estándar o disciplina de entrega continua.

PRA31 – Establecimiento de estándares para el trabajo técnico del equipo.

Nivel de aplicación inicial: Muy bajo Nivel de aplicación actual: Medio Si bien se estableció con claridad la necesidad de contar con un estándar único para el equipo, el trabajo en su definición ha sido lento. Se está trabajando en unificar los criterios de los Jefes de Diseño, documentación de buenas prácticas en una wiki, además de reuniones semanales para difundir y discutir los estándares técnicos del equipo.




23

3.1.8 Validación del proceso de implantación y próximos pasos

Comparación con nivel de agilismo inicial

Los siguientes gráficos muestran la comparativa entre la evaluación inicial (en color rojo) y la evaluación tras la primera iteración de implantación del nivel de agilismo del área (en color verde).

Figura 17. Diferencia evaluación por áreas – Fuente: Elaboración propia basado en resultado evaluación.

Figura 18. Diferencia evaluación por objetivos – Fuente: Elaboración propia basado en resultado evaluación.

En ambos gráficos puede observarse un incremento en el nivel promedio de aplicación de prácticas ágiles por área y objetivos en base a las prácticas implantadas.

Encuesta aplicada al equipo

En base a las prácticas implantadas se generó una encuesta que fue respondida de forma anónima. Dado que el equipo es pequeño se exponen los resultados directamente. El aumento en la frecuencia de las reuniones de seguimiento y planificación de los proyectos permite que trabajemos en lo más prioritario para el área y la facultad. Muy de acuerdo (6) De acuerdo (2) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0)

1

2

3

4

5Fundamento ágil

Producto

Técnicas

Cliente

Equipo

Dinámica

Reuniones

Espacio trabajo

Liderazgo

Proceso

1

2

3

4

5Evitar retrasos

Gestionar cambios

Reducir horas extra

Reducir defectos

Visibilidad trabajo

Decisiones oportunas

Gestión RRHH

Mejora comunicaciónAlineación negocio

Involucrar cliente

Evitar sobre-proceso

Sistematizar trabajo

Mejora Continua

Reducir re-trabajo

Time to market

Gestión multi-proyecto




24

Las reuniones diarias o stand-up meetings han permitido al equipo de desarrollo solucionar rápida y oportunamente factores que pudiesen bloquear el normal avance de los proyectos. Muy de acuerdo (5) De acuerdo (2) Ni de acuerdo ni en desacuerdo (1) En desacuerdo (0) Muy en desacuerdo (0) Las reuniones de retrospectiva facilitan la transmisión de conocimiento de los miembros más experimentados a los más novatos en el equipo. Muy de acuerdo (7) De acuerdo (1) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0) Los tableros Kanban utilizados para dar visibilidad al trabajo realizado son una herramienta útil para mi rol específico en el equipo. Muy de acuerdo (3) De acuerdo (4) Ni de acuerdo ni en desacuerdo (1) En desacuerdo (0) Muy en desacuerdo (0) Existe en el equipo un líder de mejora de proceso al que puedo recurrir si tengo inquietudes o propuestas de mejora. Muy de acuerdo (8) De acuerdo (0) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0) La actual gestión del trabajo asignado ha permitido generar un buen flujo de trabajo terminado. Muy de acuerdo (5) De acuerdo (2) Ni de acuerdo ni en desacuerdo (1) En desacuerdo (0) Muy en desacuerdo (0) Evitar los cambios de contexto en el trabajo diario ha permitido realizar su trabajo de forma más eficaz. Muy de acuerdo (3) De acuerdo (4) Ni de acuerdo ni en desacuerdo (1) En desacuerdo (0) Muy en desacuerdo (0) Utilizar la técnica del MVP ha permitido abordar los proyectos con un enfoque incremental, entregando valor más rápidamente a nuestros clientes. Muy de acuerdo (7) De acuerdo (1) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0) Realizar entregas frecuentes de unidades de trabajo ha permitido validar de forma oportuna que las necesidades de nuestros clientes están siendo satisfechas. Muy de acuerdo (7) De acuerdo (1) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0)




25

Es necesario definir un estándar técnico para el trabajo que realiza el equipo. Muy de acuerdo (2) De acuerdo (5) Ni de acuerdo ni en desacuerdo (1) En desacuerdo (0) Muy en desacuerdo (0) En términos generales, Usted está conforme con el trabajo de implantación de prácticas ágiles en el equipo y considera que deberían existir más iteraciones para abordar más prácticas ágiles. Muy de acuerdo (7) De acuerdo (1) Ni de acuerdo ni en desacuerdo (0) En desacuerdo (0) Muy en desacuerdo (0) Los resultados de la encuesta son concluyentes por cuanto al grado de aprobación de las actividades y herramientas implementadas. Es necesario revisar y ajustar prácticas como el tablero Kanban de la cual, si bien es sólo un caso, existe un indicio de que para un miembro del equipo no significa un mayor aporte.

4 Conclusiones

La agilidad es un instrumento poderoso pero intangible, no se puede vender ni comprar, se adquiere, con disciplina, dedicación y constancia. Busca descubrir mejores formas de construir software, ayudando a otros en el proceso. Es un proceso cultural y por tanto, centrado en las personas y su interacción que valora la experiencia y su transmisión. Las metodologías ágiles proveen un marco de trabajo centrado en los principios de la agilidad y son fruto de la experiencia de personas que han adoptado su esencia y la hicieron suya en sus respectivas áreas de conocimiento. Muchas de ellas buscan crear un marco cultural mediante procedimientos, actividades y tareas. En nuestro contexto particular, es de conocimiento público que nuestra cultura latinoamericana dista mucho de las otras culturas en las que nacieron estas metodologías y, según nos ha enseñado la experiencia, no es posible su aplicación directa a nuestra realidad. Requiere algunos ajustes. Herramientas como AgileRoadmap+ de TUNE-UP Process permiten tener una primera aproximación a esta adaptación al contexto cultural propio de cada organización y de cada área dentro de esas organizaciones. La identificación e implantación de las prácticas ágiles seleccionadas permitió en su conjunto potenciar la comunicación, capacidad y experiencia del equipo creando instancias formales de debate y búsqueda de mejores formas de trabajar. Permitió dar visibilidad interna del estado de avance de los proyectos y actividades realizadas mediante la creación de tableros y el establecimiento de la disciplina en el equipo para mantenerlo actualizado, lo cual permitió además mejorar la gestión de los proyectos y actividades pendientes. Esta primera iteración de implantación de prácticas buscaba principalmente la adopción del espíritu de mejora continua, parte de la cultura de la agilidad sin generar un rechazo por tratarse de un tema que fue intentado anteriormente por otras personas y resultó en un rechazo profundo por todo lo que tuviese que ver con agilidad. En este sentido el objetivo global de la primera iteración se cumplió a cabalidad por cuanto la motivación del equipo aumento y continua en aumento. La siguiente iteración buscará hilar más fino en aquellos indicadores que permitan cuantificar de manera más precisa la capacidad y calidad del equipo, así como también generar estadísticas que permitan tomar decisiones a mediano y largo plazo. Además, se buscará profundizar en las prácticas que ya fueron implantadas acercándose un poco más al canon de cada metodología, así como también implantar otras que pudiesen potenciar las ya adoptadas.




26

Lo anterior, unido al hecho de que se incorporaron planes de trabajo, tableros kanban e instancias como reuniones y otros, además de la positiva evaluación del proceso que entregó el equipo y el positivo impacto percibido por la Dirección respecto al proceso, permiten afirmar que la hipótesis planteada se ha cumplido. El principal aporte de este trabajo consiste en la transmisión de la experiencia en la adopción de agilidad en un área de desarrollo de software que, de forma manifiesta, tenía un rechazo contra ella. Es un paso humilde y moderado que se transformó en el catalizador que puso a punto el equipo de trabajo, comprometiéndolos aún más en la entrega de valor a todos los estamentos de la Universidad de Chile, especialmente a la Facultad de Ciencias Físicas y Matemáticas. La recomendación al abordar un trabajo en esta área de conocimiento es simple: busque un buen mentor17 (que tenga experiencia y trayectoria), lea mucho, documéntese desde las fuentes oficiales de información así como también de los referentes de cada una de las metodologías.

Agradecimientos

Agradezco a todas las personas que me acompañaron en este camino, es imposible mencionarlos a todos. Agradezco especialmente a mi Padre, Patricio Arriagada y mi Madre, Rosa Cancino quienes siempre me han guiado y han sido y siempre serán mi ejemplo a seguir. A mi esposa Nancy Leiva y a mis hijos, Francisca Raquel y Juan Pablo, por el tiempo que me regalaron para embarcarme en este desafío, su paciencia y amor en todo momento. A mis compañeros de generación, especialmente a Denny Alquinta, Juan Carlos Orellana, Jorge Salinas, Ricardo Escares, Roberto Schiaffino, Rodrigo Díaz y Rodrigo Fuentes, quienes compartieron su amistad, su extenso conocimiento y experiencias. A mis colegas de trabajo en el Área de Infotecnologías de la Universidad de Chile, especialmente a Milenko Tomic, el primer seguidor y el más crítico en este proceso. A la comunidad Ágil latinoamericana que siempre estuvo dispuesta a entregar consejo, ayuda y motivación, especialmente a Agustín Villena quien fue el guía invisible del trabajo realizado.

17 Puede unirse a la conversación de la Comunidad Ágil Latinoamericana en Telegram mediante el siguiente enlace:

https://t.me/joinchat/BNT3rEQdC1Wc00UBPhES2w




27

5 Referencias

[1] Agustín Villena. ¿Sabemos por qué estamos desarrollando Software?, StarsConf SCL 2017 [Online]. Disponible: https://www.youtube.com/watch?v=d-9lHYXbeQI

[2] Patricio Letelier. AgileRoadmap+ [Online]. Disponible: http://agile-roadmap.tuneupprocess.com [3] K. Beck, M. Beedle, A. van Bennukum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A.

Hunt, R. Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steven Mallor, Ken Schwaber, Jeff Sutherland. The Agile Manifesto [Online]. Disponible: http://agilemanifesto.org

[4] Menzinsky Alexander, López Gertrudris, Palacios Juan:: “Scrum Manager Gestión de Proyectos”, Disponible: http://www.scrummanager.net/files/sm_proyecto.pdf

[5] Scrum [Online]. Disponible: http://www.scrumalliance.org [6] Programación Extrema [Online]. Disponible: http://www.extremeprogramming.org [7] Highsmith Jim, 2001, History: The Agile Manifesto [Online]. Disponible: http://agilemanifesto.org/history.html [8] Patricio Letelier. Curso Gestión Ágil de Proyectos de Software. MTI. [9] Leonardo de Seta. Los 7 principios del desarrollo Lean.

Disponible: https://dosideas.com/noticias/metodologias/410-los-7-principios-del-desarrollo-lean [10] Manuel Rubio. Kanban: El Método Toyota Aplicado al Software.

Disponible: https://altenwald.org/2009/06/22/kanban-el-metodo-toyota-aplicado-al-software/ [11] Henrik Kniberg, Mattias Skarin. Kaban y Scrum - obteniendo lo mejor de ambos. 2010.

Disponible: http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf [12] TuneUP Process. Disponible: http://www.tuneupprocess.com/ [13] ¿Qué es Agile Roadmap+?. Disponible: http://agile-roadmap.tuneupprocess.com [14] ¿Qué es un Agile Roadmap?. Disponible: http://agile-roadmap.tuneupprocess.com [15] Pasos para elaborar un Agile Roadmap+. Disponible: http://agile-roadmap.tuneupprocess.com [16] Evaluación del Nivel de Agilismo. Versión Extendida. Disponible: https://drive.google.com/file/d/0B1C8yUCnvYHoNVUtcDFGSmxXZk1JR1NJbk5jZTQ5MkFxR1dJ/view [17] Manifesto for Agile Software Development. Disponible: http://agilemanifesto.org/ [18] Retrospectives. Disponible: https://www.atlassian.com/team-playbook/plays/retrospective [19] Facilitador (Scrum Master). Disponible: https://proyectosagiles.org/facilitador-scrum-master/ [20] David Lay, 2018, Agilistas Parásitos [Online]. Disponible: https://davidlaym.com/2018/05/agilistas-parasitos [21] Agile Roadmap+, Mapa de Prácticas Ágiles, Practica 8: Organizar el trabajo del equipo con el foco en la generación

de un buen flujo de trabajo terminado [Online]. Disponible: https://agileroadmap.herokuapp.com/es/mapa-practicas-agiles/8

[22] Rohit Sharma, 2017, How to define your Minimum Viable Product? [Online]. Disponible: https://medium.com/hackerlife/how-to-define-your-minimum-viable-product-dc7e118baec1




28

6 Anexos

6.1 Anexo A – Evaluación del Nivel de Agilismo

EVALUACIÓN DEL NIVEL DE AGILISMO

¿POR QUÉ MEDIR EL NIVEL DE AGILISMO?

Determinar el nivel de agilismo como una medida y por sí misma no es algo especialmente interesante. A menos que se quiera alcanzar un cierto nivel para lucir una especie de condecoración por ser ágil, el nivel de agilismo es sólo un dato. Sin embargo, el proceso de medición del nivel de agilismo sí que conlleva conseguir dos importantes resultados: 1) Ser conscientes de las prácticas ágiles que estamos aplicando y en qué intensidad las aplicamos, y 2) Conocer qué prácticas ágiles no estamos aplicando y valorar si sería interesante aplicarlas con algún nivel de intensidad. A diferencia de otras iniciativas para medir el nivel de agilismo esta evaluación es más global e integradora, no se concentra en un determinado método ágil. Utilizamos el catálogo de prácticas ágiles de nuestro sitio Agile Roadmap+ (www.agile-roadmap.tuneupprocess.com), el cual contiene 42 prácticas ágiles provenientes de los métodos ágiles más populares (Scrum, Kanban, Lean Development y Extreme Programming). Además, estas prácticas están explicadas de forma genérica de forma que sean comprendidas también fuera del contexto de desarrollo de software. Otra diferencia en nuestra medición del nivel de agilismo es que las prácticas se valoran en el contexto de trabajo del interesado. Es decir, no es simplemente un cálculo al estilo “mientras más prácticas mayor nivel de agilismo”, sino que se considera la posibilidad de que ciertas prácticas no se incluyan en la evaluación, y más aún, se mide el agilismo en relación con los objetivos de mejora que se desean conseguir en dicho contexto de trabajo. El cuestionario que hemos elaborado permite medir el nivel de agilismo en base a dos perspectivas: el nivel de aplicación de las prácticas ágiles agrupadas por categorías o dimensiones, y los objetivos de mejora que se desean alcanzar (teniendo en cuenta que cada práctica contribuye en cierta medida al cumplimiento de algunos objetivos).

RELLENANDO EL CUESTIONARIO

Hemos preparado este documento ya que el sitio web donde tenemos alojado el cuestionario no permite, de momento, guardarlo para continuar posteriormente. Para responder el cuestionario nos pareció interesante poder hacerlo previamente en un documento que se pudiese manipular fácilmente, para que una vez completado se introduzcan los valores establecidos en el cuestionario de nuestro sitio web disponible en este enlace Cuestionario. Para comenzar, se pide la introducción de unos datos básicos en cuanto al contexto de trabajo y el equipo. Es importante destacar que la evaluación del nivel de agilismo es para un equipo de trabajo en un determinado producto o servicio del cual es responsable. Puede ser necesario elaborar evaluaciones separadas si la gestión de distintos productos o servicios en un mismo equipo presentan diferencias significativas, o más aún, cuando se trata de diferentes equipos.




29

Posteriormente se procede a rellenar la prioridad de los objetivos que se quieren alcanzar en el contexto del trabajo. La prioridad se mide en una escala que va desde el "Urgente cumplimiento" del objetivo hasta "Cumplido o nada prioritario", que indica que el objetivo ya se ha cumplido, y por tanto no se desea tener en cuenta, o que simplemente no es relevante para la evaluación. A continuación se muestra como ejemplo el objetivo “Reducir horas extra” en el formato que se presenta en el cuestionario.

Luego se pasa a la evaluación del nivel (intensidad) de aplicación de las 42 prácticas ágiles, agrupadas en 10 áreas. Al principio de cada área se muestra una imagen donde se remarca el área que se está evaluando y aquellas que ya se han evaluado. El nivel de aplicación (intensidad) de cada práctica ágil se mide seleccionando uno de los siguientes valores: Muy bajo, Bajo, Medio, Alto y Muy alto. A continuación se muestra la práctica 6 tal como se presenta en el cuestionario.

RESULTADOS DEL CUESTIONARIO

Una vez completado el cuestionario se recibirá por email un informe con los resultados de la evaluación. En este informe se incluyen dos gráficos radiales que muestran el nivel actual de agilismo. Además, se proporcionan unas recomendaciones respecto a las prácticas ágiles que se podrían incorporar o intensificar. El primer gráfico presenta el nivel de agilismo en cada área de prácticas ágiles. En este gráfico se pueden visualizar dos zonas; la zona amarilla corresponde al nivel agilismo con respecto al número de prácticas del área, teniendo en cuenta sólo aquellas para las que se ha especificado un nivel de aplicación. El área anaranjada se corresponde con el nivel promedio de agilismo teniendo en cuenta todas las prácticas del área (hayan sido especificadas o no). En la siguiente imagen se muestra un ejemplo de este gráfico radial cuyas dimensiones son las 10 áreas que agrupan prácticas ágiles.




30

El segundo gráfico presenta el nivel de agilismo respecto de los objetivos. En este caso se muestra el nivel de agilismo calculando el número de prácticas respondidas, su nivel de aplicación y la contribución que cada una de ellas hace a la consecución de cada objetivo.

Cada práctica contribuye en distinta medida a la consecución de un determinado objetivo. En la siguiente imagen se muestra la aportación que cada una hace a los objetivos considerados en el cuestionario.




31

Se incluyen 16 objetivos de mejora, cada uno de ellos en el ámbito de Productividad (P), Satisfacción del Cliente (S) o Motivación y compromiso del equipo (M). Las prácticas ágiles tienen diferente contribución al objetivo lo cual se representa con círculos concéntricos, el grado de contribución es mayor desde el centro hacia afuera.




32

EVALUACIÓN DE OBJETIVOS

La prioridad de cada objetivo se mide en una escala de 1 a 5. El valor 1 indica que el objetivo es de máxima prioridad, y el valor 5 que el objetivo no es prioritario o ya ha sido cumplido.

Objetivo de mejora Prioridad

Evitar retrasos: Evitar o reducir los retrasos en las entregas. Gestionar cambios: Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades.

Reducir horas extra: Reducir las horas extras o demanda no prevista de recursos humanos adicionales.

Reducir defectos: Reducir defectos en el trabajo entregado al cliente. Mejorar comunicación: Mejorar la comunicación dentro del equipo y con el cliente. Involucrar cliente: Involucrar en mayor medida al cliente en la planificación, definición y validación del trabajo.

Sistematización trabajo: Mejorar la sistematización del trabajo. Mejora continua: Promover la mejora continua del proceso empleado por el equipo. Reducir re-trabajo: Reducir el re-trabajo debido a trabajo defectuoso o incompleto detectado por el equipo.

Time to market: Reducir el tiempo de entrega al cliente, acelerar el "time to market". Gestión multi-proyecto: Gestionar eficazmente el contexto multi-proyecto. Visibilidad trabajo: Hacer más visible el trabajo del equipo Decisiones oportunas: Tomar decisiones en el momento oportuno Gestión RRHH: Mejorar la gestión de recursos humanos en el equipo Alineación con negocio: Alineación del trabajo del equipo con los objetivos del negocio Evitar sobre-proceso: Evitar costos asociados a la realización de tareas prescindibles o dudosamente rentables

EVALUACIÓN DE PRÁCTICAS ÁGILES Indique el nivel de aplicación que considera tiene cada práctica ágil en su contexto de trabajo (puede omitir algunas que no sean de su interés). Acompañando a algunos valores de nivel de aplicación de la práctica se ofrece un ejemplo de situaciones que corresponden a dicho valor.

Área Fundamento ágil # Práctica ágil

1

Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria

para el cliente. Mas información: http://bit.ly/1HpqIun ☐☐☐☐ Muy bajo: Siempre intentamos conseguir la solución más completa, cueste lo que cueste. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Nos esforzamos en establecer lo mínimo que nos podría ser útil en el momento actual.




33

Área Producto > General # Práctica ágil

2

Abordar y entregar trabajo terminado de forma incremental. Más informaciónhttp://bit.ly/1Nqfww3 ☐☐☐☐ Muy bajo: Abordamos el trabajo todo a la vez y vamos avanzamos todo en conjunto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Abordamos incrementalmente el trabajo comenzando por lo más prioritario.

3

Realizar entregas frecuentes de unidades de trabajo terminadas. Más informaciónhttp://bit.ly/1ecQqFc ☐☐☐☐ Muy bajo: No entregamos nada al cliente hasta que esté todo lo solicitado terminado. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Intentamos entregar frecuentemente trabajo terminado que pueda ser utilizado ya por el cliente.

5

Acotar el trabajo previsto para un período en base a su estimación y la correspondiente coherencia con la capacidad del equipo. (Aplicable solo si el trabajo el planificable). Más informaciónhttp://bit.ly/1JfZCDw ☐☐☐☐ Muy bajo: Comprometemos fechas de entrega sin evaluar el esfuerzo ni nuestra capacidad. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Antes de comprometer la entrega verificamos si es coherente el esfuerzo involucrado con nuestra capacidad.

6

Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista. (Aplicable solo si el trabajo el planificable). Más informaciónhttp://bit.ly/1JrxlNl ☐☐☐☐ Muy bajo: No usamos iteraciones (Sprints) ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Usamos iteraciones (Sprints), tienen la misma duración, la cual es de menos de un mes.

8

Organizar el trabajo del equipo con el foco en la generación de un buen flujo de trabajo terminado. Más informaciónhttp://bit.ly/1BYOCuE ☐☐☐☐ Muy bajo: Realizamos lo que se nos pida en el momento, sin importar interrumpir trabajo no terminado. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Intentar siempre terminar el trabajo ya comenzado que iniciar nuevos trabajos.

9

Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado. Más informaciónhttp://bit.ly/1TX6I5S ☐☐☐☐ Muy bajo: El trabajo pendiente no está explícito u ordenado. Se hace siempre lo que parece más urgente. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El trabajo pendiente es frecuentemente ordenado por el cliente, considerando diversos criterios estratégicos para el éxito del producto o servicio.

13

Seguimiento continuo (frecuencia de días, no semanas). Más informaciónhttp://bit.ly/1KneXoY ☐☐☐☐ Muy bajo: No todo el equipo conoce el estado actualizado del trabajo y/o solo lo conoce en algunos momentos puntuales y distantes entre sí. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Cada miembro del equipo conoce el estado actualizado del trabajo.




34

Área Producto > Técnicas # Práctica ágil

27

Trabajo centrado en satisfacer pruebas de aceptación acordadas con el cliente. Más

informaciónhttp://bit.ly/1NnMfTc ☐☐☐☐ Muy bajo: Al definir el trabajo que se realizará no se establecen las pruebas de aceptación. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Las pruebas de aceptación son establecidas al definir el trabajo. Son la especificación detallada del trabajo en sí.

28

Documentar, pero solo lo estrictamente necesario. Que sea rentable el aprovechamiento de la documentación

respecto del esfuerzo asociado a elaborarla. Más informaciónhttp://bit.ly/1Ils8oL ☐☐☐☐ Muy bajo: Se realizan especificaciones que no tienen una utilidad o propósito claros, o resultan redundantes. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Sólo se especifica lo que pueda resultar imprescindible para ejecutar correctamente el trabajo.

38

Automatizar las pruebas para poder garantizar que el producto mantiene el comportamiento deseado cuando se

realizan cambios. Más informaciónhttp://bit.ly/1LCJfnK ☐☐☐☐ Muy bajo: No se dispone de pruebas de regresión automatizadas. ☐☐☐☐ Bajo:

☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Existen pruebas de regresión automatizada para garantizar ciertas propiedades del sistema.

42

Mejorar continuamente la organización interna del producto para facilitar su mantenimiento. Más

informaciónhttp://bit.ly/1GJBJ4c ☐☐☐☐ Muy bajo: Sólo hacemos cambios explícitamente solicitados por el cliente. No realizamos ninguna mejora de

la arquitectura del producto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: En ciertas situaciones extremas nos damos un tiempo para mejorar la arquitectura del producto. ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Cada vez que modificamos el producto intentamos hacer alguna mejora de su arquitectura.

Área Cliente # Práctica ágil

17

Cliente en estrecho contacto con el equipo y altamente disponible, incluso si es posible, que esté in-situ. Más informaciónhttp://bit.ly/1dquxSa ☐☐☐☐ Muy bajo: El cliente normalmente no está disponible cuando necesitamos hablar con él. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El cliente está junto con el equipo y siempre disponible para resolver cualquier duda.

18

Que exista una única persona que tome las decisiones respecto de las prioridades del trabajo del equipo y que sea un buen representante de la parte cliente. Más información ☐☐☐☐ Muy bajo: Se tienen varios interlocutores de la parte cliente y no se ponen de acuerdo en las prioridades. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: La parte cliente está representada por una persona con autoridad para implantar el producto o

servicio.




35

24

Establecer y comunicar al equipo la visión del producto o servicio, y reforzarla regularmente. Más

informaciónhttp://bit.ly/1LvTI3B ☐☐☐☐ Muy bajo: El cliente no motiva ni ilusiona al equipo con el producto o servicio que deben generar. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El cliente es un líder que tiene la visión del producto o servicio que quiere conseguir.

Área Equipo > General # Práctica ágil

11

Formar equipos pequeños y procurar que mantengan sus integrantes. Más informaciónhttp://bit.ly/1RIGIax ☐☐☐☐ Muy bajo: El equipo tiene decenas de integrantes y constantemente cambia sus componentes. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo tiene menos de 10 miembros y no tienen mucha rotación de integrantes.

12

Acotar el ámbito de trabajo de cada equipo. Más informaciónhttp://bit.ly/1CCgxLK ☐☐☐☐ Muy bajo: El equipo está encargado de muchos productos o de productos muy grandes, esto dificulta su

conocimiento del contexto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo centra su trabajo en un producto o en una parte de él..

15

Visualización de todo el trabajo pendiente encargado al equipo. Más informaciónhttp://bit.ly/1KiycOJ ☐☐☐☐ Muy bajo: Cada persona conoce sólo el trabajo en el que participa ignorando el resto del trabajo de su equipo. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo dispone de un tablero kanban en el cual está actualizado todo su trabajo.

16

Gestión integrada de todo el trabajo asignado, tanto a nivel del equipo como a nivel de cada miembro. Más

informaciónhttp://bit.ly/1KiyeWN ☐☐☐☐ Muy bajo: Las asignaciones de trabajo se deciden sobre la marcha pasando por alto el resto de trabajo asignado

o no asignado. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Las asignaciones de trabajo siempre se deciden a nivel de equipo considerando todo el trabajo

pendiente y sus prioridades.

25

Que el equipo sume entre sus miembros las habilidades para abordar todas las actividades necesarias para terminar

el trabajo. Más informaciónhttp://bit.ly/1QXe9eb ☐☐☐☐ Muy bajo: El equipo debe solicitar ciertas actividades a personas externas esperando para poder continuar. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Equipo cross-functional, no necesita ayuda de nadie externo para completar su trabajo.

35

No abusar de las horas extra, negociar y re-planificar oportunamente para evitarlo. Más

informaciónhttp://bit.ly/1QXecXp ☐☐☐☐ Muy bajo: Sistemáticamente el equipo se ve presionado para realizar horas extras para cumplir plazos. ☐☐☐☐ Bajo: ☐☐☐☐ Medio:




36

☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo mantiene un ritmo de trabajo sostenible, ni relajado ni estresado. Las alteraciones de lo

planificado se detectan y negocian oportunamente.

36

Reducir las interrupciones o cambios de contexto que afectan en su trabajo a los miembros del equipo. Más

informaciónhttp://bit.ly/1IDbGfd ☐☐☐☐ Muy bajo: Los miembros del equipo están expuestos a continuas interrupciones asociadas a trabajos diferentes

al que están realizando. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Los miembros del equipo están protegidos para evitar en lo posible interrupciones en su trabajo.

Área Equipo > Dinámica

# Práctica ágil

7

Evitar invertir esfuerzo en adelantar trabajo que no esté comprometido y/o no esté cercano a su entrega. Más

informaciónhttp://bit.ly/1NnNbqF ☐☐☐☐ Muy bajo: Con frecuencia el equipo está preparando trabajo que se ejecutará mucho más adelante y suele

ocurrir que dicha preparación debe luego actualizarse, o que incluso el trabajo no llega a ejecutarse. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo sólo trabaja en la definición del trabajo que se realizará de inmediato.

10

Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una

determinada actividad. Más informaciónhttp://bit.ly/1LCJtvm ☐☐☐☐ Muy bajo: No hay control del WIP, hay actividades que presentan gran acumulación de trabajo en proceso

y quienes realizan dichas actividades no dan abasto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: Si bien no existen límites específicos, se supervisa la cantidad de trabajo en cada actividad para

evitar los cuellos de botella. ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: En cada actividad existe un número máximo de trabajos que pueden estar en proceso. (Se asume

que es posible establecer dicho límite).

26

Que los integrantes del equipo puedan encargarse de diferentes tipos de actividades (ojalá de todas), aunque

puedan ser especialistas en alguna(s) de ellas. Más informaciónhttp://bit.ly/1HpsBqV ☐☐☐☐ Muy bajo: Cada miembro del equipo desempeña un cargo específico y no está dispuesto a realizar actividades

fuera de cargo. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Aunque existen especialistas en algunas actividades, todos los miembros del equipo están

dispuestos a echar una mano en cualquier actividad.

34

Trabajo o actividades realizadas en conjunto por dos o más integrantes. Más

informaciónhttp://bit.ly/1LCJsaI ☐☐☐☐ Muy bajo: Los integrantes del equipo no están dispuestos a trabajar con otros en una misma tarea. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: Algunas tareas que son críticas o de gran tamaño son abordadas trabajando en parejas. ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Los integrantes del equipo realizan todas sus tareas en parejas.

39 Postergar hasta último momento la asignación del encargado de realizar una actividad. Más

informaciónhttp://bit.ly/1fYqRbX




37

☐☐☐☐ Muy bajo: Los integrantes tienen trabajo asignado con mucha anticipación y suele suceder que en el momento que deberían realizarlo están ocupados en otras tareas.

☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Las actividades se asignan (auto-asignan) en el momento justo antes de tener que realizarlas.

40

Integrar de forma continua en el producto el trabajo terminado. Más informaciónhttp://bit.ly/1BNXMcU ☐☐☐☐ Muy bajo: El trabajo se integra después de días o semanas, y suelen aparecer conflictos por cambios

realizados en partes del producto donde han trabajado varios integrantes. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Los integrantes del equipo integran varias veces al día su trabajo terminado con el del resto del

equipo.

41

Promover que los miembros del equipo en su trabajo lleguen a conocer todas las partes del producto o servicio

que han sido encargadas al equipo. Más informaciónhttp://bit.ly/1HpsQ5h

☐☐☐☐ Muy bajo: Cada integrante se especializa en una parte del producto o servicio y no tienen experiencia en otras partes.

☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Si bien pueden existir especialistas en ciertas partes del producto o servicio, se promueve que

todos los integrantes del equipo conozcan todo y se familiaricen modificando partes que no son su especialidad.

Área Equipo > Reuniones # Práctica ágil

4

Realizar reuniones de planificación frecuentemente (frecuencia de pocas semanas, no meses). (Aplicable solo si el trabajo el planificable). Más información. ☐☐☐☐ Muy bajo: Sólo se realiza formalmente una reunión de planificación antes de comenzar el trabajar pero luego

sólo se realizan de manera informal, de forma irregular, o simplemente no se realizan. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Se realizan reuniones de planificación constantemente, especialmente cuando se detecta alguna

variación significativa del trabajo. Si se utilizan Sprints debería haber una reunión de planificación al menos antes de cada Sprint.

14

Realizar una reunión diaria del equipo al completo, cara a cara y muy breve. Más

informaciónhttp://bit.ly/1KngZFC ☐☐☐☐ Muy bajo: No se realiza la reunión diaria, ni siquiera con menor frecuencia. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: La reunión se realiza cada día y no dura más de 15 minutos.

19

Realizar reuniones de revisión del trabajo entregado. Más informaciónhttp://bit.ly/1NqiTmx ☐☐☐☐ Muy bajo: No se realizan reuniones de revisión. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: Se realizan reuniones de revisión pero no suele asistir el cliente. ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Después de cada Sprint, Entrega o al menos regularmente se realiza una reunión de revisión con el

cliente.




38

32

Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua

del proceso. Más informaciónhttp://bit.ly/1IlsYla ☐☐☐☐ Muy bajo: No se realizan reuniones de retrospectiva. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Después de cada Sprint, entrega o al menos regularmente se realiza una reunión de retrospectiva.

37

Establecer una disciplina de aprovechamiento de las reuniones. Más informaciónhttp://bit.ly/1ecSiOa ☐☐☐☐ Muy bajo: Las reuniones suelen ser improductivas. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Las reuniones son correctamente moderadas, consiguen sus objetivos y se ciñen al tiempo previsto.

Área Equipo > Espacio de trabajo # Práctica ágil

22

Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico.

Más informaciónhttp://bit.ly/1LvUWf4 ☐☐☐☐ Muy bajo: Equipo distribuido y sin comunicación directa (on-line). ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Equipo co-localizado.

23

Contar con un espacio físico de trabajo que favorezca la interacción entre los miembros del equipo.

Más informaciónhttp://bit.ly/1LvUZaE ☐☐☐☐ Muy bajo: Espacio con serios inconvenientes para que los miembros del equipo se comuniquen, trabajen en

parejas o tenga reuniones. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Espacio bien acondicionado para favorecer la comunicación en el equipo, trabajo en parejas y

reuniones. Área Equipo > Liderazgo # Práctica ágil

20

El equipo se auto-organiza y toma las decisiones técnicas. Más informaciónhttp://bit.ly/1eSbEcn ☐☐☐☐ Muy bajo: Los miembros del equipo esperan a que alguien (jefe o cliente) les asigne trabajo y les proporcione

indicaciones técnicas al respecto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Los miembros del equipo, de mutuo acuerdo, se distribuyen el trabajo, deciden cómo abordarlo y

toman las decisiones técnicas.

21

Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador. Más informaciónhttp://bit.ly/1FIsIqg ☐☐☐☐ Muy bajo: El jefe ejerce un fuerte control sobre todo el trabajo de cada uno de los miembros del equipo. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El jefe resuelve cualquier impedimento o conflicto que afecte el rendimiento del equipo y reduce su

exposición a interrupciones no deseadas.




39

Área Definición y mejora del proceso # Práctica ágil

29

Establecer pautas para gestionar convenientemente el re-trabajo. Más informaciónhttp://bit.ly/1LvVdyE ☐☐☐☐ Muy bajo: Cada miembro del equipo actúa de forma diferente cuando detecta algún defecto. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Está consensuado por el equipo cómo debe actuarse cuando se detectan defectos.

30

Que exista un líder de mejora de proceso disponible para el equipo. Más informaciónhttp://bit.ly/1Iltb88 ☐☐☐☐ Muy bajo: Los miembros del equipo no disponen de una persona de apoyo para la mejora del proceso. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Existe una persona con experiencia en mejora de procesos con disponibilidad para apoyar y orientar

al equipo en cuanto a mejora de proceso.

31

Establecimiento de estándares para el trabajo técnico del equipo. Más informaciónhttp://bit.ly/1KiyVQb ☐☐☐☐ Muy bajo: Cada integrante del equipo tiene sus propios criterios técnicos para la realización del trabajo. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: El equipo ha adoptado en las diferentes actividades estándares (externos y/o propios) respecto a

cómo realizar el trabajo técnico.

33

Acordar y definir qué se entiende por trabajo terminado, tanto para las actividades realizadas por el equipo como

respecto de las entregas al cliente. Más informaciónhttp://bit.ly/1LCJDCV ☐☐☐☐ Muy bajo: Cada miembro del equipo interpreta de forma diferente lo que se entiende por finalizar una actividad

(o para dar por realizada una entrega) o las tareas que deben realizarse para ello. ☐☐☐☐ Bajo: ☐☐☐☐ Medio: ☐☐☐☐ Alto: ☐☐☐☐ Muy alto: Están claramente establecidas las tareas que deben realizarse y los criterios necesarios para dar por

finalizada una actividad o una entrega al cliente.




40

6.2 Anexo B – Detalle Evaluación Nivel de Agilismo

La prioridad de cada objetivo se mide en una escala de 1 a 5. El valor 1 indica que el objetivo es de máxima prioridad, y el valor 5 que el objetivo no es prioritario o ya ha sido cumplido. El resumen es el siguiente:

OBJETIVO O PREGUNTA VALOR Evitar retrasos: Evitar o reducir los retrasos en las entregas. 3 Gestionar cambios: Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades.

5

Reducir horas extra: Reducir las horas extras o demanda no prevista de recursos humanos adicionales.

1

Reducir defectos: Reducir defectos en el trabajo entregado al cliente. 5 Mejorar comunicación: Mejorar la comunicación dentro del equipo y con el cliente. 4 Involucrar cliente: Involucrar en mayor medida al cliente en la planificación, definición y validación del trabajo.

1

Sistematización trabajo: Mejorar la sistematización del trabajo. 4

Mejora continua: Promover la mejora continua del proceso empleado por el equipo. 4 Reducir re-trabajo: Reducir el re-trabajo debido a trabajo defectuoso o incompleto detectado por el equipo.

4

Time to market: Reducir el tiempo de entrega al cliente, acelerar el "time to market". 3 Gestión multi-proyecto: Gestionar eficazmente el contexto multi-proyecto. 5 Visibilidad trabajo: Hacer más visible el trabajo del equipo. 5 Decisiones oportunas: Tomar decisiones en el momento oportuno. 4 Gestión RRHH: Mejorar la gestión de recursos humanos en el equipo. 2 Alineación con negocio: Alineación del trabajo del equipo con los objetivos del negocio.

4

Evitar sobre-proceso: Evitar costos asociados a la realización de tareas prescindibles o dudosamente rentables.

3

La segunda parte del cuestionario indica el nivel de aplicación que se considera tiene cada práctica ágil en el contexto de trabajo. En la siguiente tabla se muestra los resultados de la evaluación.

PRÁCTICA ÁGIL

NIVEL DESCRIPCIÓN

Área Fundamento Ágil

1

Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente.

MEDIO

Siempre intentamos conseguir la solución más completa, cueste lo que cueste.

Área Producto > General

2 Abordar y entregar trabajo terminado de forma incremental. ALTO

Abordamos incrementalmente el trabajo comenzando por lo más prioritario.

3 Realizar entregas frecuentes de unidades de trabajo terminadas. ALTO

Intentamos entregar frecuentemente trabajo terminado que pueda ser utilizado ya por el cliente.




41

5

Acotar el trabajo previsto para un período en base a su estimación y la correspondiente coherencia con la capacidad del equipo. (Aplicable solo si el trabajo el planificable).

ALTO

Antes de comprometer la entrega verificamos si es coherente el esfuerzo involucrado con nuestra capacidad.

6

Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista. (Aplicable solo si el trabajo el planificable).

MUY BAJO

No usamos iteraciones (Sprints)

8 Organizar el trabajo del equipo con el foco en la generación de un buen flujo de trabajo terminado.

MEDIO Realizamos lo que se nos pida en el momento, sin importar interrumpir trabajo no terminado.

9 Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado.

MEDIO El trabajo pendiente no está explícito u ordenado. Se hace siempre lo que parece más urgente.

13 Seguimiento continuo (frecuencia de días, no semanas). BAJO

No todo el equipo conoce el estado actualizado del trabajo y/o solo lo conoce en algunos momentos puntuales y distantes entre sí.

Área Producto > Técnicas

27 Trabajo centrado en satisfacer pruebas de aceptación acordadas con el cliente. MEDIO

Al definir el trabajo que se realizará no se establecen las pruebas de aceptación.

28

Documentar, pero solo lo estrictamente necesario. Que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla.

MUY ALTO

Sólo se especifica lo que pueda resultar imprescindible para ejecutar correctamente el trabajo.

38

Automatizar las pruebas para poder garantizar que el producto mantiene el comportamiento deseado cuando se realizan cambios.

MUY BAJO

No se dispone de pruebas de regresión automatizadas.

42 Mejorar continuamente la organización interna del producto para facilitar su mantenimiento.

MEDIO En ciertas situaciones extremas nos damos un tiempo para mejorar la arquitectura del producto.

Área Cliente

17 Cliente en estrecho contacto con el equipo y altamente disponible, incluso si es posible, que esté in-situ.

ALTO El cliente está junto con el equipo y siempre disponible para resolver cualquier duda.

18

Que exista una única persona que tome las decisiones respecto de las prioridades del trabajo del equipo y que sea un buen representante de la parte cliente.

ALTO

La parte cliente está representada por una persona con autoridad para implantar el producto o servicio.

24 Establecer y comunicar al equipo la visión del producto o servicio, y reforzarla regularmente.

BAJO El cliente no motiva ni ilusiona al equipo con el producto o servicio que deben generar.

Área Equipo > General

11 Formar equipos pequeños y procurar que mantengan sus integrantes.

MUY ALTO

El equipo tiene menos de 10 miembros y no tienen mucha rotación de integrantes.




42

12 Acotar el ámbito de trabajo de cada equipo. ALTO

El equipo centra su trabajo en un producto o en una parte de él..

15 Visualización de todo el trabajo pendiente encargado al equipo. ALTO

El equipo dispone de un tablero kanban en el cual está actualizado todo su trabajo.

16 Gestión integrada de todo el trabajo asignado, tanto a nivel del equipo como a nivel de cada miembro.

ALTO Las asignaciones de trabajo siempre se deciden a nivel de equipo considerando todo el trabajo pendiente y sus prioridades.

25

Que el equipo sume entre sus miembros las habilidades para abordar todas las actividades necesarias para terminar el trabajo.

MUY ALTO

Equipo cross-functional, no necesita ayuda de nadie externo para completar su trabajo.

35

No abusar de las horas extra, negociar y re-planificar oportunamente para evitarlo. MUY

ALTO

El equipo mantiene un ritmo de trabajo sostenible, ni relajado ni estresado. Las alteraciones de lo planificado se detectan y negocian oportunamente.

36 Reducir las interrupciones o cambios de contexto que afectan en su trabajo a los miembros del equipo.

BAJO Los miembros del equipo están expuestos a continuas interrupciones asociadas a trabajos diferentes al que están realizando.

Área Equipo > Dinámica

7

Evitar invertir esfuerzo en adelantar trabajo que no esté comprometido y/o no esté cercano a su entrega. MEDIO

Con frecuencia el equipo está preparando trabajo que se ejecutará mucho más adelante y suele ocurrir que dicha preparación debe luego actualizarse, o que incluso el trabajo no llega a ejecutarse.

10

Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad.

ALTO

En cada actividad existe un número máximo de trabajos que pueden estar en proceso. (Se asume que es posible establecer dicho límite).

26

Que los integrantes del equipo puedan encargarse de diferentes tipos de actividades (ojalá de todas), aunque puedan ser especialistas en alguna(s) de ellas.

MUY ALTO

Aunque existen especialistas en algunas actividades, todos los miembros del equipo están dispuestos a echar una mano en cualquier actividad.

34 Trabajo o actividades realizadas en conjunto por dos o más integrantes. MEDIO

Algunas tareas que son críticas o de gran tamaño son abordadas trabajando en parejas.

39 Postergar hasta último momento la asignación del encargado de realizar una actividad.

ALTO Las actividades se asignan (auto-asignan) en el momento justo antes de tener que realizarlas.

40 Integrar de forma continua en el producto el trabajo terminado. ALTO

Los integrantes del equipo integran varias veces al día su trabajo terminado con el del resto del equipo.

41

Promover que los miembros del equipo en su trabajo lleguen a conocer todas las partes del producto o servicio que han sido encargadas al equipo.

ALTO

Si bien pueden existir especialistas en ciertas partes del producto o servicio, se promueve que todos los integrantes del equipo conozcan todo y se familiaricen modificando partes que no son su especialidad.

Área Equipo > Reuniones




43

4

Realizar reuniones de planificación frecuentemente (frecuencia de pocas semanas, no meses). (Aplicable solo si el trabajo el planificable). ALTO

Se realizan reuniones de planificación constantemente, especialmente cuando se detecta alguna variación significativa del trabajo. Si se utilizan Sprints debería haber una reunión de planificación al menos antes de cada Sprint.

14 Realizar una reunión diaria del equipo al completo, cara a cara y muy breve. MEDIO

No se realiza la reunión diaria, ni siquiera con menor frecuencia.

19 Realizar reuniones de revisión del trabajo entregado. ALTO

Después de cada Sprint, Entrega o al menos regularmente se realiza una reunión de revisión con el cliente.

32

Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua del proceso.

BAJO

No se realizan reuniones de retrospectiva.

37 Establecer una disciplina de aprovechamiento de las reuniones. MEDIO

Las reuniones suelen ser improductivas.

Área Equipo > Espacio de Trabajo

22 Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico.

MUY ALTO

Equipo co-localizado.

23 Contar con un espacio físico de trabajo que favorezca la interacción entre los miembros del equipo.

MUY ALTO

Espacio bien acondicionado para favorecer la comunicación en el equipo, trabajo en parejas y reuniones.

Área Equipo > Liderazgo

20 El equipo se auto-organiza y toma las decisiones técnicas. ALTO

Los miembros del equipo, de mutuo acuerdo, se distribuyen el trabajo, deciden cómo abordarlo y toman las decisiones técnicas.

21

Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador. ALTO

El jefe resuelve cualquier impedimento o conflicto que afecte el rendimiento del equipo y reduce su exposición a interrupciones no deseadas.

Área Definición y Mejora del Proceso

29 Establecer pautas para gestionar convenientemente el re-trabajo. ALTO

Está consensuado por el equipo cómo debe actuarse cuando se detectan defectos.

30

Que exista un líder de mejora de proceso disponible para el equipo.

ALTO

Existe una persona con experiencia en mejora de procesos con disponibilidad para apoyar y orientar al equipo en cuanto a mejora de proceso.

31 Establecimiento de estándares para el trabajo técnico del equipo. ALTO

El equipo ha adoptado en las diferentes actividades estándares (externos y/o propios) respecto a cómo realizar el trabajo técnico.

33

Acordar y definir qué se entiende por trabajo terminado, tanto para las actividades realizadas por el equipo como respecto de las entregas al cliente.

MUY ALTO

Están claramente establecidas las tareas que deben realizarse y los criterios necesarios para dar por finalizada una actividad o una entrega al cliente.




44

6.3 Anexo C – Objetivos de Mejora, Prácticas, Relación entre Objetivos y Prácticas de TUNE-UP

La información que se entrega a continuación fue obtenida mediante ingeniería inversa a la herramienta sitio Agile Roadmap+ debido a que, en el momento en que se realizó la evaluación del nivel de agilismo, la herramienta online no estaba entregando la información correcta respecto a la recomendación de prácticas a implantar. La siguiente tabla detalla los objetivos de mejora TUNE-UP y sus códigos:

OBJ7 Hacer más visible el trabajo del equipo OBJ3 Gestionar eficazmente los cambios, tanto en los trabajos como en sus prioridades OBJ5 Reducir defectos en el trabajo entregado al cliente OBJ22 Gestionar eficazmente el contexto multi-proyecto OBJ10 Mejorar la comunicación dentro del equipo y con el cliente OBJ15 Mejorar la sistematización del trabajo OBJ19 Promover la mejora continua del proceso empleado por el equipo OBJ20 Reducir el re-trabajo debido a trabajos defectuoso o incompleto detectado por el equipo OBJ8 Tomar decisiones en el momento oportuno OBJ11 Alineación del trabajo del equipo con los objetivos del negocio OBJ1 Evitar o reducir los retrasos en las entregas OBJ21 Reducir el tiempo de entrega al cliente, acelerar el "time to market" OBJ14 Evitar costos asociados a la realización de tareas prescindibles o dudosamente rentables OBJ9 Mejorar la gestión de recursos humanos en el equipo OBJ4 Reducir las horas extras o demanda no prevista de recursos humanos adicionales OBJ12 Involucrar en mayor medida al cliente en la planificación, definición y validación del trabajo

La siguiente tabla detalla las prácticas ágiles identificadas por TUNE-UP y sus códigos:

PRA1 Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente.

PRA2 Abordar y entregar trabajo terminado de forma incremental. PRA3 Realizar entregas frecuentes de unidades de trabajo terminadas.


PRA5 Acotar el trabajo previsto para un período en base a su estimación y la correspondiente coherencia con la capacidad del equipo.

PRA6 Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista.

PRA7 Evitar invertir esfuerzo en adelantar trabajo que no esté comprometido y/o no esté cercano a su entrega.


PRA9 Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado.

PRA10 Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad.

PRA11 Formar equipos pequeños y procurar que mantengan sus integrantes. PRA12 Acotar el ámbito de trabajo de cada equipo. PRA13 Seguimiento continuo (frecuencia de días, no semanas).




45

PRA14 Realizar una reunión diaria del equipo al completo, cara a cara y muy breve. PRA15 Visualización de todo el trabajo pendiente encargado al equipo.


PRA17 Cliente en estrecho contacto con el equipo y altamente disponible, incluso si es posible, que esté in-situ.

PRA18 Que exista una única persona que tome las decisiones respecto de las prioridades del trabajo del equipo y que sea un buen representante de la parte cliente.

PRA19 Realizar reuniones de revisión del trabajo entregado. PRA20 El equipo se auto-organiza y toma las decisiones técnicas.

PRA21 Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador.

PRA22 Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico.

PRA23 Contar con un espacio físico de trabajo que favorezca la interacción entre los miembros del equipo.

PRA24 Establecer y comunicar al equipo la visión del producto o servicio, y reforzarla regularmente.

PRA25 Que el equipo sume entre sus miembros las habilidades para abordar todas las actividades necesarias para terminar el trabajo.

PRA26 Que los integrantes del equipo puedan encargarse de diferentes tipos de actividades (ojalá de todas), aunque puedan ser especialistas en alguna(s) de ellas.

PRA27 Trabajo centrado en satisfacer pruebas de aceptación acordadas con el cliente.

PRA28 Documentar, pero solo lo estrictamente necesario. Que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla.

PRA29 Establecer pautas para gestionar convenientemente el re-trabajo. PRA30 Que exista un líder de mejora de proceso disponible para el equipo. PRA31 Establecimiento de estándares para el trabajo técnico del equipo.

PRA32 Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua del proceso.

PRA33 Acordar y definir qué se entiende por trabajo terminado, tanto para las actividades realizadas por el equipo como respecto de las entregas al cliente.

PRA34 Trabajo o actividades realizadas en conjunto por dos o más integrantes. PRA35 No abusar de las horas extras, negociar y re-planificar oportunamente para evitarlo.

PRA36 Reducir las interrupciones o cambios de contexto que afectan en su trabajo a los miembros del equipo.

PRA37 Establecer una disciplina de aprovechamiento de las reuniones

PRA38 Automatizar las pruebas para poder garantizar que el producto mantiene el comportamiento deseado cuando se realizan cambios.

PRA39 Postergar hasta último momento la asignación del encargado de realizar una actividad. PRA40 Integrar de forma continua en el producto el trabajo terminado.

PRA41 Promover que los miembros del equipo en su trabajo lleguen a conocer todas las partes del producto o servicio que han sido encargadas al equipo.

PRA42 Mejorar continuamente la organización interna del producto para facilitar su mantenimiento.




46

La siguiente tabla muestra la relación entre las prácticas y aporte de las mismas a los objetivos de mejora:

OBJ1 OBJ3 OBJ4 OBJ5 OBJ7 OBJ8 OBJ9 OBJ10 OBJ11 OBJ12 OBJ14 OBJ15 OBJ19 OBJ20 OBJ21 OBJ22

PRA1 5 5 5 PRA2 4 2 4 PRA3 4 2 2 4 PRA4 3 4 3 2 3 PRA5 3 4 3 PRA6 4 3 PRA7 4 PRA8 3 4 2 4 3 PRA9 5 3 5 5 PRA10 4 PRA11 2 4 4 PRA12 4 PRA13 3 4 4 PRA14 3 4 3 PRA15 5 5 5 5 5 PRA16 5 5 4 4 PRA17 4 5 4 PRA18 4 4 PRA19 4 4 PRA20 5 PRA21 2 PRA22 2 3 4 PRA23 4 PRA24 4 PRA25 2 4 PRA26 5 PRA27 5 4 PRA28 4 PRA29 2 PRA30 4 3 4 PRA31 4 PRA32 4 4 PRA33 4 3 PRA34 3 PRA35 4 2 PRA36 3 PRA37 3 PRA38 4 PRA39 4 PRA40 3 2 PRA41 3 PRA42 1 2




47

La siguiente tabla muestra la relación entre las prácticas:

PRA1 "PRA27" PRA2 "PRA3", "PRA5", "PRA6", "PRA9", "PRA40" PRA3 "PRA2", "PRA5", "PRA6", "PRA13" PRA4 "PRA9", "PRA11", "PRA15", "PRA16", "PRA17", "PRA22", "PRA35", "PRA37" PRA5 "PRA2", "PRA3", "PRA6", "PRA15", "PRA16", "PRA35" PRA6 "PRA2", "PRA3", "PRA5", "PRA9", "PRA15", "PRA16" PRA7 "PRA10" PRA8 PRA9 "PRA2", "PRA4", "PRA6", "PRA14", "PRA15", "PRA17" PRA10 "PRA7", "PRA12", "PRA16", "PRA35", "PRA36" PRA11 "PRA4", "PRA14", "PRA22", "PRA19", "PRA20", "PRA32" PRA12 "PRA10", "PRA36" PRA13 "PRA3", "PRA15", "PRA14", "PRA16" PRA14 "PRA37", "PRA15", "PRA16", "PRA13", "PRA22", "PRA11", "PRA9" PRA15 "PRA14", "PRA16", "PRA13", "PRA9", "PRA4", "PRA5", "PRA6" PRA16 "PRA15", "PRA14", "PRA13", "PRA4", "PRA5", "PRA6", "PRA10", "PRA19", "PRA35" PRA17 "PRA9", "PRA4", "PRA19" PRA18 "PRA21", "PRA20" PRA19 "PRA37", "PRA16", "PRA22", "PRA11", "PRA17", "PRA33" PRA20 "PRA11", "PRA21", "PRA18" PRA21 "PRA18", "PRA20" PRA22 "PRA14", "PRA11", "PRA4", "PRA19", "PRA32" PRA23 "PRA34" PRA24 PRA25 PRA26 PRA27 "PRA1", "PRA33", "PRA28" PRA28 "PRA27", "PRA33", "PRA31" PRA29 "PRA32" PRA30 "PRA33", "PRA32", "PRA31" PRA31 "PRA30", "PRA28" PRA32 "PRA37", "PRA22", "PRA11", "PRA29", "PRA30" PRA33 "PRA27", "PRA19", "PRA30", "PRA28" PRA34 "PRA23" PRA35 "PRA16", "PRA4", "PRA5", "PRA10" PRA36 "PRA12", "PRA10" PRA37 "PRA14", "PRA4", "PRA19", "PRA32" PRA38 "PRA40" PRA39 PRA40 "PRA2", "PRA38" PRA41 PRA42




48

La siguiente tabla muestra el esfuerzo de implantación y nivel de aplicación de cada una de las prácticas seleccionadas como candidatas.

Código Descripción Esfuerzo de Implantación Nivel de

Aplicación

PRA2 Abordar y entregar trabajo terminado de forma incremental.

Medio Bajo

PRA3 Realizar entregas frecuentes de unidades de trabajo terminadas.

Medio Muy bajo


Muy bajo Muy bajo

PRA6 Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista.

Medio Bajo

PRA7 Evitar invertir esfuerzo en adelantar trabajo que no esté comprometido y/o no esté cercano a su entrega.

Muy bajo Medio


Alto Bajo

PRA9 Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado.

Alto Medio

PRA10 Limitar el trabajo en proceso (WIP), es decir, la cantidad de unidades de trabajo que tiene el equipo en una determinada actividad.

Medio Muy bajo

PRA11 Formar equipos pequeños y procurar que mantengan sus integrantes.

Muy bajo Muy alto

PRA13 Seguimiento continuo (frecuencia de días, no semanas).

Muy bajo Bajo

PRA14 Realizar una reunión diaria del equipo al completo, cara a cara y muy breve.

Bajo Muy bajo

PRA15 Visualización de todo el trabajo pendiente encargado al equipo.

Medio Muy bajo


Alto Muy bajo

PRA17 Cliente en estrecho contacto con el equipo y altamente disponible, incluso si es posible, que esté in-situ.

Muy alto Muy bajo

PRA18

Que exista una única persona que tome las decisiones respecto de las prioridades del trabajo del equipo y que sea un buen representante de la parte cliente.

Bajo Medio

PRA19 Realizar reuniones de revisión del trabajo entregado.

Muy bajo Alto

PRA22 Co-localización de los miembros del equipo, todo el equipo trabajando en el mismo espacio físico.

Muy bajo Muy alto

PRA23 Contar con un espacio físico de trabajo que favorezca la interacción entre los miembros del equipo.

Muy bajo Muy alto




49

PRA24 Establecer y comunicar al equipo la visión del producto o servicio, y reforzarla regularmente.

Alto Muy bajo

PRA27 Trabajo centrado en satisfacer pruebas de aceptación acordadas con el cliente.

Muy alto Muy bajo

PRA28

Documentar, pero solo lo estrictamente necesario. Que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla.

Medio Alto

PRA30 Que exista un líder de mejora de proceso disponible para el equipo.

Alto Muy bajo

PRA31 Establecimiento de estándares para el trabajo técnico del equipo.

Alto Alto

PRA32 Realizar reuniones de retrospectiva para evaluar el desempeño del equipo y sus formas de trabajo. Mejora continua del proceso.

Medio Muy bajo

PRA42 Mejorar continuamente la organización interna del producto para facilitar su mantenimiento.

Muy alto Medio

mejora continua en la gestión de una unidad de ti ... · producto 6 incluye además consultoría,...

Documents