T x 5:T x 5:TTips & ips & TTricks...ricks...

TTools, ools, TTechniques & echniques & TTechnologiesechnologies

eXtreme ProgrammingeXtreme ProgrammingJuan Carlos Fidalgo FernándezJuan Carlos Fidalgo Fernández

TTechniquechniqueses

T x 5 – XPT x 5 – XPConvenciones usadas y aclaracionesConvenciones usadas y aclaraciones

Colores utilizados: Código fuente Comentarios Pregunta/petición lanzada al público

T x 5 – XPT x 5 – XPAgile Development, Extreme Programming (XP)Agile Development, Extreme Programming (XP)

2ª ed. 20042ª ed. 2004 20042004

T x 5 – XPT x 5 – XPTest-Driven Development (TDD)Test-Driven Development (TDD)

20022002 20102010

T x 5 – XPT x 5 – XPRefactoringRefactoring

19991999 20072007

T x 5 – XPT x 5 – XPPatternsPatterns

20042004

20022002

19961996

19941994

T x 5 – XPT x 5 – XPModelo waterfall (en cascada)Modelo waterfall (en cascada)

El más antiguo, conocido y básico de todos los modelos para el desarrollo de software y ha servido como bloque de construcción para los demás paradigmas de ciclo de vida

Está basado en el ciclo convencional de una ingeniería y su visión es muy simple:el desarrollo de software se debe realizar siguiendo una secuencia de fases

Esencialmente, nos movemos al paso N+1 sólo cuándo se ha completado el 100% de N

Las etapas o actividades del modelo en cascada son requerimientos, diseño, programación, testing y mantenimiento

El modelo presente la ventaja evidente de su sencillez, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software

Sin embargo, presenta un gran número de [serios] inconvenientes: Los proyectos reales raras veces siguen el flujo secuencial propuesto por el modelo Al cliente le es difícil establecer todos los requisitos de forma explícita al principio

del proyecto(es habitual que se den situaciones descritas en el antipatrón “Analysis paralysis”)

El cliente debe ser paciente: no verá la solución hasta el final (ausencia de retroalimentación)

Si un requerimiento no fue tomado correctamente, o una decisión de diseño no fue acertada, … (amplificación de los errores)

T x 5 – XPT x 5 – XPLa crisis del software I: Standish Group ILa crisis del software I: Standish Group I

En 1985, un conjunto de profesionales de Massachussets se unió bajoel nombre de Standish Group

Su objetivo: obtener información de los proyectos fallidos en IT y así poder encontrar y combatir las causas de los fracasos

A lo largo del tiempo, el Standish Group reveló 50.000 proyectos fallidos

Concretamente, en 1994: El 31% de los proyectos fueron cancelados El 53% registró enormes desvíos en presupuesto y en cronograma El 16% se completó a tiempo y dentro de los costos presupuestados

(la funcionalidad comprometida sólo se cumplió, de promedio, ¡en el 61%!)

Sobre las causas de los problemas relacionadas con requerimientos: El 13% eran debidas a requerimientos erróneos El 12% a requerimientos incompletos Otro 12% a cambios en los requerimientos

T x 5 – XPT x 5 – XPLa crisis del software I: Standish Group IILa crisis del software I: Standish Group II

¿La respuesta a la vista de estos fracasos? La de la industria: durante los siguientes 10 años se invirtieron varios

miles de millones de dólares destinadas a mejorar la administración y la productividad(desarrollo y perfeccionamiento de metodologías y tecnologías – PMI, CMMI, …)

La del ciclo de vida en cascada: intentar con ahínco pulir, estabilizar y fijar los requerimientos antes de cualquier diseño o implementación

Los resultados de la encuesta del 2004 (10 años después) demuestran que estas inversiones no sirvieron de mucho: Los proyectos exitosos crecieron sólo al 29% Los proyectos fracasados representan el 71% E. d.:

7 de cada 10 proyectos se cancelaron o bien registraron desvíos del 45%sobre lo presupuestado en costos y del 63% en tiempos

Además apenas se cumplió con el 67% de la funcionalidad comprometida

T x 5 – XPT x 5 – XPLa crisis del software I: Standish Group y IIILa crisis del software I: Standish Group y III

