Rev Junio 2006 Juan Palacio Bañeres

Transcripción

1 Compendio de Ingeniería del Software II Rev Junio 2006 Juan Palacio Bañeres

2 Tabla de contenido Prólogo Derechos 1.- Introducción a la ingeniería del software 2.- Ciclo de vida 3.- Requisitos 4.- Análisis y diseño 5.- Documentación de usuario 6.- Verificación y validación 7.- Mantenimiento 8.- Gestión de la configuración Prólogo Derechos 9.- Ingeniería de procesos del software 10.- Agilidad y procesos Modelos formales: CMMI 12.- Modelos formales: ISO / IEC Modelos ágiles 14.- Gestión de proyectos Gestión formal de proyectos Gestión ágil de proyectos: Scrum 15.- Gestión de organizaciones de Software 2

3 Prólogo CIS ofrece una visión práctica y sinóptica de la Ingeniería del Software. El formato de exposición que emplea resulta adecuado para foros que requieren una exposición didáctica de la Ingeniería del Software, o de alguna de sus áreas (requisitos, CMMI, etc.) de carácter ejecutivo o general, sin entrar en la densidad del libro especializado: Formación de Ingeniería del Software como asignatura complementaria en programas de estudio técnicos. Formación continua de gestores intermedios o directivos de empresas de software. Presentaciones de asesoría y formación profesional durante la implantación de procesos de mejora. Etc. Este no es un trabajo completo, y por su carácter general no pretende cubrir todos los modelos, técnicas o líneas de trabajo de la Ingeniería del Software, sino las más relevante y las que mayor repercusión o uso tienen en la industria del desarrollo y mantenimiento de software. Si resulta posible, en futuras revisiones se incluirán temas que por razones de tiempo y prioridad aún se han quedado fuera (DSDM, métricas, estimaciones, etc.). También en ellas se revisarán los contenidos actuales. Obra y derechos registrados en safecreative.net. Código de obra: Puede consultar la forma en la que puede emplear y distribuir este trabajo en: 3

4 9.- Ingeniería de procesos del software 4

5 Ingeniería de procesos del software Procesos: conceptos generales Qué es un proceso? Conjunto repetitivo... De actividades interrelacionadas... Que se realizan sistemáticamente... Mediante las cuales... Un entrada se convierte en una salida o resultado,... después de añadirle valor 5

6 Ingeniería de procesos del software Ingeniería de procesos de software: definición Finalidad de los procesos de Ingeniería del Software Facilitar el entendimiento y comunicación Dar soporte a la gestión y mejora de procesos Proporcionar un soporte / guía automatizado Los procesos deben ser adecuados a la organización y tipo de proyectos Naturaleza del trabajo (Mto. / Desarrollo) Dominio de aplicación Estructura del proceso de entrega (incremental, evolutivo, cascada...) Madurez de la organización 6

7 Ingeniería de procesos del software Ejemplo: estructura de procesos en ISO PROCESO Un proceso está compuesto por actividades. Una actividad está compuesta de tareas. ACTIVIDAD 1 ACTIVIDAD n TAREA 1 TAREA X TAREA 1 La descomposición del proceso en actividades y tareas se realiza sobre el concepto de ciclo de mejora PDCA Plan Do Chek Act (Planificación, ejecución, medición y mejora) INICIO PLAN Tareas, agenda, asignaciones ACT Problemas y acciones correctivas PROCESO DO Ejecición de planes y tareas CHECK Evaluación y medición FIN 7

8 Modelos de documentación de procesos Ingeniería de procesos del software Hay diferentes MODELOS para definir y documentar procesos: Diferentes niveles de abstracción - Diferentes tipos de definición Modelos de marco del ciclo de vida del software Los más comunes son: evolutivo / incremental, cascada, prototipado, prototipado evolutivo, espiral, software reutilizable. Modelos de proceso del ciclo de vida del software Las principales referencias son: o ISO/IEC IT Software Life Cycle Processes o ISO/IEC IT Software Process Assesment 8

9 Ingeniería de procesos del software Notaciones Lenguajes de modelado gráfico que sirven para representar a los procesos. Diagramas de flujo: Técnica para especificar los detalles de un proceso en términos de actividades, tareas, entradas, salidas, condiciones. IDEF0: Estándar para desarrollar representaciones gráficas estructuradas de un sistema o entorno empresarial. Permite la construcción de modelos que comprenden funciones del sistema (actividades, acciones, operaciones, procesos), relaciones y datos. UML... 9

10 Proceso de Ingeniería de Software Niveles del proceso de Ingeniería del Software Ingeniería de procesos del software El proceso de ingeniería del software puede examinarse en 2 niveles: Actividades técnicas y de gestión ejecutadas durante la adquisición, desarrollo, mantenimiento y retirada Meta-nivel concerniente a la definición, implementación, medición y mejora de los procesos Ingeniería de procesos del software 10

11 Ingeniería de procesos de software Ingeniería de procesos del software Modelos más relevantes de ingeniería de procesos PDCA IDEAL SM ISO 15504, Parte 7 Modelos genéricos Basados en ciclos de mejora continua Tienen similitudes ISO 9004:

12 Ingeniería de procesos de software PDCA Ingeniería de procesos del software PLAN Identificar el problema Analizar el problema DO Desarrollar soluciones Implementar una solución CHECK Evaluar los resultados ACT Determinar los siguientes pasos 12

13 Ingeniería de procesos de software IDEAL Ingeniería de procesos del software Fase Inicial Fase de Diagnóstico Fase de establecimiento Fase de acción Fase de aprendizaje 13

14 Ingeniería de procesos del software ISO / IEC Examine needs Scope Organization s needs 2. Initiate improv. Quantified results Preliminary plan 3. Conduct assess. 8. Monitor perform. Results Instituc. gains Reassessment request 4. Plan improv. 7. Sustain gains Action plan Confirmed improvements 6. Confirm improv. 5. Implement improv. Improvements 14

15 Ingeniería de procesos del software Patrones comunes Establecer infraestructura Planificar implementación y cambio de procesos Medición Definición Análisis cualitativo Implementación y cambio Base Experiencia Implementación y cambio de procesos Evaluación del proceso Medición Análisis cualitativo Implementación y cambio 15

16 Ingeniería de procesos: Patrones comunes Ingeniería de procesos del software DEFINICIÓN MEDICIÓN ANÁLISIS IMPLEMENTACIÓN Y CAMBIO 16

17 Ingeniería de procesos del software Medición Obtener, analizar e interpretar información CUANTITATIVA para: CARACTERIZAR Entender el proceso actual, entorno, etc. Disponer de información de la situación anterior al cambio EVALUAR Determinar la consecución de objetivos Identificar fortalezas y debilidades del proceso PREDECIR Entender las relaciones entre procesos y productos Establecer objetivos alcanzables de calidad, costes y agendas MEJORAR Identificar causas y oportunidades de mejora Seguir el rendimiento de los cambios y compararlo con líneas base 17

18 Ingeniería de procesos del software Medición Se puede medir la calidad del proceso (en si mismo) o la calidad de sus salidas. PROCESO SALIDAS (resultado) CONTEXTO 18

19 Ingeniería de procesos del software Medición Qué medir La forma de identificar qué medir y cómo hacerlo más eficiente es basándose en los objetivos del proceso (goal-oriented / goal driven) 1) Empezar por especificar las necesidades de información 2) Después, identificar las medidas que satisfacen esas necesidades Fiabilidad: Margen de error de la medición Validez: Capacidad de medir realmente lo que creemos que mide 19

20 Ingeniería de procesos del software Medición Paradigmas ANALÍTICO/A Evidencias cuantitativas de la necesidad de mejoras y del éxito de iniciativas de mejoras ANÁLISIS COMPARATIVO (Benchmarking) Comparación con organización excelente en un campo y documentar sus practicas y herramientas 20

21 Ingeniería de procesos del software Medición El modelo ANALÍTICO consiste en: ENTENDER CONSOLIDAR REVISAR Ejemplos: Estudios experimentales y de observación Simulación de procesos Clasificación ortogonal de defectos Control estadístico de procesos 21

