SCRUM LEVEL Guía para evaluación de la agilidad 1.02

Transcripción

1 SCRUM LEVEL Guía para evaluación de la agilidad 1.02

2 SCRUM LEVEL Junio EXENCIÓN DE RESPONSABILIDAD LOS AUTORES DE ESTE DOCUMENTO SON MIEMBROS Y COLABORADORES DE LA COMUNIDAD PROFESIONAL SCRUM MANAGER VERSADOS EN GESTIÓN DE PROYECTOS; REALIZAN ESTE TRABAJO PARA COMPARTIR SU CONOCIMIENTO PROFESIONAL CON LAS PERSONAS Y ORGANIZACIONES QUE LO CONSIDEREN ÚTIL. ESTE TRABAJO SE OFRECE TAL CUAL, SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O IMPLÍCITA INCLUYENDO GARANTÍAS DE IDONEIDAD PARA UN PROPÓSITO PARTICULAR. EN NINGÚN CASO, NI LOS AUTORES, NI LOS TITULARES DE LOS DERECHOS SERÁN RESPONSABLES DE NINGUNA RECLAMACIÓN, DAÑOS U OTRAS RESPONSABILIDADES. Han hecho posible esta versión de Scrum Level: Alexander Menzinsky, Claudia Ruata, Marta Ariza, Miguel Santiago, Nelson Monzón, José López, Juan Palacio y Raquel García. Imagen de portada cc by Tim Sheerman-Chase Scrum Level es una iniciativa creada y coordinada por Iubaris Info 4 Media SL, y desarrollada como obra colectiva por profesores y colaboradores de la comunidad profesional Scrum manager. Iubaris Info 4 Media SL es la propietaria de los derechos, y los libera en las condiciones de la licencia Creative Commons by nd nc 4.0 Scrum Level y Scrum Manager son marcas registradas, propiedad de Iubaris Info 4 Media SL Derechos registrados en Safe Creative. Nº de registro :

3 Contenido PREFACIO... 5 Propósito de este documento... 5 Audiencia... 5 Organización de esta guía:... 5 Convenciones empleadas... 5 INTRODUCCIÓN... 6 Lo que entendemos por scrum Rugby Métodos de trabajo... 7 Gestión Ágil... 9 Técnicas, prácticas y valores... 9 Técnicas y prácticas: Valores: Implicación del cliente GESTIÓN DE PROYECTOS PREDICTIVA Y EVOLUTIVA ÁMBITO DE SCRUM LEVEL Dimensiones Factores analizados TÉCNICAS Y PRÁCTICAS EJES ORGÁNICOS Tabla 2: Ejes orgánicos a medir en la organización EVALUACIÓN Y ANÁLISIS Dimensiones Evaluación de la flexibilidad Evaluación de la flexibilidad: Prácticas y técnicas Conocimiento técnico ágil Análisis y evaluación de la flexibilidad Prácticas Evaluación de la flexibilidad: Conocimiento técnico Formulación de la flexibilidad Prácticas Evaluación de la fluidez Evaluación de la fluidez: Ejes orgánicos Conocimiento profesional de las personas Análisis y valoración de la fluidez Rasgos

4 Formulación de la fluidez Ejes orgánicos ANÁLISIS Informar de la fiabilidad Analizar los puntos de atención de la evaluación Consideraciones Apéndices Documento de evaluación Protocolos Normas y restricciones para protocolos Glosario Trabajos citados Índice

5 PREFACIO Scrum Level es un modelo de referencia y buenas prácticas para mejorar la agilidad en la gestión y producción. Este modelo se ha desarrollado, y está en continua revisión y mejora, desde el conocimiento y experiencia aportados por los miembros y colaboradores de la comunidad profesional Scrum Manager. Propósito de este documento Guía y referencia en los procesos de evaluación Scrum Level. Audiencia La audiencia de esta guía incluye a todas las personas interesadas en la mejora de la gestión y producción ágil; resulta adecuada como texto formativo para los interesados en el conocimiento o estudio de la agilidad, y como documento de referencia para los responsables de procesos de evaluación, asesoría y mejora. Organización de esta guía: Introducción Puesta en contexto del origen y razón de la agilidad, y de esta guía. Scrum Descripción de Scrum, desde la perspectiva de Scrum Manager. Scrum Level Presentación esquemática de Scrum Level. Evaluación y análisis Guía para evaluaciones Scrum Level, y uso de los resultados en procesos de asesoría y mejora. Convenciones empleadas Los términos recogidos en el glosario aparecen en cursiva siempre que se emplean con el significado concreto en él definido. 5

6 INTRODUCCIÓN Muchas compañías han descubierto que para mantenerse en el actual mercado competitivo necesitan algo más que los conceptos básicos de calidad elevada, costes reducidos, diferenciación. Además de esto también es necesario velocidad y flexibilidad Ikujiro Nonaka, Hirotaka Takeuchi (1986) The New New Product Development Game A esta conclusión llegaron Nonaka y Takeuchi en 1986, tras analizar a las empresas tecnológicas que mejor respondían al cambio rápido y continuo de sus entornos de negocio. En ellas identificaron como denominador común, una forma de trabajo a la que denominaron scrum, porque el factor clave, al igual que en la formación scrum de rugby, eran equipos comprometidos y atenazados. El trabajo en scrum era el empleado en los departamentos de innovación y desarrollo de nuevos productos de las empresas tecnológicas, objeto del estudio de Nonaka y Takeuchi (Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett- Packard) y se propagó durante las dos décadas siguientes al desarrollo de software. En 2001, diecisiete expertos en desarrollo de software, convocados por Kent Beck, resumieron de forma breve y memorable en el documento que denominaron Manifiesto Ágil (Agile Manifesto) estos nuevos principios, aplicados al software: Manifiesto por el Desarrollo Ágil de Software 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. (2001) Manifesto for Agile Software Development Las empresas que desarrollan productos, y tienen en la innovación su principal valor o ventaja competitiva, necesitan desarrollo ágil. La incorporación de prácticas de ingeniería concurrente, o de agilidad, mejora el time to market de los productos y los mantiene vivos y en continua adaptación a la evolución de su mercado. La incorporación de los valores de la agilidad en la organización, mejora el valor innovador de los productos que desarrolla. Adicionalmente mejora la reputación de la organización frente a los clientes que valoran la innovación y el compromiso con sus productos, y frente a los profesionales 6

