Metodologas giles

Universidad de Morn
Faculta de Informtica, Cs. De la Comunicacin y
Tc. Especiales
Herramientas y Procesos de Software

Motivaci
Motivacin

Problemas comunes al desarrollar software?...




Una solucin: UML y el Rational Unified Process (RUP), CMM.




Caos
Falta de un mtodo sistemtico de trabajo, que se sigue a veces

Completsimo y apoyado por muchas herramientas

Tan grande, que nadie lo usa completamente

Y si adems tengo pocos recursos? Y necesito el trabajo para

sobrevivir?



Puedo gastar tiempo en documentar ms all de lo necesario?

Las herramientas, pueden ser ms importantes que el objetivo

Fundamentos de XP

Problema fundamental del desarrollo del software

Lidiar con el Riesgo

Causa del Riesgo?

La incertidumbre

La nica certeza?

El cambio
3

Or
Orgenes de los m
mtodos giles
En marzo de 2001, 17 crticos de estos modelos, convocados por Kent Beck,
que acababa de definir una nueva metodologa denominada Extreme
Programming, se reunieron en Salt Lake City para discutir sobre los modelos
de desarrollo de software.
En la reunin se acu el trmino Mtodos giles para definir a aquellos
que estaban surgiendo como alternativa a las metodologas formales, (CMMSW, PMI, SPICE) a las que consideraban excesivamente pesadas y rgidas
por su carcter normativo y fuerte dependencia de planificaciones
detalladas, previas al desarrollo.
Los integrantes de la reunin resumieron en cuatro postulados lo que ha
quedado denominado como Manifiesto gil, que compendia el espritu en el
que se basan estos mtodos.
En la actualidad hay aproximaciones que combinan lo mejor de ambos
enfoques (formal y gil), aunque en cada lado, sus defensores adoptaron
posturas radicales, quiz ms ocupadas en descalificar a la contraria que en
estudiarla y conocerla para mejorar la propia.
4

Manifiesto gil

Estamos poniendo al descubierto mejores mtodos para desarrollar

software, hacindolo y ayudando a otros a que lo hagan. Con este
trabajo hemos llegado a valorar:

A los individuos y su
interaccin
El software que funciona
La colaboracin con el
cliente
La respuesta al cambio

por
por
por
por

encima
encima
encima
encima

de los procesos y las

herramientas
de la documentacin
exhaustiva
la
negociacin
contractual
seguimiento de un plan

Aunque hay valor en los elementos de la derecha, se valora ms

los de la izquierda
http://agilemanifesto.org/
5

Manifiesto gil
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de SW que le

aporte un valor.
Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin
dentro de un equipo de desarrollo.
El software que funciona es la medida principal de progreso.
Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y
usuarios deberan ser capaces de mantener una paz constante.
La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s
mismos.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y
segn esto ajusta su comportamiento

Mtodos giles
 Recogen tcnicas, buenas
prcticas contrastadas por
profesionales reconocidos.

 Cada una tiene sus caractersticas

propias y cubre un rango de reas
de procesos ms o menos amplia:
 Tendencia a combinarlas para
dar mayor cobertura en el ciclo
de vida

5. Procesos primarios

5. Procesos de soporte

5.1 Adquisicin

6.1 Documentacin

5.2 Suministro

6.2 Gestin de la configuracin

6.3 Control de calidad

5.3
Operacin

6.4 Verificacin

6.5 Validacin

5.3
Desarrollo

6.6 Reuniones
5.3
6.7 Auditora

Mantenimiento

 Han surgido de entornos reales de

desarrollo de software
 Responden mejor a la realidad
del software y las diferencias
con produccin industrial.

6.8 Resolucin de problemas

7. Procesos organizacionales
7.1 Gestin

7.2 Infraestructura

7.3 Mejora

7.4 Formacin

eXtreme Programming (XP)

Este es el mtodo que ms popularidad ha alcanzado entre las
metodologas giles, y posiblemente sea tambin el ms 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 suposicin de que es
posible desarrollar software de gran calidad a pesar, o incluso como
consecuencia del cambio continuo. Su principal asuncin es que con un
poco de planificacin, un poco de codificacin y unas pocas pruebas se
puede decidir si se est siguiendo un camino acertado o equivocado,
evitando as tener que echar marcha atrs demasiado tarde.