Según el informe de Standish, las 10 causas principales de los fracasos son las siguientes (por orden de importancia):1) Escasa participación de los usuarios2) Requerimientos y especificaciones incompletas3) Cambios frecuentes en los requerimientos y especificaciones4) Falta de soporte ejecutivo5) Incompetencia tecnológica6) Falta de recursos7) Expectativas no realistas8) Objetivos poco claros9) Cronogramas irreales10) Nuevas tecnologías(7 de estos factores son factores humanos)

T x 5 – XPT x 5 – XPAgile (“Agilismo”) IAgile (“Agilismo”) I

Como reacción a los constantes fracasos de los métodos más pesados derivados del modelo en cascada, …

… fueron apareciendo una serie de métodos llamados “ligeros” XP era uno de ellos, pero había muchos más: SCRUM, FDD,

Crystal, … Cada uno de estos métodos ligeros tenía su propio conjunto de

principios, valores y prácticas, así como su propio grupo de partidarios

En el año 2000, Kent Beck reunió a los 17 más influentes de todos elloshttp://www.agilemanifesto.org/authors.html

El objetivo era ver si los valores y principios de los distintos métodos podían mezclarse de un modo consistente

Los asistentes, dejando a un lado sus diferencias, acordaron crear un manifiesto y un conjunto de principios que abarcase a todos los métodos

A estos principios también les dieron un nombre: Agile

T x 5 – XPT x 5 – XPAgile (“Agilismo”) IIAgile (“Agilismo”) II

“Estamos descubriendo mejores formas de desarrollar software,haciéndolo y ayudando a otros a hacerlo.A través de este trabajo hemos llegado a valorar: Individuos e interacciones por encima de procesos y herramientas Software que funciona por encima de documentación exhaustiva Colaboración con clientes por encima de negociación de contratos Respuesta al cambio (*) por encima de seguir un plan”Firmaban: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

http://www.agilemanifesto.org/http://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil(*) Respuesta al cambio… ¿os suena? RE: Formación OO día 1 de 4; año 2008

La orientación a objetos La orientación a objetos El desarrollo convencional vs. el desarrollo OO IIEl desarrollo convencional vs. el desarrollo OO II

En las metodologías funcionales (Yourdon, DeMarco, …) se hace un especial hincapié en especificar y descomponer la funcionalidad del sistema

Este enfoque puede parecer la forma más directa de implementarun objetivo deseado pero el sistema resultante puede ser muy frágil

Si cambian los requisitos, un sistema basado en la descomposición funcional puede requerir una importante reestructuración

En cambio, el enfoque OO se centra primordialmente en identificar objetos del dominio de la aplicación y ajustarles después los procedimientos

Puede parecer más indirecto, pero soporta mejor las evoluciones de los requisitos porque ...

... está basado en el entorno subyacente del dominio de la aplicación en si, más que en los requisitos funcionales de un único problema

La orientación a objetos La orientación a objetos ““¿Si cambian los requisitos?¿Si cambian los requisitos? Ah, entonces no me Ah, entonces no me

preocupa …”preocupa …”

“(*) El desarrollo iterativo es un enfoque en el que el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (p. ej., cuatro semanas) llamados iteraciones.El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. (**)

Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas.(…)El subtítulo de un libro que trata el desarrollo iterativo es Aceptar el cambio [Beck00].Esta frase evoca una aptitud clave del desarrollo iterativo: en lugar de luchar contra el inevitablecambio que ocurre en el desarrollo de software intentando (normalmente sin éxito) especificar,congelar y ‘firmar’ de manera completa y correcta a partir de un conjunto de requisitos fijos ydiseñar antes de implementar, el desarrollo iterativo se basa en una aptitud de aceptación delcambio y la adaptación como motores inevitables y, de hecho, esenciales.Esto no quiere decir que el desarrollo iterativo (y el UP) fomenten un proceso dirigido por ‘una adición de características’ de manera incontrolada y reactiva.El UP llega a un equilibro entre la necesidad – por un lado – de llegar a un acuerdo y estabilizar un conjunto de requisitos, y – por otro lado – la realidad de los requisitos cambiantes, cuando el personal involucrado clarifica su visión o cambia el mercado.” (***)