7 mejor cualificados de su sector, que prefieren las empresas que convierten el modelo de gestión de recursos humanos, en el de gestión del talento. NECESIDAD DE UN MARCO DE REFERENCIA Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil, necesitan una guía y criterios de referencia para identificar y analizar las áreas de mejora. Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para mejorar la agilidad de las organizaciones. Scrum Level realiza una evaluación estructurada de la organización: de sus ejes orgánicos, y de las prácticas de trabajo que emplea, revelando los aspectos más y menos consolidados, y las posibles acciones de revisión y mejora. El resultado permite la medición y análisis de cada rasgo y práctica por separado, y de la organización, bien de forma global en su conjunto, o parcialmente, en su dimensión técnica (agilidad técnica). Lo que entendemos por scrum 1.- Rugby Formación de rugby Scrum es el término que define a la formación más reconocible del rugby, en la que ambos equipos, agazapados y atenazados entre sí, empujan para obtener el balón, y sacarlo de la formación sin tocarlo con la mano. 2.- Métodos de trabajo Ambiente de trabajo ágil autoorganizado En 1986 los investigadores Nonaka y Takeuchi dan dimensión polisémica al término originalmente deportivo scrum, al emplearlo para bautizar los principios de desarrollo que descubrieron en las empresas tecnológicas más innovadoras (Takeuchi & Nonaka, 1986). Figura 1. Formación de rugby scrum. Scrum, en la concepción original de Nonaka y Takeuchi, se caracteriza por el protagonismo de equipos brillantes, autoorganizados y motivados, que abordan el desarrollo sistemas complejos partiendo de una visión general y solapando las fases del desarrollo. Figura 2. Scrum como marco de trabajo: 1986, Hirotaka Takeuchi, Ikujiro Nonaka "The New New Product Development Game" 7

8 Metodología para desarrollo de software En 1995 Ken Schwaber presentó en OOPSLA (Conferencia anual Object-Oriented Programming, Systems, Language s & Applications ) (Schwaber, 1995) una metodología de desarrollo de software, basada en un ambiente scrum y uso ese mismo término para definir el proceso. Figura 3. Ken Schwaber, "Scrum Development Process Marco para desarrollo de software basado en la metodología scrum de Ken Schwaber En 2005 Mike Cohn, Esther Derby y Ken Schwaber constituyeron la organización Scrum Alliance para difundir un marco de trabajo específico para el desarrollo de software, basado en esta metodología. y a la que también denominaron scrum. Figura 4. Marco scrum Scrum Level usa el término en el significado original de Nonaka y Takeuchi, como un ambiente de trabajo caracterizado por la composición de equipos autoorganizados que trabajan de forma ágil: con autonomía y solapamiento de las fases de desarrollo, y compartiendo el conocimiento y aprendizaje de forma abierta. 8

9 Gestión Ágil Guía para evaluación En el ámbito de gestión de proyectos, personas y organizaciones, el concepto de agilidad surgió a finales del siglo pasado como antítesis de los modelos tayloristas, y de producción industrial de ciclos de desarrollo secuenciales y calidad basada en ingeniería de procesos. En los últimos 20 años la agilidad ha demostrado que los marcos de desarrollo iterativo, y calidad basada en el conocimiento tácito de las personas, son los más apropiados para desarrollar productos o servicios innovadores, que requieren revisión continua por ser de ciclos de venta breves, o competir en escenarios comerciales de incertidumbre elevada. El concepto de agilidad surgió al identificar en la industria manufacturera japonesa (Takeuchi & Nonaka, 1986) una forma de trabajo de que estaba sorprendiendo en su sector por la innovación de sus productos y la rapidez con la que los desarrollaban; y reveló que el denominador común eran la autoorganización de equipos autónomos, multifuncionales, trabajando en un mismo espacio físico, sin emplear ciclos de desarrollo secuenciales. Scrum fue el nombre con el que se denomino a esa novedosa forma de trabajo. Al mismo tiempo, en otra industria diferente: la del software, algunos equipos de programadores desafiaban a los ciclos de desarrollo secuencial y a los modelos de producción basados en procesos, empleando también principios ágiles, bien por propia iniciativa a través de modelos como XP (extreme Programming), o bien trabajando en ambientes scrum. El Manifiesto para Desarrollo Ágil de Software, comúnmente llamado Manifiesto ágil, fue redactado en 2001 por 17 ingenieros de software. Sintetiza los principios de agilidad proclamados como alternativa a la producción secuencial y procedimentalizada; y se ha convertido en el hito de referencia en cuanto a principios y consolidación de la agilidad. Técnicas, prácticas y valores El resultado de un marco de desarrollo scrum depende del grado en el que se compaginan sus dos componentes: Las técnicas y prácticas empleadas para producir el resultado de forma incremental y continua. Los valores y la cultura de la organización de las personas que trabajan con esas técnicas. Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar agilidad técnica. La agilidad técnica es adecuada para trabajos en los que por su mecanicidad resulta más eficiente basar la calidad y homogeneidad del resultado en ingeniería de procesos, que en el conocimiento profesional de las personas que lo realizan. En este sentido, la agilidad técnica resulta apropiada cuando la entrega temprana y el incremento continuo son un valor relevante para el cliente. 9

10 Figura 5. Agilidad técnica y scrum Sin embargo, hay entornos profesionales donde la innovación y el ingenio son imprescindibles para aportar verdadero valor al producto. En estos casos, el conocimiento profesional de las personas que realizan los distintos procesos es fundamental, y un ambiente scrum potencia el talento de equipos compuestos por personas competentes y motivadas. Esto es lo que se conoce como Agilidad. La potencia de scrum radica en cómo gestiona el ciclo de vida de vida y la aportación de valor al producto. Ciclo de vida Scrum no tiene como objetivo entregar el producto completo y terminado en el tiempo y con el coste previsto, sino suministrar lo antes posible un producto mínimo viable e incrementar su valor a través de iteraciones de desarrollo breves y continuas. Valor del producto El valor del producto depende y es proporcional al conocimiento profesional de las personas que lo desarrollan, a diferencia de la producción industrial que confía el valor del resultado al know how explicitado en los procesos y la tecnología empleados. La gestión de un ciclo de vida que incremente el producto de forma continua e iterativa, se consigue aplicando determinadas técnicas y prácticas. Sin embargo la aportación del conocimiento necesario a través de las personas, no se logra por emplear determinadas técnicas, sino creando ambientes de trabajo scrum para atraer y hacer brotar el talento. Técnicas y prácticas: El ciclo de vida ágil se caracteriza por la entrega temprana de valor, y su incremento continuo en periodos breves. Los retos que plantea el ciclo de vida ágil son: 1.- Definición del producto mínimo viable: Funcionalidades suficientes para lanzar el producto, y forma en la que se deben integrar. 2.- Gestión de la evolución continua de los requisitos. 3.- Monitorización y mantenimiento de un flujo de entregas de valor constantes. 10

