modelos para calidadimp

8/7/2019 Modelos para calidadimp

http://slidepdf.com/reader/full/modelos-para-calidadimp 1/72

1

1.- Agilidad y procesos1.- Agilidad y procesos



2

Agilidad y procesos

Visión simplificada de modelos formales y ágiles

1959MIL-Q 9858

1979BS 5750

1987 ISO 9000

1997

TickIT1991

ISO 9000-3Adaptaciones

parasoftw.

1995

ISO 122071995

Proy. SPICE

1993

CMM-SWModelosespecíf

icos

parasoftware.

2003-05

ISO 15504

2001

CMMI

ModelosCMM

TR 15504Modelosy

es

tándares

formales

dec

alidad

Modelos genéricos Modelos para software

Trillium

Bootstrap

DSDM

SCRUM

CRYSTALXP

ASD

PP

AM

ISD

19952000

ManifiestoÁgil

Técnicasym

étod

os

ágiles



3

Modelos formales: CMMI

CMM (Capability Maturity Model)

Deficiencias en las metodologías ⇒ Incapacidad para manejar elproceso de software

En 1986, SEI (Software Engineering Institute): marco de trabajosobre madurez de procesos

En 1991, SEI desarrolló Capability Maturity Model (CMM)

Conjunto de prácticas recomendadas en determinadas áreas clave deproceso 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



4


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

Organizaciones de software maduras / inmadudas



5


