Metodologias Agiles

Metodologas giles y XP
Patricio Letelier
letelier@dsic.upv.es
Departamento de Sistemas Informticos y Computacin
Universidad Politcnica de Valencia
www.dsic.upv.es/~letelier/pub
Contenidos
Introduccin a Metodologas giles
Extreme Programming (XP)
Introduccin
Prcticas de XP
Conclusiones

Qu es una Metodologa gil?
www.agilealliance.com
Las Metodologas giles (AMs) valoran:
Al individuo y las interacciones en el equipo de desarrollo
ms que a las actividades y las herramientas

Desarrollar software que funciona ms que conseguir una
buena documentacin Minimalismo respecto del
modelado y la documentacin del sistema

La colaboracin con el cliente ms que la negociacin de
un contrato

Responder a los cambios ms que seguir estrictamente
una planificacin

Por qu surgen las
Metodologas giles (AMs)?
Dificultad para implantar metodologas tradicionales.
Sofisticadas herramientas CASE y notaciones (UML)

Una solucin a medida para un segmento importante de
proyectos de desarrollo de software

Pugna entre comunidades/gurs

Aceptar el cambio ...
Costo de los Cambios en SW
Costo
del
cambio
tiempo
Tradicional
Suposicin AMs
Manifiesto de las AMs
agilemanifesto.org
Principios:
1. La prioridad principal es satisfacer al cliente mediante
tempranas y continuas entregas de software que le
reporte un valor

2. Dar la bienvenida a los cambios. Los AMs capturan los
cambios para que el cliente tenga una ventaja
competitiva

3. Entregar frecuentemente software que funcione, desde
un par de semanas a un par de meses, con el menor
intervalo de tiempo posible entre una entrega y la
siguiente
4. La gente del negocio y los desarrolladores deben trabajar
juntos a lo largo del proyecto

5. Construir proyecto en torno a individuos motivados. Darles
el entorno y el apoyo que necesitan y confiar en ellos para
conseguir el trabajo

6. El dilogo cara a cara es el mtodo ms eficiente y efectivo
para comunicar informacin dentro de un equipo de
desarrollo

7. El software que funciona es la medida principal de progreso

8. Los procesos giles promueven un desarrollo sostenible.
Los promotores, desarrolladores y usuarios deberan ser
capaces de mantener una paz constante

9. La atencin continua a la calidad tcnica y al buen diseo
mejora la agilidad

10. La simplicidad es esencial

11. Las mejores arquitecturas, requisitos y diseos surgen de
los equipos organizados por s mismos

12. En intervalos regulares, el equipo reflexiona respecto de
cmo llegar a ser ms efectivo, y segn esto ajusta su
comportamiento

Comparacin gil - gil
Metodologa gil Metodologa No gil
Pocos Artefactos Ms Artefactos
Pocos Roles Ms Roles
No existe un contrato tradicional o al
menos es bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de
desarrollo (adems in-situ)
El cliente interacta con el equipo
de desarrollo mediante reuniones
Grupos pequeos (< 10 integrantes)
y trabajando en el mismo sitio
Grupos grandes
Menos nfasis en la arquitectura La arquitectura es esencial
Principales AMs
Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org

SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com

DSDM (Dynamic Systems Development Method), www.dsdm.org

Lean Programming, Mary Poppendieck, www.poppendieck.com

FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, www.coad.com/peter/#fdd

Extreme Programming, Kent Beck www.extremeprogramming.org,
www.xprogramming.com

Adaptative Software Development, Jim Highsmith
www.adaptivesd.com
12
eXtreme Programming
Qu es XP?
Es una metodologa gil
Diseada para entornos dinmicos
Pensada para equipos pequeos (hasta 10
programadores)
Orientada fuertemente hacia la codificacin
nfasis en la comunicacin informal, verbal

Historia de XP
Creado por Kent Beck para la plantilla
del proyecto C3 en Chrysler
Kent fue contratado para dirigir el proyecto
Durante el proceso naci una nueva
metodologa: eXtreme Programming (XP)
C3 concluy exitosamente en 1997

Valores que fomenta XP
Comunicacin
Simplicidad
Retroalimentacin

Coraje
Roles XP
c2.com/cgi/wiki?ExtremeRoles
Programador (Programmer)
Responsable de decisiones
tcnicas
Responsable de construir el
sistema
Sin distincin entre analistas,
diseadores o codificadores
En XP, los programadores
disean, programan y realizan las
pruebas
Jefe de Proyecto
(Manager)
Organiza y gua las
reuniones
Asegura condiciones
adecuadas para el
proyecto