22 Ingeniería de procesos del software Medición El modelo ANÁLISIS COMPARATIVO consiste en medir: La madurez de una organización o la capacidad de sus procesos Los modelos de evaluación de procesos recogen lo que se consideran best practices SW-CMM y CMMI CBA IPI y SCAMPI ISO ISO 15504, Part 8 ISO arquitecturas generales con distintas asunciones en cuanto al orden en el que medir los procesos: continua y escalonada 22

23 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) OBJETIVO Cada métrica debe esta dirigida a cubrir / medir un objetivo. La idea es que debemos tener buenas razones para recoger datos. REQUISITO Cada objetivo debe contestarse con uno o varios requisitos (preguntas). El requisito debe establecerse de forma que la métrica pueda responderlo claramente. MÉTRICA INDICADOR El indicador debe ser una entidad cuantitativa que de respuesta a un requisito especifico. 23

24 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) Resumen de los pasos de GQM 1. Establecer los objetivos / expectativas de la colección de datos 2. Desarrollar una lista de requisitos / criterios de interés 3. Establecer los indicadores 4. Diseñar los medios para recoger los datos 5. Recoger y validar los datos 6. Analizar los datos Objetivos negocio Qué tengo que conseguir? Qué quiero conocer? Indicador 24

25 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) Ayuda para identificar requisitos: listar entidades y cuestiones relacionadas con los objetivos. Entidad 1 Entidad 2... Descartar según sean comprensibles, cuantificables, conscientes, coherentes. 25

26 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) Ejemplos de requisitos: Entidad Financiera Fabricantes de coches Fiabilidad Sin averías Sin cargos o abonos improc. Conformidad importe p- importe c... Sin reparación no accidental antes de 2 años... Establecimiento hotelero Rapidez Recepción de mensajes < 15 min. Chequeo inmediato... 26

27 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) G1 G2 Q1 Q2 Q3 I1 I2 I3 I4 M1 M2 M3 27

28 Ingeniería de procesos del software Medición orientada a objetivos GQM (Goal Question Metric) 28

29 10.- Agilidad y procesos 29

30 Agilidad y procesos Manifiesto ágil (2001) Origen de los métodos ágiles En marzo de 2001, 17 críticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software. En la reunión se acuñó el término Métodos Ágiles para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo. Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como Manifiesto Ágil, que compendia el espíritu en el que se basan estos métodos. Aunque como se verá más adelante, en la actualidad hay aproximaciones que combinan lo mejor de ambos enfoques (formal y ágil), hasta 2005, en cada lado sus defensores adoptaron posturas radicales, quizá más ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia. 30

31 Agilidad y procesos Manifiesto ágil (2001) Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interacción El software que funciona La colaboración con el cliente La respuesta al cambio por encima por encima por encima por encima de los procesos y las herramientas de la documentación exhaustiva la negociación contractual seguimiento de un plan Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 31

32 Agilidad y procesos 12 principios del manifiesto ágil 1.- Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. 2.- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. 3.- Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. 4.- Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. 32

33 Agilidad y procesos 12 principios del manifiesto ágil 5.- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea. 6.- La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. 7.- El software que funciona es la principal medida del progreso. 8.- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. 33

34 Agilidad y procesos 12 principios del manifiesto ágil 9.- La atención continua a la excelencia técnica enaltece la agilidad La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia. 34

35 Técnicas y métodos ágiles Modelos específicos para software. Modelos y estándares formales de calidad Adaptaciones para softw. Visión simplificada de modelos formales y ágiles Agilidad y procesos Modelos genéricos Modelos para software 1997 TickIT 1991 ISO MIL-Q BS ISO 9000 Trillium Bootstrap 1995 ISO Proy. SPICE TR ISO CMM-SW Modelos CMM 2001 CMMI DSDM SCRUM CRYSTAL XP ASD PP ISD AM Manifiesto Ágil 35

36 11.- Modelos formales: CMMI 36

37 Modelos formales: CMMI CMM (Capability Maturity Model) Deficiencias en las metodologías proceso de software Incapacidad para manejar el En 1986, SEI (Software Engineering Institute): marco de trabajo sobre madurez de procesos En 1991, SEI desarrolló Capability Maturity Model (CMM) Conjunto de prácticas recomendadas en determinadas áreas clave de proceso Mejora la capacidad del proceso de software Guía en la selección de estrategias de mejora de proceso Establecer la madurez de los procesos Determina cuestiones críticas para la calidad y la mejora del proceso 37

38 Modelos formales: CMMI Organizaciones de software maduras / inmadudas Idea principal: distinción entre empresas maduras/inmaduras En una organización inmadura: - Procesos de software: improvisados o no respetados (si existen) - Planificación en función de los problemas - Presupuestos y planificación incumplidos - Sin base objetiva para evaluar la calidad o para resolver problemas - Inexistencia o reducción de las actividades de mejora de la calidad En una organización madura: - Capacidad de gestión: desarrollo de software y procesos de mantenimiento - Proceso de software difundido al equipo y planificado - Procesos modificables: pruebas piloto controladas y análisis de coste/beneficio - Roles y responsabilidades establecidos en el proyecto y la organización - Gestores: monitorización la calidad de los productos y de los procesos - Planificaciones y presupuestos realistas: rendimientos históricos - Proceso disciplinado en el que todos los participantes entienden su valor, existiendo además la infraestructura necesaria para soportar el proceso 38

39 Modelos formales: CMMI Proyecto CMMI DoD (Departamento de Defensa de los Estados Unidos), SEI (Software Engineering Institute) y NDIA (National Defense Industrial Association). Más de 100 organizaciones involucradas U.S. Army, Navy, Air Force Federal Aviation Administration National Security Agency Software Engineering Institute ADP, Inc. AT&T Labs BAE Boeing Computer Sciences Corporation EER Systems Ericsson Canada Ernst and Young General Dynamics Harris Corporation Honeywell KPMG Lockheed Martin Motorola Northrop Grumman Pacific Bell Q-Labs Raytheon Reuters Rockwell Collins SAIC Software Productivity Consortium Sverdrup Corporation TeraQuest Thomson CSF TRW 39

40 Modelos formales: CMMI Modelos CMMI Modelo combinado System Engineering/Software Engineering Aplicable: Sólo a proyectos de software engineering Sólo a proyectos de system engineering Ambos Continua o escalonada? Ambas incluyen el mismo contenido y consiguen idénticos objetivos La representación continua centra su actuación en la CAPACIDAD DE LOS PROCESOS La representación escalonada centra su actuación en la MADUREZ DE LA ORGANIZACIÓN 40

41 Por qué dos representaciones del modelo? Modelos formales: CMMI Heredado de los modelos de origen. Software CMM--Escalonado SECM--Continuo IPD CMM--Híbrido En el del equipo de desarrollo de CMMI había defensores de de cada una de las representaciones. Seleccionar una única representación se planteaba como algo too hard. Compromiso: Inicialmente soportar dos representaciones del modelo con contenidos equivalentes. 41

42 Capacidad Modelos formales: CMMI Un modelo, dos representaciones Continuo Escalonado ML5 PA PA PA...para un área de proceso o un conjunto de áreas de proceso ML2 ML 1 ML3 ML4...para un conjunto de áreas de proceso establecido 42

43 Modelos formales: CMMI Capacidad y madurez Capacidad es un atributo que se aplica a los procesos y define la eficacia del mismo para conseguir los objetivos previstos. Madurez es un atributo que se aplica a la organización y define su potencial de calidad en la producción. ML5 ML4 ML3 ML2 ML 1 43

44 Modelos formales: CMMI Niveles de capacidad 0 Incompleto Los procesos no se realizan, o no consiguen sus objetivos 1 Ejecutado Los procesos se ejecutan y se logran los objetivos específicos del área 2 Gestionado Los procesos que además de considerarse ejecutados son también planificados, revisados y evaluados para comprobar que cumplen los requisitos 3 Definido Los procesos que además de considerarse gestionados se ajustan al conjunto de procesos estándar conforme a las líneas directivas de la organización 4 Gestión cuantificada Procesos definidos que son controlados utilizando técnicas estadísticas u otras técnicas cuantitativas 5 Optimizado Procesos gestionados cuantificadamente que son cambiados y adaptados para conseguir objetivos relevantes de negocio 44