11 El conjunto de prácticas y técnicas ágiles proporciona el inventario de recursos profesionales para gestionar estos retos. Así por ejemplo, para representar y gestionar la visión del producto, es habitual el uso de pilas de producto, estimación en la pared, mockups, etc. Las prácticas para la definición y gestión de avance en sprints, o las empleadas para mantener un flujo continuo de tareas con técnicas de gestión visual kanban, resuelven la monitorización del avance y el mantenimiento de un flujo constante de entregas de valor, etc. Valores: Que el principal responsable del valor entregado al cliente sea el conocimiento profesional de las personas, implica rasgos culturales de la organización importantes: 1.- Entrega de valor como objetivo. Un ambiente scrum no centra el objetivo en el valor propio, sino en el entregado al cliente. No quiere esto decir que la organización no obtenga beneficio por su trabajo, sino que éste se considera una consecuencia, no un fin; es la consecuencia de la entrega continua de valor al cliente. 2.- Trabajo en equipo. La interacción de los miembros del equipo, la difusión del conocimiento compartido y la fertilización cruzada de las ideas multiplica la potencia del aporte de las personas: el talento. 3.- Excelencia profesional. La motivación y el perfil profesional de las personas de la organización, debe ser lo más alto posible. Implicación del cliente. Para mantener un ciclo de vida incremental con un flujo continuo de producción es necesario emplear prácticas ágiles. Si además se necesita potenciar el talento de las personas, también son necesarios determinados rasgos culturales en la organización; pero siempre es imprescindible la implicación del cliente. La comunicación e implicación del cliente con el equipo del producto es necesaria, porque la entrega continua requiere feedback continuo de su parte. Si además no se trata de agilidad técnica, sino de agilidad, el equipo debe conocer y compartir la visión del cliente. 11

12 Figura 6. Agilidad técnica y scrum 12

13 GESTIÓN DE PROYECTOS PREDICTIVA Y EVOLUTIVA Dos son los patrones de los ciclos de vida empleados en el desarrollo de productos: Predictivo Tiene como objetivo entregar el producto completo y terminado, velando por el cumplimiento de los requisitos y las estimaciones de fecha de entrega y esfuerzo necesario. Evolutivo Tiene como objetivo entregar lo antes posible un producto suficiente, y mantener sobre él un ritmo continuo de evolución y mejora. Figura 7. Ingeniería secuencial, ingeniería concurrente y scrum. La gestión predictiva comienza con un plan de proyecto calculado a partir de la descripción completa del producto, y sobre él calcula el tiempo y trabajo de ejecución necesario, que posteriormente gestiona en fases secuenciales (cascada) La gestión evolutiva no parte de la descripción completa del producto sino de la visión inicial, y detalla y desarrolla de forma continua partes del mismo, manteniendo un flujo de incrementos que desde la primera entrega inicial lo amplían y mejoran de forma constante. Las diferentes fases del desarrollo, desde el diseño hasta la validación y entrega se ejecutan de forma solapada, porque no es el producto completo en bloque el que va avanzando en cascada a través de las diferentes fases. La gestión evolutiva puede confiar el conocimiento, el saber hacer necesario, al seguimiento de pautas o procesos institucionalizados (conocimiento explicitado en procesos) o al conocimiento tácito de las personas que las realizan. 13

14 En el primer caso, emplea ingeniería de procesos con solapamiento de las fases de desarrollo; se trata por tanto de ingeniería concurrente aplicada con un ciclo de vida evolutivo. Esta estrategia, vista desde la perspectiva de la agilidad se trata de una agilidad técnica: una agilidad que emplea prácticas y técnicas ágiles sobre ingeniería de procesos. Vista desde la perspectiva de la producción industrial, se trata de la aplicación de ingeniería concurrente para desarrollar productos de forma incremental. ÁMBITO DE SCRUM LEVEL Scrum Level analiza y evalúa el nivel de agilidad en las dos dimensiones que vienen determinadas por los dos factores vistos: Técnicas y prácticas por un lado, y valores por otro. Dimensiones Scrum Level analiza indicadores y evidencias de forma separada en dos dimensiones: Dimensión técnica: Determinada por las técnicas y prácticas de trabajo empleadas. Las evaluaciones de Scrum Figura 8. Dimensiones del modelo. Level miden esta dimensión como flexibilidad. Dimensión organizativa: Determinada por los rasgos de personalidad de la organización. Las evaluaciones de Scrum Level miden esta dimensión como fluidez. Factores analizados Para la evaluación de la flexibilidad: Técnicas y prácticas de trabajo. Conocimiento técnico de las personas. Figura 9. Flexibilidad en las prácticas Para la evaluación de la fluidez: Ejes orgánicos Conocimiento profesional de las personas 1. Figura 10. Fluidez en las prácticas 1 El conocimiento profesional de las personas es un factor determinante de la fluidez, pero su evaluación excede el campo de una evaluación Scrum Level. 14

