Me to Do Log i as a Giles y Extreme Programming

7/29/2019 Me to Do Log i as a Giles y Extreme Programming

http://slidepdf.com/reader/full/me-to-do-log-i-as-a-giles-y-extreme-programming 1/50

Metodologías Ágiles y XP

Patricio Letelier [email protected]

Departamento de Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia



www.dsic.upv.es/~letelier/pub

Contenidos

Introducción a Metodologías Ágiles

Extreme Programming (XP) IntroducciónPrácticas de XP

Conclusiones




¿Qué es una Metodología Ágil?www.agilealliance.com

Las Metodologías Ágiles (AMs) valoran: Al individuo y las interacciones en el equipo de desarrollo

más que a las actividades y las herramientas

Desarrollar software que funciona más que conseguir unabuena documentación Minimalismo respecto delmodelado y la documentación del sistema

La colaboración con el cliente más que la negociación deun contrato

Responder a los cambios más que seguir estrictamenteuna planificación

http://www.agilealliance.com/

http://www.agilealliance.com/




¿Por qué surgen lasMetodologías Ágiles (AMs)?

Dificultad para implantar metodologías tradicionales.Sofisticadas herramientas CASE y notaciones (UML)

Una solución a medida para un segmento importante deproyectos de desarrollo de software

Pugna entre comunidades/gurús

“Aceptar el cambio” ...




Costo de los Cambios en SW

Costodel

cambio

tiempo

Tradicional

Suposición AMs




Manifiesto de las AMsagilemanifesto.org

Principios:1. La prioridad principal es satisfacer al cliente mediante

tempranas y continuas entregas de software que lereporte un valor

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

3. Entregar frecuentemente software que funcione, desdeun par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y lasiguiente

http://agilemanifesto.org/

http://agilemanifesto.org/


http://slidepdf.com/reader/full/me-to-do-log-i-as-a-giles-y-extreme-programming 7/50 www.dsic.upv.es/~letelier/pub

… Manifiesto de las AMs

4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto

5. Construir proyecto en torno a individuos motivados. Darlesel entorno y el apoyo que necesitan y confiar en ellos paraconseguir el trabajo

6. El diálogo cara a cara es el método más eficiente y efectivopara comunicar información dentro de un equipo de

desarrollo

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



… Manifiesto de las AMs

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

9. La atención continua a la calidad técnica y al buen diseño

mejora la agilidad10. La simplicidad es esencial

11. Las mejores arquitecturas, requisitos y diseños surgen delos equipos organizados por sí mismos

12. En intervalos regulares, el equipo reflexiona respecto decómo llegar a ser más efectivo, y según esto ajusta sucomportamiento



Comparación Ágil - ¬Ágil

Metodología Ágil Metodología No ÁgilPocos Artefactos Más Artefactos

Pocos Roles Más Roles

No existe un contrato tradicional o almenos es bastante flexible Existe un contrato prefijado

Cliente es parte del equipo dedesarrollo (además in-situ)

El cliente interactúa con el equipode desarrollo mediante reuniones