45 Capacidad Modelos formales: CMMI Dimensión de la capacidad Los valores describen cómo de bien se realiza el proceso (nivel de capacidad del proceso). Proceso bien ejecutado y mejorado continuamente Proceso no ejecutado Area Proceso 1 Area Proceso 2 Procesos Area Proceso 3 Area Proceso n 45

46 Modelos formales: CMMI Niveles de madurez 1 Inicial Control deficiente e impredecibilidad de los resultados 2 Gestionado Es posible obtener niveles de calidad previamente alcanzados 3 Definido Los procesos realizados se encuentran normalizados, son conocidos y comprendidos 4 Gestionado cuantitativamente Los procesos incluyen indicadores de medición y control 5 Optimizado Centralización en la mejora de los procesos 46

47 Modelos formales: CMMI Dimensión de la madurez 5 Centrado en la mejora de procesos Optimizado 4 Proceso medido y controlado Gestionado cuantitativamente 3 Proceso caracterizado para la organización y proactivo Definido 2 1 Proceso caracterizado para los proyectos y a menudo reactivo Proceso imprevisible, poco controlado y reactivo Inicial Gestionado 47

48 Modelos formales: CMMI Áreas de procesos CMMI recoge prácticas para 22 áreas de procesos Las áreas de procesos agrupan a las actividades necesarias para la ejecución de los proyectos de ingeniería de sistemas y de software El modelo en su representación escalonada clasifica a las 22 áreas de proceso en aquellas cuya gestión es necesaria para lograr cada nivel de calidad El modelo en su representación continua las clasifica según a la categoría que pertenecen: Gestión de proyectos, ingeniería, soporte y gestión de procesos 48

49 Modelos formales: CMMI Áreas de procesos en la representación escalonada NIVEL DE MADUREZ 5 OPTIMIZADO 4 GESTIONADO CUANTITATIVAMENTE ÁREAS DE PROCESO Innovación y desarrollo Gestión cuantificada de proyectos Rendimiento de los procesos de la organización 3 DEFINIDO Desarrollo de requisitos Solución técnica Verificación Validación Integración de producto Procesos orientados a la organización Definición de los procesos de la organización Formación Gestión integrada de proyecto Gestión de riesgos Análisis y resolución de decisiones 2 GESTIONADO 1 INICIAL Gestión de requisitos Planificación de proyecto Monitorización y control de proyectos Gestión y acuerdo con suministradores Medición y análisis Gestión de la calidad de procesos y productos Gestión de la configuración 49

50 Áreas de procesos en la representación continua Modelos formales: CMMI CATEGORÍA GESTIÓN DE PROYECTOS ÁREAS DE PROCESO Planificación de proyecto Monitorización y control de proyecto Gestión y acuerdo con proveedores Gestión integrada de proyecto Gestión de riesgos Gestión cuantificada de proyecto SOPORTE INGENIERÍA GESTIÓN DE PROCESOS Gestión de la configuración Gestión de la calidad de procesos y productos Medición y análisis Análisis y resolución de decisiones Análisis y resolución de problemas Desarrollo de requisitos Gestión de requisitos Soluciones técnicas Integración de producto Verificación Validación Definición de los procesos de la organización Procesos orientados a la organización Formación Rendimiento de los procesos de la organización Innovación y desarrollo 50

51 Modelos formales: CMMI Cómo usar el modelo Área de proceso Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos. Componentes requeridos Objetivo genérico Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso Objetivo específico Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso 51

52 Modelos formales: CMMI Cómo usar el modelo Componentes esperados Práctica genérica Una practica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso. Práctica específica Una practica específica es una actividad que se considera importante en la realización del objetivo especifico al cual está asociado. Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso. Componentes informativos Propósito Notas introductorias Referencias Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportar información adicional o más detallada Nombres Tablas de relaciones práctica-objetivo Prácticas 52

53 Modelos formales: CMMI Cómo usar el modelo Componentes informativos Propósito Notas introductorias Referencias Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportar información adicional o más detallada Nombres Tablas de relaciones práctica-objetivo Prácticas Productos típicos Subprácticas Una subpractica es una descripción detallada que sirve como guía para la interpretación de una practica genérica o especifica Ampliaciones de disciplina Las ampliaciones contienen información relevante de una disciplina particular y relacionada con una practica especifica. Elaboraciones de prácticas genéricas Una elaboración de una practica genérica es una guía de cómo la practica genérica debe aplicarse al área de proceso. 53

54 Modelos formales: CMMI Mapa del documento Propósito Área de proceso Notas Objetivos específicos Objetivos genéricos Referencias 54

55 Modelos formales: CMMI Mapa del documento R. Metas-Practicas Practicas especificas Nombres 55

56 Modelos formales: CMMI Mapa del documento Notas Practicas genericas Productos de trabajo Subpracticas Elaboraciones 56

57 Modelos formales: CMMI Áreas de proceso CMMI SE/SW incluye 22 áreas de proceso Las áreas de proceso son iguales en ambas representaciones del modelo En la representación continua, las áreas de proceso se agrupan por categorías: Gestión de proyectos, Ingeniería, Soporte y Gestión de procesos Process areas by capability En la representación escalonada, las áreas de proceso se agrupan por niveles de madurez (2 5) Process areas by maturity level 57

58 Modelos formales: CMMI Áreas de proceso Gestión de proyecto Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con la planificación, monitorización y control del proyecto. El modelo CMMI SE/SW incluye seis áreas de proceso en gestión de proyectos: Planificación de proyecto Monitorización y control de proyecto Gestión y acuerdos con proveedores Gestión integrada de proyecto Gestión de riesgos Gestión cuantificada de proyecto 58

59 Modelos formales: CMMI Áreas de proceso Gestión de proyecto: áreas básicas Acciones Correctivas Replanificar PMC Que controlar Acciones Correctivas Estado, cuestiones, resultados de evaluaciones de producto, Medidas y análisis Estado, cuestiones, resultados de progreso y revisiones de hitos PP Que construir Que hacer Áreas de proceso Soporte e Ingeniería Planes Acuerdos Proveedor Proveedor SAM Necesidades de medición Requisitos de componente de producto Cuestiones técnicas Revisiones y test de aceptación 59

60 Modelos formales: CMMI Áreas de proceso Gestión de proyecto: planificación de proyecto Propósito: establecer y mantener planes que definan las actividades del proyecto Establecer Estimaciones Datos Planificación Desarrollar Plan de Proyecto Obtener Compromisos con el Plan Planes de Proyecto PMC 60

61 Modelos formales: CMMI Áreas de proceso Gestión de proyecto: monitorización y control Propósito: Proporcionar información sobre el progreso del proyecto que permita tomar acciones correctivas cuando la ejecución del proyecto se desvía significativamente del plan. Monitorizar Proyecto contra Planes Gestionar Acciones Correctivas Monitorizar Parámetros Planificación Monitorizar Riesgos Monitorizar Implicación Stakeholder Conducir Revisiones Analizar Cuestiones Monitorizar Compromisos Monitorizar Gestión Datos Conducir Revisiones de Progreso Tomar Acciones correctivas Gestionar Acciones correctivas PP Planes de Proyecto 61

62 Modelos formales: CMMI Áreas de proceso Gestión de proyecto: gestión y acuerdos con proveedores Propósito: Gestionar la adquisición de productos a proveedores según un acuerdo formal existente. Establecer Acuerdos con Proveedores Determinar Tipo Adquisición Seleccionar Proveedores Establecer Acuerdos Lista de productos Requisitos Proveedor Producto Acuerdo Proveedor Satisfacer Acuerdos Proveedor Revisar Productos COTS Aceptar Producto Transición Productos Ejecutar Acuerdos 62

63 Modelos formales: CMMI Áreas de proceso Ingeniería Las áreas de proceso de ingeniería cubren las practicas de desarrollo y mantenimiento compartidas por diferentes disciplinas como ingeniería de software e ingeniería de sistemas. El modelo CMMI SE/SW incluye seis áreas de proceso en ingeniería: Desarrollo de requisitos Gestión de requisitos Soluciones técnicas Integración de producto Verificación Validación 63

64 Modelos formales: CMMI Áreas de proceso Ingeniería: áreas básicas REQM Requisitos Requisitos de producto & Componente de producto RD Soluciones Alternativas Requisitos TS Componentes Producto Componentes de producto, productos del trabajo, informes de verificación y validación PI Producto CLIENTE VER VAL Necesidades del cliente 64

