Extreme Programming
http://www.extremeprogramming.org
Una de les metodologies d'Enginyeria del Software que més m'han atret en els últims dies ha estat l'Extreme Programming. Kent Beck va proposar aquesta metodologia fent-la especial en el fet que, a diferència dels mètodes tradicionals, aquesta es centralitza més en l'adaptabilitat que no pas en la previsibilitat.
Els defensors de la XP (sigles de eXtreme Programming), creuen que els canvis de requeriments sobre la marxa són un aspecte natural, inevitable i també dessitjable en el desenvolupament de projectes. Creuen que ser capaços d'adaptar-se als canvis de requeriments en qualsevol punt de la vida del projecte, és una aproximació millor i més realista que intentar definir tots els requeriments al principi del projecte i invertir molts més esforços després a l'hora d'intentar controlar els canvis en aquests. Es pot considerar la programació extrema com l'adopció de les millor metodologies de desenvolupament d'acord al que es vol portar a terme amb el projecte, i aplicar-ho de manera dinàmica durant el cicle de vida del software.
Les característiques fonamentals del mètode són:
- Desenvolupament iteratiu i incremental: petites millores, una darrere l'altre.
- Proves unitaries continues, freqüentment repetides i automatizades, incloent proves de regressió. S'aconsella escriure el codi de la prova abans de la codificació. Vegi's per exemple, les eines de prova JUnit orientada a Java i DUnit orientada a Delphi i inspirada en JUnit.
- Programació en parelles. Es recomana que les tasques de desenvolupament es portin a terme per dues persones en un mateix lloc. Es suposa que la major qualitat del codi escrit d'aquesta manera -el codi és revisat i discutit mentres 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.
- Refactorització del codi, és a dir, reescriure certes parts del codi per augmentar la seva llegibilitat i mantenibilitat però sense modificar el seu comportament. Les proves han de garantir que en la refactorització no s'hagi introduit ningún error.
- Propietat del codi compartida. En comptes de dividir la responsabilitat en el desenvolupament de cada mòdul en grups de treball diferents, aquest mètode promou el que tot el personal pugui corregir i extendre qualsevol part del projecte. Les freqüents proves de regressió garantitzen 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. La programació extrema aposta que és més simple fer alguna cosa simple i tenir una mica de treball extra per canviar-ho si es requereix, que realitzar alguna cosa complicada i pot ser mai utilitzar-ho. La simplicitat i la comunicació són extraordinàriament complementàries. Amb més comunicació resulta més fàcil identificar què es deu fer i què no es deu fer. Mentres més simple és el sistema, menys tindrà que comunicar sobre aquest, el que porta a una comunicació més completa, especialment si es pot reduir l'equip de programadors.
Podeu llegir molta més informació i la definició del procés en si mateix en la web que anteriorment us he adjuntat. Us ho recomano als interessats en la programació, ja que em va semblar una metodologia a provar, al menys.

3 comentaris:
está clarísimo...
weno!!
Quina riquesa de vocabulari.. sort que no he passat del primer paràgraf ;)!
Tot això sona a món paral·lel...
Per a quan un nou capítol de l'esfera de Leian? Va!! Que estic impacient!! A veure si passa alguna coseta!!!
Salut
Xtreme Programming...
ara mateix estic a un projecte "gegant" fent manteniment...
1) es molt bonic apostar en la possibilitat d'adaptabilitat del projecte versus analisi de requeriments, pero la realitat es la seguent:
els "clients" no deixan de demanar... sempre... que ho tenen clar en un principi: els requeriments estaran clars, l'arquitectura sera clara, la funcionalitat sera clara, etc...
que volen quelcom realment diferent.. projecte nou i "santas pascuas"
perque codi amb un cicle de vida de mes de 5 anys... mai es senzill, ni d'adaptar, ni d'arreglar.
Publica un comentari a l'entrada