Valores
Valores que
que inspiran
inspiran XP
XP
SIMPLICIDAD

FEEDBACK

CORAJE

COMUNICACIN

Procesos y t
tcnicas para desarrollo de
software
Comunicacin
Comunicacin
XP pone en comunicacin 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 da a da, y es
posible ajustar la agenda y las funcionalidades de forma consecuente

Feedback
Feedback rpido
rpido yy continuo
continuo
Una metodologa basada en el desarrollo incremental de pequeas
partes, con entregas y pruebas frecuentes y continuas, proporciona un
flujo de retro-informacin valioso para detectar los problemas o
desviaciones.

 De esta forma fallos se localizan muy pronto.

 La planificacin no puede evitar algunos errores, que slo se
evidencian al desarrollar el sistema.

 La retro-informacin es la herramienta que permite reajustar la

agenda y los planes.

Procesos y t
tcnicas para desarrollo de
software
Simplicidad
Simplicidad
La simplicidad consiste en desarrollar slo el sistema que realmente se
necesita. Implica resolver en cada momento slo las necesidades
actuales. Con este principio de simplicidad, junto con la comunicacin y
el feedback resulta ms fcil conocer las necesidades reales
Los costes y la complejidad de predecir el futuro son muy
elevados, y la mejor forma de acertar es esperar al futuro.

Coraje
Coraje
El coraje implica saber tomar decisiones difciles. Reparar un error
cuando se detecta. Mejorar el cdigo siempre que tras el feedback y las
sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rpidamente con el cliente los desajustes de agendas para
decidir qu partes y cundo se van a entregar.
10

Fundamentos de XP Cmo disminuir la

incertidumbre

Obteniendo retroalimentacin exacta y precisa del avance

de un proyecto

Invirtiendo los menos recursos posibles al comienzo

Ofreciendo la oportunidad de ir ms rpido

Permitiendo cambiar drsticamente los requerimientos

11

Fundamentos de XP Las variables de todo proyecto

de SW

Tiempo, Costo, Alcance, Calidad

Por lo regular se fijan las 3 primeras variables:




Hazme un administrador de estas tablas de la base de datos, en

una semana, con dos programadores
Entonces la variable que sufre es la calidad

Pero la calidad no es algo realmente negociable (A quin le

gusta hacer un mal trabajo?)

Y si lo variable fuera el Alcance?

12

Fundamentos de XP Los Costos del cambio de

alcance

Visin tradicional

Y si fuera as?

13

Fundamentos de XP Cmo aplanar la curva de

costos

No sucede mgicamente

Hay tecnologas que son ms amigables con el cambio





Programacin Orientada a Objetos

Bases de Datos Orientadas a Objetos
Pero la tecnologa sola no sirve

Prcticas tiles

Un diseo simple del sistema, sin reas desiertas (cdigo que

no se usa)
Un sistema automtico de Pruebas

Mucha prctica en cambiar diseos de sistemas

Permite hacer cambios y comprobar la coherencia del sistema

14

Fundamentos de XP Valores de XP
Comunicacin

(Centro de todo problema humano)

Abierta y honesta
Ensear a aprender
Trabajar con los instintos de las personas

Coraje

Jugar a ganar
Responsabilidad aceptada (antes que
asumida)
Trabajo de Calidad
Atacar problema urgente, dejando la mayor
cantidad de opciones

Simplicidad

Asumirla siempre
Viajar con equipaje: poco, simple y
valioso
Cambios paso a paso
Adaptacin local
Retroalimentacin

Rpida (favorece el aprendizaje)

Medir honestamente
Experimentos concretos

15

Pr
Prcticas de XP

16