“UML y patrones” – Craig Larman

T x 5 – XPT x 5 – XPAgile (“Agilismo”) y IIIAgile (“Agilismo”) y III

Tras este manifiesto se encuentran 12 principios de vital importancia para entender su filosofía:

Satisfacción cliente a través de entregas tempranas y continuas de software valioso (prioritario) Requisitos cambiantes bienvenidos, tb en etapas finales desarrollo (ventaja competitiva cliente) Entregamos s/w que funciona frecuentemente: de 2 semanas a 2 meses (común 3-4 semanas)

(subjconjuntos con calidad de producción del sistema final; ¡no prototipos!) Gente de negocio y desarrollo deben trabajar juntos a diario durante todo el proyecto Construimos proyectos entorno a individuos motivados, dándoles apoyo y confianza La conversación cara a cara es el método más eficiente y efectivo de comunicar la información La principal medida de avance es el software que funciona Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y

usuarios deben poder mantener un ritmo constante La atención continua a la excelencia técnica y el buen diseño mejoran la agilidad La simplicidad, es esencial Las mejores arquitecturas, requisitos y diseños emergen de la autoorganización de los equipos Reflexión a intervalos regulares sobre cómo ser más eficaces y mejora+ajuste en consecuencia

http://www.agilemanifesto.org/principles.html

T x 5 – XPT x 5 – XP¿Qué es eXtreme Programming (XP)? I¿Qué es eXtreme Programming (XP)? I

XP es una metodología ligera que combina una serie de principios, prácticas y procesos

XP permite a equipos de desarrollo [¿pequeños?] construir s/w de forma rápida ycon calidad a pesar de requisitos “vagos o cambiantes” ¿“Y dos huevos duros”? – Groucho Marx RE: no, XP no lo hace tan incompatible. ¿Alguien cree que futuros cambios en los

requisitos en CCPPT – relativos a validaciones – podrían implicarme problemas serios?

XP está orientada fuertemente hacia la codificación y hace un gran énfasis en la comunicación informal, verbal

XP puede ser desplegada con éxito en entornos de pequeña, mediana o gran empresa

Aunque XP es relativamente nueva, sus prácticas existen desde hace tiempo;la metodología simplemente une y exprime “mejores prácticas”

XP es actualmente la más destacada de todas las metodologías ágiles(Scrum lo es a nivel de gestión de proyectos)

T x 5 – XPT x 5 – XP¿Qué es eXtreme Programming (XP)? y II¿Qué es eXtreme Programming (XP)? y II

Historia: C3 (“Chrysler Comprehensive Compensation System”) se inició en 1995 Su objetivo era crear para 1999 un nuevo sistema de nóminas (87.000

empleados) Un año más tarde, Kent Beck fue contratado para dirigir el proyecto:

¡el sistema no había impreso hasta la fecha ni un solo cheque! Kent Beck se trajo a Ron Jeffries En marzo de 1996 estimaron que el sistema estaría listo para entrar en

producción alrededor de un año después C3 concluyó con éxito en 1997

(con un par de meses de retraso pero que se consideraron justificados) Durante el proceso había nacido una nueva metodología:

eXtreme Programming (XP)

T x 5 – XPT x 5 – XPLas 12 prácticas de XP ILas 12 prácticas de XP I

Las 12 prácticas de XP:(ninguna de las prácticas establece algo por sí misma; todas requieren de otras para conseguir un cierto “equilibrio”)

T x 5 – XPT x 5 – XPLas 12 prácticas de XP y IILas 12 prácticas de XP y II

Las 12 prácticas de XP, agrupadas en 4 áreas, son: “Fine scale feedback” (retroalimentación a pequeña escala)

“Pair programming” (programación por parejas) “Planning game” (el juego de la planificación) “Testing” / “Test-driven development” (pruebas / desarrollo guiado por tests) “On-site customer” / “Whole team” (cliente in situ / equipo completo)

“Continuous process” (proceso continuo) “Continuous integration” (integración continua) “Short releases” / “Small releases” (pequeñas entregas) “Design improvement” / “Refactoring” (mejoras de diseño / refactorizar)