DoD (Departamento de Defensa de los Estados Unidos), SEI (SoftwareEngineering 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

Proyecto CMMI



6


CMMI-SE/SW

Staged

Representatio

n

CMMI-SE/SW

Continuous

Representation

Modelo combinadoSystem Engineering/SoftwareEngineering

Aplicable:– Sólo a proyectos de software

engineering– Sólo a proyectos de system

engineering– Ambos

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

Modelos CMMI

¿Continua o escalonada?




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 decada una de las representaciones.

Seleccionar una única representación se planteaba como algo “toohard”.

Compromiso: Inicialmente soportar dos representaciones delmodelo con contenidos equivalentes.

¿Por qué dos representaciones del modelo?




. . .para un conjunto deáreas de proceso establecido

Escalonado

ML 1

ML2

ML3

ML4

ML5

. . .para un área de proceso

o un conjunto de áreas de proceso

Continuo

PA PA

Capac

idad

0

1

2

3

4

5

PA

Un modelo, dos representaciones




Capacidad es un atributo que se aplica a los procesos y define laeficacia 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.

ML 1

ML2

ML3

ML4

ML5

0

1

2

3

4

5

Capacidad y madurez




0 – IncompletoLos procesos no se realizan, o no consiguen sus objetivos

1 – EjecutadoLos procesos se ejecutan y se logran los objetivos específicos del área

2 – GestionadoLos procesos que además de considerarse “ejecutados” son también planificados,revisados y evaluados para comprobar que cumplen los requisitos

3 – DefinidoLos procesos que además de considerarse “gestionados” se ajustan al conjunto deprocesos estándar conforme a las líneas directivas de la organización

4 – Gestión cuantificadaProcesos “definidos” que son controlados utilizando técnicas estadísticas u otrastécnicas cuantitativas

5 – OptimizadoProcesos “gestionados cuantificadamente” que son cambiados y adaptados paraconseguir objetivos relevantes de negocio

Niveles de capacidad




Los valores describen “cómo de bien” se realiza el proceso (nivelde capacidad del proceso).

C a p a c id a d

Procesos

AreaProceso 1

AreaProceso n

AreaProceso 2

AreaProceso 3

Proceso bien ejecutado ymejorado continuamente

Proceso no ejecutado

Dimensión de la capacidad




1 – InicialControl deficiente e impredecibilidad de los resultados

2 – GestionadoEs posible obtener niveles de calidad previamente alcanzados

3 – DefinidoLos procesos realizados se encuentran normalizados, son conocidos ycomprendidos

4 – Gestionado cuantitativamente

Los procesos incluyen indicadores de medición y control 5 – Optimizado

Centralización en la mejora de los procesos

Niveles de madurez



13


Proceso imprevisible, pococontrolado y reactivo

Proceso caracterizadopara los proyectos y amenudo reactivo

Proceso caracterizadopara la organización yproactivo

Proceso medido

y controlado

Centrado en la mejora deprocesos

Optimizado

Gestionadocuantitativamente

Definido

Inicial

Gestionado

1

2

3

4

5

Dimensión de la madurez



14


CMMI recoge prácticas para 22 áreas de procesos

Las áreas de procesos agrupan a las actividades necesarias parala 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 paralograr cada nivel de calidad

El modelo en su representación continua las clasifica según a lacategoría que pertenecen: Gestión de proyectos, ingeniería,soporte y gestión de procesos

Áreas de procesos



15


1 INICIAL

2 GESTIONADO

3 DEFINIDO

4 GESTIONADOCUANTITATIVAMENTE

5 OPTIMIZADO

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

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

Gestión cuantificada de proyectos

Rendimiento de los procesos de la organización

Innovación y desarrollo

NIVEL DE MADUREZ ÁREAS DE PROCESO

Áreas de procesos en la representación escalonada



16


GESTIÓN DE PROCESOS

INGENIERÍA

SOPORTE

GESTIÓN DE PROYECTOS

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

Desarrollo de requisitos

Gestión de requisitos

Soluciones técnicas

Integración de producto

Verificación

Validación

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

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

CATEGORÍA ÁREAS DE PROCESO

Áreas de procesos en la representación continua



17


Cómo usar el modelo

Área de procesoConjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir unconjunto de objetivos.

Componentes requeridos

Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debealcanzar en ese nivel de capacidad.El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en laejecución del área de proceso

Objetivo genérico

Objetivo específico

Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades quedescriben que se debe implementar para satisfacer el propósito del área de proceso



18



Componentes esperados

Una practica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamientoy el control de cualquier proceso.

Práctica genérica

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ósitoNotas introductoriasReferencias

Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportarinformación adicional o más detalladaNombresTablas de relaciones práctica-objetivoPrácticas



19



Componentes informativosPropósitoNotas introductoriasReferencias

Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportarinformación adicional o más detalladaNombresTablas de relaciones práctica-objetivoPrácticasProductos típicosSubprácticas

Una subpractica es una descripción detallada que sirve como guía para la interpretación de unapractica genérica o especificaAmpliaciones de disciplina

Las ampliaciones contienen información relevante de una disciplina particular y relacionada con unapractica especifica.

Elaboraciones de prácticas genéricasUna elaboración de una practica genérica es una guía de cómo la practica genérica debe aplicarse alárea de proceso.



20


Área de proceso

Propósito

Notas

Referencias

Objetivos específicos

Objetivos genéricos

Mapa del documento



21


R. Metas-Practicas

Practicas especificas

Nombres

Mapa del documento



22


Productos de

trabajo

Practicas genericas

Elaboraciones

Notas

Subpracticas

Mapa del documento



23


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 deproyectos, 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

Áreas de proceso



24

Áreas de proceso

Gestión de 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

Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con laplanificación, monitorización y control del proyecto.Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con laplanificación, monitorización y control del proyecto.




25

ISO/IEC 15504: Origen

En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajopara el desarrollo de un modelo que fuera la base de un futuro estándarinternacional para la evaluación de los procesos del ciclo de vida del software.

Este trabajo recibió el nombre de proyecto SPICE (Software ProcessImprovement and Capability dEtermination), y en junio de 1995, con lapublicación de su primer borrador, desde ISO fueron invitadas diferentes

organizaciones para aplicarlo y valorar sus resultados.

Proyecto SPICE

Proyecto -> Instrucción Técnica -> Estándar

Modelos formales: ISO/IEC 15504

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 15504.

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 15504 durante el periodo 2003-2005.Ámbito de aplicación

Cualquier organización de software que quiera establecer y mejorar su capacidad enadquisició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.



26


Conceptosy guía de

introducción

Guia para det.capacidad deproveedores

Realizaciónde

evaluación

Guía de

evaluación

Guia decapacitación de

evaluadores

Vocabulario

Guíapara mejorade procesos

Modelo de ref.para procesosy capacidad

Modelo deevaluación

y guía de indic.

P1P1 P9P9

P7P7

P8P8 P6P6

P3P3 P4P4

P2P2 P5P5

Estructura



27


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 12207 Information Technology Software Life CycleProcesses

Dimensiones del modeloEl modelo tiene una arquitectura basada en dos dimensiones:

Dimensión de procesoCaracterizada por las declaraciones del propósito de un proceso,que son objetivos esenciales mensurables de un proceso.

Dimensión de capacidad de procesoCaracterizada por una serie de atributos de proceso, aplicables acualquier proceso, que representan características mensurablesnecesarias para gestionar un proceso y mejorar su capacidad.



28


Características

Dimensión de proceso

Agrupa los procesos en tres grupos correspondientes a los procesos delciclo de vida que contienen cinco categorías de acuerdo al tipo deactividad.

Procesos primarios

CUS: Cliente – Proveedor

ENG: Ingeniería

Procesos organizacionales MAN: Gestión

ORG: Organización

Procesos de soporte

SUP: Soporte



29



CUS: Cliente - proveedor

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

La categoría CUS está formada por procesos que afectan directamente alcliente, soportan el desarrollo y la transición del software al cliente ypermiten la correcta operación y uso del producto y/o servicio de software.



30



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 elsistema 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



31



SUP: Soporte

La categoría SUP está formada por procesos que dan soporte al resto deprocesos (incluidos los SUP), en distintos puntos del ciclo de vida delsoftware. 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



33



ORG: Organización

La categoría ORG está formada por procesos que establecen los objetivosde 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



34



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

TipoHay 5 tipos de proceso. 3 de primer nivel (básico, extendido y nuevo) y 2 desegundo nivel (componente, componente extendido)

PropósitoPárrafo que establece el propósito del proceso indicando los objetivosglobales de su ejecución.

SalidasLista de resultados observables de la implementación exitosa del proceso

Notas



35


Dimensión de capacidad

Def ine una escala de medida para determinar la capacidad de cualquier proceso

Consta de seis niveles de capacidadNivel 0 IncompletoNivel 1 RealizadoNivel 2 GestionadoNivel 3 EstablecidoNivel 4 Predecible

Nivel 5 En optimización ...y un conjunto de atributos de procesos asociados al nivel de

capacidad

Capacidad de proceso: rango de resultados que espera obtenerseal seguir el proceso.

Capacidad de proceso: rango de resultados que espera obtenerseal seguir el proceso.



36


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



37


Dimensión de capacidadMedición de atributos

Los atributos de un proceso se evalúan con N (Not), P (Partially), L(Largely) y F (Fully), siendo:

NNNo alcanzado (0% a 15%).Escasa o ninguna evidencia de la consecución del atributo.No alcanzado (0% a 15%).Escasa o ninguna evidencia de la consecución del atributo.

PPParcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndelatributo. Algunos aspectos de la consecución pueden serimpredecibles.

Parcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndelatributo. Algunos aspectos de la consecución pueden serimpredecibles.

LL

Ampliamente alcanzado (51% a 85%).Evidencia de un enfoque sistemático y de una consecuciónsignificativa del atributo.La realización del proceso puede variar en algunas áreas.

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.

FF

Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de laconsecución plena del atributo.

Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de laconsecución plena del atributo.



38

En marzo de 2001, 17 críticos de estos modelos, convocados por KentBeck, que acababa de definir una nueva metodología denominada Extreme

Programming, se reunieron en Salt Lake City para discutir sobre losmodelos de desarrollo de software.

En la reunión se acuñó el término “Métodos Ágiles” para definir aaquellos 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 deplanificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que haquedado denominado como “Manifiesto Ágil”, que compendia el espíritu enel que se basan estos métodos.

Aunque como se verá más adelante, en la actualidad hay aproximacionesque combinan lo mejor de ambos enfoques (formal y ágil), hasta 2005, encada lado sus defensores adoptaron posturas radicales, quizá másocupadas en descalificar a la contraria que en estudiarla y conocerla paramejorar la propia.

Origen de los “métodos ágiles”Manifiesto ágil (2001)

Agilidad y procesos

Agilidad y procesos

Manifiesto ágil (2001)



39

Agilidad y procesos

Estamos poniendo al descubierto mejores métodos paradesarrollar software, haciéndolo y ayudando a otros aque lo hagan. Con este trabajo hemos llegado a valorar:

A los individuos y suinteracción

de los procesos y lasherramientas

porencimaEl software que

funciona

de la documentación

exhaustiva

por

encimaLa colaboración con elcliente

la negociacióncontractual

porencimaLa respuesta al

cambioseguimiento de unplan

porencima

Aunque hay valor en los elementos de la derecha,valoramos más los de la izquierda

Kent Beck, Mike Beedle, Arie van Bennekum, AlistairCockburn, Ward Cunningham, Martin Fowler, James

Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, JonKern, Brian Marick, Robert C. Martin, Steve Mellor, Ken

Schwaber, Jeff Sutherland, Dave Thomashttp://agilemanifesto.org/

g ( )



40

3.- Entregar con frecuencia software que funcione, enperiodos de un par de semanas hasta un par de

meses, con preferencia en los periodos breves.

3.- Entregar con frecuencia software que funcione, enperiodos de un par de semanas hasta un par de

meses, con preferencia en los periodos breves.

2.- Son bienvenidos los requisitos cambiantes,

incluso si llegan tarde al desarrollo. Los procesoságiles se doblegan al cambio como ventajacompetitiva para el cliente.

2.- Son bienvenidos los requisitos cambiantes,

incluso si llegan tarde al desarrollo. Los procesoságiles se doblegan al cambio como ventajacompetitiva para el cliente.

1.- Nuestra principal prioridad es satisfacer al cliente através de la entrega temprana y continua de softwarede valor.

1.- Nuestra principal prioridad es satisfacer al cliente através de la entrega temprana y continua de softwarede valor.

12 principios del manifiesto ágil

4.- Las personas del negocio y los desarrolladoresdeben trabajar juntos de forma cotidiana a través delproyecto.

4.- Las personas del negocio y los desarrolladoresdeben trabajar juntos de forma cotidiana a través delproyecto.

Agilidad y procesos



41

8.- Los procesos ágiles promueven el desarrollosostenido. Los patrocinadores, desarrolladores yusuarios deben mantener un ritmo constante de formaindefinida.

8.- Los procesos ágiles promueven el desarrollosostenido. Los patrocinadores, desarrolladores yusuarios deben mantener un ritmo constante de formaindefinida.

7.- El software que funciona es la principal medida del

progreso.

7.- El software que funciona es la principal medida del

progreso.

6.- La forma más eficiente y efectiva de

comunicar información de ida y vuelta dentrode un equipo de desarrollo es mediante laconversación cara a cara.

6.- La forma más eficiente y efectiva de

comunicar información de ida y vuelta dentrode un equipo de desarrollo es mediante laconversación cara a cara.

5.- Construcción de proyectos en torno a individuosmotivados, dándoles la oportunidad y el respaldo quenecesitan y procurándoles confianza para que realicenla tarea.

5.- Construcción de proyectos en torno a individuosmotivados, dándoles la oportunidad y el respaldo quenecesitan y procurándoles confianza para que realicenla tarea.


Agilidad y procesos



42

12.- En intervalos regulares, el equipo reflexiona sobrela forma de ser más efectivo y ajusta su conducta enconsecuencia.

12.- En intervalos regulares, el equipo reflexiona sobrela forma de ser más efectivo y ajusta su conducta enconsecuencia.

11.- Las mejores arquitecturas, requisitos y diseñosemergen de equipos que se auto-organizan.

11.- Las mejores arquitecturas, requisitos y diseños

emergen de equipos que se auto-organizan.

10.- La simplicidad como arte de maximizar lacantidad de trabajo que se hace, es esencial.10.- La simplicidad como arte de maximizar lacantidad de trabajo que se hace, es esencial.

9.- La atención continua a la excelencia técnicaenaltece la agilidad.9.- La atención continua a la excelencia técnicaenaltece la agilidad.


Agilidad y procesos



43

3.- Modelos ágiles3.- Modelos ágiles



44

Modelos ágiles

Ubicación en el panorama general de modelos y procesos

1959

MIL-Q 98581979

BS 57501987

ISO 9000

1997

TickIT1991

ISO 9000-3Adapta

ciones

paras

oftw.

1995

ISO 122071995

Proy. SPICE

1993

CMM-SWModelosespecíf

icos

parasoftware.

2003-05

ISO 15504

2001

CMMI

ModelosCMM

TR 15504Modelosyes

tándares

decalidad

Modelos genéricos Modelos para software

Trillium

Bootstrap

DSDM

SCRUM

CRYSTAL

XP

ASD

PP

AM

ISD

19952000

Manifiesto

Ágil

Técnicasym

étodos

ágiles



45

DSDM: Dynamic Systems Development Method

Modelos ágiles

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 unmodelo DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 demadurez.

Sin embargo los aspectos que DSDM reprocha a CMM son:

Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo quefunciona 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 ennuestra 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ónestrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos dedesarrollo incremental y entregas evolutivas.

DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte ymantenimiento y se autodefine como un marco de trabajo para desarrollo rápido más que como unmétodo específico para el desarrollo de sistemas.



46

eXtreme Programming (XP)Modelos ágiles

Este es el método que más popularidad ha alcanzado entre lasmetodologí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 esposible desarrollar software de gran calidad a pesar, o inclusocomo consecuencia del cambio continuo. Su principal asunción es

que con un poco de planificación, un poco de codificación y unaspocas pruebas se puede decidir si se está siguiendo un caminoacertado o equivocado, evitando así tener que echar marcha atrásdemasiado tarde.

Valores que inspiran XP

FEEDBACK CORAJE COMUNICACIÓNSIMPLICIDAD



47

eXtreme Programming (XP)

Modelos ágiles

XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente seintegra en el equipo para establecer prioridades y resolver dudas. De esta forma ve elavance día a día, y es posible ajustar la agenda y las funcionalidades de formaconsecuente

Comunicación

Una metodología basada en el desarrollo incremental de pequeñaspartes, con entregas y pruebas frecuentes y continuas, proporcionaun flujo de retro-información valioso para detectar los problemas odesviaciones.

De esta forma fallos se localizan muy pronto.

La planificación no puede evitar algunos errores, que sólo seevidencian al desarrollar el sistema.

La retro-información es la herramienta que permite reajustarla agenda y los planes.

Feedback rápido y continuo



48


Modelos ágiles

La simplicidad consiste en desarrollar sólo el sistema que realmente senecesita. Implica resolver en cada momento sólo las necesidades actuales.

Con este principio de simplicidad, junto con la comunicación y el feedbackresulta más fácil conocer las necesidades reales

Simplicidad

El coraje implica saber tomar decisiones difíciles. Reparar un error

cuando se detecta. Mejorar el código siempre que tras el feedbacky las sucesivas iteraciones se manifieste susceptible de mejora.

Tratar rápidamente con el cliente los desajustes de agendas paradecidir qué partes y cuándo se van a entregar.

Coraje

Los costes y la complejidad de predecir el futuro son muy elevados, y lamejor forma de acertar es esperar al futuro.Los costes y la complejidad de predecir el futuro son muy elevados, y lamejor forma de acertar es esperar al futuro.




49


Modelos ágiles

XP no es un modelo de procesos ni un marco de trabajo, sino unconjunto de 12 prácticas que se complementan unas a otras y deben

implementarse en un entorno de desarrollo cuya cultura se base enlos cuatro valores citados

Las 12 prácticas de XP

PRÁCTICAS DE CODIFICACIÓNPRÁCTICAS DE CODIFICACIÓN1.- 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ésdel código.

4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código conclaridad.

PRÁCTICAS DE DESARROLLOPRÁCTICAS DE DESARROLLO1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que elcódigo se comporta según lo esperado.

2.- Programación por parejas, para incrementar el conocimiento, la experiencia ylas ideas.

3.- Asumir la propiedad colectiva del código, para que todo el equipo searesponsable de él.

4.- Integración continua, para reducir el impacto de la incorporación de nuevasfuncionalidades.



50


Modelos ágiles

Las 12 prácticas de XP

PRÁCTICAS DE NEGOCIOPRÁ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 agendael trabajo más importante.

3.- Entregas regulares y frecuentes para satisfacer la inversióndel cliente.

4.- Ritmo de trabajo sostenible, para terminar la jornadacansado pero no agotado.

Scrum



51

Scrum

Modelos ágiles

No es propiamente un método o metodología de desarrollo, e implantarlo comotal resulta insuficiente.

Scrum define métodos de gestión y control para complementar la aplicación deotros 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 agregarlestrabajo extra.

Reuniones diarias en las que los miembros del equipo se plantean3 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 finalde las cuales se presenta el resultado a los externos del equipo dedesarrollo, y se realiza una planificación de la siguiente iteración, guiada

por cliente.



52

Scrum

Modelos ágiles

Otros métodos ágiles



53

Modelos ágiles


Familia de métodos Crystal

La familia de metodologías Crystal ofrece diferentes métodos paraseleccionar el más apropiado para cada proyecto.

Crystal identifica con colores diferentes cada método, y su elección debe serconsecuencia del tamaño y criticidad del proyecto, de forma que los demayor tamaño, o aquellos en los que la presencia de errores odesbordamiento de agendas implique consecuencias graves, deben adoptarmetodologí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écnicaspropias de las metodologías ágiles.

No se trata de una metodología, sino de la implantación de unacultura en la empresa, basada en la adaptabilidad.




54

Modelos á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 solucionarlos problemas cotidianos

AM (Agile Modeling)

Agile Modeling es la presentación de un nuevo enfoque para realizar elmodelado 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 paralas situaciones que requieren ciclos de desarrollo muy breves conentregas 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.Elpunto de referencia son las características que debe reunir el software, y secentra en las fases de diseño e implementación del sistema



55

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 paraadaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodologíaprescriptiva; porque parte de la base de que no hay una estructura de procesos óptima para lasnecesidades de todos los entornos de desarrollo posibles.

El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entornode desarrollo:

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.

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.

MSF: PRINCIPIOS FUNDAMENTALES



56

Modelos ágiles


Elementos que componen el modeloPrincipios fundamentales

Modelos

Disciplinas

Conceptos clave

Prácticas contrastadas

Recomendaciones

Principios básicos en los que se basa todo el modelo (los 8 de la pág. ant.)

Mapas mentales de organización. Hay 2: De equipo y de procesos

Áreas de trabajo en las que se usan métodos determinados (Gestión deproyecto, de riesgos y de la mejora del talento)

Ideas que dan soporte a los principios y disciplinas de MSF y se muestrana través de prácticas específicas contrastadas.

Prácticas que han demostrado su efectividad en proyectos en diferentescondiciones de entornos reales

Prácticas opcionales, sugeridas por el modelo.



57

Modelos ágiles


Relación entre los componentes del modeloEste diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes deMicrosoft Solutions Framework

Aprender delas

experiencias

Modelo deprocesos

Disposición alaprendizaje

Hitos derevisión

Uso defacilitadores

externos

Permanecerágil y esperar

el cambio

Gestión deriesgos

Evaluacióncontinua de

riesgos

Definir ymonitorizardisparadoresde riesgos

Creación deuna BD de

riesgos

Principio

Fundamental

Modelo o

Disciplina

Concepto

Clave

Práctica

ContrastadaRecomendac.

˜

˜

˜

˜

˜

˜

˜

˜

˜Está relacionado

En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” haganerado 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.



58

Modelos ágiles

Modelos de propiedad Comercial: RUP

Rational Unified ProcessEs un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignaciónde tareas y responsabilidades en las organizaciones de desarrollo de software.

RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en suconjunto de herramientas de desarrollo, y distribuido por IBM.

RUP integra un conjunto de “buenas prácticas” para el desarrollo de software en un marco deprocesos válido para un rango amplio de tipos de proyectos y organizaciones.

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.

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.

RUP: Buenas Prácticas



59

Modelos ágiles


Rational Unified Process: Visión estáticaEn 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 deadministración.

Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividaddel proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividadespueden tener duración de horas o de algunos días; y son elementos base de planificación yprogreso.

Artefactos: Son los elementos de entrada y salida de las actividades. Son productostangibles del proyecto. Las cosas que el proyecto produce o usa para componer el productofinal (modelos, documentos, código, ejecutables…)

Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUPcomprende 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, yconstituyen la secuencia de actividades que producen resultados visibles.



60

Modelos ágiles


Rational Unified Process: Visión dinámicaEn su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrolloiterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios derumbo.

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 unaarquitectura 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. Laespecificación de las necesidades y el diseño de la arquitectura. Termina con el “hito deArquitectura”.

3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para suentrega 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”.



61

4.- Gestión de proyectos: formal y ágil4.- Gestión de proyectos: formal y ágil



62

Cómo gestionar los proyectos de software

Referentes de la gestión formal de proyectosLas 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)