15 TÉCNICAS Y PRÁCTICAS Guía para evaluación La evaluación de la agilidad técnica de la organización analiza y evalúa de forma diferenciada el grado de implantación de las siguientes prácticas: ÁMBITO PRÁCTICA 1. DE PROYECTO 1.1 Reunión diaria. 1.2 Revisión continua del avance por estimación del esfuerzo pendiente. 1.3 Desarrollo incremental. 1.4 Entregas en reunión con el cliente. 1.5 Reuniones de planificación frecuentes. 1.6 Información visual. 1.7 Control del trabajo en proceso (WIP). 1.8 Definición de tarea terminada. 2. DE PRODUCTO 2.1 Propietario de producto único. 2.2 Propietario de producto autónomo. 2.3 Propietario de producto implicado. 2.4 Visión definida. 2.5 Visión compartida. 2.6 Pila de producto. 3. DE ORGANIZACIÓN 3.1 Equipos autoorganizados. 3.2 Reuniones retrospectivas. 3.3 Espacio de trabajo común para el equipo. 3.4 Ritmo sostenido (< 40 horas semana). 3.5 Flexibilidad funcional. 4. DE PRODUCCIÓN (ING. SOFTWARE) 4.1 Comprobación continua. 4.2 Integración continua. 4.3 Programación en parejas. 4.4 Diseño simple e incremental. 4.5 Estándares de codificación. 4.6 Propiedad colectiva del código. Tabla 1: Ámbitos y prácticas que definen la agilidad. 15

16 EJES ORGÁNICOS El nivel de agilidad organizativa o fluidez, viene determinado por el conjunto de principios y valores que inspiran la cultura de la organización. Para determinar los factores culturales que favorecen y los que impiden el desarrollo de modos de trabajo ágiles, y en qué grado, Scrum Level evalúa 16 rasgos de la organización. Para cada rasgo se determina en qué grado facilita o entorpece el trabajo ágil, representando sobre un hipotético eje la posición en la que se encontraría, más o menos próxima al extremo ágil o al no ágil. ÁREA EJE RASGO NO ÁGIL RASGO ÁGIL 1. GESTIÓN 1.1. OBJETIVO ORGANIZACIONAL Objetivo beneficio Objetivo cliente 1.2. CONOCIMIENTO: TIPO Explícito Tácito 1.3. CONOCIMIENTO: DISTRIBUCIÓN Departamentalizado Socializado 1.4. PERSONAS: GESTIÓN Operarios Artífices 1.5. PERSONAS: MOTIVACIÓN Extrínseca Intrínseca 1.6. ORGANIZACIÓN DEL TRABAJO Trabajo individual Trabajo en equipo 1.7. GOBERNANZA Directiva Colaborativa 1.8. GESTIÓN DEL ERROR Incriminatoria Analítica 2. MÉTODOS 2.1. GESTIÓN DE LA MEJORA Mejora periódica Mejora continua 2.2. COMUNICACIÓN: PROCESO Escrita Directa 2.3. COMUNICACIÓN: ESTILO Jerarquizada Abierta 3. PROYECTO 3.1. ADQUISICIÓN Contractual Colaborativa 3.2. SEGUIMIENTO Cliente pasivo Cliente participativo 3.3. SUMINISTRO Entrega puntual Entrega continua 3.4. REQUISITOS Cerrados Evolutivos 3.5. GESTIÓN Planificada Orientada al valor Tabla 2: Ejes orgánicos a medir en la organización. 16

17 EVALUACIÓN Y ANÁLISIS Las organizaciones son realidades sistémicas con múltiples relaciones e interacciones entre sus diferentes áreas, departamentos y equipos. La introducción de prácticas ágiles de forma departamentalizada, o no alineada con los valores y la visión de la organización genera fricción cultural. Scrum Level proporciona un método para la evaluación estructurada de las variables que determinan las características y grado de agilidad de la organización. El método incluye criterios de formulación para determinar cuantitativamente cada factor, y a la organización en su conjunto. La evaluación puede emplearse como herramienta de diagnóstico para identificar las áreas de mejora, o posibles desequilibrios entre diferentes sectores de la organización. También como indicador para referencia y medición de los avances. Dimensiones El grado de agilidad de la organización es resultado de la combinación de los patrones de agilidad en sus dos dimensiones: Técnica: Determinada por las técnicas y prácticas de trabajo empleadas. Las evaluaciones de Scrum Level miden esta dimensión como flexibilidad. Organizativa: Determinada por los valores y rasgos de personalidad de la organización. Las evaluaciones de Scrum Level miden esta dimensión como fluidez. Evaluación de la flexibilidad Medida del grado de agilidad en la dimensión técnica de la organización. Los factores que la determinan son: Prácticas y técnicas de trabajo empleadas. Conocimiento técnico que las personas tienen de prácticas de trabajo ágiles. Evaluación de la flexibilidad: Prácticas y técnicas Las prácticas y técnicas de trabajo deben ser adecuadas a las características del ciclo de vida ágil: entrega de valor temprana, iterativa e incremental. Deben emplearse en las cuatro áreas de la producción: Proyecto: gestión del ciclo de vida ágil. Producto: gestión ágil de producto. Organización: gestión y autoorganización del trabajo. Desarrollo: Técnicas específicas para el tipo de producto o servicio desarrollado. 17

18 1. PRÁCTICAS DE PROYECTO 1.1 Reunión diaria. A diario, las personas de cada equipo mantienen una reunión breve, en la que todos los miembros comunican la tarea o tareas en las que están trabajando, analizando en equipo si el ritmo de avance es el esperado, o si se están encontrando o es previsible algún impedimento. 1.2 Revisión continua del avance por estimación del esfuerzo pendiente. Los equipos revisan a diario el avance del trabajo, o emplean técnicas de monitorización visual del mismo que presentan la información actualizada, y que basan en la estimación del esfuerzo pendiente. 1.3 Desarrollo incremental. Los equipos entregan a sus respectivos clientes incrementos o mejoras del producto o servicio en periodos cortos, o de forma continua. 1.4 Entregas en reunión con el cliente. La entrega de cada incremento del producto se realiza en una reunión del equipo que la ha desarrollado, con el cliente. En la reunión se ve el resultado en funcionamiento. 1.5 Reuniones de planificación frecuentes Cada equipo que desarrolla un producto o presta un servicio, mantiene reuniones frecuentes con el cliente en las que se plantea y planifica la parte de producto, o las características de la prestación del servicio que se va a producir en el periodo que se abre hasta la próxima reunión. 1.6 Información visual. Se utilizan herramientas de información visual que permiten a todos los miembros e interesados de cada proyecto conocer su estado de avance. 1.7 Control del trabajo en proceso (WIP). La organización tiene institucionalizadas prácticas de trabajo que limitan en cada equipo el número de tareas que pueden estar desarrollando de forma simultánea. 1.8 Definición de tarea terminada. Los equipos tienen definido e institucionalizado el concepto de tarea terminada como la tarea que ya no necesita ninguna intervención ni recurso de desarrollo ni comprobación. 2. PRÁCTICAS DE PRODUCTO 2.1 Propietario del producto único. Cada producto o servicio tiene una única persona responsable de las decisiones que afectan al interés del cliente. 18