Grupos pequeños (< 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 Highsmithwww.adaptivesd.com

http://www.crystalmethodologies.org/

http://www.controlchaos.com/

http://www.dsdm.org/

http://www.poppendieck.com/

http://www.nebulon.com/fdd

http://www.coad.com/peter/

http://www.extremeprogramming.org/

http://www.xprogramming.com/

http://www.adaptivesd.com/

http://www.adaptivesd.com/

http://www.xprogramming.com/

http://www.extremeprogramming.org/

http://www.coad.com/peter/

http://www.nebulon.com/fdd

http://www.poppendieck.com/

http://www.dsdm.org/

http://www.controlchaos.com/

http://www.crystalmethodologies.org/



eXtreme Programming



¿Qué es XP?

Es una metodología ágil Diseñada para entornos dinámicos

Pensada para equipos pequeños (hasta 10programadores)

Orientada fuertemente hacia la codificación

Énfasis en la comunicación informal, verbal



Historia de XP

Creado por Kent Beck para la plantilladel proyecto C3 en Chrysler Kent fue contratado para dirigir el proyecto

Durante el proceso nació una nuevametodología: eXtreme Programming (XP)

C3 concluyó exitosamente en 1997



Valores que fomenta XP

Comunicación

SimplicidadRetroalimentación

Coraje



Roles XPc2.com/cgi/wiki?ExtremeRoles

Programador (Programmer)

Responsable de decisionestécnicas

Responsable de construir elsistema

Sin distinción entre analistas,diseñadores o codificadores

En XP, los programadoresdiseñan, programan y realizan laspruebas

Jefe de Proyecto (Manager)

Organiza y guía lasreuniones

Asegura condiciones

adecuadas para elproyecto

Cliente (Customer)

Es parte del equipo Determina qué construir

y cuándo Establece las pruebas

funcionales

http://c2.com/cgi/wiki?ExtremeRoles

http://c2.com/cgi/wiki?ExtremeRoles



... Roles XP

Entrenador (Coach)

Responsable del proceso

Tiende a estar en unsegundo plano a medidaque el equipo madura

Encargado dePruebas (Tester )

Ayuda al cliente con laspruebas funcionales

Se asegura de que laspruebas funcionales sesuperan

Rastreador (Tracker )

Metric Man

Observa sin molestar

Conserva datoshistóricos



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 programación con

un nº de horas de desarrollo

Las establece el cliente

Son la base para las pruebas funcionales



Captura de Requisitos en XPUna ficha de User-Story



Planificación en XP

Planificación por entregas (releases)Se priorizan aquellas user-stories que el clienteselecciona porque son más importantes para elnegocio

Entregas: Son lo más pequeñas posibles

Se dividen en iteraciones (iteración = 2 o 3 semanas)

Están compuestas por historias A cada programador se le asigna una tarea de lauser-story



Programación en XP

La programación de tareas se realiza por parejas

La pareja diseña, prueba, implementa eintegra el código de la tarea

Código dirigido por las pruebas

Código modular, intentando refactorizar siempre que se pueda



Programación en XPUna ficha de Tarea




Modelo de un Proyecto XP




Espacio de trabajo XP

Espacio abiertoMesas centrales

Cubículos en el espacio exterior

Espacio de trabajo

del proyecto C3 de

DaimlerChrysler




Prácticas XP

• El juego de laplanificación

• Entregas pequeñas• Metáfora

• Diseño simple

• Pruebas• Refactoring

• Programación enparejas

•

Propiedad colectiva• Integración contínua

• Semana de 40 horas

• Cliente in situ• Estándares de

programación




Prácticas XPEl Juego de la planificación

Decisiones de negocio (cliente): Alcance ¿Cuándo debe estar listo el producto para

que sea valioso en producción? Prioridad Prioriza la incorporación de las user-

stories

Composición de entregas ¿Qué se necesita para

que el negocio sea mejor antes de tener el sw? Fechas de entrega Fechas cuando el software

funcionando causaría una gran diferencia




Prácticas XP... El Juego de la planificación

Decisiones técnicas (programadores y otros): Estimaciones ¿Cuánto tiempo tardará en

implementarse una user-story?

Consecuencias Tener en cuenta las consecuenciastécnicas de determinadas decisiones de negocio

Proceso Organización del proceso y el equipo

Planificación detallada Dentro de una entrega, qué

user-stories se realizan primero. Intentar trasladar lossegmentos de desarrollo más arriesgados al principio,intentando respetar las prioridades del negocio

P á ti XP




Reunión diaria “Stand-up Meeting” Todo el equipo

Problemas Solutiones

De pie en un círculo Evitar discusiones largas

Sin conversaciones separadas

Prácticas XP... El Juego de la planificación

Reunión diaria XP




Cada entrega es lo más corta posible: Contenga requisitos más valiosos del sistema

(básicos)

Reducen el riesgo mayor retroalimentacióndesde el cliente, y más frecuente

Minimizar el nº de user-stories que componen

una entrega No realizar user-stories amedias

Prácticas XPEntregas pequeñas




Cada proyecto XP es guiado por unametáfora global

Da un contexto al equipo para entender loselementos básicos y sus relaciones

Proporciona integridad conceptual

Prácticas XPMetáfora




Se diseña “la cosa más simple que pueda

funcionar”

Uso de tarjetas CRCDiseño de software correcto, es aquel que: Supera todas las pruebas

No tiene lógica duplicada

Pone de manifiesto las intenciones importantes delos programadores

Tiene el mínimo número de clases y métodos

Prácticas XPDiseño simple




Las pruebas unitarias se escriben ANTESque el códigoPruebas automatizadasPermiten el desarrollo de proyectos de formarápida y seguraPruebas unitarias programadores

Pruebas funcionales clienteResultado Un programa cada vez másseguro

Prácticas XPPruebas

P á ti XP




Refactorización = Mejora del código

Intentar eliminar complejidad

Código duplicado Refactorización

Se plantea su aplicación después deimplementar cada user-story

Prácticas XPRefactoring

www.refactoring.com

http://www.refactoring.com/

http://www.refactoring.com/




P á ti XP




Toda el código se escribe en parejas Se produce código de mayor calidad

Extiende el conocimiento

“Se realiza el trabajo de 1 persona en casi la

mitad del tiempo y mejor” (cuestionable)

Prácticas XPProgramación en parejas

www.pairprogramming.com

http://www.pairprogramming.com/

http://www.pairprogramming.com/




Cualquiera puede modificar el código encualquier momento Se evitan cuellos de

botella en la codificación

Todos asume las responsabilidades sobre elconjunto del sistema

Todos conocen algo sobre todas las partes yconocen muy bien aquéllas en las que trabajan

Prácticas XPPropiedad colectiva




El código se integra y se prueba después depocas horas

Existe una ordenador dedicado para laintegración

Cada pareja integra su código en dichoordenador

Prácticas XPIntegración contínua




Filosofía: “Los programadores que descansan

son más productivos”

El exceso de trabajo es un serio problema enun proyecto

La gente está más fresca y tiene mejores ideas

Prácticas XPSemana de 40 horas




Cliente real = Aquel que usará el sistemacuando esté en producción

El cliente real debe estar con el equipo detrabajo: Responder preguntas

Resolver disputas

Establecer prioridades

Discutir mejoras

Prácticas XPCliente in situ




Son fundamentales cuando los programadorescambian de pareja o hacen refactoring del

código de otros

Se consigue un código con el mismo estilo,homogéneo, legible

Prácticas XPEstándares de programación

Prácticas XP




Prácticas XPInteracción entre Prácticas

XP: Kent Beck



42

Conclusiones




Un día de trabajo en XP




Stories

Pair Programming

Frequent ReleasesDaily Stand-up Meetings

Create Great Architectures

Working SW >>

Documentation

Collective OwnershipImprove 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)Don’t Create Things to Discard (moderation!) x