IPMA se constituyó en 1965, PMI lo hizo en 1969, y PRINCE2 se comenzó a desarrollar en 1989.

Forma inicial y evoluciónForma inicial y evoluciónPMI e IPMA son organizaciones que han ido desarrollando estándares, métodos y modelos decertificación profesional (www.pmi.org – www.ipma.ch).

Siguiendo un camino inverso, PRINCE2 no nace como asociación, sino como metodología alrededorde la cual se ha formado un grupo de desarrollo.

Gestión formal de proyectos

Gestión de proyectos

http://www.pmi.org/

http://www.ipma.ch/

http://www.ipma.ch/

http://www.pmi.org/



63


Referentes de la gestión formal de proyectos

Ámbito global de la gestión formalÁmbito global de la gestión formalPMI E IPMA defienden que la gestión de proyectos comprende un cuerpo de conocimiento que debeser 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 PRINCE2fue el contrario: su desarrollo inicial lo llevó a cabo la CCTA (Central Computer andTelecommunications Agency) del Gobierno Británico, para que sirviera como estándar en losproyectos de Tecnologías de la Información. Sin embargo, el ámbito de aplicación se fue ampliandoy en su revisión de 1996 se le dio cobertura global para los proyectos de todas las industrias.




64


Objeciones a la gestión formal de proyectosLos modelos ágiles para el desarrollo de software plantean objeciones a la teoría de la gestiónformal de proyectos.