19 2.2 Propietario del producto autónomo. El propietario del producto tiene atribuciones y autonomía para realizar propuestas y tomar decisiones relativas al producto e interés del cliente. 2.3 Propietario del producto implicado El propietario del producto mantiene comunicación y colaboración continua y activa con el equipo del producto. 2.4 Visión definida. El propietario del producto tiene una visión definida del objetivo. 2.5 Visión compartida. El propietario del producto está comprometido con la comunicación y transmisión de la visión del objetivo a todo el equipo. 2.6 Pila de producto. El propietario del producto mantiene una lista priorizada de las funcionalidades que espera del producto. Esta lista es conocida y permanentemente accesible a todo el equipo. 3. PRÁCTICAS DE ORGANIZACIÓN 3.1 Equipos autoorganizados. La organización de los equipos y la asignación y distribución de los trabajos la realiza cada equipo de forma autónoma. 3.2 Reuniones retrospectivas. Los equipos realizan periódicamente reuniones para analizar las prácticas y métodos de trabajo para su perfeccionamiento. 3.3 Espacio de trabajo común para el equipo. Los miembros de cada equipo comparten el espacio físico de trabajo. 3.4 Ritmo sostenido. Los equipos mantienen una cadencia de trabajo continua (menor a 40 horas semana), de alto rendimiento, y sin sobrecargas, ni continuadas ni puntuales. 3.5 Flexibilidad funcional. Las distintas técnicas y conocimiento empleado en el desarrollo del producto o la prestación del servicio de cada equipo son conocidos o compartidos por distintos miembros. En los equipos no se producen islas de conocimiento, y una misma tarea puede ser realizada por diferentes miembros. 19

20 4. PRÁCTICAS DE PRODUCCIÓN (ING.SOFTWARE) 4.1 Comprobación continua. La organización tiene institucionalizadas prácticas destinadas a la comprobación continua de que se está desarrollando el producto esperado por el cliente en la forma correcta. Algunas de las prácticas esperadas con esta finalidad son: TDD (Test-driven development), ATDD (Acceptance Test Driven Development) y BDD Behavior-Driven Development) 4.2 Integración continua. En la organización está institucionalizado el uso de la práctica de ingeniería del software: Integración continua, o alguna práctica equivalente de integración con la finalidad de la detección temprana de posibles fallos. Se entiende por integración la compilación y ejecución de pruebas del proyecto. 4.3 Programación en pareja En la organización está institucionalizada la programación en pareja. 4.4 Diseño simple e incremental El diseño del software se basa en los principios: 1. Es una actividad evolutiva que incluye refactorización 2. La calidad del diseño se evalúa con el criterio de la simplicidad de código 3. Las decisiones de diseño se evalúan con el criterio de coste/beneficio 4. Las decisiones de diseño se abordan justo a tiempo, en el momento que se necesitan. 4.5 Estándares de codificación Los equipos tienen institucionalizados estándares de codificación. 4.6 Propiedad colectiva del código En cada equipo se escribe el código dentro de la arquitectura y diseño del sistema, y todos los miembros son responsables del código de todo el sistema. Conocimiento técnico ágil. El segundo factor del grado de flexibilidad es el conocimiento técnico de las personas para aplicar prácticas y métodos ágiles. Un ejemplo para ilustrar la participación de los dos factores de la fluidez: prácticas empleadas y conocimiento técnico. Además de estar institucionalizado el uso de pilas de producto en la gestión de requisitos, los responsables de producto deben conocer y saber gestionar una pila de producto. Análisis y evaluación de la flexibilidad. El estudio de la flexibilidad analiza y evalúa los dos factores vistos: las prácticas ágiles empleadas, y conocimiento técnico de agilidad, aplicando los criterios siguientes. 20

21 Prácticas Verificación pericial o técnica de los siguientes parámetros para cada una de las prácticas. Escala 0 - No implementada Poca o ninguna evidencia de que la práctica se realice. 1 - Parcialmente implementada La práctica se aplica pero no siempre o no en todos los proyectos del ámbito de la evaluación, ni de forma homogénea. 2 - Ampliamente implementada La práctica se aplica siempre, pero no está institucionalizada (sin garantía de homogeneidad y mejora continua) 3 - Completamente implementada La práctica se aplica siempre y se encuentra institucionalizada (con formación y en mejora continua) 21

22 PRODUCCIÓN ORGANIZACIÓN PRODUCTO PROYECTO Guía para evaluación Ejemplo de un posible resultado de la verificación de valores en las prácticas. PRÁCTICA GRADO DE IMPLEMENTACIÓN 1.1 Reunión diaria 1 Parcial 1.2 Cálculo del avance 3 Completo 1.3 Desarrollo iterativo o continuo 2 Amplio 1.4 Entrega iterativa o continua 2 Amplio 1.5 Reuniones de planificación 3 Completo 1.6 Información visual 3 Completo 1.7 Control del WIP 0 Ninguno 1.8 Definición de tarea terminada 2 Amplio 2.1 Propietario de producto único 3 Completo 2.2 Propietario de producto autónomo 1 Parcial 2.3 Propietario de producto implicado 2 Completo 2.4 Visión definida 2 Completo 2.5 Visión compartida 1 Parcial 2.6 Pila de producto 3 Completo 3.1 Autoorganización 2 Amplio 3.2 Reuniones retrospectivas 0 Ninguno 3.3 Espacio de trabajo común 3 Completo 3.4 Ritmo sostenido 2 Amplio 3.5 Flexibilidad funcional 2 Amplio 4.1 TDD 1 Parcial 4.2 Integración continua 2 Amplio 4.3 Programación en parejas 0 Ninguno 4.4 Estándares de codificación 1 Parcial 4.5 Propiedad colectiva del código 1 Parcial Tabla 3: Prácticas y grado de implementación. 22