“Programmer welfare” (bienestar del programador) “Sustainable pace” / “40 hour week” (ritmo sostenible / 40 horas semanales) (*)

“Shared understanding” (entendimiento compartido) “[System] metaphor” (metáfora [del sistema]) – en STR limbo; otros: pizarra, saco, … “Coding standards” (estándares de codificación) (**)

“Collective [code] ownership” (propiedad colectiva [del código]) “Simple design” (diseño simple) – no siempre simple es sinónimo de fácil (***)

http://en.wikipedia.org/wiki/Extreme_Programming_Practices

T x 5 – XPT x 5 – XPLos valores de XPLos valores de XP

XP fomenta los siguiente 4/5 valores: Comunicación

(tanto entre todos los miembros del equipo como con el cliente y preferiblemente verbalen lugar de escrita)

Simplicidad(diseñar la solución más simple que funcione hoy vs. una complicada pensando en mañana:YAGNI: http://es.wikipedia.org/wiki/No_vas_a_necesitarlo_(YAGNI) )

Retroalimentación(entre cliente, usuarios y equipo y además cuánto más inmediata mejor: PP, IPC, …)

Coraje o valor(en el contexto de las otras: valor para refactorizar – tenemos tests para “cubrirnos” –,valor para la simplicidad – vs. YAGNI –, valor para el feedback – vs. la adivinación –, …)

Respeto(añadido en la 2ª edición de “Extreme Programming Explained: Embrace Change”)

T x 5 – XPT x 5 – XPLos roles de XP ILos roles de XP I

Cada proyecto XP tiene varios roles diferentes, cada uno con su propio conjunto de derechos y obligaciones

XP intenta mejorar la comunicación entre clientes y desarrolladores,para lo cuál divide claramente el trabajo entre los dos

Así, XP da a cada uno de ellos autoridad en su área de especialización:a los desarrolladores sobre las decisiones técnicas y al cliente sobrelas decisiones de negocio

De esta forma en XP se mejoran las posibilidades de éxito

T x 5 – XPT x 5 – XPLos roles de XP IILos roles de XP II

Customer (Cliente): Es parte del equipo Determina qué construir y cuándo Establece las pruebas de aceptación

Manager (Jefe de proyecto): Organiza y guía las reuniones Asegura condiciones adecuadas para el proyecto

Desarrollador (Developer):(sin distinción entre analistas, diseñadores o programadores; en XP los programadores diseñan, programan y realizan las pruebas) Responsable de decisiones técnicas Responsable de construir el sistema

Tester (Probador / verificador): Enfocado en ayudar al cliente Ayuda al cliente a encontrar y escribir pruebas funcionales Es responsable de correr las pruebas regularmente y poner los resultados en un

lugar visible

T x 5 – XPT x 5 – XPLos roles de XP y IIILos roles de XP y III

Existen un par de roles suplementarios que no están presentes en todos los equipos: Tracker (Rastreador):

“Metric Man”:mide las estimaciones del equipo y les informa en cuánto se equivocaron, paraconseguir mejores resultados la próxima vez (las estimaciones son esenciales en XP)

Debe saber si no se llega a finalizar una iteración e informar al equipo a tiempo Es responsable de tener una visión global Observa sin molestar Conserva datos históricos

Coach (Entrenador / preparador): Guía al equipo a entender XP cuando se adopta éste por primera vez Unas veces enseña directamente y otras “se remanga” y enseña a través de la

práctica Su principal virtud es la experiencia; debe entender XP en profundidad Puede sugerir cambios en la implementación, ofrecer ideas para resolver un

problema técnico espinoso, etc. pero siempre con una posición de respeto Tiende a estar en un segundo plano a medida que el equipo madura

T x 5 – XPT x 5 – XPXP vs. AgileXP vs. Agile

Algunas veces los términos “XP” y “Agile” se utilizan para referirse a lo mismo, mientras que otras significan cosas diferentes

¿Es “Agile” lo mismo que “XP”? ¿Es XP Agile? El término “XP” es unos años anterior a “Agile” XP es un conjunto de prácticas, principios y valores inventados

por Kent Beck y que se ajustan a los de “Agile” E. d., XP es un método concreto mientras que “Agile” es una

clasificación Así, hay muchos más métodos ágiles; XP es sólo uno de ellos

T x 5 – XPT x 5 – XPLa crisis del software y II: MIT Sloan Management La crisis del software y II: MIT Sloan Management

ReviewReview

Un estudio de 2 años, presentado en el MIT Sloan Management Review sobre los proyectos software con éxito, identificó 4 factores comunes: Desarrollo iterativo en lugar de un proceso en cascada Como mínimo una incorporación diaria de nuevo código para la

construcción del sistema completo y una rápida retroalimentación de los cambios del diseño(a través de las pruebas)

Equipo con experiencia en expedir múltiples productos Centrarse pronto en la construcción y prueba de una arquitectura

consistente

3 de estos 4 factores son prácticas explícitas en la mayoría[?] de las metodologías ágiles

T x 5 – XPT x 5 – XPLa tierra llamando al Jefe…La tierra llamando al Jefe…

¿En qué consiste el programa de cortes de precios en temporada?

Tras escuchar a Santi, cualquier programador que se precie habrá visto claro que necesitamos los patrones State, Command, Strategy, Façade,…

… ¿o no? 0;-) RE: No, o no necesariamente, o sí pero ahora no es el momento