65 Modelos formales: CMMI Áreas de proceso Ingeniería: gestión de requisitos Propósito: Gestionar los requisitos del producto y de componentes del producto del proyecto e identificar inconsistencias entre los requisitos, los planes del proyecto y los resultados del trabajo. Gestión de Requisitos Entender los Requisitos Requisitos Identificar Inconsistencias entre Proyecto y Requisitos Obtener compromisos a Requisitos Gestionar Cambios Requisitos Matriz Trazabilidad Mantener Trazabilidad Requisitos 65

66 Modelos formales: CMMI Áreas de proceso Ingeniería: desarrollo de requisitos Propósito: Producir y analizar los requisitos del cliente, del producto y de los componentes de producto. Desarrollar Requisitos del Cliente Desarrollar Requisitos del Producto Analizar y Validar Requisitos Requisitos Cliente Requisitos Producto Requisitos Validados 66

67 Modelos formales: CMMI Áreas de proceso Ingeniería: solución técnica Propósito: Desarrollar, diseñar e implementar soluciones a los requisitos. Requisitos Validados Seleccionar Soluciones Producto-Comp. Desarrollar Diseño Implementar Producto Diseños alternativos y Criterios de evaluación Diseño detallado & Documentacion Producto Entregado 67

68 Modelos formales: CMMI Áreas de proceso Ingeniería: integración de producto Propósito: Ensamblar el producto asegurando que funciona apropiadamente y entregar el producto. DAR Preparar Integración Producto Solución Técnica Plan Integración Subassemblies Garantizar Interfaces Compatibles Assemblies Ensamblar Comp. Producto y Entregar Producto 68

69 Modelos formales: CMMI Áreas de proceso Ingeniería: verificación Propósito: Asegurar que los resultados del trabajo seleccionados cumplen los requisitos especificados. Preparar para Verificación Ejecutar Peer Reviews Plan Verificación Verificar Productos Seleccionados Acciones Correctivas 69

70 Modelos formales: CMMI Áreas de proceso Ingeniería: validación Propósito: Demostrar que un producto o componente de producto satisface su uso previsto en el entorno previsto. - Requisitos Cliente - Requisitos Producto - Productos - Validación de Requisitos Validar Producto o Componentes Producto Preparar para Validación -Conformidad -Deficiencias - Plan Validación Requisitos - Plan Validación Producto - Procesos y necesidades de Soporte 70

71 Modelos formales: CMMI Áreas de proceso Soporte Las áreas de procesos de soporte cubren las practicas que sirven de base para el desarrollo del producto y su mantenimiento. El modelo CMMI SE/SW incluye cinco áreas de proceso en soporte: Gestión de la configuración Gestión de la calidad de procesos y productos Medición y análisis Análisis y resolución de decisiones Análisis y resolución de problemas 71

72 Modelos formales: CMMI Áreas de proceso Soporte: áreas básicas MA Medidas, análisis Información necesaria Todas las áreas de proceso Elementos de configuración; peticiones de cambio CM Calidad y no conformidades Procesos y resultados; estándares y procedimientos Líneas base; informes de auditoria PPQA 72

73 Modelos formales: CMMI Áreas de proceso Soporte: gestión de la configuración Propósito: Establecer y mantener la integridad de todos los productos de trabajo, utilizando identificación de la configuración, control de la configuración, informes de estado de configuración y auditorias de la configuración. Sistema Gestión Configuración Establecer Líneas Base BBDD Peticiones de cambio Peticiones de cambio Establecer Integridad Estado Resultados Auditoria Elementos Acción Seguir y controlar cambios 73

74 Modelos formales: CMMI Áreas de proceso Soporte: aseguramiento de la calidad de procesos y producto Propósito: Proporcionar un entendimiento objetivo de los procesos y los productos del trabajo asociado. Evaluar objetivamente procesos y productos de trabajo Productos trabajo Evaluación Objetiva Procesos Evaluación Objetiva P. Trabajo y Servicios Informes y Registros Proporcionar entendimiento objetivo Comunicar y Garantizar Resolución de No Conformidades Establecer Registros 74

75 Modelos formales: CMMI Áreas de proceso Soporte: medición y análisis Propósito: Desarrollar y mantener una capacidad para medir, utilizada para dar soporte a las necesidades de información de la gerencia. Ajustar actividades de medición y análisis Personal Medición Objetivos Medición Indicadores Medición Repositorio Medición Procedimientos, Herramientas Proporcionar resultados de mediciones 75

76 Modelos formales: CMMI Áreas de proceso Gestión de procesos Las áreas de procesos de soporte cubren las actividades de definición, planificación, recursos, desarrollo, implementación, monitorización, control, evaluación, medición y mejora de procesos. El modelo CMMI SE/SW incluye cinco áreas de proceso en gestión de procesos: Definición de procesos Enfoque de procesos a la organización Formación Rendimiento de los procesos Innovación y desarrollo 76

77 Modelos formales: CMMI Áreas de proceso Gestión de procesos: áreas básicas Senior Management Necesidades y objetivos de procesos Formación en procesos Objetivos Negocio OT Necesidades Formación OPF Recursos y Coordinación OPD Procesos Estándares y Propios Procesos Estándares y Propios Áreas de proceso de gestión de proyecto, soporte e ingeniería Propósitos de mejora de procesos; Participación en definir, evaluar, y desarrollar procesos Información de mejora (e.j., lessons learned, datos) 77

78 12.- Modelos formales: ISO/IEC

79 Modelos formales: ISO/IEC ISO/IEC 15504: Origen Proyecto SPICE En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software. Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability determination), y en junio de 1995, con la publicación de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados. Proyecto -> Instrucción Técnica -> Estándar En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasó a la fase de informe técnico con la denominación ISO/IEC TR La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes, que se han ido publicando como redacción definitiva del estándar internacional ISO/IEC durante el periodo Ámbito de aplicación Cualquier organización de software que quiera establecer y mejorar su capacidad en adquisición, suministro, desarrollo, operación evolución y soporte de software. Independientemente de estructuras, filosofías de gestión, modelos de ciclo de vida de software, tecnologías o metodologías de desarrollo. 79

80 Modelos formales: ISO/IEC Estructura P7 P1 Conceptos y guía de introducción P9 Vocabulario Guía para mejora de procesos P8 Guia para det. capacidad de proveedores P6 Guia de capacitación de evaluadores P3 Realización de evaluación Guía de evaluación P4 Modelo de ref. para procesos y capacidad P2 Modelo de evaluación y guía de indic. P5 80

81 Modelos formales: ISO/IEC Características Marco para métodos de evaluación, no es un método o modelo en sí. Comprende: Evaluación de procesos Mejora de procesos Determinación de capacidad Alineado con ISO/IEC Information Technology Software Life Cycle Processes Dimensiones del modelo El modelo tiene una arquitectura basada en dos dimensiones: Dimensión de proceso Caracterizada por las declaraciones del propósito de un proceso, que son objetivos esenciales mensurables de un proceso. Dimensión de capacidad de proceso Caracterizada por una serie de atributos de proceso, aplicables a cualquier proceso, que representan características mensurables necesarias para gestionar un proceso y mejorar su capacidad. 81

82 Modelos formales: ISO/IEC Características Dimensión de proceso Agrupa los procesos en tres grupos correspondientes a los procesos del ciclo de vida que contienen cinco categorías de acuerdo al tipo de actividad. Procesos primarios CUS: Cliente Proveedor ENG: Ingeniería Procesos de soporte SUP: Soporte Procesos organizacionales MAN: Gestión ORG: Organización 82

83 Modelos formales: ISO/IEC Dimensión de proceso CUS: Cliente - proveedor La categoría CUS está formada por procesos que afectan directamente al cliente, soportan el desarrollo y la transición del software al cliente y permiten la correcta operación y uso del producto y/o servicio de software. CUS.1 Proceso de adquisición CUS.1.1 Proceso de preparación de la adquisición CUS.1.2 Proceso de selección de proveedor CUS.1.3 Procesos de seguimiento de proveedor CUS.1.4 Proceso de aceptación del cliente CUS.2 Proceso de suministro CUS.3 Proceso de obtención de requisitos CUS.4 Proceso de operación CUS.4.1 Proceso de uso operacional CUS.4.2 Proceso de soporte al cliente 83