23 Evaluación de la flexibilidad: Conocimiento técnico Verificación pericial o técnica del conocimiento técnico de las personas incluidas en el ámbito de la evaluación. Escala 0. - Insuficiente La persona no tiene un conocimiento suficiente para desempeñar las tareas propias de su trabajo empleando prácticas y técnicas ágiles. Referencia para la evaluación; El nivel de conocimiento es insuficiente para superar un examen de acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum Master (scrumstudy.org, scrum.org, Scrum Alliance) 1.- Nivel técnico La persona tiene un conocimiento suficiente para desempeñar las tareas propias de su trabajo empleando prácticas y técnicas ágiles. Referencia para la evaluación: El nivel de conocimiento es suficiente para superar un examen de acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum Master (scrumstudy.org, scrum.org, Scrum Alliance) 2.- Nivel experto La persona tiene conocimientos holgados para desempeñar las tareas propias de su trabajo empleando prácticas y técnicas ágiles. Referencias para la evaluación: El nivel de conocimiento es suficiente para superar un examen de acreditación Scrum Manager de nivel experto. El nivel de conocimiento es suficiente para superar un examen de acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum Master (scrumstudy.org, scrum.org, Scrum Alliance) y tiene al menos 12 meses de experiencia de trabajo en equipos empleando técnicas ágiles. 3.- Nivel Autoridad La persona es un conocedor experto de la gestión ágil de proyectos y organizaciones, y de scrum. Referencias de contrastación: La persona tiene certificado un nivel de autoridad en Scrum Manager de más de 200 PDAs. El nivel de conocimiento es suficiente para superar un examen de acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum Master (scrumstudy.org, scrum.org, Scrum Alliance) y tiene al menos 24 meses de experiencia trabajando en equipos ágiles, empleando técnicas ágiles. 23

24 Formulación de la flexibilidad Guía para evaluación Una vez realizadas las verificaciones de los distintos factores, el análisis de su combinación determina la flexibilidad general de la organización. Los tres principios que deben guiar el análisis son: 1.- Valores medios La flexibilidad global refleja el promedio de las flexibilidades parciales que la componen. Se debe considerar la media aritmética, y no la moda o la mediana. 2.- Homogeneidad La falta de homogeneidad entre los valores parciales de flexibilidad es síntoma de tensiones o fricciones en la organización, y disminuye, o incluso neutraliza los efectos de scrum. Cuando se produce, en la ponderación se deben analizar siempre las causas y considerar la valoración de sus consecuencias. 3.- Ponderación El análisis de la flexibilidad pondera los valores medios obtenidos considerando al menos: Las evaluaciones técnicas deben incluir criterios de formulación que consideren el impacto atenuador, cuando se produce falta de homogeneidad. Las evaluaciones expertas, a diferencia de las técnicas, son actuaciones ágiles y en ellas prevalece el criterio experto de la persona que realiza la evaluación, por encima del criterio técnico de la formulación. La ponderación de las evaluaciones expertas incluye el razonamiento y argumentación de los ajustes realizados a los valores medios de la formulación. Prácticas 1.- Valoración de la flexibilidad parcial por cada área de prácticas Con los valores verificados en las diferentes prácticas se obtienen los promedios de cada grupo: prácticas de proyecto, producto, organización y producción. Ejemplo de un posible resultado de la verificación de un grupo de prácticas. PRÁCTICAS DE PROYECTO Reunión diaria 1.2 Revisión continua del avance 1.3 Desarrollo iterativo o continuo 1.4 Entrega iterativa o continua 1.5 Reuniones de planificación 1.6 Información visual 1.7 Control del WIP 1.8 Definición de tarea terminada Tabla 4. Flexibilidad parcial por cada área. 24

25 2.- Valoración de la flexibilidad parcial por las prácticas Con las flexibilidades parciales de los cuatro grupos de prácticas se calcula el promedio de la flexibilidad parcial de las prácticas. Ejemplo de un posible resultado de la verificación de los grupos de prácticas. ÁREAS DE PRÁCTICAS De proyecto 2.- De producto 3.- De organización 4.- De producción Tabla 9. Flexibilidad parcial por prácticas. 3.- Valoración de la flexibilidad parcial por el conocimiento técnico. Con los valores verificados del conocimiento técnico de las personas se obtiene el promedio. Siguiendo el principio de homogeneidad, el análisis debe considerar siempre en la ponderación de esta media, la presencia de más de un 20% de las personas que forman parte del ámbito de la evaluación con valoración 0. Ejemplo de un posible resultado de la verificación del conocimiento técnico.. CONOCIMIENTO TÉCNICO Nombre de la persona Nombre de la persona Nombre de la persona Nombre de la persona Nombre de la persona Nombre de la persona Nombre de la persona Evaluación de la fluidez Tabla 10. Flexibilidad parcial por conocimiento técnico. Medida que expresa el grado de agilidad en la dimensión cultural de la organización. Los factores que la determinan son: Valores ágiles de los ejes orgánicos. Conocimiento profesional de las personas. Evaluación de la fluidez: Ejes orgánicos Scrum Level identifica 16 ejes que polarizan los rasgos que configuran la personalidad y valores culturales de la organización. Estos 16 ejes orgánicos se agrupan en tres áreas: 25