Las 12 Pr
Prcticas de XP
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12
prcticas que se complementan unas a otras y deben implementarse en un entorno
de desarrollo cuya cultura se base en los cuatro valores citados
PRCTICAS DE CODIFICACIN
1.- Simplicidad de cdigo y de diseo para producir software fcil de modificar.
2.- Reingeniera continua para lograr que el cdigo tenga un diseo ptimo.
3.- Desarrollar estndares de codificacin, para comunicar ideas con claridad a travs del
cdigo.
4.- Desarrollar un vocabulario comn, para comunicar las ideas sobre el cdigo con
claridad.
PRCTICAS DE DESARROLLO
1.- Adoptar un mtodo de desarrollo basado en las pruebas para asegurar que el cdigo se
comporta segn lo esperado.
2.- Programacin por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del cdigo, para que todo el equipo sea responsable de l.
4.- Integracin continua, para reducir el impacto de la incorporacin de nuevas
funcionalidades.
17

Las 12 Pr
Prcticas de XP
PRCTICAS DE NEGOCIO

1.- Integracin de un representante del cliente en el equipo, para

encauzar las cuestiones de negocio del sistema de forma directa, sin
retrasos o prdidas por intermediacin.
2.- Adoptar el juego de la planificacin para centrar en la agenda el
trabajo ms importante.
3.- Entregas regulares y frecuentes para satisfacer la inversin del
cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero
no agotado.

18

Cmo interviene la gesti

gestin un proyecto XP

Es importante reaccionar ante los problemas apenas aparecen

Se reflexiona acerca de qu provoco el problema

Si hay que tomar medidas impopulares, hacerlo firme pero

humildemente

Ejemplos de intervencin




Cambios de personal
En las estrategias de desarrollo
Matar el proyecto

19

Actores del desarrollo XP

Se abstraen las individualidades en dos bandos




Clientes (Bussiness)
Desarrolladores (Development)

Programador
Encargado de pruebas
Encargado de seguimiento
Consultor externo
Gestor (vnculo entre clientes y programadores)

Cada cual posee derechos y deberes

20

Actores del desarrollo XP - Derechos del Cliente

Tiene el derecho y el deber de








Decidir qu ser implementado (Alcance del proyecto),

definiendo la prioridad, composiciones y fechas de las
entregas
Siempre saber el estado actual y el progreso del proyecto.
Agregar, cambiar y remover requerimientos en cualquier
momento.
Obtener el mayor valor de cada semana de desarrollo.
Tener un sistema funcional cada 3 o 4 meses

21

Actores del desarrollo XP - Derechos del

Desarrollador

Tiene el derecho y el deber de



Decidir cmo se implementarn las cosas

Crear sistemas con la ms alta calidad posible

Consultar al cliente aclaraciones a los requerimientos en

cualquier momento

Estimar el esfuerzo de implementar un sistema, y cambiar las

estimaciones basado en nuevos descubrimientos

Definir las consecuencias tcnicas de una decisin del cliente

22

Fases de XP

Exploracin: descripcin de las historias de usuario,

construccin de un prototipo
Planificacin de la entrega: prioridad de las
historias y estimacin del esfuerzo, cronograma
Iteraciones: asignacin de tareas a los
programadores
Produccin: desarrollo y pruebas unitarias
Mantenimiento: mantenimiento del sistema en
funcionamiento mientras se integran los incrementos
Muerte del proyecto: generacin de documentacin
23

Cmo funciona XP

Plan de Entregas
con Historias de Usuario

El Cliente selecciona la lista

de historias para la
iteracin / mini-entrega

Reunin de
Planificacin de Entregas

Escribir cdigo y Pruebas de Mdulos

Refactorizar la iteracin previa

Pruebas
de Aceptacin

Aprobacin del
cliente
Entregas pequeas al
cliente

Pruebas
de aceptacin
OK?

Mantenerse iterando
para pasar las Pruebas
de Aceptacin:
Pruebas de sistema
(Bugs)
Pruebas de Mdulos
Pruebas de usuario

24

SCRUM
No es propiamente un mtodo o metodologa de desarrollo, e implantarlo como
tal resulta insuficiente.
Scrum define mtodos de gestin y control para complementar la aplicacin de
otros mtodos giles como XP que, centrados en prcticas de tipo tcnico,
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 revisin?

 Qu obstculos te impiden cumplir la meta?
 Qu vas a hacer antes de la prxima reunin?
 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 planificacin de la siguiente iteracin, guiada