84 Modelos formales: ISO/IEC Dimensión de proceso ENG: Ingeniería La categoría ENG está formada por procesos que directamente especifican, implementan o mantienen el producto de software, su relación con el sistema y documentación. ENG.1 Proceso de desarrollo ENG.1.1 Proceso de análisis y diseño de requisitos de sistema. ENG.1.2 Proceso de análisis de requisitos de software. ENG.1.3 Procesos de diseño de software. ENG.1.4 Proceso de construcción de software. ENG.1.5 Proceso de integración de software. ENG.1.6 Proceso de prueba de software. ENG.1.7 Proceso de integración y prueba de sistema. ENG.2 Proceso de mantenimiento de software 84

85 Modelos formales: ISO/IEC Dimensión de proceso SUP: Soporte La categoría SUP está formada por procesos que dan soporte al resto de procesos (incluidos los SUP), en distintos puntos del ciclo de vida del software. SUP.1 Proceso de documentación SUP.2 Proceso de gestión de configuración SUP.3 Proceso de aseguramiento de calidad SUP.4 Proceso de verificación SUP.5 Proceso de validación SUP.6 Proceso de revisión conjunta SUP.7 Proceso de auditoría 85

86 Modelos formales: ISO/IEC Dimensión de proceso MAN: Gestión La categoría MAN está formada por procesos utilizados en la gestión de cualquier tipo de proyecto o proceso en el ciclo de vida del software. MAN.1 Proceso de gestión MAN.2 Proceso de gestión de proyecto MAN.3 Gestión de calidad MAN.4 Gestión de riesgos 86

87 Modelos formales: ISO/IEC Dimensión de proceso ORG: Organización La categoría ORG está formada por procesos que establecen los objetivos de negocio de la organización. ORG.1 Proceso de alineación organizacional. ORG.2 Proceso de mejora ORG.2.1 Proceso de definición de proceso. ORG.2.2 Proceso de evaluación de proceso. ORG.2.3 Proceso de mejora de proceso. ORG.3 Proceso de gestión de RR.HH. ORG.4 Proceso de infraestructura ORG.5 Proceso de medición ORG.6 Proceso de reutilización 87

88 Modelos formales: ISO/IEC Dimensión de proceso Componentes de proceso Identificador Identifica la categoría del proceso y el nº de secuencia en la categoría. Distingue entre procesos de primer y segundo nivel. Nombre Frase descriptivo del contenido del proceso Tipo Hay 5 tipos de proceso. 3 de primer nivel (básico, extendido y nuevo) y 2 de segundo nivel (componente, componente extendido) Propósito Párrafo que establece el propósito del proceso indicando los objetivos globales de su ejecución. Salidas Lista de resultados observables de la implementación exitosa del proceso Notas 88

89 Modelos formales: ISO/IEC Dimensión de capacidad Capacidad de proceso: rango de resultados que espera obtenerse al seguir el proceso. Define una escala de medida para determinar la capacidad de cualquier proceso Consta de seis niveles de capacidad Nivel 0 Incompleto Nivel 1 Realizado Nivel 2 Gestionado Nivel 3 Establecido Nivel 4 Predecible Nivel 5 En optimización...y un conjunto de atributos de procesos asociados al nivel de capacidad 89

90 Modelos formales: ISO/IEC Dimensión de capacidad Niveles de capacidad y atributos Nivel 0: Proceso Incompleto Nivel 1: Proceso Realizado Nivel 2: Proceso Gestionado PA 2.1 Gestión de realización PA 2.2 Gestión productos Nivel 3: Proceso Establecido PA 3.1 Definición de proceso PA 3.2 Recursos de proceso Nivel 4: Proceso Predecible PA 4.1 Medición PA 4.2 Control de proceso Nivel 5: Proceso en optimización PA 5.1 Cambio de proceso PA 5.2 Mejora continua 90

91 Modelos formales: ISO/IEC Dimensión de capacidad Medición de atributos Los atributos de un proceso se evalúan con N (Not), P (Partially), L (Largely) y F (Fully), siendo: N No alcanzado (0% a 15%). Escasa o ninguna evidencia de la consecución del atributo. P Parcialmente alcanzado (16% a 50%). Evidencia de un enfoque sistemático y de la consecucióndel atributo. Algunos aspectos de la consecución pueden ser impredecibles. L Ampliamente alcanzado (51% a 85%). Evidencia de un enfoque sistemático y de una consecución significativa del atributo. La realización del proceso puede variar en algunas áreas. F Totalmente alcanzado (86% a 100%). Evidencia de un enfoque completo y sistemático y de la consecución plena del atributo. 91

92 13.- Modelos ágiles 92

93 Técnicas y métodos ágiles Modelos específicos para software. Modelos y estándares de calidad Adaptaciones para softw. Modelos ágiles Ubicación en el panorama general de modelos y procesos Modelos genéricos Modelos para software 1997 TickIT 1991 ISO MIL-Q BS ISO 9000 Trillium Bootstrap 1995 ISO Proy. SPICE TR ISO CMM-SW Modelos CMM 2001 CMMI DSDM SCRUM CRYSTAL XP ASD PP Manifiesto Ágil ISD AM 93

94 Modelos ágiles DSDM: Dynamic Systems Development Method Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de Jennifer Stapleton, la actual directora del DSDM Consortium. DSDM es la metodología ágil más próxima a los métodos formales, de hecho la implantación de un modelo DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 de madurez. Sin embargo los aspectos que DSDM reprocha a CMM son: Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo que funciona bien en unos entornos no tiene por qué servir para todos. CMM no le da al diseño la importancia que debería tener. CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria tiene el talento de las personas. El tener procesos claramente definidos no es sinónimo de tener buenos procesos. En común con los métodos ágiles, DSDM considera imprescindible una implicación y una relación estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos de desarrollo incremental y entregas evolutivas. DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte y mantenimiento y se autodefine como un marco de trabajo para desarrollo rápido más que como un método específico para el desarrollo de sistemas. 94

95 Modelos ágiles extreme Programming (XP) Este es el método que más popularidad ha alcanzado entre las metodologías ágiles, y posiblemente sea también el más transgresor de la ortodoxia basada en procesos. Su creador, Kent Beck fue el alma mater del Manifiesto Ágil. Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde. Valores que inspiran XP SIMPLICIDAD FEEDBACK CORAJE COMUNICACIÓN 95

96 Modelos ágiles extreme Programming (XP) Comunicación XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente Feedback rápido y continuo Una metodología basada en el desarrollo incremental de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones. De esta forma fallos se localizan muy pronto. La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema. La retro-información es la herramienta que permite reajustar la agenda y los planes. 96

97 Modelos ágiles extreme Programming (XP) Simplicidad La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales. Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro. Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales Coraje El coraje implica saber tomar decisiones difíciles. Reparar un error cuando se detecta. Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora. Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a entregar. 97

98 Modelos ágiles extreme Programming (XP) Las 12 prácticas de XP XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prácticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores citados PRÁCTICAS DE CODIFICACIÓN 1.- Simplicidad de código y de diseño para producir software fácil de modificar. 2.- Reingeniería continua para lograr que el código tenga un diseño óptimo. 3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código. 4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad. PRÁCTICAS DE DESARROLLO 1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se comporta según lo esperado. 2.- Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas. 3.- Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él. 4.- Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades. 98

99 Modelos ágiles extreme Programming (XP) Las 12 prácticas de XP PRÁCTICAS DE NEGOCIO 1.- Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación. 2.- Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante. 3.- Entregas regulares y frecuentes para satisfacer la inversión del cliente. 4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado. 99

100 Modelos ágiles Scrum No es propiamente un método o metodología de desarrollo, e implantarlo como tal resulta insuficiente. Scrum define métodos de gestión y control para complementar la aplicación de otros métodos ágiles como XP que, centrados en prácticas de tipo técnico, carecen de ellas. Los principios de Scrum son: Equipos autogestionados. Una vez dimensionadas las tareas no es posible agregarles trabajo extra. Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones: Qué has hecho desde la última revisión? Qué obstáculos te impiden cumplir la meta? Qué vas a hacer antes de la próxima reunión? Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se presenta el resultado a los externos del equipo de desarrollo, y se realiza una planificación de la siguiente iteración, guiada por cliente. 100