de decidirlo. Dicho de otro modo, ¿sería eso aplicar “simplicidad”?

Cuando veamos TDD veremos como la arquitectura se va forjando en pequeños pasos a base de iterar y refactorizar, y no toda a priori

Carlos Blé hace una comparación muy ingeniosa:moldear una figura a golpe de cincel

Al final hay un artículo de Robert C. Martin sobre “Bowling” en el quetambién se puede apreciar esto de forma muy, muy clara

T x 5 – XPT x 5 – XPUser StoriesUser Stories

Una “user story” o historia de usuario es la representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario

Son usadas en las metodologías ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación)

Dentro de XP las historias de usuario deben ser escritas por los clientes

Son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar muchos documentos formales ni requerir mucho tiempo para administrarlos

Se caracterizan por prioridad, riesgo y esfuerzo Permiten responder rápidamente a requerimientos cambiantes o

poco claros El estilo puede ser libre pero la historia de usuario debe responder a tres

preguntas:¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio?

Por ello, algunos autores recomiendan redactarlas según el formato:Como (rol) quiero (algo) para poder (beneficio)

T x 5 – XPT x 5 – XPUser Stories: característicasUser Stories: características

Una historia de usuario debe ser: Independiente: De ser necesario, combinar las historias dependientes o buscar

otra forma de dividir las historias de manera que resulten independientes Negociable: La historia en si misma no lo suficientemente explícita como para

considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación

“Valiosa” (aportar valor a los clientes / usuarios): Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador

Estimable: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto

Pequeña: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo (tendrían que poder escribirse en un post-it).Generalmente se recomienda la consolidación de historias muy cortas en una sola historia

Verificable: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto

T x 5 – XPT x 5 – XPUser Stories: beneficiosUser Stories: beneficios

Si están bien escritas, los beneficios de las historias de usuario son: Son adecuadas para el desarrollo iterativo

(son cortas y por tanto de rápida implementación – días, semanas –, de tamaño idóneo para la planificación, permiten dividir los proyectos en pequeñas entregas, son fáciles de estimar, …)

Son comprensibles por todo el equipo(usan vocabulario del cliente y no técnico, eliminan la posible ambigüedad, no son listas interminables y tediosas de “El sistema debería bla, bla, bla”, …)

Enfatizan la comunicación verbal (cara a cara), fomentando una relación cercana con el cliente

Dan soporte al diseño “oportunista” y permiten diferir los detalles a la implementación(una historia no es ni pretende ser un registro exhaustivo de un requerimiento; cuando llegael momento de implementar una historia, el cliente – cara a cara – proporciona los detalles)

Favorecen el crecimiento del conocimiento tácito (extienden el conocimiento) Fomentan el diseño participativo Tienen un bajo mantenimiento Son ideales para proyectos con requerimientos cambiantes o no muy claros