Características específicas del softwareCaracterí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 muymaleables. Por esta razón, resulta tendencioso comparar la construcción de un edificio, un avión, oun 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 elcliente; o desarrollar una embarcación básica, para ir ampliando y modificando sus características, amedida que por el uso las van descubriendo los clientes.

Sin embargo con el software esto es posible.

Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultarviables para los proyectos de software de determinadas características, pero que se apartan de losmétodos formales de gestíón.

¿Es posible un marco único y universal para la gestión de proyectos?

Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultarviables para los proyectos de software de determinadas características, pero que se apartan de losmétodos formales de gestíón.

¿Es posible un marco único y universal para la gestión de proyectos?




65


Referentes de la gestión ágil de proyectosLas principales referencias de la gestión ágil de proyectos son:

Scrum Rational Unified Process (RUP) Microsoft Solutions Framework (MSF)

CaracterísticasCaracterísticas

Scrum es un modelo ágil no centrado en prácticas de programación (como XP p. ej.), sino enprá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 RationalSoftware (IBM).MSF es un marco de desarrollo que define procesos, principios, modelos, disciplinas, conceptos yprácticas contrastadas por Microsoft.No son modelos de procesos sino marcos de trabajo adaptables a las circunstancias de lasorganizaciones de los proyectos.

Gestión ágil de proyectos