Cliente (Customer)
Es parte del equipo
Determina qu construir
y cundo
Establece las pruebas
funcionales
... Roles XP
Entrenador (Coach)
Responsable del proceso
Tiende a estar en un
segundo plano a medida
que el equipo madura

Encargado de
Pruebas (Tester)
Ayuda al cliente con las
pruebas funcionales
Se asegura de que las
pruebas funcionales se
superan
Rastreador (Tracker)
Metric Man
Observa sin molestar
Conserva datos
histricos
Captura de Requisitos en XP
Historias del Usuario (User-Stories)
Establecen los requisitos del cliente
Trozos de funcionalidad que aportan valor
Se les asignan tareas de programacin con
un n de horas de desarrollo
Las establece el cliente
Son la base para las pruebas funcionales
Captura de Requisitos en XP
Una ficha de User-Story
Planificacin en XP
Planificacin por entregas (releases)
Se priorizan aquellas user-stories que el cliente
selecciona porque son ms importantes para el
negocio
Entregas:
Son lo ms pequeas posibles
Se dividen en iteraciones (iteracin = 2 o 3 semanas)
Estn compuestas por historias
A cada programador se le asigna una tarea de la
user-story
Programacin en XP
La programacin de tareas se realiza por
parejas

La pareja disea, prueba, implementa e
integra el cdigo de la tarea

Cdigo dirigido por las pruebas

Cdigo modular, intentando refactorizar
siempre que se pueda

Programacin en XP
Una ficha de Tarea
Modelo de un Proyecto XP
Espacio de trabajo XP
Espacio abierto
Mesas centrales
Cubculos en el espacio exterior
Espacio de trabajo
del proyecto C3 de
DaimlerChrysler
Prcticas XP

El juego de la
planificacin
Entregas pequeas
Metfora
Diseo simple
Pruebas
Refactoring

Programacin en
parejas
Propiedad colectiva
Integracin contnua
Semana de 40 horas
Cliente in situ
Estndares de
programacin
Prcticas XP
El Juego de la planificacin
Decisiones de negocio (cliente):
Alcance Cundo debe estar listo el producto para
que sea valioso en produccin?
Prioridad Prioriza la incorporacin de las user-
stories
Composicin de entregas Qu se necesita para
que el negocio sea mejor antes de tener el sw?
Fechas de entrega Fechas cuando el software
funcionando causara una gran diferencia
Prcticas XP
... El Juego de la planificacin
Decisiones tcnicas (programadores y otros):
Estimaciones Cunto tiempo tardar en
implementarse una user-story?
Consecuencias Tener en cuenta las consecuencias
tcnicas de determinadas decisiones de negocio
Proceso Organizacin del proceso y el equipo
Planificacin detallada Dentro de una entrega, qu
user-stories se realizan primero. Intentar trasladar los
segmentos de desarrollo ms arriesgados al principio,
intentando respetar las prioridades del negocio

Reunin diaria Stand-up Meeting
Todo el equipo
Problemas
Solutiones
De pie en un crculo
Evitar discusiones largas
Sin conversaciones separadas
Prcticas XP
... El Juego de la planificacin
Reunin diaria XP
Cada entrega es lo ms corta posible:
Contenga requisitos ms valiosos del sistema
(bsicos)
Reducen el riesgo mayor retroalimentacin
desde el cliente, y ms frecuente
Minimizar el n de user-stories que componen
una entrega No realizar user-stories a
medias

Prcticas XP
Entregas pequeas
Cada proyecto XP es guiado por una
metfora global

Da un contexto al equipo para entender los
elementos bsicos y sus relaciones

Proporciona integridad conceptual

Prcticas XP
Metfora
Se disea la cosa ms simple que pueda
funcionar
Uso de tarjetas CRC
Diseo de software correcto, es aquel que:
Supera todas las pruebas
No tiene lgica duplicada
Pone de manifiesto las intenciones importantes de
los programadores
Tiene el mnimo nmero de clases y mtodos

Prcticas XP
Diseo simple
Las pruebas unitarias se escriben ANTES
que el cdigo
Pruebas automatizadas
Permiten el desarrollo de proyectos de forma
rpida y segura
Pruebas unitarias programadores
Pruebas funcionales cliente
Resultado Un programa cada vez ms
seguro
Prcticas XP
Pruebas
Refactorizacin = Mejora del cdigo

Intentar eliminar complejidad
Cdigo duplicado Refactorizacin

Se plantea su aplicacin despus de
implementar cada user-story