T x 5 – XPT x 5 – XPUser Stories: limitaciones e inconvenientesUser Stories: limitaciones e inconvenientes

Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones

Se requiere un contacto permanente con el cliente durante el proyecto,lo cuál puede llegar a ser algo difícil o costoso

Puede resultar difícil escalar a proyectos o equipos grandes

T x 5 – XPT x 5 – XPUser Stories vs. IEEE 830User Stories vs. IEEE 830

El IEEE publicó un conjunto de directrices sobre cómo escribir las especificaciones de los requerimientos software

Este documento, conocido como IEEE Standard 830, fue revisado en 1998 Sus recomendaciones abarcan como organizar el documento de

especificación de requisitos, el papel del prototipado o las características de unos buenos requermientos

Un documento que siga este estándar se caracteriza por el uso de frases “El sistema…”, ya que es la forma recomendada para escribir los requisitos funcionales

Documentar los requisitos de un sistema a este nivel es tedioso, propenso a errores y muy laborioso

Eso por no mencionar que con documentos de este tipo hay que acabar asumiendo queno serán leídos por todas las personas que deberían, que los acusan de “aburridos”

Incluso aunque un usuario, p.ej., lea 100 hojas en lugar de ojearlas y no se salte nada, con un documento escrito a este nivel es muy difícil poder entender “la foto global”

T x 5 – XPT x 5 – XPUser Stories vs. Use Cases IUser Stories vs. Use Cases I

Los casos de uso fueron introducidos por primera vez por Ivar Jacobson en 1992

Un caso de uso es una descripción de un conjunto de interacciones entre el sistema y uno o más actores, dónde un actor puede ser un usuario u otro sistema

Hoy en día, los casos de uso están principalmente asociados al proceso unificado (UP)

Los casos de uso pueden ser escritos de forma no estructurada o siguiendo una plantilla, siendo las más utilizadas las propuestas por Alistair Cockburn\\sausr\Informatica\Comun\Desarrollo\Documentacion\Plantillas Word\Otros\Alistair Cockburn\\sausr\Informatica\Comun\Desarrollo\Documentacion\Plantillas Word\Otros\Vico\Descripcion Use Cases\\sausr\Informatica\Comun\Desarrollo\Documentacion\Plantillas Word\Proceso de desarrollo

Hay varios grados de formalidad al escribir un caso de uso: breve, informal y completo

T x 5 – XPT x 5 – XPUser Stories vs. Use Cases y IIUser Stories vs. Use Cases y II

Ambos describen escenarios y, si están bien escritos, deben añadir lo que se conoce como “valor cuantificable al negocio”. Sin embargo hay diferencias: Ámbito:

Las historias de usuario suelen tener un ámbito más pequeño que un caso de uso debido a las restricciones que ponemos a su tamaño (e. j.: no más de una semana de desarrollo)

Grado de completado: “Text on a story card plus acceptance tests are basically the same thing as a use case.” –

James Grenning(e. d., que la historia es el camino feliz de un caso de uso y los tests de aceptación las extensiones)

Longevidad: Los casos de uso son más longevos y continúan existiendo durante el desarrollo e incluso el

mantenimiento. Las historias de usuario, en cambio, no suelen sobrevivir a su iteración

Detalles (relativos al UI): Los casos de uso son más propensos a incluir detalles sobre el interfaz de usuario

(prototipos),a pesar de que muchos autores lo desaconsejan

Propósito: Los casos de uso son escritos en un formato comprensible para que clientes y

desarrolladores trabajen con ellas y lleguen a un acuerdo Las historias de usuario, en cambio, son escritas para facilitar la planificación de las

iteraciones y sirven como “recordatorio” para las conversaciones sobre las necesidades de los usuarios

T x 5 – XPT x 5 – XPCCPPT: User StoriesCCPPT: User Stories

El responsable comercial puede crear un corte de cadena nuevo a partir de un corte efectivo realizado mediante el simulador de cortes.

El responsable comercial puede buscar las fechas de corte de los cortes efectivos, realizados mediante el simulador de cortes, asociados a una campaña.