101 Modelos ágiles Scrum 101

102 Modelos ágiles Otros métodos ágiles Familia de métodos Crystal La familia de metodologías Crystal ofrece diferentes métodos para seleccionar el más apropiado para cada proyecto. Crystal identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas. Los métodos Crystal no prescriben prácticas concretas ASD (Adaptative Software Development) Método que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de técnicas propias de las metodologías ágiles. No se trata de una metodología, sino de la implantación de una cultura en la empresa, basada en la adaptabilidad. 102

103 Modelos ágiles Otros métodos ágiles PP (Pragmatic Programming) Pragmatic Programming es la colección de 70 prácticas de programación, comunes a otros métodos ágiles, cuya aplicación resulta útil para solucionar los problemas cotidianos AM (Agile Modeling) Agile Modeling es la presentación de un nuevo enfoque para realizar el modelado de sistemas,(diseño) y basado en los principios de los métodos ágiles remarca la conveniencia de reducir el volumen de la documentación. ISD (Internet Speed Development) Es el más reciente de los métodos ágiles, surgido como respuesta para las situaciones que requieren ciclos de desarrollo muy breves con entregas rápidas. Se centra en el talento de las personas sobre los procesos. ISD es un entorno de gestión orientado al negocio FDD (Feature Driven Development) Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas. El punto de referencia son las características que debe reunir el software, y se centra en las fases de diseño e implementación del sistema 103

104 Modelos ágiles Modelos de propiedad Comercial: MSF MSF es la metodología empleada por Microsoft para el desarrollo de software. Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva; porque parte de la base de que no hay una estructura de procesos óptima para las necesidades de todos los entornos de desarrollo posibles. El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de desarrollo: MSF: PRINCIPIOS FUNDAMENTALES Fomento de la comunicación abierta. Trabajo en torno a una visión compartida. Apoderar a los integrantes del equipo ( empowerment ) Establecimiento de responsabilidades claras y compartidas. Centrar el objetivo en la entrega de valor para el negocio. Permanecer ágiles y esperar e cambio. Invertir en calidad. Aprender de la experiencia. 104

105 Modelos ágiles Modelos de propiedad Comercial: MSF Elementos que componen el modelo Principios fundamentales Principios básicos en los que se basa todo el modelo (los 8 de la pág. ant.) Modelos Mapas mentales de organización. Hay 2: De equipo y de procesos Disciplinas Conceptos clave Prácticas contrastadas Áreas de trabajo en las que se usan métodos determinados (Gestión de proyecto, de riesgos y de la mejora del talento) Ideas que dan soporte a los principios y disciplinas de MSF y se muestran a través de prácticas específicas contrastadas. Prácticas que han demostrado su efectividad en proyectos en diferentes condiciones de entornos reales Recomendaciones Prácticas opcionales, sugeridas por el modelo. 105

106 Modelos ágiles Modelos de propiedad Comercial: MSF Relación entre los componentes del modelo Este diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes de Microsoft Solutions Framework Principio Fundamental Modelo o Disciplina Concepto Clave Práctica Contrastada Recomendac. Aprender de las experiencias Modelo de procesos Disposición al aprendizaje Hitos de revisión Uso de facilitadores externos Permanecer ágil y esperar el cambio Gestión de riesgos Evaluación continua de riesgos Definir y monitorizar disparadores de riesgos Creación de una BD de riesgos Está relacionado En 2005, el desarrollo del nuevo producto de Microsoft Visual Studio 2005 Team System ha ganerado la evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas: Microsoft Solutions Framework (MSF) for Agile Software Development. Microsoft Solutions Framework (MSF) for CMMI Process Improvement. 106

107 Modelos ágiles Modelos de propiedad Comercial: RUP Rational Unified Process Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación de tareas y responsabilidades en las organizaciones de desarrollo de software. RUP es un modelo-producto desarrollado y mantenido por Racional Software, integrado en su conjunto de herramientas de desarrollo, y distribuido por IBM. RUP integra un conjunto de buenas prácticas para el desarrollo de software en un marco de procesos válido para un rango amplio de tipos de proyectos y organizaciones. RUP: Buenas Prácticas Desarrollo iterativo. Gestión de requisitos. Uso de arquitecturas basadas en componentes. Uso de técnicas de modelado visual. Verificación continua de la calidad. Gestión y control de cambios. 107

108 Modelos ágiles Modelos de propiedad Comercial: RUP Rational Unified Process: Visión estática En su visión estática, el modelo RUP está compuesto por: Roles: analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración. Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso. Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables ) Disciplinas: son contenedores empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas técnicas y 3 de soporte. Técnicas: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo. Soprte: gestión de proyecto, gestión de configuración y cambio, y entorno. Flujos de trabajo: son el pegamento de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles. 108

109 Modelos ágiles Modelos de propiedad Comercial: RUP Rational Unified Process: Visión dinámica En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo. Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP: 1.- Inicio. Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el hito de objetivo. 2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el hito de Arquitectura. 3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el hito del inicio de la capacidad operativa. 4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el hito de entrega del producto. 109

110 14.- Gestión de proyectos: formal y ágil 110