26 1.- Gestión. Se encuentran en esta área los ejes con los rasgos que definen el estilo de gestión, tanto de la organización como de las personas. 2.- Métodos. Pertenecen a esta los rasgos que determinan el modo de proceder las personas de la organización en su relación, comunicación, y mejora continua. 3.- Proyecto. Área con los rasgos que determinan la estrategia de gestión de proyectos Área 1. GESTIÓN Eje 1.1 OBJETIVO ORGANIZACIONAL. Determina el punto en el que se sitúa el foco de atención de la organización entre estos dos objetivos: a) obtención de beneficio, b) entrega al cliente del mayor valor posible. Eje 1.2 CONOCIMIENTO: TIPO. Determina cuál de estos tipos de conocimiento tiene más peso, y en qué grado, en el desarrollo de los productos o en la prestación de los servicios que ofrece la organización: El conocimiento explicitado en los procesos y la tecnología, o el conocimiento tácito de las personas que producen o prestan los servicios. Eje 1.3 CONOCIMIENTO: DISTRIBUCIÓN. Determina en qué medida el conocimiento se encuentra más próximo a uno de los extremos siguientes: a) es compartido dentro de la organización y entre departamentos. B) se encuentra confinado a las especialidades departamentales, y es utilizado como instrumento de poder para fortalecer perímetros funcionales. Eje 1.4 PERSONAS: GESTIÓN. Determina si las pautas de gestión de recursos humanos son más idóneas para la gestión de operadores u operarios (delimitación de horarios y tareas) o de artífices (autonomía y responsabilidad global). Eje 1.5 PERSONAS: MOTIVACIÓN. Determina el grado de preferencia de la organización, entre motivadores extrínsecos (incentivos económicos y recompensas) e intrínsecos (satisfacciones inherentes al desarrollo del propio trabajo: autonomía, maestría y propósito). Eje 1.6 ORGANIZACIÓN DEL TRABAJO. Determina si la empresa tiene un modelo organizativo basado en individualidades profesionales o en equipos. Eje 1.7 GOBERNANZA. Determina el estilo de gerencia de la organización entre los polos: directivo y colaborativo. Eje 1.8 GESTIÓN DEL ERROR. Determina la actitud general de la organización frente a los errores y la apreciación de los mismos como necesarios para el aprendizaje. Área 2. MÉTODOS. 26

27 Eje 2.1 GESTIÓN DE LA MEJORA. Determina el grado de institucionalización de prácticas de mejora continua. Eje 2.2 COMUNICACIÓN: PROCESO. Determina el grado de "intermediación" en la comunicación entre personas de la organización; entendiendo por "intermediación" tanto la física por el uso de medios de transmisión como alternativa a la comunicación cara a cara, como la temporal o comunicación asíncrona (telefónica, videoconferencia, correo electrónico, chat, foros, etc.). Eje 2.3 COMUNICACIÓN: ESTILO. Determina el grado de "transversalidad jerárquica" de la comunicación. Por ejemplo, si la comunicación entre distintos niveles jerárquicos es considerada un puenteo, o existe una política de puertas abiertas, o se realizan reuniones del tipo skip-level meetings. Área 3. PROYECTO. Eje 3.1 ADQUISICIÓN. Determina el modelo de adquisición de los requisitos del cliente, si se basa en una formulación contractualizada en forma rígida (con penalizaciones y métricas estrictas) o está abierta a una dinámica de colaboración más flexible entre cliente y proveedor (por ej. definición de capacidad fija y alcance negociado). Eje 3.2 SEGUIMIENTO. Determina el grado de colaboración entre el cliente y el equipo de trabajo de su proyecto. Eje 3.3 SUMINISTRO. Determina en qué medida la entrega del producto o servicio es completa o evolutiva. Eje 3.4 REQUISITOS. Determina si el modelo de adquisición cliente <-> proveedor se basa en requisitos cerrados o evolutivos. Eje 3.5 GESTIÓN. Determina si la organización emplea un modelo de gestión de proyectos predictivo o evolutivo. Conocimiento profesional de las personas Los procesos y la tecnología empleados por la ingeniería concurrente minimizan las diferencias de calidad entre el trabajo realizado por personas con niveles de conocimiento profesional diferentes. Sin embargo cuando las características del producto o servicio no hacen posible explicitar el conocimiento necesario en los procesos y la tecnología empleados, resulta necesario abordarlo desde la agilidad, y en este tipo de trabajos basados en el conocimiento tácito de las personas, la diferencia de resultados entre los mediocres y los mejores puede ser muy grande. Al mismo tiempo, resulta difícil y cuestionable determinar la capacidad profesional de las personas, por lo que una evaluación Scrum Level no aborda su verificación. 27

28 Sin embargo en los procesos tanto de asesoría como de evaluación orientados a la mejora de la agilidad se debe: Formar o informar de la relevancia de ese factor a las personas responsables de la gestión de la organización. Las evaluaciones expertas pueden, y deben incluir ponderación sobre este factor, si cuentan con información o evidencias que así lo aconsejan. Análisis y valoración de la fluidez El estudio de la fluidez se centra en el análisis y evaluación de los ejes orgánicos. El nivel de agilidad de cada eje se determina combinando los valores verificados en el rasgo no ágil y ágil que polariza el eje. Rasgos Escala 0. - Ausencia Poca o ninguna presencia del rasgo. 1.- Presencia parcial Presencia parcial del rasgo. No se puede verificar su aplicación sistemática, y ésta se produce sólo puntualmente en áreas, equipos o momentos determinados. 2.-Presencia amplia Presencia generalizada del rasgo. No se puede verificar que su aplicación se deba a la institucionalización determinada de la dirección de la organización y / o que se aplique en todas las ocasiones, pero es de aplicación generalizada. 3.-Presencia completa Presencia permanente del rasgo. Se puede verificar que su aplicación se aplica en todas las ocasiones, y que responde a una institucionalización determinada desde la dirección de la organización. Formulación de la fluidez Una vez realizadas las verificaciones de los distintos ejes, el análisis de su combinación determina la fluidez general de la organización. Los tres principios que deben guiar el análisis son: 1.- Valores medios. La fluidez de cada área refleja el promedio de la fluidez de los diferentes ejes que la componen, y a su vez la fluidez global de la organización es reflejo del promedio de la fluidez de las diferentes áreas. Se debe considerar la media aritmética, y no la moda o la mediana. 28

