Embed Size (px)
Citation preview
Metodologies àgils Enginyeria del software II
2010
Marc Compta Perpiña, u1063912 i Jordi Coma Garcia, u1055876 EINF
17/03/2010
2
1. HISTÒRIA. 3
2. METODOLOGIES ÀGILS. 4
3. EL MANIFEST ÀGIL (THE AGILE MANIFIESTO). 5
3.1. ELS PRINCIPIS DEL MANIFEST. 6
3.2. PRÀCTIQUES ESSENCIALS A LES METODOLOGIES ÀGILS (SEGONS A. COCKBURN). 6
4. EXTREME PROGRAMMING, O XP. 7
4.1. ELS 4 VALORS. 8
4.2. ELS PRINCIPIS SECUNDARIS. 9
5. SCRUM 9
5.1. HISTÒRIA. 10
5.2. CARACTERÍSTIQUES. 11
5.3. ROLS. 12
5.3.1. PORCS (PIG). 12
5.3.2. POLLASTRES (CHICKEN). 13
5.4. REUNIONS. 13
5.4.1. DAILY SCRUM. 13
5.4.2. SCRUM OF SCRUMS. 14
5.4.3. SPRINT REVIEW (REVISIÓ DEL SPRINT). 14
5.4.4. SPRINT RETROSPECTIVE. 14
5.5. DEFINICIONS. 15
5.5.1. PRODUCT BACKLOG. 15
5.5.2. SPRINT BACKLOG. 15
5.6. VARIANTS DE SCRUM. 15
5.6.1. SCRUM-BAN. 15
6. ALTRES METODOLOGIES. 16
6.1. CRYSTAL METHODOLOGIES. 16
6.2. DYNAMIC SYSTEM DEVELOPMENT. 18
7. BIBLIOGRAFIA. 19
3
S’entén com a desenvolupament àgil de software a un paradigma de desenvolupament
de software basat en processos àgils. Aquests intenten evitar els durs i burocràtics
camins de les metodologies tradicionals centrant la seva atenció en la gent i els
resultats.
1. Història.
La definició moderna de desenvolupament àgil de software va “evolucionar” a mitjans
dels anys 90 com una part de la reacció contra els mètodes de “pes pesat”, molt
estructurats i estrictes, extrets del model de desenvolupament en cascada. El procés
originat de l’ús del model en cascada era vist com a burocràtic, lent, degradant i
inconsistent vers les formes de desenvolupament de software que realment
realitzaven una tasca eficient.
Metodologies àgils Metodologies tradicionals
Basades en heurístiques provinents de pràctiques de producció de codi.
Basades en normes provinents d’estàndards seguits per l’entorn de desenvolupament.
Especialment preparades vers els canvis durant el projecte.
Certa resistència als canvis.
Impostades internament (per l’equip). Imposades externament.
Procés menys controlat, amb pocs principis. Procés molt controlat, amb moltes polítiques / normes.
No existeix contracte tradicional o, al menys, és força flexible.
Existeix un contracte prefixat.
El client és part de l’equip de desenvolupament.
El client interactua amb l’equip de desenvolupament mitjançant reunions.
Grups petits (< 10 integrants) treballant al mateix lloc.
Grups grans i possiblement distribuïts.
Pocs rols. Molts rols.
Menys èmfasi en l’arquitectura del software. L’arquitectura del software és essencial i s’expressa mitjançant models.
Els mètodes de desenvolupament àgils i iteratius poden ser vistos com un retrocés en
les pràctiques de desenvolupament observades en els primers anys del
desenvolupament software (tot i que en aquell temps no existien encara metodologies
formals).
L’any 2001, membres prominents de la comunitat es reuniren a Snowbird, Utah, i
adoptaren el nom de “metodologies àgils”. Poc després algunes d’aquestes persones
formaren l’ “aliança àgil”, una organització sense ànim de lucre que promou el
desenvolupament àgil d’aplicacions. Molts mètodes similars a l’àgil van ser creats
abans del 2000. Entre els més notables trobem: Scrum (1986), Crystal Clear (cristall
transparent), programació extrema (o XP, 1996), desenvolupament de software
4
adaptatiu, feature driven development, mètode de desenvolupament de sistemes
dinàmics (1995).
2. Metodologies àgils.
Representen un marc de treball conceptual de la enginyeria del software que promou
iteracions en el desenvolupament al llarg de tot el cicle de vida del projecte. Existeixen
molts mètodes de desenvolupament àgil; la majoria minimitza riscos desenvolupant
software en curts períodes temporals. El software desenvolupat en una unitat de
temps és anomenat iteració, la qual ha de durar d’una a quatre setmanes. Cada
iteració del cicle inclou: planificació, anàlisis de requeriments, disseny, codificació,
revisió i documentació. Una iteració no ha d’agregar la suficient funcionalitat per tal de
justificar el llançament del producte al mercat ja que l’objectiu és obtenir una “demo”
(sense errors) al final de cada una d’elles. Al final de cada iteració l’equip tornarà a
avaluar les prioritats del projecte.
Els mètodes àgils prioritzen les comunicacions cara a cara vers la documentació. La
majoria dels equips àgils estan localitzats en una simple oficina oberta, a vegades
anomenada “plataforma de llançament” (bullpen en anglès). L’oficina haurà d’incloure
revisors, escriptors de documentació i ajuda, dissenyadors d’iteració i directors de
projecte. Els mètodes àgils també afirmen que el software funcional és la primera
mesura del progrés. Combinat amb la preferència per les comunicacions cara a cara,
generalment seran criticats i tractats com a “indisciplinats” per la falta de
documentació tècnica.
ITERACIÓ = PLANIFICACIÓ + ANÀLISI DE REQUERIMENTS +
DISSENY + CODIFICACIÓ + REVISIÓ + DOCUMENTACIÓ
5
3. El manifest àgil (The Agile Manifiesto).
Estem descobrint noves maneres de desenvolupar programari, fent-ho nosaltres
mateixos i ajudant als altres a fer-ho. A través d’aquest treball hem arribat a valorar:
Els individus i les interaccions per sobre dels processos i les eines.
El programari que funciona per sobre d’una documentació exhaustiva.
La col·laboració del client per sobre la negociació del contracte.
La importància de saber respondre al canvi per sobre de seguir un determinat
pla.
No és que els elements a la dreta de l’anterior llista no tinguin importància,
simplement és que valorem més els que estan a l’esquerra.
Manifest disponible a http://www.agilemanifesto.org . Signat entre altres per:
Kent Beck.
Alistair Cockburn.
Ward Cunningham.
Martin Fowler.
6
Ron Jeffries.
Robert C. Martin.
3.1. Els principis del manifest.
La nostra prioritat és la de donar satisfacció al client a través de l’entrega
ràpida i contínua de software valuós.
Acceptem canvis als requeriments, fins i tot al final del procés de
desenvolupament. Les metodologies àgils accepten el canvi en favor de
l’avantatge competitiu del client.
Entreguem programari funcional sovint, des de cada dues setmanes fins a cada
dos mesos, amb una clara preferència cap a la primera opció.
La gent del negoci i els desenvolupadors han de treballar junts dia a dia al llarg
de tot el projecte.
Els projectes s’han de construir al voltant d’individus motivats. Dona’ls l’entorn
i el suport que necessiten i confia en ells per a fer la feina.
La forma més eficient i efectiva de fer arribar informació a (o a dins de) un
equip de desenvolupament és amb converses cara a cara.
Un programari que funciona és la principal mesura de progrés.
Les metodologies àgils promouen el desenvolupament sostenible. Els
promotors, desenvolupadors i usuaris han de poder mantenir un ritme
constant de forma indefinida.
Una atenció contínua a l’excel·lència tècnica i el bon disseny millora l’agilitat.
La senzillesa (art de maximitzar el treball no fet) és essencial.
Les millors arquitectures, requeriments i dissenys emergeixen d’equips
autoregulats i organitzats.
A intervals regulars, l’equip ha de reflexionar sobre com arribar a ser més
efectiu i aleshores ajustar el seu comportament.
3.2. Pràctiques essencials a les metodologies àgils (segons A.
Cockburn).
De 2 a 8 persones per sala.
Comunicació i comunitat.
Usuaris experts junts amb l’equip de desenvolupament.
Cicles de feedback curts i continus.
Iteracions curtes.
Com a màxim 3 mesos per afavorir testing i depuració ràpides.
Tests de regressió totalment automàtics.
Els testos unitaris i funcionals estabilitzen el codi i permeten millorar-lo de
forma contínua.
7
Desenvolupadors experimentats.
L’experiència fa que la velocitat de desenvolupament augmenti entre 2 i 10 vegades.
4. eXtreme Programming, o XP.
L’Extreme Programming o XP és un enfocament de l’enginyeria del software formulat
per Kent Beck, autor del primer llibre sobre la matèria, Extreme Programming
Explained: Embrace Change (1999). Es diferencia de les metodologies tradicionals en
que posa més èmfasi en la adaptabilitat que en la previsibilitat. Així, els seus defensors
creuen que els canvis en els requisits sobre la marxa són un aspecte natural, inevitable
i, fins i tot, desitjable en el desenvolupament de projectes. Creuen que ser capaç
d’adaptar-se als canvis de requisits en qualsevol punt de la vida d’un projecte és molt
millor que intentar definir tots els requisits a l’ inici del projecte, havent d’invertir
esforços llavors en controlar els canvis en els requisits. Aquesta metodologia és
recomanable especialment en:
Projectes amb requeriments canviants.
El risc del projecte és molt elevat.
Equips de desenvolupament petits (de 2 a 12 persones).
Entre les característiques d’aquesta metodologia podem destacar:
Desenvolupament iteratiu i incremental. Petites millores, una rere l’altra.
Proves unitàries contínues, freqüentment repetides i automatitzades, incloent
proves de regressió. S’aconsella escriure el codi de la prova abans de la pròpia
codificació.
Programació per parelles: Es recomana que el desenvolupament es realitzi en
grups de dos persones treballant conjuntament. Així, es considera més
important la revisió i comentari del codi “en calent” que la possible pèrdua de
productivitat immediata. A més, cal tenir en compte la propietat col·lectiva del
codi. Així, qualsevol membre de l’equip podrà comprovar i/o estendre el teu
codi facilitant així el procés de depuració i solució d’errors.
Freqüent integració de l’equip de programació amb el client fins al punt que
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. A més,
realitzarem entregues freqüents.
Refactorització del codi, és a dir, reescriure certes parts del codi per així
augmentar-ne la facilitat de lectura i manteniment però sense modificar-ne el
comportament. Les diferents proves que hauríem d’haver preparat prèviament
hauran de garantir que no s’han afegit nous errors durant el procés.
8
Simplicitat, ja que és la millor manera d’aconseguir que les coses funcionin. Un
cop tot funcioni ho ampliarem funcionalment. Aquesta metodologia aposta
més per realitzar una tasca simple i tenir una mica de feina extra realitzant
modificacions on calgui, que no endinsar-se en complicades tasques referents a
funcionalitats que potser mai seran utilitzades.
Setmana de 40 hores, ja que ningú pot aguantar a ple rendiment més de 40
hores de forma continuada. Si excepcionalment una setmana es treballa més a
la següent s’ha de compensar amb menys hores de treball.
4.1. Els 4 valors.
Comunicació: comunicació entre els desenvolupadors, comunicació amb el
client...
Simplicitat: si una cosa es pot fer de forma senzilla perquè complicar-la.
FeedBack: és important incorporar totes les opinions al procés per a que
aquest pugui millorar.
Coratge: a vegades s’ha de ser valent per a adoptar la decisió més convenient.
9
4.2. Els principis secundaris.
Ensenyar a aprendre: per adaptar-se al canvi s’ha d’estar constantment
aprenent.
Inversió inicial petita: si sabem que al cap de poc temps haurem de canviar,
perquè invertir tant de temps al principi en trobar “la solució”?
Jugar a guanyar: adoptar actitud d’equip guanyador.
Experiments concrets: l’experimentació és necessària i important però és
convenient que els experiments es realitzin sobre parts concretes, amb
condicions molt controlades.
Comunicació Oberta i Honesta: si volem enganyar a algú (companys, client...)
això acabarà repercutint negativament en la feina.
Treballar amb els instints de la gent, no contra ells: els instints i la forma de
ser de cadascú es poden aprofitar, lluitar en contra d’ells sòl ser una pèrdua de
temps.
Responsabilitat acceptada: la responsabilitat assignada no té cap sentit si el
responsabilitzat no l’accepta amb totes les seves conseqüències.
Adaptació local: tot i que els principis són aplicables en qualsevol situació, hem
de ser conscients i acceptar les particularitats de l’entorn local.
Viatjar lleuger: el “canvi” a vegades pot implicar llençar bona part de la feina
que hem fet, si fem les coses senzilles aconseguirem viatjar lleugers i que el
canvi sigui menys traumàtic.
5. Scrum
Scrum és una metodologia de programació que intenta solucionar un problema que
han tingut sempre les metodologies: des de fora només es veu el temps dedicat a
programar el projecte, la resta moltes vegades costa de justificar. La solució que aporta
scrum és el desenvolupament dels projectes en fases petites on cada fase correspon
aproximadament a un requeriment del programa. Cada un d'aquests “trossos”
s'anomena sprint. Cada sprint és assignat a un grup de treball que normalment sol ser
molt petit (de 5 a 10 persones).
L'avantatge de dissenyar mitjançant aquest sistema és que cada un dels sprints que
s'han fet és més fàcil de portar i de dissenyar i, al final del desenvolupament d'aquest,
sempre es pot fer una demostració perquè els clients vegin com està evolucionant el
projecte.
10
5.1. Història.
L’historia de scrum comença el 1986 quan Hirotaka Takeuchi i Ikujino Nonaka realitzen
una primera aproximació del que més endavant seria scrum. Les seves principals
característiques eren l’increment en la flexibilitat de desenvolupament de productes
comercials permetent que fos més fàcil realitzar canvis durant el procés de
desenvolupament.
Aquesta solució solapa moltes fases de desenvolupament de manera intensa (una per
requeriment) i la feina es fa en grups petits. Ho comparen amb la manera en que es
juga a rugbi on tot l’equip juga com si es tractés d’una sola persona amb un únic
objectiu on tot l’equip col·labora per assolir-lo.
El 1991 Peter DeGrace i Lesle Stahl en el seu llibre “Wicked Problems, Righterous
Solutions” parlen d’aquest sistema i l’anomenen scrum, que és un terme propi del
rugbi.
Al principi dels anys 90 Ken Schwaber va començar a utilitzar l’aproximació del mètode
a la seva companyia “Advanced Development Methods”. Més o menys al mateix temps,
Jeff Sutherland va fer una altre aproximació similar i la va implementar en la seva
pròpia companyia “Easel Corporation”. Aquest va ser el primer que el va denominar
scrum.
El 1995 Sutherland i Schwaber, durant el OOPSLA ’95, van presentar una sèrie
d’articles descrivint scrum, essent aquesta la seva primera presentació de cara al
públic. Durant els següents anys Schwabere i Sutherland van col·laborar per a
consolidar els seus articles, les seves experiències i les millores pràctiques aportades
per la metodologia.
Finalment el 2001 es crea el primer llibre que parla sobre scrum, realitzat per
Schwaber i Mike Beedle, anomenat “Agile Software Development with Scrum”.
11
5.2. Característiques.
Scrum és un model flexible que defineix un sèrie de pràctiques i rols. Els rols principals
són Scrum Master, que és el que manté els processos, semblant al director de projecte,
el Product Owner, que representa als client i el Team, que és el conjunt de tots els
desenvolupadors.
Un projecte scrum es divideix en diferents sprints on cada un d’aquests representa una
funcionalitat del projecte final i té una durada limitada, definida prèviament per
l’equip, que normalment és d’ uns 15 a 30 dies. Cada un d’aquests sprints han de ser,
en la seva conclusió, potencialment entregable i ha de poder servir per a realitzar una
petita demostració de cara al client al final del procés.
Les característiques de cada sprint venen donades pel Sprint Backlog que és allà on es
recullen el conjunt de requisits que ha de complir al final del seu desenvolupament.
El conjunt de tots aquests punts és decidit durant una reunió que es fa al principi de
cada sprint anomenada “Sprint Planning”. Durant aquesta reunió el Product Owner
identifica cada un dels elements que s’han de completar en aquell sprint extrets del
Product Backlog.
Però aquest Product Backlog tampoc és fixe ja que pot canviar durant el projecte
depenent de si el client modifica els requisits, etc.
Un equip (o Team) funciona per ell sol de manera que un cop reben la feina
s’autoorganitzen per tal d’assolir l’objectiu.
12
El procés de scrum es pot gestionar de maneres molt diverses. Es pot emprar software
molt especialitzat o es pot gestionar mitjançant mètodes molt més tradicionals com el
que podem veure en la següent imatge:
5.3. Rols.
Els trobarem repartits en dos grups anomenats “PIG” i “CHICKEN”. Els noms d’aquests
grups venen de l’acudit que podem veure il·lustrat a continuació:
5.3.1. Porcs (PIG).
Són els que intervenen en el procés de scrum i s’impliquen de forma activa en la feina.
Principalment tindrem els programadors / desenvolupadors del projecte.
Scrum Master. La seva tasca principal és eliminar tots els obstacles que es
puguin interposar entre els desenvolupadors (equip) per poder arribar a
13
complir l’objectiu final del sprint. No pertany a l’equip si no que la seva feina és
aïllar-lo de qualsevol influència que pugui distreure’l. Una altra feina important
que té és que s’ha d’assegurar que les regles que imposa scrum es compleixen.
Equip (Team). Acostuma a ser un grup petit que treballa de forma independent
de la resta, normalment format per de 5 a 10 persones. Incorpora tot el
personal especialitzat necessari per el desenvolupament, el disseny... del
conjunt de requeriments en curs.
Product Owner. És el representant del client, encarregat de prendre els
requeriments i posar-los al Product Backlog, de controlar que els requeriments
es compleixin, d’imposar un ordre, si cal, dels requeriments que s’han de
complir preferentment i de realitzar les modificacions que calgui. Finalment,
també té la responsabilitat de negociar una data d’entrega i un preu final.
5.3.2. Pollastres (Chicken).
No formen part del procés scrum però s’han de tenir en compte ja que entre ells
trobem l’usuari, experts i altres persones interessades. Tota aquesta gent és important
que vegi el funcionament i el desenvolupament de l’aplicació per tal de poder revisar i
ajudar en la planificació de cada sprint.
Usuaris. Són els que finalment hauran de fer servir el software que s’està
produint i que, finalment, pot produir els beneficis. És important escoltar i tenir
en compte les seves opinions.
Stakeholders (clients i proveïdors). Són la gent que fa possible el projecte i que
finalment podran obtenir beneficis gràcies a aquest. S’han d’involucrar al final
de cada sprint per tal de revisar-lo i sol·licitar canvis quan calgui.
Managers. La gent que estableix l’ambient de desenvolupament del projecte.
5.4. Reunions.
Per mantenir el funcionament de la metodologia s’han de realitzar un seguit de
reunions.
5.4.1. Daily Scrum.
És una reunió que es fa cada dia. S'explica l'estat de l'sprint i es segueix el següent
procediment:
Es comença sempre en una hora acordada concreta fins arribar al punt que es
pot castigar els components que arriben tard a la reunió, el càstig s’acorda
entre tots els membres.
14
Tothom és benvingut, però només els representants dels “porcs”
(desenvolupadors) tenen el dret de parlar.
Té una durada fixa de 15 minuts.
Sempre s'ha de produir al mateix lloc i a la mateixa hora.
Durant la trobada cada membre de l'equip ha de respondre les següents preguntes:
Què has fet des d'ahir?
Què penses fer avui?
Tens problemes per aconseguir el teu objectiu?
La feina que té el Scrum Master és la de solucionar aquests problemes.
5.4.2. Scrum of Scrums.
És una altre reunió que també es fa cada dia, però en aquest cas no amb tot l'equip,
sinó només un representant de cada un d'aquests. El que s'hi discuteix és el mateix
que al “Daily Scrum” però amb les següents qüestions afegides:
Què ha fet el teu equip des de l'última reunió?
Què és el que fareu fins la propera reunió?
Hi ha alguna cosa que fa endarrerir al teu equip?
Faràs alguna cosa que pugui interferir amb el que estigui fent un altre equip?
Les reunions que segueixen es realitzen totes al final de cada cicle.
5.4.3. Sprint review (revisió del sprint).
Es revisa la feina que s'ha pogut completar i la que no s'ha pogut completar.
Es presenta la feina feta. Es genera una demostració de funcionament al client.
Només es demostra la feina totalment acabada.
Límit de 4 hores.
5.4.4. Sprint Retrospective.
Tots els membres de l'equip donen la seva impressió sobre l'sprint.
S'intenta de millorar el procés.
Es pregunta: Què ha anat bé i què es pot millorar.
Límit de temps de 3 hores.
15
5.5. Definicions.
5.5.1. Product Backlog.
És una descripció, a alt nivell, del conjunt del projecte que incorpora la descripció de
cada un dels requeriments que el conformen.
Incorpora un sistema de prioritats (què volem acabar primer?). També incorpora
informació del cost d’implementar cada requeriment, per lo que serveix de guia al
Product Owner, per decidir què és el que s’ha de prioritzar i posar una data final al
projecte.
5.5.2. Sprint Backlog.
Incorpora informació de com l’equip ha d’implementar el que es demana al següent
sprint. Cada Sprint Backlog està dividit en diferents tasques on cada desenvolupador
n’anirà agafant segons vagi acabant les que tingui entre mans i la seva especialitat.
Cada tasca durarà de 4 a 16 hores aproximadament.
L’sprint backlog pertany a l’equip de desenvolupadors. Normalment es crea un Task
Board on s’apunta el què s’està fent, què és el que falta per fer i què s’ha fet.
5.6. Variants de Scrum.
5.6.1. Scrum-ban.
És un model de producció basat en scrum i Kanban.
Aquest sistema està pensat sobretot per projectes que necessiten molt manteniment o
desenvolupament constant. Per això els sprints no tenen final. Amb això les reunions
encara són més importants que en el scrum normal, sobretot les diàries, per assegurar-
se que la feina es va fent correctament.
Per veure a quina fase estan de la feina normalment els equips que treballen junts
posen notes “post-it” o ho escriuen en una pissarra. En els casos en que es treballa
amb equips separats, que no treballen al mateix lloc, es fa servir software especialitzat
com per exemple ScrumWorks i JIRA amb GreenHopper.
Cada feina de l'sprint es pot separar en diferents fases:
Per començar.
Treballant-hi.
Acabada.
16
Si cal, es poden definir més estats en el procés.
Aquest mètode s'aplica en companyies com per exemple Microsoft o Corbis.
A continuació trobareu una imatge de com és la pantalla d’informació de sprint a
scrumWorks.
6. Altres metodologies.
6.1. Crystal Methodologies.
Impulsada per Alistair Cockburn, Crystal dona una importància fonamental a les
persones que formen l’equip d’un projecte i, per tant, els seus punts d’estudi són:
Aspecte humà de l’equip.
Mida de l’equip.
Comunicació entre els components.
Polítiques a seguir.
Espai físic de treball.
17
Crystal aconsella que l’equip de treball estigui format per un reduït nombre de
components, optant per a fer-los treballar a tots en un mateix espai millorant així la
comunicació existent entre ells. Considera que una millora a nivell individual aportarà
un valor afegit a tot l’equip.
Tot i això, planteja solucions per a tota una diversitat de tipus de projectes, totes elles
diferents entre si. Així, Crystal utilitza polítiques diferents segons el nombre de
components de l’equip, fent ús d’un sistema de codificació per colors:
Cada metodologia encaixa en una part diferent de la reixa, de manera que per un
projecte de quaranta persones en el que hi ha en joc una gran quantitat de diners farà
ús d’una metodologia diferent que per a un projecte vital de sis persones.
Les metodologies crystal més desenvolupades són Crystal Clear (per a projectes molt
petits) i Crystal Orange (per a projectes mitjans). Es basen en el desenvolupament
incremental amb “releases” habituals, la implicació de l’usuari i la utilització de testos
de regressió.
18
6.2. Dynamic System Development.
DSDM (Dynamic System Development Method) és un entorn lliure per al
desenvolupament ràpid molt conegut a Gran Bretanya (www.dsdm.org). La idea
fonamental és que en comptes de fixar la quantitat de funcionalitats d’un producte i
aleshores ajustar el temps i els recursos necessaris per aconseguir aquesta
funcionalitat és millor primer fixar el temps i els recursos i després ajustar la
funcionalitat. Hi ha 5 fases: estudi de viabilitat, estudi de negocis, iteració del model
funcional, iteració de disseny i construcció i implementació.
Els principis:
Implicació de l’usuari.
L’equip ha de prendre decisions.
Entregar sovint.
Les entregues han de tenir valor de negoci.
Desenvolupament iteratiu i incremental.
Tots els canvis són reversibles.
Els requeriments només s’especifiquen a alt nivell.
El testeig s’ha d’integrar al llarg de tot el cicle de vida.
El procés ha de ser col·laboratiu i compartit per tots els interessats.
19
7. Bibliografia.
http://www.agile-spain.com/manifiesto_agil
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software
http://ima.udg.edu/Docencia/07-08/3105200728/ScrumToni.pdf
http://xavier.amatriain.net/es1/internal/apunts/Apunts.pdf
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-
xp-desde-las-trincheras.pdf
http://kmels.net/files/2009/uvg/cc2003/Resources/Contenidos/XP/x
p.pdf
