Cry éQué es eXtreme Programming (XP)? Es una filosoffa para el desarrollo de software, basado en un conjunto de précticas utiles y técnicas probadas para implementar cédigo de forma que su disefio, arquitectura y codificacién permitan incorporar modificaciones y afiadir nuevas funcionalidades sin demasiado impacto en la calidad del ¢ LAS PROMESAS DE XP. Reducir el riesgo del proyect Mejorar la respuesta ante cambios en el negocio, Mejorar la productividad a lo largo de toda Ia vida del software, Los equipos XP producen software de calidad a un ritmo sostenible, SE CARACTERIZA Po: Funciona con equipos de eualquier tamafo. Los valores y principios detras de XP son aplicables a cualquier escala Se adapta a requisites vagos o que cambian répidamente, Sin embargo, también aplica en proyectos en los que los requisites no son tan volatiles. Sus cortos ciclos de desarrollo, que dan como resultado feedback tempranas, concretos y continuos. na la planificacién incremental, que genera un plan general que se espera que evolucione a lo largo de la vida del proyecto. Su capacidad para programar de manera flexible la implementacién de las funcionaldades, respondiendo a las necesidades cambiantes del negocio. Su dependencia de pruebas automatizadas, desarrollada con TDD, para monitorear el progreso del desarrollo y permitir que el sistema evolucione detectando los defectos lo mas pronto posible. Su dependencla de la comunicacién oral, las pruebas y el cédigo fuente para comunicar la estructura y la intenclén del sistema, Para ello usa la figura del Sistema de Metiforas (System Metaphor) para describ el sistema de forma sencilla, Se basa en un proceso de disefo evolutive que dura tanto como el sistema, Su dependencia de a estrecha colaboracién de personas activamente comprometidas con talento y la excelCmca tele Nailed VALORES VALORES ‘© Los valores son los criterios a gran escala que usarnos para juzger lo ‘que vemnos, pensamos y hacemos, Los valores aportan un propésito a las prdcticas y deben hacerse explicitas para que las practicas no se welvan rutinarias, Un desarrollador en una Retrospectva da tun feedback poco detallada y ambiguo. Yo ha dado un feedback pero este no es transparente _yno revela lo que realmente opina por temor a ser juzgado y que sus palabras se wuelvan en su contra posteriormente. Realmente se est ‘negondo a dar un feedback mas profundo de ‘mo ha vista el Sprint ya que no quiere tener responsabilidades por haber sid injustamente ‘cusado en el pasado. En este caso el desarrliador valora la proteccién por encima de lo comunicacién. " PRINCIPIOS PRACTICAS Las précticas son las actividades que se realizan dentro del equipo de forma continuada en el dia a diay conforme a unas reglas claras y objetivas. Su ejecucién da como resultado la adqulsicién de nuevas habilidades y experiencia, Las practicas son la evidencia de los valores y pueden cambiar dependiendo de la situacién , Si valoras Ja comunicacién, algunas de tus précticas probablemente sean: asistir a la Stand Up Daily Meeting a diario, 0 bien te preocuparés confusa y preferirés una reunién cara a cara, al envio de un email para aclarar las dudas. Por tanto, dards soporte a todo tipo de prdcticas que mejoren y fomenten a cuando recibas informacién Cry PRACTICAS PRINCIPIOS Los pri enden un puente entre los valores y las practicas. Son un sistema de normaso leyes ‘que deben ser cumplidas para que un sistema funcione adecuadamente. Ej. Un jardinero que pretenda repoblar una ‘montatia sabré que si planta pines, (a bierba no creceré ya que al competir por agua las roices tan extensas de los pinas mo les permitirén fo supervvencia. Por tanto, se basaré en el Principio de compari para ‘denticar qué plantas y drbotes pueden crecer fuerte y sanos juntas. Se puede oplicar ef mismo principio en ta creacién de un equipo de desarrllo a la hora de selecionar fos integrantes,COMUNICACION SIMPLICIDAD FEEDBACK RESPETO Cry Valores XP XP esta basado en valores. No se trata de un conjunto de regias, sino de una forma de trabajar de acuerdo a tus valores personales y corporativos. xP recomienda comenzar con los valores listados a continuacién y posteriormente agregar aquellos que se alineen con el comportamiento del equipo. La comunicacién es el valor més importante dentro de un equipo de desarrollo. Aunque algunos problemas son causados por la falta de conocimiento la mayorfa surgen por falta de comunicacién. Por tanto, cada uno es parte del equipo y se comunican cara a cara en lo daly. Se trabajard juntos en todo, desde la definiciin de requisitos hasta la cosificacién y se creard la mejor soluci6n al problema entre todos. La simplicidad es la esencia de XP, es es el més intelectual de los valores de XP, Por tanto, nos centraremos en hacer lo que se necesita y se nos pide pero nada més. Esto maximlzaré el valor creado para la inversién hecha hasta la fecha, Por esta razén, se tomardn pequefios pasos que nos hagan avanzar a nuestra meta y se mitigardn los fallos segun se den, De modo que erearemos algo de lo que estemos orgullosos de mantener a largo plazo a un coste razonable. EI feedback es una parte eritica de la comunicacién, Dado que los cambios son inevitables estos generan la necesidad de obtener feedback. Por consiguiente, usaremos este feedback para acercarnos més y més a nuestros abjetivas y en consecuencla las equipos de XP se esforzardn por obtener la mayor cantidad de feedback que puedan manejar lo mas ripido posible El coraje es la fuerza de voluntad que puede desarrollar una persona, sin miedo al fracaso, para superar ciertos impedimentos y que a veces se manifiesta como la tendencia ala accién. El coraje como valor sélees peligraso pero junto con otros se hace poderoso. En XP se emplea para decir la verdad sobre el progreso y as estimaciones. No se tere a nada porque nunca se trabaja sé, Silos miembros de un equipo no se preocupan por el resto ni el trabajo que hacen, XP no funcionard, Por ello, cada uno da Y¥ siente el respeto que ellos se merecen como un miembro valorado del equipo, Cada uno aporta valor incluso si es simple entusiasmo. Los desarrolladores respetan la experiencia de los clientes y viceversa y la direccién respeta nuestro Gerecho a aceptar responsabilidad y recibe autoridad sobre nuestro propio trabajo,Cry Principios XP Los principios permiten cerrar la brecha entre valores y practicas, proveyendo pautas especificas de dominio para encontrar practicas en armonfa con los valores. Los principios enumerados aqui no son los Gnicos posibles para guiar el desarrollo de software, pero estos son los principios que guian a XP. 14 prINcIPIOS Humanidad: €! software lo desarrollan personas y es importante tener presente que los factores humanos son la clave para crear un software de calidad, Economia: E! producto que se cree debe ser rentable tanto a corto como a largo plazo, debe producir beneficios. Beneficio mutuo: Uno de los principales principios de XP y de los mas dificiles de poner en practica, Propone pensar siempre en el beneficio de todas las partes implicadas en un desarrollo. Auto-similitud: Buscar soluciones similares en diferentes contextos, Los patrones de la forma de trabajo deben repetirse ‘adaptandolos ala situacién en la que estemos, Mejora: Excelencia en el desarrollo a través de la mejora. Se busca perfeccionar, no lo perfecto. Diversidad: Dos ideas sobre un disefio presentan una oportunidad, no un conflict Reflexién: Los buenos equipos piensan cémo y por qué hacen el trabajo, no esconden errores. Flujo: Entrega continua de valor. Oportunidad: Los problemas son oportunidades de cambio, Redundancia: Los problemas dificles deben poder resolverse de diferentes maneras, Fallo: Un fallo no es un desperdicio si me sirve para aprender algo. Calidad: No vas a ir mas répido aceptando rebajar la calidad. Pequefios pasos: :Qué es lo menos que puedes hacer que sea reconocible y que vaya en la direccién correcta? Responsabilidad aceptada: El que acepta algo se hace responsable de ello.Cry Practicas Las préctieas son un elemento que influye en el comportamiento de las personas y las hace ir en una direccién determinada desde donde estén hasta donde pueden estar con XP. Aunque aplicar una practica es una eleccién, las que se indican son précticas que funcionan y lo hacen aun mejor cuando se aplican juntas, ya que las interacciones entre las practicas amplifican su efecto, TIPOS DE PRACTICAS Las practicas se dividen en dos tipos: 13 précticas primarias y 11 corolarios. Las précticas principales son utiles ra inmediata, Puedes comenzar con independientemente de lo que esté haciendo. Cada una puede brindarle una m i ss de aplicar sin dominar antes las, seguridad con cualquiera de ellas. Sin embargo, los corolarios pueden resultar diffe prdcticas primarias. En las fichas posteriores se describe en qué consistenCOREE Ca (E3_ SeNTARsE 2uNTos (sIT TocETHER) Disponer de un espace [Link] el ave toa ol equine pueda Una forma de satsfacer le necesidad de espacio privado es imitandl. rndmero de horas de trabalo, co de vabajo debe promover que Norezca la cornunicacién, los cubleulos y las barreras que te impiden comunicarte con so, ‘Cuantas mas reuniones cara-a-cara, més humane y procuc rviete el proyec Be Tov0 EL EaUiPo (wHoL= TEAM) + Lagente necesita tener la sensacién de equipa: 0 Todos somes un equipo 9 Apeyames el trabajo, el crecimiento y el apren Los equipos son dinémicos, Size require un conjunt sctituces, trae a una parsons con ezas habilidaces al equipo Sia alguien rrosele requiere mas, se Hera y puede ira otras lugares sy espacio De TRABAJO INFORMATIVO Hacer que ol espacto de trabajo se empape del proyecto en el que estamos trabajando jetas con Ins historias de usuario en las paredes, Colocar también an un higarwsble Cry (BB) procmata PRevERO LAS PRUEBAS (TD) las prucbas 0 lo que es fo mismo aplica un Desarrollo Orientado ® Pruebas (Test Driven Development) Ventajas: Las pruebas sirven de especificacién y aclaran el aleance de! Cohesién y acoplamianto sies fc escribir el test, es una se de que tenemos un problema de dlesfa EI ebdigo obi Conflanza - escrblende céxiga linpio es muy fa a pregromande. Con el enfoque de test-first asta to que hoy ‘ue hacer @ continuacisn: 0 escribimas ung prueba © hacemos ‘ue funcione una prueba rota (broken test) Elciclo que se genera 8 _rmaars0 enencizano fenenoize> wong ‘Trabajar a plane rencimierto, nero solo tantas heras come se pueda ser productive do forma sostenida. CCon sucionteeafeina es muy fécllegar al punto en ue se escribe quita valor al proyecto y (lo mis pot que ol eédige + Es posible aumentar la productivided geationande mejor el tempo. Por elemplo, dec Programacién, descanectar fos e-mails y fos mévles y dlicarse ar una franja de das horas come Tiempo deCORE al By PROcRAMACION EN PAREZA(PAIR PROGRAMMING) Todo al eédige que va» produccién debe ser escrito por dos personas sentadas frente a la méquina, Pair programming es un didloge entre dos personas ave estan simulténeamente anaizand disefand, probanda eintentanda programar meior © Semantienen centrados mutuamente © Seclantican ideas © Sevencen fos bioqueosinavicuoles © Secumpien mejor ios esténdores del equipo Consejos © Ne invedirel espace personal de ot (monitores grandes) (D)_cicto semanas weeny evets) + Reunign al comienzo de cada semana, ‘Revision del pragreso hasta a feche,incluyendo siel progres Je la semono previa se corresponde con lo previsto| © Hacer queef cliente excaia historias que sumen una semona de ‘+ Comenzar ia semana escribiendo las pruebas autométieas que se realzaran cuandolas historias exten completas y aasar el esto de la semana implementandolase integrandbolas en el proyacta, {final de la semana las nuevas historias deben estar disponibles para ser desplegadas. La somana es un ciclo corto para poder hacer experimentos del esto “vamos a ura la técniea del Pomodoro durante una semana” o esta semana eambiamos de pareja cada hor Cry HISTORIAS DE USUARIO (STORIES) rib las Historias de usuario en tarjetas pequefas incicando un Es més adecuado hablar de “historias” que de “requistos” (palabra con connctaciones ae “inmutabildac" y “permanencla' que no son ceampatibes con “abrazarelcambia" ‘Al estimar cada historia es fil darce cuenta del corte de cad una de teliaey podemos combinalas, priorizarlas. ‘Colocar las tarjtas en la pared en un sitio visible, no en un programa = Recomendamoseluse den tablero Kanban E23 _cicto TrIMEsTRAL (QUARTERLY CYCLE) cconveniente hacer reuniones con un ciclo superior al emanal para ver la evolucién del proyecto en conjunta ada S meses: Escoger historias que sumen un trimestre para cumpli eon los temas ascogidas Centrorse an una visién general de mo el proyecto encaja en la lorganizacién yd valor que anade Los timestres también son un buen ciclo para reflexionar sobre el ‘equipo, proponer y evaluar experimentos cue duren mas de unsORE eae 1B) Teasazan con woLcuna Aca) ‘Trabajarcon un cierto colchén que suaview Ia tonsién de cumple compromises imposible. Es importante eatablecer una atméefera de conflanza en la que lo ue pideny lbs que desarrolan elproducto se comunican de forma dlaray honest, ‘Trabajar con plazos no reallstas introduce errores inmane| Jones antagonistas CCumpli los compromisos, incluso miodestos, elimina desperdicios la moraly constuye lbs tensiones, mejor Is crecibilcad y construye ur relaciones basadas on la cornunieacion honest 6° INTEGRACION CONTINUA (CONTINUOUS INTEGRATION) No dejar pasar més de dos horas sin integra os cambios que heros pregramaso. La programacin en equipo es un problema de "avde, veneer © integra" La Integracién os un pate no predecible que puede costa mas que Integracin sincrona: cad pareja despude de un pr de horas ube st cambios yexpera aque se compete el build se hayan pasado todas ls pruebas sin ringun problema de egresion. Integracién asncrona: cada noche se hace un build dario en elque se construe la nueva versio delssteme Siceproducen erates erotica conaleras de eri El sistema resultante debe ser unsatomsa isto para fanzarse sin domasindos problemas. Sil cbt es desplegar una web hay ue deeplgar la web fon el entorno de staging) Cry 5% CONSTRUCCION DE 10 MINUTOS (10" BUILD) 10 minutos para construrautoms edo el proceso de build y de paso de as automatizade, No comprobarsélo las pruebas ea nueva parte ahadida a tema sino todas las anteriores, mente todo ol stoma y En continuous delivery so va un paso mas allay se automatiza ambien el despliegue yl lanzamiento de las nuevas furcionalidades en produccién DISEfIO INCREMENTAL (INCREMENTAL DESIGN) Disefio gradual, con pases pequetiosy seguros. El disefo no debe hacerse s6lo al principio, sino conforme vamos Invert cada dla en el disefo del sistema, luchando por ver cémo Pensar todo el tempo en el problema en conjunto, buscando forma ‘mejor, trabajar gradual pero continuamente para alinear el sistema real {Les equipos XP tabajan cura para crear las conclciones bajo las que el cote de cambiar el software sea bajo. Una regi sencilla para mejorar el cise: eliminar Ia duplicacién,Haz que las personas cuyas vidas y negocios se vean afectadios por tu ister formen parte del equips. + En general euanto més se acerquen las necesidades del ellente alas funclonalldades del desarrollo, més valioso ae valves el desarrall. 1 Lainelusion de cientes en elproceso de desatallofomentala ‘confianza y a mejora continua, @- (@j conminuipan DEL EQUIPO Un equipo de desarrollo debe mantenerse aunque se camble de proyecto, De esta forma se mantiane la efectividad del equipo Las relaciones y ls logros del equipo aportan valor al software. Igrorar el val de las relacionesy Ia confianza para simpiica los Que los equipos 2e mantengan unidos ne impllea que sean completamente estétices. En cualquier momento nuevos miembr pueden incarporar fementando una otacion azonable dentro del {equipo propercionando 2 la compania los benetcios de los equipos estables asi coma la prepagacién del conocimiento la experiencia en ola Cry BL esPLiecue WcREMENTAL Luna prctica corolario aue puede aplicarse tanto al reemplazamiento de sistemas Legacy come migraciones masivas de consis en modifieat primero algunas de sus functonalldades del producto ya exstentes sobre el que seestévabsjandoy poco a pees ir ‘modifieande el resto de forna incremental SRE nepucie 10s equiros Con elsiempo un eauina ser cada vez mas productiva, Mantenienda carga de trabajo, se podré enviat @ alguno de sus miembros a formar Evita crear equipos cada ver més grandes ya que ol rensimiento delPORE Carlee CE) A antusis de causa raz Cada ver que se encuentre un defecto seo fiminar el dofecto y su cometa el mismo tipe de error de nuevo. Un ejercicio simple que se puede aplicar para ello es usar la téenlea de los 5 Porqués ae Taichi Ohno. NEGOCIAR EL ALCANCE DEL CONTRATO Eseriba contratos que fen eltlempo, los costes y ance preciso del sistem: continua mediante contrates cortes en lugar de uno large Les contrates grandes y largos se pueden dividiren la mitad en ‘tercios.Y sila solictud de cambio en un contrato ae muy costors, £2 puede redactar con menos aleance ‘jo por calidad, perono Jantadoy menores tos paral = para. ol desarrollo de software resulta mas ily menos oriesgado negectar varies contrates de durscién més cota far de Negectar el alcance del contrato es un mecanieme para alinear los tar la comunieacin y' retroalimentacién,y par tener la oportunidad de mostrar elcoraje ae go inefieaz sole porque extéenel Cry aaae 1201 pRopiepap coLectiva DEL coDIco ++ Todos tos miembros del equipo sienten o cédige como suyoy se ssponsabilizan del mismo por igual Cuslquier miembro del eauio EB copiricacion v PRUEBAS + Los elementos clave del proyecto ave ne ge pueden dejar de mantener momento, en todo lugar CODIGO BASE UNICO @,_vespuecue piano CCada dia debe ponerse el e6digo desarroliado en preduccion pars evar un destace entre la cima version de software y la oe cada maquina local. Para poder desavolar esta practica CoFelaro a imprescindiole el dominio ce las primavias asi como el Coralia Despliegue incremental SE PACARPOR FUNCIONALIDAD + Si se paga por funcion: lrg el desarrollo, 1d, $0 sabré con precisién hacia dénde