29 2.- Homogeneidad. La falta de homogeneidad entre los valores parciales, tanto entre los diferentes ejes de una misma área, como entre los valores de las diferentes áreas, es síntoma de tensiones o fricciones en la organización y disminuye, o incluso neutraliza los efectos de scrum. Cuando se produce, en la ponderación se deben analizar siempre las causas y considerar la valoración de sus consecuencias. 3.- Ponderación El análisis de la fluidez pondera los valores medios obtenidos considerando al menos: Las evaluaciones técnicas deben incluir criterios de formulación que consideren el impacto atenuador generado por la falta de homogeneidad. Las evaluaciones expertas, a diferencia de las técnicas, son actuaciones ágiles, y en ellas prevalece el criterio experto de la persona que realiza la evaluación, por encima del criterio técnico de la formulación. La ponderación de las evaluaciones expertas incluye el razonamiento y argumentación de los ajustes realizados a los valores medios de la formulación. Ejes orgánicos La tabla siguiente refleja el criterio para determinar la fluidez de un eje, en base a la valoración del rasgo ágil y no ágil que polariza. Fluidez del eje Rasgo no ágil Rasgo ágil 0.- Muy baja Escasa * Parcial * Completa Tabla 11. Escala de valoración de rasgos que definen la agilidad organizacional. El carácter * representa a cualquier valor. La ponderación de la evaluación debe considerar el principio de homogeneidad, y las posibles distorsiones motivacionales en los resultados obtenidos con formularios o entrevistas. Ejemplo de un posible resultado de la verificación de valores en los ejes del área de gestión. EJES DEL ÁREA DE GESTIÓN Objetivo organizacional 1.2 Conocimiento: tipo 1.3 Conocimiento: distribución 1.4 Personas: gestión 1.5 Personas: motivación 1.6 Organización del trabajo 1.7 Gobernanza 1.8 Gestión del error Tabla 12. Fluidez parcial por ejes de gestión. 29

30 Ejemplo de un posible resultado de la verificación de valores de cada área. 1.- Gestión 2.- Métodos 3.- Proyecto ÁREA Tabla 13: Fluidez parcial por ejes de gestión. 30

31 ANÁLISIS Guía para evaluación La evaluación Scrum Level identifica y valora de forma estructurada la información clave para el análisis en actividades de asesoría y mejora. Las asesorías que toman como referencia el marco y los resultados de una evaluación Scrum Level, deben: Informar de la fiabilidad La documentación de los procesos de asesoría o mejora debe indicar la fiabilidad de los datos de la evaluación empleados: Por un lado, si se realiza una evaluación con un protocolo que no incluye indicadores de distorsión motivacional se debe indicar Desconocida ; por el otro lado, si incluye indicadores de distorsión motivacional se debe indicar la fiabilidad obtenida en la evaluación: baja, media o alta. Analizar los puntos de atención de la evaluación. Además de los aspectos de análisis cubiertos por las circunstancias de la organización y el criterio del asesor, no se deben omitir los puntos identificados en la evaluación como puntos de atención. Consideraciones Objetividad en el tratamiento de la gestión predictiva y la gestión ágil. En las referencias que el análisis pueda abordar sobre la gestión predictiva y la gestión evolutiva, se recomienda un enfoque neutro y una consideración objetiva de cada una de ellas respecto a las características de los productos y servicios desarrollados en la organización o en sus diferentes áreas. Diferenciar entre scrum, e ingeniería concurrente o agilidad técnica. Analizar con objetividad la idoneidad de ingeniería concurrente o de agilidad, en función de las características de la empresa y los productos o servicios que desarrolla. No ofrecer de forma ambigua o confusa una mejora de ingeniería concurrente o agilidad técnica, como mejora de Agilidad global o scrum. 31

32 Apéndices Documento de evaluación. El resultado de una evaluación Scrum Level se compone de un resumen o diploma, y un informe de evaluación. Contienen la siguiente información: Información En el resumen o En el informe diploma Tipo de evaluación Organización evaluadora (si procede) ( ) * Evaluador responsable (si procede) Nivel de independencia (si procede) Protocolo empleado Organización evaluada * Categoría de la evaluación Ámbito (si procede) Dimensión o dimensiones Resultado de la evaluación * Resultados parciales Puntos de atención ( ) Opcional * Información completa, además del nombre. Tipo de evaluación Evaluador responsable No certificado por Scrum Manager Certificado por Scrum Manager Sin evaluador (Evaluación técnica) Debe indicar No oficial Oficial Autoevaluación Las evaluaciones oficiales son emitidas por Scrum Level. Organización evaluadora No debe indicarse en las autoevaluaciones. Las evaluaciones oficiales las debe realizar una organización evaluadora acreditada por Scrum Level. En el resumen o diploma: Nombre comercial de la organización evaluadora y razón social (en el caso de que sean diferentes). En el informe de evaluación: Nombre comercial de la organización evaluadora y razón social (en el caso de que sean diferentes). Dirección completa: vía, ciudad, país y código postal. Teléfono y, o dirección de correo electrónico para contacto relacionado con las evaluaciones Scrum Level. Persona de contacto para cuestiones relacionadas con la evaluación realizada. 32

33 Evaluador responable No debe indicarse en las autoevaluaciones. Nombre completo del evaluador Nivel de independencia Debe indicarse si la evaluación forma parte de un proceso de asesoría o mejora, o si se ha realizado en la organización evaluada un proceso de asesoría en los 6 meses previos a la evaluación. Nivel 1.- Algún evaluador (responsable o auxiliar) ha participado también en el proceso de asesoría. Nivel 2.- Ni el evaluador responsable, ni los posibles evaluadores auxiliares han participado en el proceso previo de asesoría. Nivel 3.- Evaluación con nivel de independencia 2, realizada por una organización distinta e independiente de la responsable de la asesoría previa. Protocolo empleado Nombre y versión del protocolo empleado para realizar la evaluación. Organización evaluada En el resumen o diploma: Nombre comercial de la organización evaluada y razón social (en el caso de que sean diferentes) En el informe de evaluación: Nombre comercial de la organización evaluada y razón social (en el caso de que sean diferentes) Dirección completa: vía, ciudad, país y código postal. Teléfono y, o dirección de correo electrónico para contacto relacionado con las evaluaciones Scrum Level. Persona de contacto para cuestiones relacionadas con la evaluación realizada. Categoría de la evaluación Indicación de la categoría de la evaluación: 1, 2 o 3. Categoría 1: El sistema está compuesto por un único equipo de personas, y puede comprender un único proyecto o varios. Categoría 2: El sistema está compuesto por más de un equipo de personas y más de un proyecto. Todos los equipos y proyectos pertenecen a la misma unidad organizativa (área, departamento o sucursal). Categoría 3: El sistema incluye a más de una unidad organizativa (área, departamento o sucursal) y cada una de ellas puede incluir un único o varios equipos y / o proyectos. Ámbito de la evaluación Opcional en evaluaciones de categoría 1 En evaluaciones de categoría 2: relación de proyectos y equipos objeto de evaluación. 33