Programació extrema

La programació extrema —extreme programming en anglès, XP— és un mètode o una aproximació a l'enginyeria de programari, formulat per en Kent Beck, que va escriure el primer llibre sobre la matèria, Extreme Programming Explained: Embrace Change (ISBN 0201616416). És un dels diversos processos àgils de desenvolupament.

Aquest article o secció no cita les fonts o necessita més referències per a la seva verificabilitat.

Característiques fonamentals de la programació extrema

• Desenvolupament iteratiu i incremental: petites millores, una rere l'altra. Proves unitàries contínues, sovint repetides i automàtiques, incloent proves de regressió. S'aconsella d'escriure el codi de la prova abans de la codificació. Per exemple, JUnit.
• Programació per parelles: es recomana que les tasques de desenvolupament es duguin a terme per dues persones en un mateix lloc. Se suposa que la major qualitat del codi escrit d'aquesta forma (el codi és revisat i discutit mentre s'escriu) és més important que la possible pèrdua de productivitat immediata.
• Freqüent interacció de l'equip de programació amb el client o usuari. Es recomana que un representant del client treballi juntament amb l'equip de desenvolupament.
• Correcció de tots els errors abans d'afegir una nova funcionalitat. Fer entregues freqüents.
• Refactoreig del codi, és a dir, reescriure certes parts del codi per tal d'augmentar la seva llegibilitat i manteniment però sense modificar el seu comportament. Les proves han de garantir que en el refactoreig no s'ha introduït cap errada.
• Propietat del codi compartida: en lloc de dividir la responsabilitat en el desenvolupament de cada mòdul en grups de treball diferents, aquest mètode promou que tot el personal pugui corregir i estendre qualsevol part del projecte. Les freqüents proves de regressió garanteixen que els possibles errors seran detectats.
• Simplicitat en el codi: és la millor manera de què les coses funcionin. Quan tot funcioni es podrà afegir funcionalitat si cal.

Valors

Per a garantir l'èxit d'un projecte, es consideren fonamentals els següents valors:

• Comunicació. La majoria de problemes són causats per manca de comunicació. Per aquesta raó, la comunicació entre els membres d'un equip i entre equip i clients s'ha de maximitzar. Un altre tipus de comunicació és entre els desenvolupadors i el codi. El codi ha d'expressar una intenció, no un algorisme. D'aquesta manera, no importarà qui hagi escrit cap funció perquè es podran llegir i modificar amb facilitat.
• Simplicitat. Esforç en fer que les coses més simples funcionin. No obstant això, aconseguir-ho és molt difícil. Requereix experiència, idees i treballar de valent. La simplicitat afavoreix la comunicació, redueix el codi i millora la qualitat. La principal pauta és no planejar futures possibles necessitats (noves característiques, quan realment es necessiten, seran fàcils d'afegir en un sistema simple).
• Realimentació. Les eines fonamentals de realimentació són l'estret contacte amb el client i la disponibilitat d'un conjunt de proves automatitzades, desenvolupades amb el mateix sistema. Requereix moltes i contínues proves per assegurar que el sistema funciona en tot moment. Així, quan es fan errors es troben immediatament.
• Coratge. Totes les metodologies i processos són eines que redueixen els temors. Com més por faci un projecte, majors i més dures seran les metodologies que es necessitaran. Comunicació, simplicitat i realimentació permeten afrontar amb coratge fins a grans canvis en requeriments. El coratge sol és perillós, però amb altres valors es converteix en una poderosa eina per afrontar canvis.
• Humilitat. Aquest valor deriva dels quatre anteriors. Si els membres d'un equip no es preocupen per ells ni pel seu treball, cap metodologia funcionarà. S'ha de ser respectuós amb els companys i les seves aportacions, amb l'empresa i amb aquells que estan implicats en el codi que s'està tocant.

Amb aquests cinc valors, XP assegura dissenys i codis simples, mètodes eficients i clients contents. Els cinc valors no donen consells específics sobre com portar un projecte o com escriure programari. Per això, es necessiten unes pràctiques, i abans de les pràctiques, uns principis.

Principis

• Humanitat. El programari el desenvolupen persones, per tant els factors humans són la principal clau de la qualitat del programari. XP assigna els objectius a la gent i les seves organitzacions, pel benefici d'ambdós. Però és necessari trobar un equilibri entre objectius: Si se sobreestimen les necessitats de la gent, no es treballarà adequadament, amb la conseqüent baixa productivitat i pèrdues en el negoci. I si se sobreestimen les necessitats de l'organització, hi haurà inquietud, excés de treball i conflictes.
• Economia. En XP es diu que un dòlar avui val més que un dòlar demà. Aleshores, quant més aviat guanyi diners el desenvolupament de programari i més tard el gasti, més benefici crea el software. És molt útil poder endarrerir les despeses de disseny fins que siguin òbvies.
• Benefici mutu. Qualsevol activitat hauria de beneficiar a tota la gent i organitzacions implicades. Potser és aquest el principi de XP més important i el més difícil de mantenir. Sempre hi ha solucions senzilles per a qualsevol problema, on uns guanyen i altres perden. Sovint, aquestes solucions són dreceres temptadores. No obstant això, sempre suposen pèrdues perquè desmunten relacions personals i deterioren l'ambient de treball. Serà necessari solucionar més problemes dels que es creen. Per tant, són necessàries pràctiques que beneficiïn tant al treballador com al client, ara i al futur.
• Similitud en si mateixa. S'ha de ser capaç de reutilitzar solucions similars en diferents contextos. Per exemple, un patró bàsic de XP és escriure proves que fallen, i escriure codi que passi les proves. Això és cert en diverses escales de temps: en 15 minuts, s'enumeren els temes a resoldre, i llavors s'escriuen les històries que els descriuen; en una setmana, s'enumeren les històries a implementar, s'escriuen les proves d'acceptació i finalment s'escriu el codi que passi les proves; en poques hores, s'escriuen proves unitàries i després el codi capaç de passar-les.
• Millora. La clau són les contínues millores. La perfecció no existeix però s'ha de fer un esforç continu per aconseguir-la. A la pràctica, en cada iteració el sistema millora en qualitat i funcionalitats, utilitzant realimentació del client, de proves automatitzades i de l'equip en si.
• Diversitat. Els equips on tothom és del mateix estil són agradables, però no efectius. S'han d'incloure diferents coneixements, habilitats i caràcters per descobrir i solucionar problemes. D'altra banda, ser diferents porta a conflictes potencials, que han de ser controlats i resolts. Tenir diferents opinions i proposar distintes solucions és molt útil en desenvolupament de programari si es poden controlar i resoldre els conflictes i escollir la millor alternativa.
• Reflexió. Un equip efectiu no només fa el seu treball. Els membres de l'equip es qüestionen com treballen i per què treballen així. No amaguen errors i els fan explícits e intenten aprendre d'ells. Durant iteracions de 15 minuts i setmanals, es prenen un temps per reflexionar sobre com està funcionant el projecte i quines són les possibles millores. No obstant això, no s'ha de pensar en excés. L'enginyeria del programari té gent tan ocupada pensant sobre la millora del procés que ja no escriuen programari. La reflexió va després de l'acció, i abans de la següent acció.
• Flux. XP assumeix un continu flux d'activitats, no una seqüència de diferents fases amb llançament del programari només després de l'última. Només el flux continu permet la realimentació per assegurar que el sistema evoluciona en la direcció correcta i evita problemes relacionats amb la integració final big-bang.
• Oportunitat. Els problemes han de veure's com una oportunitat per a millorar. Sempre poden experimentar-se problemes, però per obtenir qualitat no es pot simplement corregir-los, sinó convertir-los en oportunitats d'aprendre i millorar. Per exemple, si un únic desenvolupador comet massa errors se'l posa a programar en parella.
• Redundància. Els problemes crítics i difícils haurien de resoldre's de diverses maneres. Així, si una solució falla, les altres eviten el desastre. El cost de la redundància és fàcilment amortitzat en aquests casos. Els defectes en programari han de buscar-se, trobar-se i reparar-se de moltes formes (programació en parelles, proves automatitzades, seure junts, implicació del client, etc.).
• Error. Si no es pot tenir èxit, falla. Si no se sap com implementar una història, llavors cal implementar-la de 3 o 4 formes. Encara que totes fallin, s'haurà après molt. L'error és útil sempre que t'ensenyi quelcom. Per tant, no s'ha de tenir por a fallar perquè és millor provar alguna cosa i fallar que endarrerir massa una acció intentant fer-la bé des del principi.
• Qualitat. La qualitat ha d'estar sempre al màxim. Acceptar una qualitat més baixa no produeix ni estalvis ni desenvolupaments més ràpids. En canvi, millorar la qualitat millora per força les característiques del sistema com la productivitat i l'eficiència. A més a més, la qualitat no és només un factor econòmic. Els membres de l'equip han d'estar orgullosos del seu treball perquè millora l'autoestima de l'equip i la seva efectivitat.
• Passos petits. Grans canvis en un llarg període són perillosos. És millor procedir iterativament en passos petits, el pas més petit que pugui ser apreciat en la direcció correcta. Aquests passos no tenen per què procedir lentament. Se’n poden fer molts en poc temps. Una de les raons per les quals XP dona suport als passos petits és perquè un pas petit en la direcció equivocada produeix petits danys, mentre que un gran pas que falli pot danyar el projecte de forma severa.
• Responsabilitat acceptada. És fàcil ordenar als desenvolupadors "fes això" o "fes allò altre", però aquest mètode no funciona. Inevitablement, demanes menys del que es podria aconseguir o, sovint, més del que es podria complir. De totes maneres, la persona que rep l'ordre decidirà realment si ser responsable i acceptar l'ordre, o bé no ser responsable i passar la pilota a algú altre.

Chrysler Comprehensive Compensation

El primer cop que s'usa la programació extrema (XP) és en el projecte de Chrysler Chrysler Comprehensive Compensation (C3), un sistema per gestionar tots els pagaments dels quasi 90000 empleats de la Chrysler de l'any 1995. El projecte va començar com qualsevol altre, usant una metodologia tradicional, però un equip de 26 membres no va aconseguir cap resultat en els 15 primers mesos. Al març del 1996 Kent Beck es va fer càrrec del projecte i aprofità aquesta oportunitat per proposar i implementar canvis en la manera que hi havia de programar, basats en la feina que havien estat fent juntament amb Ward Cunningham. A més, convidà a Ron Jeffries a formar part del projecte per ajudar a desenvolupar i refinar aquests mètodes i ensenyar aquestes pràctiques a l'equip de C3. En tan sols 3 setmanes ja s'havia imprès el primer xec dels quasi 90000 empleats. Després d'això només calia preparar el sistema per imprimir els xecs restants. L'agost del 1998 C3 ja pagava els xecs de 10000 empleats, tot i que finalment va ser cancel·lat a principis del 2000 perquè el projecte ja no calia. El sistema anterior havia superat l'efecte 2000 i el nou projecte estava resultant massa car.

Tot i això el projecte C3 havia fet un canvi, era el primer gran projecte que utilitzava una metodologia àgil, i havia donat resultats, parcialment. Temps després Jawed Siddiqi va explicar:

"Els problems que el projecte C3 va acabar trobant-se, per problemes de comuniació entre l'equip de desenvolupament i els dos equips d'accionistes administradors (el departament IS era el client i el departament de nòmines era l'usuari), va presentar una preocupació significativa perquè la comunicació entre els clients i l'equip es troba en el cor de l'aproximació XP."

Amb aquest projecte varen quedar diverses coses demostrades sobre la XP:

• Es poden desenvolupar projectes importants.
• Els projectes poden ser de llarga durada (aquest va durar 4 anys).
• No només és per a projectes petits, C3 constava de 2000 classes i 30000 mètodes.
• La comunicació amb el client és fonamental.
• Es pot fracassar.

Com, quan i perquè utilitzar la XP

Com a MA que és, la XP basa el seu desenvolupament en les funcionalitats, en les coses que realment importen per assolir els objectius del projecte. En el cas de la XP el que realment importa és:

• Codificar: si al final del dia el programa no fa res, aquell dia no s'ha fet res.
• Verificar: saber si s'està fent bé o no. Una verificació s'ha de programar abans que el programa, d'altra manera només es verifica que fa bé el que ja se sap que fa.
• Escoltar: abans de fer res cal saber quin és el problema que s'ha de resoldre. Per això cal escoltar atentament al client.
• Dissenyar: cal observar el programa, saber quina estructura demana i donar-li. Sinó es fa així es caurà sota el pes de les suposicions i presuposicions que s'hagin fet.

Aquests són els 4 fonaments de la XP. Per assolir l'objectiu que busca la XP els seus ideòlegs descriuen com s'ha de tractar cada un dels punts importants, donen una sèrie de regles i pràctiques per a aconseguir-ho. A continuació es descriuen les regles i pautes descrites per cada un dels punts importants a l'hora de desenvolupar un projecte segons la XP.

Codificant

• El client sempre està disponible. La presència del client dins l'equip és una de les pràctiques, a part de més innovadora, més important. Com ja s'ha vist en l'exemple del C3 de Chrysler, la comunicació és un punt fonamental dina la XP. No només perquè cal escoltar al client sinó també per integrar-lo dins l'equip i fer-lo partícip tant de l'èxit del projecte com del fracàs d'aquest. La responsabilitat del client consisteix a descriure les històries d'usuari i planificar les històries a desenvolupar en cada una de les iteracions.
• El codi ha de seguir els estàndards acordats. Per mantenir la consistència i ser fàcilment llegit pels integrants de l'equip cal seguir una codificació estàndard. Un exemple d'estàndard de codificació és Smalltalk Best Practice Patterns escrits per Kent Beck.
• Codificar la unitat de verificació primer. Codificar primer la unitat de verificació fa que desenvolupar el codi de l'aplicació sigui més ràpid i més fàcil. Només cal desenvolupar el codi necessari per passar el test. Es desenvolupa tan sols el que és necessari i que serà utilitzat, el resultat és el codi més simple.
• Tota la programació de codi es fa amb programació en parella. La programació en parella incrementa la qualitat del codi i, gràcies a la qualitat, no provoca cap pèrdua de temps al final del projecte.
• Les parelles no integren codi al sistema simultàniament. Quan un codi s'integra al sistema prèviament es verifica sobre aquest. Si dues parelles integren codi simultàniament l'integraran a un sistema sobre el que no s'ha verificat el nou codi a causa de l'aparició del codi nou de l'altra parella.
• Integracions freqüents. Cada poques hores les parelles han d'integrar un nou codi al sistema. D'aquesta manera a més de resultats les altres parelles poden desenvolupar sobre l'última versió del sistema.
• Utilitzar codi comú. Tothom té dret a introduir canvis en el codi desenvolupat per una altra parella. El resultat són idees noves, una major qualitat al sistema i més implicació de tots els membres de l'equip sobre el codi.
• Deixar les optimitzacions pel final. No s'ha d'optimitzar ni una línia de codi fins que no es té tot el codi programat i verificat.
• No fer hores extres. Les hores extres treuen l'esperit desitjat a l'equip i fan baixar el nivell de qualitat del sistema. Si falta temps per acabar és millor fer una reunió i acordar canviar la planificació de la iteració.

Planificant

• S'escriuen històries d'usuari. Les històries d'usuari tenen la mateixa finalitat que els casos d'ús, però no són el mateix. Les històries d'usuari les escriu el mateix usuari i en elles descriu una cosa que vol que el programa faci.
• La planificació d'entrega marca el calendari. Les històries d'usuaris es planifiquen en les reunions de planificació d'entrega. Cada membre de l'equip pren les decisions referents tant a l'aspecte tècnic com als plans de negoci. Un cop es tenen estimades totes les històries d'usuari entre els desenvolupadors i el client es decideix quines històries es faran en la present entrega i quines en la següent. L'ordre es decideix tant per la importància que tingui cada una de les històries com per la seva prioritat.
• Fer petites entregues sovint. Les petites entregues permeten al client veure el desenvolupament del projecte i retroalimentar-se amb les opinions que dona el client. En les planificacions d'entregues s'han d'agrupar les històries per poder donar al client petites versions del sistema sovint.
• Es mesura la velocitat del projecte. La velocitat del projecte mesura la quantitat de feina que s'està fent en el projecte. Per calcular-la s'agafen totes les històries d'usuari finalitzades en la iteració actual, i aquesta quantitat es fa servir per, en la següent reunió de planificació d'iteració, decidir quantes històries d'usuari es faran en la iteració que es planifica. Aquesta velocitat va variant al llarg del projecte, això fa que la quantitat d'iteracions o de feina per iteració variï.
• El projecte es divideix en iteracions. El desenvolupament iteratiu dona al projecte molta agilitat. XP recomana dividir els projectes en 12 iteracions d'entre 1 i 3 setmanes cada una. És important que totes les iteracions tinguin la mateixa duració, altrament la velocitat del projecte quedaria alterada. Les iteracions inclouen les tasques de verificació del codi desenvolupat.
• La planificació de cada iteració es fa al començar la iteració. La planificació de les tasques a realitzar just en el moment en què es comença la iteració, i no setmanes o mesos abans, permet adaptar-se amb molta facilitat i sense pèrdua de temps al canvis que sorgeixin. Al començar cada iteració s'escullen quines històries es faran. El nombre d'històries ve marcat per la velocitat de projecte assolida en la iteració anterior.
• Moure la gent. Moure la gent, fer que tothom treballi amb totes les tasques evita que hi hagi tasques que només sàpiga realitzar un membre de l'equip. Si hi ha més d'un membre de l'equip que conegui cada una de les àrees de treball s'evita la pèrdua de temps que pot suposar que un membre de l'equip marxi o que aquest estigui saturat de feina. Amb el coneixement general de tothom s'eviten colls d'ampolla.
• Una reunió a peu dret per començar el dia. Durant un projecte pot passar sovint que una tasca es quedi encallada per un petit problema que es pot resoldre parlant amb un altre membre de l'equip, ja sigui per resoldre un malentès o perquè l'altre s'ha trobat en el mateix problema i l'ha solucionat. Una reunió matutina promou la comunicació entre els membres de l'equip, cadascú pot explicar les solucions que ha trobat, els dubtes que té i a la vegada es promou l'esperit d'equip. La reunió és a peu dret per evitar que s'eternitzi.
• Personalitzar l'XP. L'XP dona una sèrie de pautes a seguir, però és clar que per aplicar-lo a cada projecte en particular hi haurà regles que serviran, d'altres que s'hauran de modificar i d'altres que no se seguiran.

Dissenyant

• Simplicitat. Fer les coses tant senzilles com es pugui. Un codi senzill és més fàcil de programar, més barat i més fàcil de canviar posteriorment. Cal mantenir-ho tot senzill i no afegir mai noves funcionalitats que no són requerides o que encara no estan previstes.
• Escollir un sistema de metàfores. Fer servir un sistema de metàfores, i que tot l'equip el tingui interioritzat a l'hora de posar noms a les classes, pot evitar programar una classe i després trobar-se que aquesta ja existeix.
• Utilitzar cartes CRC per les sessions de disseny. Classe, Responsabilitat i Col·laboració (CRC). Cada targeta representa un objecte, l'objecte és d'una Classe té unes Responsabilitats i Col·labora amb una sèrie d'objectes d'altres classes. En una sessió de CRC es tenen les targetes sobre la taula, en cada una s'hi escriuen els objectes necessaris per al disseny, i cada membre de l'equip les organitza com creu que haurien d'estar relacionades. D'aquesta manera s'aconsegueix que tothom expressi la seva opinió i se'n tregui el millor de cada idea.
• Crear solucions puntuals per reduir el risc. En cas de preveure un risc dins una història d'usuari es recomana, abans de fer l'estimació d'aquesta o d'acceptar-la fer una solució puntual. La solució puntual (spike solution) consisteix a simular el maquinari del que es disposarà i intentar simular la història que es demana. Si s'aconsegueix una aproximació a la solució de la història es pot fer una estimació d'aquesta reduint molt el risc, i a la vegada ja es té una part de la feina feta.
• No afegir funcionalitats abans d'hora. Desenvolupar funcionalitats addicionals que es preveu que puguin ser necessàries tendeix a ser una pèrdua de temps. En qualsevol moment el requeriments poden canviar i pot ser que aquesta s'hagi d'eliminar.
• Refactoritzar sempre que es pugui i quan es pugui. Refactoritzar consisteix en eliminar redundàncies, eliminar funcionalitats no utilitzades, rejovenir un codi obsolet. Refactoritzar permet mantenir un disseny més simple, mantenir el codi més net, evitar redundàncies i funcionalitats no utilitzades, finalment permet estalviar temps en futures modificacions i augmenta la qualitat del codi.

Verificant

• Tot el codi ha de tenir unitats de verificació. Les unitats de verificació són un dels punts forts de l'XP. Cal verificar totes les classes del sistema i és recomanable programar la verificació abans de desenvolupar el codi.
• Tot el codi ha de ser verificat abans de ser entregat. És necessari que a més de verificar totes les classes es verifiqui tots els fragments de programa per garantir-ne la validesa.
• Quan es troba un bug es fa una verificació. Quan es localitza un error es desenvolupa una unitat de verificació capaç de detectar-lo.
• [L'acceptació de les verificacions i el resultat obtingut s'acostumen a publicar.] El client dissenya una sèrie d'escenaris en els quals una

història d'usuari ha de funcionar correctament, un cop verificat el codi cal provar-lo en els escenaris descrits.

Quan utilitzar la XP

La XP està pensada per respondre als canvis en els requeriments d'un projecte. En entorns on el client no té una idea molt clara del que es vol o on els requeriments poden canviar ràpidament és on es treu més profit de la XP. En aquests entorns una metodologia tradicional molt probablement fracassaria, mentre que la XP està pensada per adaptar-s'hi. Tant aquests projectes com qualsevol altre tenen una nivell de risc, les regles i pautes marcades per la XP també permeten reduir-ne els riscos.

És una metodologia pensada per a equips petits. Es recomana que els equips siguin d'entre 2 i 12 membres. Els equips petits permeten adaptar-se més fàcilment als canvis.

La XP pot ser utilitzada en qualsevol tipus de projecte, però els que responen a l'anterior descripció són pels que s'ha pensat expressament. Sempre que es vulgui aplicar cal tenir a la gent motivada i disposada a fer el canvi de mentalitat necessari per tirar endavant el projecte seguint una nova metodologia i, sobretot, cal que el client s'hi atingui, ja que sense la seva figura la XP no té sentit.

Vegeu també

• Programació d'ordinadors
• Informàtica

Enllaços externs

• Lloc dedicat a la divulgació de la programació extrema