66


Fundamentos de la cultura ágil con problemas de encaje enla 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 diagramasde 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 desdeel principio para dar rigor al plan del proyecto.La gestión ágil

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 diagramasde 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 desdeel principio para dar rigor al plan del proyecto.La gestión ágil



67

Desavenencias


Trabajo y gestión guiada por un plan general delproyecto que comprende todo su ciclo dedesarrollo.

Trabajo y gestión guiada por un plan general delproyecto que comprende todo su ciclo dedesarrollo.

La planificación del trabajo sólo comprende el cicloen el que se está trabajando (normalmente 30días). Algunos modelos ágiles prohíben el uso degráficos de Gantt

La planificación del trabajo sólo comprende el cicloen el que se está trabajando (normalmente 30días). Algunos modelos ágiles prohíben el uso degráficos de Gantt

Conocimiento detallado de los requisitos antes decomenzar el diseño del proyectoConocimiento detallado de los requisitos antes decomenzar el diseño del proyecto

Descubrimiento progresivo de requisitos, eincorporación de cambios en cualquier iteración deldesarrollo

Descubrimiento progresivo de requisitos, eincorporación de cambios en cualquier iteración deldesarrollo

“Hacerlo bien a la primera”.Evitar la re-codificación y el re-trabajo que suponeuna pérdida de eficiencia.

