Programació Extrema
De Viquipèdia
La Programació Extrema, o Extreme Programming en anglès, (XP) es 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). Es un dels diversos processos àgils.
Taula de continguts |
[edita] Característiques fonamentals de la Programació Extrema
- 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, es 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 que les coses funcionin. Quan tot funcioni es podrà afegir funcionalitat si és necessari.
[edita] 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 casi 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, en tant sols 3 setmanes ja havia imprès el primer xec dels casi 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 cancelat a principis del 2000, el projecte ja no era necessari. El sistema anterior havia superat l'Y2K 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.
extret de http://www.eda3s.com/wiki/index.php/AgileMethodology fragment inclòs en el projecte MeRLí de Aleix Canals.
[edita] Com, quan i perquè utilitzar la XP
[edita] El Que Importa A 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'altre 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 serie de regles i practiques per aconseguir-ho.
[edita] Regles I Pautes De La Xp
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 en 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 del 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 tant 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 de
integrar nou codi al sistema. D'aquesta manera a més de resultats les altres parelles poden desenvolupar sobre la última versió del sistema.
- [Utilitzar codi comú.] Tothom té dret a introduir canvis en el
codi desenvolupat per una altre 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 és 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 que 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 número 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 es seguiran.
Dissenyant
- [Simplicitat] Fer les coses tant senzilles com es pugui. Un
codi senzill és mes 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 tarja representa un objecte, l'objecte és d'una Classe té unes Responsabilitats i Col·labora amb una serie d'objectes d'altres classes. En una sessió de CRC es tenen les targes 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 s'en 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 la estimació d'aquesta o d'acceptar-la fer una solució puntual. La solució puntual (spike solution) consisteix en 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 necessaries 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 recomenable 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 serie d'escenaris en els que una història d'usuari a 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:
Imatge:Http://www.extremeprogramming.org/map/images/project.gif
[edita] 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, sense la seva figura la XP no té sentit.
extret de http://www.eda3s.com/wiki/index.php/AgileMethodology fragment inclòs en el projecte MeRLí de Aleix Canals.