El responsable comercial puede suscribir países a un corte de cadena. El responsable comercial puede publicar un corte de cadena no publicado. El responsable comercial puede publicar un corte de cadena ya publicado con países suscritos

agregados. El responsable comercial puede consultar en qué estado se encuentra un corte de cadena y sus cortes

de país sugeridos asociados. Un comercial puede validar corte de países sugeridos (incluso aunque los comerciales responsables de

los países sean otros). Un comercial puede eliminar referencias a recortar de un corte de país sugerido. Un comercial puede rebajar el precio de venta nuevo de referencias de un corte de país sugerido. Un comercial puede aumentar el precio de venta nuevo de referencias de un corte de país sugerido. Dos días antes de la fecha de corte de un corte de cadena, se informará a comercial si éste tiene cortes

de país sugeridos pendientes de validar. . . .

T x 5 – XPT x 5 – XPATDD IATDD I

¿Cómo podemos garantizar que …? El objetivo se ha entendido bien (análisis):

que si el objetivo es A, no entendemos A’ La implementación se ajusta al objetivo (desarrollo):

que si el objetivo es A y entendimos A, no acabamos implementando A’ La implementación se mantiene ajustada al objetivo

(mantenimiento):que si el objetivo fue A y en su momento implementamos A, los cambios posteriores no acaben convirtiendo la implementación en A’

RE: Tests de aceptación (ATDD)

T x 5 – XPT x 5 – XPATDD IIATDD II

T x 5 – XPT x 5 – XPATDD IIIATDD III

Están basados en ejemplos de historias de usuario Son escritos antes del desarrollo y por el propio cliente

(o por “alguien” en estricta colaboración con él) Forman parte de la definición del “completado” ¡Normalmente son automatizados!

T x 5 – XPT x 5 – XPATDD y IVATDD y IV

http://www.concordion.org/Example.html http://www.concordion.org/Tutorial_es.html

T x 5 – XPT x 5 – XPCCPPT: Acceptance TestsCCPPT: Acceptance Tests

User Story:El responsable comercial puede suscribir países a un corte de cadena. Verificar que un corte de cadena no publicado no tiene países suscritos. Verificar que un corte de cadena no publicado no tiene países

pendientes de suscribir. Verificar que suscribir un país no pendiente de suscribir a un corte de

cadena no publicado, lo registra como pendiente de suscribir. Verificar que suscribir un país ya pendiente de suscribir a un corte de

cadena no publicado, "no hace nada". Verificar que suscribir un país no pendiente de suscribir y no suscrito a

un corte de cadena publicado, lo registra como pendiente de suscribir. Verificar que suscribir un país ya pendiente de suscribir a un corte de

cadena publicado, "no hace nada". Verificar que suscribir un país ya suscrito a un corte de cadena

publicado,"no hace nada".

T x 5 – XPT x 5 – XPTDD ITDD I

“Test-Driven Development (TDD) is a deceptively simple idea:write the tests for your code before writing the code itself.We say “deceptively simple” because this transforms the role testing plays in the development process and challenges our industry’s assumptions about what testing is for.Testing is no longer just about keeping defects from the users; instead, it’s about helping the team to understand the features that the users need and to deliver those features reliably and predictably.When followed to its conclusions, TDD radically changes the way we develop software and, in our experience, dramatically improves the quality of the systems we build, in particular their reliability and their flexibility in response to new requirements.”

“Growing Object-Oriented Software, Guided by Tests” – Steve Freeman & Nat Pryce

Del texto anterior se puede “deducir” algo más:TDD – como mucha gente piensa – es “un mal nombre”, ya que se trata de una práctica de programación y no de una técnica de testing(Peter Provost, Carlos Blé, …)

T x 5 – XPT x 5 – XPTDD IITDD II

“Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work.Of those disciplines, Test Driven Development is the most revolutionary and impactful.”

http://objectmentor.com/omSolutions/agile_xp_differences.html – Robert C. Martin

“TDD es la respuesta a las grandes preguntas de: ¿Cómo lo hago? ¿Por dónde empiezo? ¿Cómo sé qué es lo que hay que implementar y lo que no? ¿Cómo escribir un código que se pueda modificar sin romper funcionalidad existente?”