“Hacerlo bien a la primera”.Evitar la re-codificación y el re-trabajo que suponeuna pérdida de eficiencia.

“Refactorización” de código como modelo detrabajo compatible con el punto anterior.“Refactorización” de código como modelo detrabajo compatible con el punto anterior.

Comunicación formal según el plan decomunicación del proyectoComunicación formal según el plan decomunicación del proyecto

Comunicación directa entre los integrantes delequipo (incluidos cliente y usuarios) prefiriendo laverbal directa.

Comunicación directa entre los integrantes delequipo (incluidos cliente y usuarios) prefiriendo laverbal directa.

Gestión de equipos y personas centralizada en elgestor del proyectoGestión de equipos y personas centralizada en elgestor del proyecto

Equipos auto-gestionados.Equipos auto-gestionados.

Gestión formalGestión formal Gestión ágilGestión ágil



69

Gestión de proyectos: principales conceptos y prácticas

Gestión de riesgos

IDENTIFICACIÓN

ANÁLISIS

TRATAMIENTO

G

ESTIÓ

N

DERIESG

OS

Plan de gestiónde riesgos

IEEE Std P1540-2001




70


Gestión de riesgosCausas y consecuenciasCausas y consecuencias

Causa

Causa

CONSECUENCIACONSECUENCIA



