Programació Extrema

De Viquipèdia
Dreceres ràpides: navegació, cerca

La Programació Extrema, o Extreme Programming en anglès, (XP) és un mètode de 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.

Característiques fonamentals de la Programació Extrema[modifica | modifica el codi]

  • Desenvolupament iteratiu i incremental: petites millores, una rere l'altra.
  • Proves unitàries contínues, freqüentment repetides i automàtiques, incloent proves de regressió. S'aconsella d'escriure el codi de la prova abans de la codificació. Vegeu, com a 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 ó 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 mantenibilitat 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 és necessari.

Valors[modifica | modifica el codi]

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è podrem llegir-les i modificar-les amb facilitat.

  • Simplicitat:

Esforç en fer les coses més simples que 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-nos que el sistema funciona en tot moment. Així, quan fem errors els trobarem immediatament.

  • Coratge:

Totes les metodologies i processos són eines que redueixen els nostres temors. Com més por ens faci un projecte, majors i més dures seran les metodologies que necessitarem. 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à. Has de ser respectuós amb els teus companys i les seves aportacions, amb la teva empresa i amb aquells que estan implicats en el codi que estàs tocant.

Amb aquests 5 valors, XP assegura dissenys i codis simples, mètodes eficients i clients contents.

Els 5 valors no donen consells específics sobre com portar un projecte o com escriure software. Per això, es necessiten unes pràctiques, i abans de les pràctiques, uns principis.

Principis[modifica | modifica el codi]

  • Humanitat:

El software el desenvolupen persones, per tant els factors humans són la principal clau de la qualitat del software. XP assigna els objectius a la gent i les seves organitzacions, pel benefici d'ambdós.

Però necessitem trobar un equilibri entre objectius: Si sobreestimem les necessitats de la gent, no treballaran adequadament, amb la conseqüent baixa productivitat i pèrdues en el negoci. I si sobreestimem les necessitats de l'organització, 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 software i més tard el gasti, més benefici crea el software.

És molt útil poder endarrerir les despeses de disseny fins que siguin obvis.

  • Benefici mutu:

Qualsevol activitat deuria beneficiar a tota la gent i organitzacions implicades. Potser sigui 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.

Necessites solucionar més problemes dels que crees. Per tant, necessites pràctiques que et beneficiïn tant a tu com al client, ara i al futur.

  • Similitud en si mateixa:

Hem de ser capaços 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, enumeres els temes a resoldre, i llavors escrius les històries que els descriuen; en 1 setmana, enumeres les històries a implementar, escrius les proves d'acceptació i finalment escrius el codi que passi les proves; en poques hores, escrius proves unitàries i després el codi capaç de passar-los.

  • 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 software si podem 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 software té gent tan ocupada pensant sobre la millora del procés que ja no escriuen software. La reflexió va després de l'acció, i abans de la següent acció.

  • Fluxe:

XP assumeix un continu flux d'activitats, no una seqüència de diferents fases amb llançament del software 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 ha de veure's com una oportunitat per a millorar. Sempre poden experimentar-se problemes, però per obtenir qualitat no pots simplement corregir-los, sinó convertir-los en oportunitats d'aprendre i millorar. Per exemple, un únic desenvolupador comet massa errors? Que programi en parella!

  • Redundància:

Els problemes crítics i difícils deurien resoldre's de diverses maneres. Així, si una solució falla, les altres evitaran el desastre. El cost de la redundància és fàcilment amortitzat en aquests casos. Els defectes en software han de buscar-se, trobar-se i reparar-se de moltes formes (programació en parelles, proves automatitzades, seure junts, implicació del client, etc.).

  • Falla:

Si no pots tenir èxit, falla. No saps com implementar una història? Implementa-la de 3 o 4 formes. Encara que totes fallin, hauràs après molt. És la falla útil? Sí, si t'ensenya quelcom. Per tant, no tinguis 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 deu 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 de temps 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 dóna 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[modifica | modifica el codi]

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 d'aleshores, 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 fa càrrec del projecte i aprofita aquesta oportunitat per proposar i implementar canvis en la manera que hi havia de programar, bastats en la feina que havien estat fent juntament amb Ward Cunningham. A més, convida 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'aquesta només calia preparar el sistema per imprimir els restants xecs. A l'agost del 1998 C3 ja pagava els xecs de 10000 empleats, tot i que finalment va ser cancel·lat a principis del 2000, el projecte ja no era necessari. 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 resultat, parcialment. Temps després Jawed Siddiqi va explicar "The troubles the C3 project later encountered, due to communication problems between the development team and the two sets of management stakeholders (the IS department which was the customer, and the Payroll Department which was the user) present significant concern because communication between the customers and the team lies at the heart of XP’s approach."

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 projectes petits petits, C3 constava de 2000 classes i 30000 mètodes.
  • La comunicació amb el client és fonamental.
  • Poden fracassar.

Com, quan i perquè utilitzar la XP[modifica | modifica el codi]

El Que Importa A La Xp[modifica | modifica el codi]

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 practiques per aconseguir-ho.

Regles I Pautes De La Xp[modifica | modifica el codi]

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 fracas 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ó estandard. Un exemple d'estandard 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 sober el que no s'ha verificat el nou codi degut a l'aparició del codi nou de l'altre parella.
  • [Integracions freqüents.] Cada poques hores les parelles han d'integrar 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 sober 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 propi 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 importancia que tingui cada una de les històries com per la seva prioritat.
  • [Fer petites entregues freqüentment.] 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 freqüentment.
  • [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, cada ú 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 pel 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 uns 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.] Refacoritzar consiteix en eliminar redundàncies, eliminar funcionalitats no utilitzades, rejuvenir 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 que una

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

Procés de desenvolupament

Les regles i pautes per les diverses accions durant el procés de desenvolupament d'un projecte en XP es reflecteixen en un procés de desenvolupament que es veu en el següent mapa:

Quan Utilitzar La Xp[modifica | modifica el codi]

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, sense la seva figura la XP no té sentit.

Vegeu també[modifica | modifica el codi]

Enllaços externs[modifica | modifica el codi]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Programació Extrema Modifica l'enllaç a Wikidata