Mala Precaución Buena

• Nightly Builds

• Refactoring

• Cliente in situ

• Integración contínua

• No crear cosas que se desecharán

Historias de usuario

Programación en parejas

Releases frecuentesReunión “Stand-up” cada día

Crear buenas arquitecturas

• SW funcionando >>

Documentation

• Propiedad colectiva

• Mejora de la calidad

iterativamente

• Colaboración >> Contrato

No todas las ideas/prácticaságiles son buenas

Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

Fuerzas que influyen los enfoque




Fuerzas que influyen los enfoquepara el desarrollo de software

Grado deCeremonia/control

en el proceso

Tiempo

1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s

Diapositiva obtenida de la presentación “A History of Agile Methods” presentada por Alan Davis en JISBD 2002

Q é res ltado pro een las




¿Qué resultado proveen lasMetodologías Ágiles?

Hay pocos datos concretos del índice de éxito deproyectosEstá teniendo un gran auge Aumento en el número de proyectos ¿Por qué?

Tiene el apoyo de muchos gurús en ingeniería de sw Es un proceso para gente que odia los procesos Tiene sentido ¿Política? ... Pugna entre comunidades




¿Cuándo utilizar unaMetodología Ágil?

¿Existe ya un proceso? Si¿Reacciona bien a los cambios? Si

¿Está el equipo contento con él? Si

Mejor esperar Se están recogiendo datos (red NAME)

http://name.case.unibz.it/ En un futuro se podrán hacer comparaciones

sobre lo que es más conveniente

http://name.case.unibz.it/

http://name.case.unibz.it/




... ¿Cuándo utilizar unaMetodología Ágil?

¿Existe ya un proceso? Noo existe pero no reacciona bien a los cambios o existe pero el equipo no está contento con él

Una Metodología Ágil puede ser una buenaforma de empezar

Fácil de financiar A los programadores les gusta A los clientes les gusta el control añadido




¿Qué hace la gente con las

Metodologías Ágiles?International Conference on eXtremeProgramming and Agile Methods in Software

Development (XP200x) http://www.xp2003.org

XP Agile Universe http://www.agileuniverse.com

http://www.xp2003.org/

http://www.agileuniverse.com/

http://www.agileuniverse.com/

http://www.xp2003.org/



Metodologías Ágiles y XP

Departamento de Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia

Fin de la Presentación

Patricio Letelier [email protected]

Me to Do Log i as a Giles y Extreme Programming

Documents

Transcript of Me to Do Log i as a Giles y Extreme Programming