consecuenciaconsecuencia



Requisitos

crecientes

Requisitos

crecientes

Más horasMás horas

Presión equipoPresión equipo

Desbordamientocostes

Desbordamientocostes

IncumplimientofechasIncumplimientofechas

Más errorespeor calidadMás errorespeor calidad

Desmotivaciónmenor eficienciaDesmotivación

menor eficiencia




71


Gestión de riesgos


La gestión de proyectos incorpora métodos sistemáticos de control de riesgos consoluciones genéricas.

La gestión de proyectos incorpora métodos sistemáticos de control de riesgos consoluciones genéricas.

RIESGO TIPORIESGO TIPO

Desbordamiento de costesDesbordamiento de costes

Errores en los productosErrores en los productos

Procesos de desarrolloincontrolados

Procesos de desarrolloincontrolados

Producto incontroladoProducto incontrolado

Problemas de comunicaciónProblemas de comunicación

SOLUCIÓN TIPOSOLUCIÓN TIPO

Verificación / validación derequisitos y diseño

Verificación / validación derequisitos y diseño

Verificación / validaciónpruebas en el desarrolloVerificación / validaciónpruebas en el desarrollo

Desarrollo sobre procesosdefinidos

Desarrollo sobre procesosdefinidos

Gestión de la configuraciónSQA

Gestión de la configuraciónSQA

Normalización document.Comunicación, resolución prob.

Normalización document.

Comunicación, resolución prob.

Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, elpresupuesto 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 deproyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DELPROYECTO.

Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, elpresupuesto 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 deproyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DELPROYECTO.



Roles: gallinas y cerdos

Una gallina y un cerdo paseaban por la carretera. La gallina dijo alcerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró lapropuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. Lagallina respondió: “Huevos con beicon”.

Una gallina y un cerdo paseaban por la carretera. La gallina dijo alcerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró lapropuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. Lagallina 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”.

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”.

COMPROMETIDOS EN EL PROYECTODueño del producto

IMPLICADOS EN EL PROYECTOMarketingComercial

Scrum diferencia claramente entre estosdos grupos para garantizar que quienestienen la responsabilidad tienen también

la autoridad necesaria para poder lograrel éxito, y que quienes no tienen la

responsabilidad no produceninterferencias innecesarias

Scrum diferencia claramente entre estosdos grupos para garantizar que quienestienen la responsabilidad tienen también

la autoridad necesaria para poder lograrel éxito, y que quienes no tienen la

responsabilidad no produceninterferencias innecesarias

Gestión ágil de proyectos: Scrum

modelos para calidadimp

Documents