por cliente.

25

SCRUM

26

Otros M
Mtodos giles
Familia
todos Crystal
m
Familia de
de m
mtodos
Crystal
La familia de metodologas Crystal ofrece diferentes mtodos para seleccionar
el ms apropiado para cada proyecto.
Crystal identifica con colores diferentes cada mtodo, y su eleccin debe ser
consecuencia del tamao y criticidad del proyecto, de forma que los de mayor
tamao, o aquellos en los que la presencia de errores o desbordamiento de
agendas implique consecuencias graves, deben adoptar metodologas ms
pesadas.
Los mtodos Crystal no prescriben prcticas concretas

ASD
ASD (Adaptative
(Adaptative Software
Software Development)
Development)
Mtodo que como alternativa a los procedimientos formales, aborda el
desarrollo de grandes sistemas con el uso de tcnicas propias de las
metodologas giles.
No se trata de una metodologa, sino de la implantacin de una cultura en la
empresa, basada en la adaptabilidad.
27

Otros M
Mtodos giles
PP
PP (Pragmatic
(Pragmatic Programming)
Programming)
Pragmatic Programming es la coleccin de 70 prcticas de programacin, comunes a otros
mtodos giles, cuya aplicacin resulta til para solucionar los problemas cotidianos.
Surge del libro The Pragmatic Programmer de Dave Thomas y Andres Hunt.

AM
AM (Agile
(Agile Modeling)
Modeling)
Agile Modeling es la presentacin de un nuevo enfoque para realizar el modelado de
sistemas,(diseo) y basado en los principios de los mtodos giles remarca la conveniencia
de reducir el volumen de la documentacin. (Amber S. Agile Modeling: Effective Practices
for Extreme Programming and the Unified Process)

ISD
ISD Internet
Internet Speed
Speed Development
Development
Surge de las conclusiones del coloquio celebrado en Octubre de 2001, promovido por SEI
que reuni a especialistas de las universidades Carneige Mellon, Georgia y Copenhagen.
Sienta bases de gestin para abordar el desarrollo de sistemas de software, de tamao
pequeo que requieren tiempos de desarrollo muy rpidos.

FDD
FDD (Feature
(Feature Driven
Driven Development)
Development)
Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.
El punto de referencia son las caractersticas que debe reunir el software, y se centra en las
fases de diseo e implementacin del sistema

28

Modelos de propiedad Comercial: MSF

MSF es la metodologa empleada por Microsoft para el desarrollo de software.
Hasta su versin 3 (principios de 2005) MSF se defina como un marco de desarrollo flexible
para adaptarse a las necesidades de cada proyecto, en oposicin a lo que sera una
metodologa 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 comunicacin abierta.

Trabajo en torno a una visin 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.

29

Modelos de propiedad Comercial: MSF

Elementos
Elementos que
que componen
componen el
el modelo
modelo
Principios fundamentales
Modelos
Disciplinas
Conceptos clave
Prcticas contrastadas
Recomendaciones