Prcticas XP
Refactoring
www.refactoring.com
Toda el cdigo se escribe en parejas
Se produce cdigo de mayor calidad

Extiende el conocimiento

Se realiza el trabajo de 1 persona en casi la
mitad del tiempo y mejor (cuestionable)

Prcticas XP
Programacin en parejas
www.pairprogramming.com
Cualquiera puede modificar el cdigo en
cualquier momento Se evitan cuellos de
botella en la codificacin

Todos asume las responsabilidades sobre el
conjunto del sistema

Todos conocen algo sobre todas las partes y
conocen muy bien aqullas en las que trabajan
Prcticas XP
Propiedad colectiva
El cdigo se integra y se prueba despus de
pocas horas

Existe una ordenador dedicado para la
integracin

Cada pareja integra su cdigo en dicho
ordenador

Prcticas XP
Integracin contnua
Filosofa: Los programadores que descansan
son ms productivos

El exceso de trabajo es un serio problema en
un proyecto

La gente est ms fresca y tiene mejores ideas

Prcticas XP
Semana de 40 horas
Cliente real = Aquel que usar el sistema
cuando est en produccin

El cliente real debe estar con el equipo de
trabajo:
Responder preguntas
Resolver disputas
Establecer prioridades
Discutir mejoras

Prcticas XP
Cliente in situ
Son fundamentales cuando los programadores
cambian de pareja o hacen refactoring del
cdigo de otros

Se consigue un cdigo con el mismo estilo,
homogneo, legible
Prcticas XP
Estndares de programacin
Prcticas XP
Interaccin entre Prcticas
XP: Kent Beck
42
Conclusiones
Un da de trabajo en XP

Stories
Pair Programming
Frequent Releases
Daily Stand-up Meetings
Create Great Architectures
Working SW >>
Documentation
Collective Ownership
Improve Quality Iteratively
Collaboration>>Contracts
Nightly Builds (too early to tell)
Refactor (when time appropriate)
Ever-Present Customers (unlikely to work in real world)
Continuous Integration (unlikely for non-trivial)
Dont Create Things to Discard (moderation!) x

Mala
Precaucin
Buena
Nightly Builds
Refactoring
Cliente in situ
Integracin contnua
No crear cosas que se desecharn
Historias de usuario
Programacin en parejas
Releases frecuentes
Reunin Stand-up cada da
Crear buenas arquitecturas
SW funcionando >>
Documentation
Propiedad colectiva
Mejora de la calidad
iterativamente
Colaboracin >> Contrato
No todas las ideas/prcticas
giles son buenas
Diapositiva obtenida de la presentacin A History of Agile Methods presentada por Alan Davis en JISBD 2002
Fuerzas que influyen los enfoque
para el desarrollo de software
Grado de
Ceremonia/control
en el proceso
Tiempo
1950s 1960s 1970s 1980s 1990s 2000s 2010s
Diapositiva obtenida de la presentacin A History of Agile Methods presentada por Alan Davis en JISBD 2002
Qu resultado proveen las
Metodologas giles?
Hay pocos datos concretos del ndice de xito de
proyectos
Est teniendo un gran auge
Aumento en el nmero de proyectos
Por qu?
Tiene el apoyo de muchos gurs en ingeniera de sw
Es un proceso para gente que odia los procesos
Tiene sentido
Poltica? ... Pugna entre comunidades

Cundo utilizar una
Metodologa gil?
Existe ya un proceso? Si
Reacciona bien a los cambios? Si
Est el equipo contento con l? Si

Mejor esperar
Se estn recogiendo datos (red NAME)
http://name.case.unibz.it/
En un futuro se podrn hacer comparaciones
sobre lo que es ms conveniente

... Cundo utilizar una
Metodologa gil?
Existe ya un proceso? No
o existe pero no reacciona bien a los cambios
o existe pero el equipo no est contento con l

Una Metodologa gil puede ser una buena
forma de empezar
Fcil de financiar
A los programadores les gusta
A los clientes les gusta el control aadido

Qu hace la gente con las
Metodologas giles?
International Conference on eXtreme
Programming and Agile Methods in Software
Development (XP200x)
http://www.xp2003.org
XP Agile Universe
http://www.agileuniverse.com
Metodologas giles y XP
Departamento de Sistemas Informticos y Computacin
Universidad Politcnica de Valencia
Fin de la Presentacin
Patricio Letelier
letelier@dsic.upv.es

Metodologias Agiles

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologias Agiles

Enviado por

Direitos autorais:

Formatos disponíveis

Metodologas giles y XP

Você também pode gostar