111 Cómo gestionar los proyectos de software Referentes de la gestión formal de proyectos Las principales referencias de la gestión formal de proyectos son las asociaciones: PMI (Project Management Institute) IPMA (International Project Management Association) Y la metodología: PRINCE2 (Projects in Controlled Environments) Gestión de proyectos IPMA se constituyó en 1965, PMI lo hizo en 1969, y PRINCE2 se comenzó a desarrollar en Forma inicial y evolución PMI e IPMA son organizaciones que han ido desarrollando estándares, métodos y modelos de certificación profesional ( Siguiendo un camino inverso, PRINCE2 no nace como asociación, sino como metodología alrededor de la cual se ha formado un grupo de desarrollo. Gestión formal de proyectos 111

112 Cómo gestionar los proyectos de software Referentes de la gestión formal de proyectos Ámbito global de la gestión formal Gestión de proyectos PMI E IPMA defienden que la gestión de proyectos comprende un cuerpo de conocimiento que debe ser profesionalizado, y que resulta válido y aplicable a los proyectos de cualquier industria: construcción, química, aeroespacial, TI, etc. Aunque en la actualidad también comparten esta visión, también en este caso el origen de PRINCE2 fue el contrario: su desarrollo inicial lo llevó a cabo la CCTA (Central Computer and Telecommunications Agency) del Gobierno Británico, para que sirviera como estándar en los proyectos de Tecnologías de la Información. Sin embargo, el ámbito de aplicación se fue ampliando y en su revisión de 1996 se le dio cobertura global para los proyectos de todas las industrias. 112

113 Cómo gestionar los proyectos de software Objeciones a la gestión formal de proyectos Los modelos ágiles para el desarrollo de software plantean objeciones a la teoría de la gestión formal de proyectos. Características específicas del software El software no resulta comparable a la materia prima de otras ingenierías. El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muy maleables. Por esta razón, resulta tendencioso comparar la construcción de un edificio, un avión, o un dispositivo de hardware con un sistema de software. A nadie se le ocurriría construir un proyecto de arquitectura con el método de prueba y error, levantando las plantas del edificio para luego demolerlas, o ampliarlas si no son como desea el cliente; o desarrollar una embarcación básica, para ir ampliando y modificando sus características, a medida que por el uso las van descubriendo los clientes. Sin embargo con el software esto es posible. Gestión de proyectos Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultar viables para los proyectos de software de determinadas características, pero que se apartan de los métodos formales de gestíón. Es posible un marco único y universal para la gestión de proyectos? 113

114 Cómo gestionar los proyectos de software Referentes de la gestión ágil de proyectos Las principales referencias de la gestión ágil de proyectos son: Scrum Rational Unified Process (RUP) Microsoft Solutions Framework (MSF) Características Scrum es un modelo ágil no centrado en prácticas de programación (como XP p. ej.), sino en prácticas de gestión. Por eso puede y suele combinarse Scrum junto con otro de prácticas técnicas. RUP. Rational Unified Process es un proceso iterativo para desarrollo de software creado por Rational Software (IBM). MSF es un marco de desarrollo que define procesos, principios, modelos, disciplinas, conceptos y prácticas contrastadas por Microsoft. No son modelos de procesos sino marcos de trabajo adaptables a las circunstancias de las organizaciones de los proyectos. Gestión ágil de proyectos Gestión de proyectos 114

115 Cómo gestionar los proyectos de software Gestión de proyectos Fundamentos de la cultura ágil con problemas de encaje en la gestión formal de proyectos Entrega temprana de software operativo. Trabajo con incertidumbre de requisitos, y apertura constante a cambios en los mismos. Entregas frecuentes de funcionalidades operativas. Preferencia de la comunicación verbal sobre otros medios. Infravaloración de métricas teóricas y formales, considerando como válida el software que funciona. Auto-organización de equipos. La gestión formal se asienta sobre la dirección del proyecto sobre un plan general con visibilidad y ámbito de certidumbre hasta el final del proyecto. La planificación de la gestión ágil es informal (algunos modelos llegan a prohibir el uso de diagramas de Gannt), y solo cubre el ciclo de software que se está elaborando (generalmente 1 mes). La gestión formal hace hincapié en la necesidad de conocer con el mayor detalle los requisitos desde el principio para dar rigor al plan del proyecto. La gestión ágil 115

116 Gestión de proyectos Desavenencias Gestión formal Trabajo y gestión guiada por un plan general del proyecto que comprende todo su ciclo de desarrollo. Conocimiento detallado de los requisitos antes de comenzar el diseño del proyecto Gestión ágil La planificación del trabajo sólo comprende el ciclo en el que se está trabajando (normalmente 30 días). Algunos modelos ágiles prohíben el uso de gráficos de Gantt Descubrimiento progresivo de requisitos, e incorporación de cambios en cualquier iteración del desarrollo Hacerlo bien a la primera. Evitar la re-codificación y el re-trabajo que supone una pérdida de eficiencia. Refactorización de código como modelo de trabajo compatible con el punto anterior. Comunicación formal según el plan de comunicación del proyecto Comunicación directa entre los integrantes del equipo (incluidos cliente y usuarios) prefiriendo la verbal directa. Gestión de equipos y personas centralizada en el gestor del proyecto Equipos auto-gestionados. 116

117 Gestión de proyectos Incompatibilidades Gestión formal Desarrollo de sistemas innovadores, en entornos no conocidos en los que no resulta posible conocer los requisitos con detalle al empezar, y el grado de inestabilidad de requisitos resulta elevado. Sin la comunicación y revisión próxima del cliente y con modelos formales de gestión de requisitos peligra el presupuesto y la calidad del proyecto. Gestión ágil Desarrollo de sistemas poco innovadores en entornos conocidos en los que resulta posible conocer con detalle los requisitos desde el principio. La gestión ágil conlleva ciclos de prototipado evolutivo cuando resultarían más eficientes modelos de cascada. Equipos pequeños en entornos y mercados ágiles en los que el tiempo de salida al mercado es importante. Los modelos formales implican formalidades que aportan muy pocos beneficios a este tipo de proyectos. Equipos grandes, físicamente dispersos (verificación independiente, varios representantes de los intereses de cliente: sponsor, usuarios departamentales, varios proveedores trabajando en el proyecto, etc.). Sin un nivel formal de comunicación y coordinación se incrementan los riesgos del proyecto. Contratos centrados en producto con funcionalidades, costes y fecha de entrega cerrados. Sin conocer con certeza los requisitos y sin hacer una planificación global sobre ellos no es posible hacer ningún cálculo fiable. 117

118 Gestión formal de proyectos 118

119 Gestión formal de proyectos Operaciones y proyectos Las empresas y las organizaciones en general llevan a cabo su trabajo bajo la forma de proyectos o de operaciones. Características comunes a las operaciones y los proyectos Son realizados por personas Disponen de recursos limitados Su ejecución se controla y responde a una planificación. Diferencias entre operaciones y proyectos Los proyectos son temporales y únicos, mientras que las operaciones realizan siempre los mismos procesos de forma continua. 119

120 Gestión formal de proyectos Proyectos Características de los proyectos Son realizados por personas Disponen de recursos limitados Su ejecución se controla y responde a una planificación. Tienen un inicio y fin definidos Tienen como finalidad producir un producto o servicio único Ciclo de vida planificado Temporalidad Cada proyecto tiene un inicio y fin definidos. El fin se alcanza cuando se consiguen los objetivos del proyecto por razones objetivas se decide abortar su ejecución. Producto único La finalidad del proyecto es realizar algo que no se piensa repetir de forma sistemática. Ciclo de vida planificado Característica derivada de la temporalidad y el objetivo único. El producto o servicio se lleva a cabo de forma incremental siguiendo unos pasos planificados que constituyen el ciclo de vida del desarrollo. 120

121 Gestión formal de proyectos Áreas de conocimiento de la gestión de proyectos Gestión de la integración del proyecto Desarrollo del plan de proyecto Ejecución del plan de proyecto Control integrado del cambio Gestión del ámbito del proyecto Inicio Planificación del ámbito Definición del ámbito Verificación del ámbito Control de cambio del ámbito Gestión de agenda Definición de la actividad Secuencia de la actividad Estimación de tiempos Desarrollo de la agenda Control de la agenda Gestión de costes Plan de recursos Estimación de costes Presupuesto Control de costes Gestión de la calidad del proyecto Plan de calidad Aseguramiento de la calidad Control de calidad Gestión de los recursos humanos del proyecto Plan de organización Incorporación de personas Desarrollo del equipo Gestión de las comunicaciones del proyecto Plan de comunicaciones Distribución de la información Informes de eficiencia Cierre administrativo Gestión de riesgos delproyecto Plan de riesgos Identificación de riesgos Análisis cuantitativo de riesgos Análisis cualitativo de riesgos Plan de exposición de riesgos Monitorización y control de ries. Gestión de compras Plan de necesidades Plan de compras Compras Selección de proveedores Contratación administrativa Cierre de contrato Fuente: PMBOK 121

122 Gestión formal de proyectos Relación de la G. de proyectos con otras áreas de gestión Gestión de proyectos Gestión y administración Negocio del proyecto El principal conocimiento que se necesita para gestionar proyectos es exclusivo de la gestión de proyectos, pero para llevar a cabo la gestión debe complementarse con conocimientos que pertenecen al área de management en general y con conocimientos específicos del negocio al que va a servir el proyecto. 122

123 Gestión de proyectos: principales conceptos y prácticas WBS Work Breakdown Structure: Estructura de las tareas en las que se descompone el proyecto. Gestión formal de proyectos Planificando el proyecto: Tipos de dependencias entre tareas FC (de Fin a Comienzo) la más habitual CC (de Comienzo a Comienzo) FF (de Fin a Fin) CF (de Comienzo a Fin) suele ser problemática 123

124 Gestión de proyectos: principales conceptos y prácticas Tipos de dependencias entre tareas Gestión formal de proyectos Diseño Web Desarrollo Web Análisis Integración Implantación Diseño Admin Desarrollo Admin 124

125 Gestión de proyectos: principales conceptos y prácticas Asignación de recursos y personas a las tareas Gestión formal de proyectos Optimización Conceptos clave para la optimización del proyecto Paso adelante Paso atrás Ruta crítica Reasignación de recursos 125

126 Gestión de proyectos: principales conceptos y prácticas Paso adelante Estimar la fecha más temprana para comenzar y terminar cada tarea Comenzando por la fecha de inicio del proyecto Estima la fecha de fin más optimista Gestión formal de proyectos 126

127 Gestión de proyectos: principales conceptos y prácticas Paso atrás Gestión formal de proyectos Estimar cuales pueden ser las fechas mas retrasadas para el inicio y fin de cada tarea sin causar retrasos en el proyecto. Se puede estimar con la fecha de entrega calculada por paso adelante, o con la fecha de entrega deseada Al calcular con la fecha de entrega por paso adelante se debe obtener a la misma fecha de inicio. Al calcular con la fecha de entrega esperada se obtiene la fecha límite para comenzar el proyecto 127

128 Gestión de proyectos: principales conceptos y prácticas Demora total Gestión formal de proyectos Diferencia entre las fechas calculadas con paso adelante y paso atrás para cada tarea Retraso máximo para una tarea sin retrasar sin afectar a la fecha de entrega del proyecto La demora total se comparte entre las tareas en una cadena. Si se emplea en una tarea ya no queda disponible para otras. 128

129 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Demora permisible Tiempo que puede retrasarse una tarea sin afectar a la agenda del proyecto Algunos programas como MS Project pueden hacer los cálculos de forma automática 129

130 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Ruta crítica Es la ruta más larga en el plan del proyecto, y delimita la fecha de entrega más temprana posible Actividades críticas Actividades que están en la ruta crítica y que no tienen demora permisible. Sus retrasos afectan al proyecto 130

131 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Optimización de agenda 1.- Dirigir el esfuerzo de trabajo sobre las actividades de la ruta crítica 2.- Revisar la asignación de personas 131

132 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Optimización de agenda 3.- Modificar la asignación 4.- Redistribuir a las personas 132

133 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Optimización de agenda Nueva ruta crítica Asignación mas eficiente 133

134 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Optimización de agenda Reducción de la demora total Recomendaciones Duplicar la asignación de personas no significa la mitad de tiempo Menos tiempo de entrega no significa menor presupuesto Cada tarea debe tener un resultado cuantificable para comprobar que se ha realizado Usar el sentido común 134

135 GESTIÓN DE RIESGOS Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos Gestión formal de proyectos IDENTIFICACIÓN ANÁLISIS TRATAMIENTO Plan de gestión de riesgos IEEE Std P

136 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos Causas y consecuencias Causa CONSECUENCIA CONSECUENCIA consecuencia consecuencia CONSECUENCIA consecuencia Requisitos crecientes Más horas Presión equipo Desbordamiento costes Incumplimiento fechas Más errores peor calidad Desmotivación menor eficiencia 136

137 Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos Gestión formal de proyectos La gestión de proyectos incorpora métodos sistemáticos de control de riesgos con soluciones genéricas. RIESGO TIPO Desbordamiento de costes Errores en los productos Procesos de desarrollo incontrolados Producto incontrolado Problemas de comunicación SOLUCIÓN TIPO Verificación / validación de requisitos y diseño Verificación / validación pruebas en el desarrollo Desarrollo sobre procesos definidos Gestión de la configuración SQA Normalización document. Comunicación, resolución prob. Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, el presupuesto y el esfuerzo para reducir las probabilidades y el impacto de los riesgos, entonces se puede considerar que hay una GESTIÓN DE RIESGOS. Cuando los riesgos se conocen y tratan con el estándar propio de la gestión de proyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DEL PROYECTO. 137

138 Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos: IDENTIFICACIÓN Método sistemático y organizado para descubrir los riesgos Pueden identificarse directa o indirectamente. DIRECTA: Identificando los orígenes (causas) que pueden ser: Gestión formal de proyectos Programación: agendas impuestas, excesivas restricciones contractuales, riesgos políticos Requisitos: inconsistencias, TBD s, crecientes Técnicos: requisitos de rendimiento, seguridad, plataforma tecnológica Calidad: deficiencias en las prácticas de desarrollo Logísticos: mantenibilidad, operación, disponibilidad (el impacto se produce cuando el sistema está en uso. Despliegue: integración, instalación, distribución INDIERECTA: Identificando el impacto y buscando las causas. Las áreas de impacto son: Agenda Coste Calidad Operación 138

139 Gestión formal de proyectos Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos: IDENTIFICACIÓN Riesgos de agenda Técnicas que ayudan a identificarlos son: CPM, PERT, Simulaciones de Montecarlo RED DE ACTIVIDAD: F 5 (2) (1) J A 1 2 (1) C (3) 3 D (1) E H (1) K L (1) (1) B (6) 4 G (5) I 6 7 (2) Letras = Actividades; Números = hitos, (x) = duración 139

140 Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos: IDENTIFICACIÓN Riesgos de costes Los principales factores que influyen en los riesgos de costes son: Incertidumbre en los requisito Estimación incorrecta de costes Requisitos crecientes Presión de agendas Costes irrazonables Gestión formal de proyectos Riesgos de requisitos Las principales causas de riesgo por los requisitos son: Requisitos incorrectos Requisitos incompletos Requisitos inconsistentes Requisitos de dificultad imprevista Requisitos imposibles Requisitos ambiguos Volatilidad 140

141 Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos: ANÁLISIS Examen de los riesgos para determinar sus dos características principales: Probabilidad Impacto Gestión formal de proyectos El análisis de los riesgos es una tarea de ejecución cíclica que debe realizarse y revisarse periódicamente de forma adecuada a las características del proyecto. El resultado del análisis se plasma en un registro de los riesgos con la identificación de su descripción y características, con apoyo de herramientas para su consulta, revisión, priorización, etc. 141

142 Gestión de proyectos: principales conceptos y prácticas Gestión de riesgos: TRATAMIENTO Gestión formal de proyectos El tratamiento de los riesgos es el tercer paso del proceso de gestión de riesgos y comprende la implementación de métodos y técnicas para reducir el impacto o la probabilidad. Las técnicas se clasifican en 5 categorías en función de su finalidad: 1.- Evitación del riesgo. 2.- Aceptación o asunción del riesgo. 3.- Control del problema (prevención). 4.- Transferencia del riesgo. 5.- Refinamiento del conocimiento. 142

143 Gestión ágil de proyectos Scrum 143

144 Gestión ágil de proyectos: Scrum Introducción Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. En 1996 se definió por primera vez un patrón para aplicar esos principios de desarrollo en campos de scrum al software. Esta fue la primera definición de un patrón Scrum aplicado al software, diseñada por Jeff Sutherland y Ken Schwaber y presentada en OOPSLA 96 Esta presentación describe esa primera definición de

145 Gestión ágil de proyectos: Scrum La esencia de Scrum Al iniciar cada iteración, el equipo revisa el trabajo pendiente del proyecto y selecciona la parte que terminará como un incremento de funcionalidad incorporado al software al terminar la iteración. Al final de la iteración el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto. El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad. Roles Scrum tiene una estructura muy simple. Todas las responsabilidades del proyecto se reparten en 3 roles: Propietario del producto Equipo Scrum Master 145

146 Gestión ágil de proyectos: Scrum Scrum Scrum es un método ágil de gestión de proyectos desarrollado por Ken Schwaber y Mike Beedle. Se basa en los principios ágiles: Colaboración estrecha con el cliente. Predisposición y respuesta al cambio Prefiere el conocimiento tácito de las personas al explícito de los procesos Desarrollo incremental con entregas funcionales frecuentes Comunicación verbal directa entre los implicados en el proyecto Motivación y responsabilidad de los equipos por la auto-gestión, auto-organización y compromiso. Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto. 146

147 Gestión ágil de proyectos: Scrum Roles Propietario del producto Equipo Representa a todos los interesados en el producto final. Sus áreas de responsabilidad son: Financiación del proyecto Requisitos del sistema Retorno de la inversión del proyecto Lanzamiento del proyecto Responsable de transformar el Backlog de la iteración en un incremento de la funcionalidad del software Auto-gestionado Auto-organizado Multi-funcional Scrum Master Responsable del proceso Scrum Formación y entrenamiento del proceso Incorporación de Scrum en la cultura de la empresa Garantía de cumplimiento de roles y responsabilidad 147

148 Gestión ágil de proyectos: Scrum Roles: gallinas y cerdos Una gallina y un cerdo paseaban por la carretera. La gallina dijo al cerdo: Quieres abrir un restaurante conmigo. El cerdo consideró la propuesta y respondió: Sí, me gustaría. Y cómo lo llamaríamos?. La gallina respondió: Huevos con beicon. El cerdo se detuvo, hizo una pausa y contestó: Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada. Scrum diferencia claramente entre estos dos grupos para garantizar que quienes tienen la responsabilidad tienen también la autoridad necesaria para poder lograr el éxito, y que quienes no tienen la responsabilidad no producen interferencias innecesarias COMPROMETIDOS EN EL PROYECTO Dueño del producto Equipo Scrum Master IMPLICADOS EN EL PROYECTO Marketing Comercial Etc. 148

149 Gestión ágil de proyectos: Scrum El flujo de Scrum Sprint Backlog Nueva funcionalidad Product Backlog seleccionado Product Backlog Requisitos priorizados Visión: ROI versiones hitos Fuente: Agile Project Management with Scrum Ken Schwaber 149

150 Gestión ágil de proyectos: Scrum El flujo de Scrum 150