Principios bsicos en los que se basa todo el modelo (los 8 de la pg. ant.)
Mapas mentales de organizacin. Hay 2: De equipo y de procesos
reas de trabajo en las que se usan mtodos determinados (Gestin 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 travs de prcticas especficas contrastadas.
Prcticas que han demostrado su efectividad en proyectos en diferentes
condiciones de entornos reales
Prcticas opcionales, sugeridas por el modelo.

30

Modelos de propiedad Comercial: MSF

Relacin
Relacin entre
entre los
los componentes
componentes del
del modelo
modelo
Este diagrama es un ejemplo para mostrar la interconexin y relacin entre los
componentes de Microsoft Solutions Framework
Principio

Modelo o

Concepto

Prctica

Fundamental

Disciplina

Clave

Contrastada

Aprender de las
experiencias

Permanecer gil y
esperar el cambio

Modelo de procesos

Gestin de riesgos

Disposicin al
aprendizaje

Evaluacin continua
de riesgos

Uso de facilitadores
externos

Hitos de revisin

Definir y monitorizar
disparadores de
riesgos

Recomendac.

Creacin de una BD de
riesgos

Est relacionado

En 2005, el desarrollo del nuevo producto de Microsoft Visual Studio 2005 Team System
ha ganerado la evolucin de MSF hacia la nueva versin 4.0 con dos lneas paralelas:

 Microsoft Solutions Framework (MSF) for Agile Software Development.

 Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
31

Factores Claves en los Proyectos

Factor

Tamao

Criticidad

Dinamismo

Personal

Cultura

Discriminadores giles
Dependencia y escalabilidad limitada por
el porcentaje alto de conocimiento tcito.
Apropiado para equipos y productos
pequeos.
La simplicidad en la documentacin y el
diseo dificulta los planes de pruebas.
No aconsejado para sistemas con niveles
de criticidad altos (IEEE 1012)
Re-factorizar desde un diseo bsico
hasta el producto final es un mtodo
ideal para entornos dinmicos e innovadores, pero muy caro por el retrabajo para entornos estables o
conocidos
Los mtodos de trabajo giles requieren
una masa crtica de tcnicos con niveles
de experiencia medios-altos, capaces de
comprender y adaptar los mtodos y las
tcnicas empleadas.
Ms apropiado para culturas de
empowerment responsabilidad y
horquilla de decisin y libertad personal.

Discriminadores formales
Escalabilidad y conocimiento explcito.
Apropiado para productos y equipos
grandes. Duro de mantener en pequeos
proyectos.
Rigor de requisitos y diseo adecuados
para procesos de pruebas, verificacin y
validacin.
Duros de gestionar en proyectos de
escasa criticidad
En sistemas estables y conocidos, partir
de requisitos completos y diseos
detallados permite trazar y seguir un
plan completo y hacerlo bien a la
primera.
Aunque es aconsejable contar con
personas expertas en las fases de
definicin del proyecto, luego pueden
ejecutarse con menor masa crtica de
expertos.
Ms apropiado en culturas en las que las
personas se sienten seguras con un
marco de tareas y responsabilidades bien
definido.

32

Procesos y t
tcnicas para desarrollo de
software
Enfoque
Enfoque formal
formal oo gil?
gil?
Personal
% Junior

% Senior y Master

40

15

30

20

20

25

10

30

Criticidad
Prdidas posibles

Vida

0
s
Bien
es

- ut
ilid

Dinamismo
% Modific. Requisitos / mes
1
5

35

10
30

ad

50

3
10

gi
90

30

For

ma
l

70
100
300

Tamao
Nmero de personas

50
30
10

Cultura
% adaptacin a entornos caticos

33

Metodolog
Metodologas giles vs. Tradicionales

34

Procesos y t
tcnicas para desarrollo de
software
Para
Para ampliar
ampliar informacin
informacin
Modelos basados en procesos






Pgina oficial CMMI del Software Engineering Institute. (http://www.sei.cmu.edu/cmmi/cmmi.html)

Pgina para descarga de los modelos CMMI. (http://www.sei.cmu.edu/cmmi/models/models.html)
SWEBOK: reas de conocimiento de la Ingeniera del software (http://www.swebok.org/)
Gestin de proyectos PMI

(http://www.pmi.org)

IPMA

(http://www.ipma.ch) PRINCE 2 (http://www.prince2.com/)

Modelos giles

Manifiesto gil

Agile Alliance (http://www.agilealliance.org/)







Scrum (http://www.controlchaos.com/)





Agile Modeling

(http://www.agilemanifesto.org/)

Exreme Programming (http://www.extremeprogramming.org/)

DSDM

(http://www.dsdm.org/)

Microsoft Solutions Framework

(http://msdn.microsoft.com/vstudio/teamsystem/msf/)

Rational Unified Process (http://www-306.ibm.com/software/rational/)

 (http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf)
(http://www.agilemodeling.com/)

Feature Driven Development

(http://www.featuredrivendevelopment.com/)

Internet Speed Development

(http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr020.pdf)

35