“Diseño ágil con TDD” – Carlos Blé Jurado Una vez “aclarado” esto, y sobre la importancia del propio

testing:“If it ain’t tested, it’s broken.”(si no está probado, está roto)

Bruce Eckel (autor de “Thinking in Java”)

T x 5 – XPT x 5 – XPTDD y IIITDD y III

El testing sucede a varios niveles: “Acceptance Tests”, para determinar si un sistema cumple con los

requerimientos del cliente (ATDD) “Unit Tests”, para determinar si los componentes individuales del

software cumplen los requerimientos funcionales “Integration Tests”, para determinar si el software encaja en el entorno

yla infraestructura y si dos componentes o más trabajan bien juntos

T x 5 – XPT x 5 – XPCríticas a XP ICríticas a XP I

“PP no puede funcionar: muchos programadores tienen gran sentimiento de posesión del código, piensan son los mejores conocedores de las herramientas y lenguajes que usan y que si alguien no lo entiende es que no sabe suficiente.” “While pair programming may sound tremendously inefficient, Alistair Cockburn and

Laurie Williams (2001) have studied it and found that not to be the case. They found that for a 15% increase in total programming time, pair programming leads to:- lower defect counts,- less code is written to solve the same problem,- problems being solved more quickly, - more people understand each piece of code and- an increase in developer job satisfaction”

“User Stories Applied” – Mike Cohn

T x 5 – XPT x 5 – XPCríticas a XP y IICríticas a XP y II

“El mito de las 40 horas semanales es un lujo para las exigencias del mercado”

“XP sólo puede funcionar con programadores muy buenos, como Kent Beck,capaces de hacer un buen diseño, sencillo y fácilmente extensible”

“XP es mas una filosofía de trabajo que una metodología” “Ninguna de las practicas defendidas por XP son invención de este método;

XP lo que único hace es ponerlas todas juntas” “XP esta pensado para grupos de pequeños programadores, más de 10 ya

seria muy complicado, y mas aún si no están en el mismo centro de trabajo” “XP / Agile = Cowboy Programming”

T x 5 – XPT x 5 – XPBajando el telón IBajando el telón I

Otros recursos: “Test Driven Development Primer with Peter Provost” (inglés

subtitulado)http://www.youtube.com/watch?v=JMEO6T6gkAA

“Antipatrones en TDD”http://www.carlosble.com/?p=225

“Bowling” (¡muy, muy recomendable!)http://www.objectmentor.com/resources/articles/xpepisode.htm

T x 5 – XPT x 5 – XPBajando el telón IIBajando el telón II

Recomendaciones: TDD sí y ahora; XP “no” aún – no de forma completa e inmediata

(p. ej. no Integration Continuous o Pair Programming) “Cry in the Dojo, laugh on the battlefield”

(“Llora en el dojo, ríe en el campo de batalla”) Es un proverbio japonés adoptado en el Aikido Guarda relación con la disciplina que requiere dicha arte marcial Aquí, se refiere a “llorar” en las sesiones de Tx5 para poder “reír” en los

proyectos

T x 5 – XPT x 5 – XPSumario ISumario I

Metodologías ágiles: Procesos iterativos e incrementales:

se entrega periódicamente (iteración) un producto al cliente(producto=subjconjunto con calidad de producción del sistema final; no prototipo)

Enfocados a mitigar el riesgo

T x 5 – XPT x 5 – XPSumario y IISumario y II

XP: Metodología de desarrollo ágil Busca un punto medio entre ningún proceso y demasiado proceso Características:

El cambio es bienvenido Orientado a la gente y no al proceso Menos orientado al documento

(exige una cantidad más pequeña de documentación para una tarea dada; la parte importante de la documentación es el propio código fuente más los tests)

Realizar las grandes decisiones lo antes posible en el tiempo para diferir su coste(cuánto más tarde se realice un cambio, mayor coste tendrá su implementación)

Coste del cambio en los modelos basados en el ciclo de vida en cascada

Fuente: http://osl.iu.edu/~lums/swc/www/swc.html

(la gráfica equivalente en XP es menos pronunciada, casi lineal)