Metodologia àgil

Els mètodes de desenvolupament de programari iteratius i incrementals es remunten a l'any 1957, amb la gestió de projectes evolutius^[10][11] i el desenvolupament de programari adaptatiu^[12] que va sorgir a principis dels anys setanta.^[13]

Durant la dècada de 1990, una sèrie de mètodes de desenvolupament de programari lleugers van evolucionar com a reacció als mètodes pesats predominants (sovint anomenats model de desenvolupament en cascada) que els crítics van descriure com massa regulats, planificats i microgestionats.^[14] Aquests mètodes lleugers inclouen: desenvolupament ràpid d'aplicacions (RAD), des de 1991;^[15][16] el procés unificat (UP) i el mètode de desenvolupament de sistemes dinàmics (DSDM), tots dos de 1994; Scrum, del 1995; Crystal Clear i programació extrema (XP), ambdues del 1996; i desenvolupament basat en funcions (FDD), des de 1997. Tot i que tots es van originar abans de la publicació de l'Agile Manifesto, van passar a denominar-se col·lectivament mètodes de desenvolupament de programari àgils.^[6]

Ja des de 1991 s'havien produït canvis similars en la fabricació^[17][18] i el pensament de gestió^[19] que derivava de la producció ajustada.

L'any 2001, disset desenvolupadors de programari es van reunir en un complex de Snowbird, Utah, per discutir mètodes de desenvolupament lleugers. Van ser: Kent Beck (Programació extrema), Ward Cunningham (Programació extrema), Dave Thomas (PragProg, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Desenvolupament de programari adaptatiu), Alistair Cockburn (Crystal), Robert C. Martin (SOLID), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler (OOAD i UML), James Grenning, Andrew Hunt (PragProg, Ruby), Ron Jeffries (Programació extrema), Jon Kern, Brian Marick (Ruby, TDD) i Steve Mellor (OOA). Junts van publicar el Manifest per al desenvolupament de programari àgil.^[4]

El 2005, un grup encapçalat per Cockburn i Highsmith va escriure sobre els principis de gestió de projectes, la Declaració d'Interdependència PM,^[20] per guiar la gestió de projectes de programari segons mètodes àgils de desenvolupament de programari.

El 2009, un grup que treballava amb Martin va escriure un afegit als principis de desenvolupament de programari, el Software Craftsmanship Manifesto, per guiar el desenvolupament àgil de programari segons la conducta i el domini professional.

El 2011, Agile Alliance va crear la Guia de pràctiques àgils (anomenada Agile Glossary el 2016),^[21] un compendi de codi obert en evolució de les definicions de treball de pràctiques, termes i elements àgils, juntament amb interpretacions i directrius d'experiència de la comunitat mundial de professionals àgils.

Basant-se en la seva experiència combinada de desenvolupar programari i per tal d'ajudar altres a fer-ho, els autors del manifest van declarar que valoraven:^[4]

Els principis bàsics de la metodologia àgil són:

• Els individus i les seves interaccions per sobre dels processos i les eines
• El programari que funciona per sobre de la documentació exhaustiva
• La col·laboració amb el client per sobre de la negociació de contractes
• La resposta davant del canvi per sobre de seguir un pla tancat

És a dir, si bé ambdues parts tenen valor i s'han de tenir en compte els ítems de la dreta, els autors consideraven que els ítems de l'esquerra haurien d'influir més en la manera com les persones aborden el seu treball.

Com va explicar Scott Ambler:^[22]

• Les eines i els processos són importants, però és més important que hi hagi persones competents que treballin junts de manera eficaç.
• Una bona documentació és útil per ajudar la gent a entendre com es construeix el programari i com utilitzar-lo, però el punt principal del desenvolupament és crear programari, no crear documentació.
• Un contracte és important, però no substitueix la col·laboració estreta amb els clients per anar veient què necessiten.
• Un pla de projecte és important; això no obstant, no ha de ser massa rígid per adaptar-se als canvis tecnològics o ambientals, les prioritats de les parts interessades i la comprensió de la gent del problema i la seva solució.

Alguns dels autors van formar l'Agile Alliance, una organització sense ànim de lucre que promou el desenvolupament de programari d'acord amb els valors i principis del manifest. En presentar el manifest en nom de l'Aliança Àgil, Jim Highsmith va dir:

El Manifest per al desenvolupament de programari àgil es basa en dotze principis: ^[24]

1. Satisfacció del client mitjançant el lliurament anticipat i continu de programari valuós.
2. Benvinguts els requisits canviants, fins i tot en el desenvolupament tardà.
3. Entrega programari que funcioni amb freqüència (setmanes en lloc de mesos).
4. Col·laboració estreta i diària entre empresaris i desenvolupadors.
5. Els projectes es construeixen al voltant d'individus motivats, en els quals cal confiar.
6. La conversa cara a cara és la millor forma de comunicació (coubicació).
7. El programari en funcionament és la mesura principal del progrés.
8. Desenvolupament sostenible, capaç de mantenir un ritme constant.
9. Atenció contínua a l'excel·lència tècnica i al bon disseny.
10. La senzillesa, l'art de maximitzar la quantitat de treball not realitzat, és essencial.
11. Les millors arquitectures, requisits i dissenys sorgeixen d'equips autoorganitzats.
12. Periòdicament, l'equip reflexiona sobre com ser més efectiu i s'ajusta en conseqüència.

 

Existeixen molts mètodes de desenvolupament àgil. El desenvolupament més promogut, el treball en equip, col·laboració, i el procés d'adaptabilitat al llarg del cicle de vida del projecte.

Iteratiu, Incremental i Evolutiu

Molt mètodes àgils fragmenten tasques en petits increments amb una planificació mínima i no involucra directament una planificació al llarg termini. Les iteracions són marcs (quadres de temps) de curt termini que típicament tarden entre una i quatre setmanes. Cada iteració involucra un equip multidisciplinari treballant en totes les funcions: planificació, anàlisi de requeriments, disseny, programació, proves unitàries, i les proves de validació. Al final de la iteració el producte treballat es mostra a les parts interessades (o clients). Això minimitza el grans riscos i permet que el producte s'adapti als canvis ràpidament. És possible que una iteració no afegeixi una funcionalitat prou feta com per satisfer les versions llançades al mercat, però l'objectiu és tenir una versió disponible al final de cada iteració. Múltiples iteracions podrien ser necessàries per llançar un producte o noves característiques.

Comunicació eficient i cara a cara

Sense que importi el mètode de desenvolupament que se segueixi, cada equip àgil inclou un representant del client, per exemple el responsable del producte en Scrum. Aquesta persona és nomenat per les parts interessades perquè actuï en el seu nom i fa un compromís personal d'estar disponible per als desenvolupadors per respondre a les preguntes al llarg de la iteració. Al final de cada iteració, les parts interessades i l'opinió del representant dels clients reavalua les prioritats per tal d'optimitzar el retorn de la inversió i assegurar l'alineació amb les necessitats del client i objectius de l'empresa.

En el desenvolupament àgil de programari, un radiador de la informació és una pantalla física (normalment gran) ubicada en un lloc preferent prop de l'equip de desenvolupament, a la vista dels que hi passin pel davant. Presenta un resum actualitzat de la situació d'un projecte de programari o qualsevol altre producte. El nom va ser encunyat per Alistair Cockburn, i es descriu en el seu llibre de 2002 Agile Software Development. Un indicador lluminós de construcció pot ser utilitzat per informar un equip sobre l'estat actual del seu projecte.

Circuit de retroalimentació molt curt i cicle d'adaptació

Una característica comuna de desenvolupament àgil són reunions d'estat diaris o "stand-ups", per exemple l'Scrum Diari (Reunió). En una breu sessió, els membres de l'equip informen els uns als altres del que van fer el dia anterior, el que pretenen fer avui, i quins són els obstacles que tenen.

Enfocament de qualitat

S'utilitzen sovint eines i tècniques específiques, com ara, integració contínua, testeig unitari automatitzat, programació en parelles, desenvolupament basat en proves, patrons de disseny, desenvolupament basat en domini, la refacció de codi entre altres tècniques per millorar la qualitat i l'agilitat del projecte.

Comparat amb el desenvolupament de programari tradicional, el desenvolupament de programari àgil s'adreça a sistemes i desenvolupaments complexos amb projectes dinàmics, on fer prediccions acurades del temps necessari de desenvolupament és molt complicat. A conseqüència d'això es perdria molts diners. Els diversos anys d'experiència han ajudat a donar forma a les metodologies àgils.

Les metodologies de desenvolupament existeixen en un continu des d'adaptatiu fins a predictiu.^[25] Les metodologies àgils formen part de les adaptatives. Un dels elements clau del desenvolupament adaptatiu és l'anomenat Rolling Wave, el qual determina objectius, però dona flexibilitat a l'hora d'aconseguir-los. Aquests objectius també estan sotmesos a possibles canvis futurs. Com més lluny es trobi, en el temps, un objectiu, un desenvolupament adaptatiu serà més imprecís sobre el que passarà en aquella data. Un equip que utilitzi desenvolupament adaptatiu no pot informar sobre que farà la pròxima setmana, però si quines funcionalitats implementaran al llarg del mes següent. Si a l'equip se li demana una predicció del que tindran fet al cap de sis mesos (o qualsevol quantitat considerable de temps) l'equip només serà capaç d'informar de l'objectiu principal, o una predicció aproximada de cost que tindrà.

D'altra banda, els mètodes predictius s'enfoquen a analitzar i planificar el futur amb detall per tal de poder controlar els possibles perills futurs. En els casos més extrems, un equip que utilitzi una metodologia predictiva és capaç de dir totes les tasques que es realitzaran al llarg del projecte. Aquestes metodologies es basen en una fase inicial d'anàlisi molt detallada, ara bé, si durant el desenvolupament alguna cosa va malament, serà molt difícil canviar la direcció del projecte. Normalment aquests equips tenen una junta de control de canvis, que s'assegurarà que només els canvis més importants s'afegeixin al projecte.

Es pot fer una anàlisi dels riscos que a l'hora de triar entre els mètodes predictius i els adaptatius.^[26] En Barry Boehm i en Richard Turner diuen que cada metodologia es pot escollir en funció d'unes característiques.

Una de les diferències principals entre el desenvolupament àgil i el desenvolupament en cascada és que la fase de testing es realitza en diferents etapes. En el Model de desenvolupament en cascada, hi ha una etapa de testejament quan s'està acabant una de les fases d'implementació, mentre que en les metodologies àgils i especialment en la Programació Extrema, es realitzen de forma paral·lela amb el desenvolupament del codi.

Com que les fases de testing es realitzen a cada petita iteració, els usuaris poden provar i validar aquesta petita peça del programari. Això permet que els usuaris puguin fer millors decisions sobre el futur d'aquest programa. Tenir a cada iteració del desenvolupament la possibilitat de replantejar el camí que seguirà el programa (p.e l'Scrum té com a màxim iteracions d'un mes), permet a l'equip intentar maximitzar el valor que ofereix el programa.

Aquesta planificació iterativa permet veure el desenvolupament del programari com un organisme que es va adaptant als canvis que es van produint. Sempre que el programari s'utilitzi, i especialment si té competència, les iteracions en el desenvolupament àgil aportarant canvis.

En una carta al IEEE Computer, Steven Rakitin va expressar el seu cinisme sobre el desenvolupament àgil, criticant un article que defensava el desenvolupament àgil com "un altre intent de minimitzar la disciplina de l'enginyeria del programari", i traslladant el "Treballar en codi per sobre la documentació" a "Només volem escriure codi, recorda els programadors de veritat no escriuen documentació".^[27]

Aquest aspectes són discutits pels defensors del desenvolupament àgil, que diuen que els desenvolupadors haurien d'escriure documentació si és la millor manera d'aconseguir els objectius rellevants, però que habitualment hi ha millors maneres d'aconseguir-los que escrivint una documentació estàtica.^[28] Scott Ambler diu que la documentació haurià de ser amb prou feines acceptable (de l'anglès Just Barely Good Enough (JBGE),^[29] ja que molta documentació seria una pèrdua de temps, perquè habitualment els desenvolupadors no es refien d'una documentació molt detallada, perquè normalment no està sincronitzada amb el codi,^[28] d'altra banda molt poca documentació o una molt pobre pot donar problemes per manteniment, comunicacio, aprenentatge, etc.

Els processos de desenvolupament del programari tradicionals parteixen de la idea de recollir i d'entendre tots els requeriments a l'inici del projecte i, un cop "firmats" els requeriments, fer-los servir com a base pel disseny i la construcció de la solució. És a dir, el procés de desenvolupament està conduït per una planificació fixada; normalment el model es coneix com a desenvolupament en cascada.

En un projecte àgil, s'assumeix que els requeriments no són fixos ni coneguts completament. Tenir, doncs, una fase inicial del projecte de disseny detallat no té cap sentit. El disseny del sistema evoluciona a través de les iteracions de desenvolupament.

Els mètodes de desenvolupament de programari àgils i/o marcs del procés coneguts inclouen:

• Desenvolupament de programari adaptatiu (ASD)
• Modelat àgil
• Procés àgil unificat
• Crystal Clear
• Lliurament àgil disciplinat
• Mètodes de desenvolupament de sistemes dinàmics
• Programació extrema
• Desenvolupament basat en característiques
• Desenvolupament de programari de Lean
• Desenvolupament Kanban
• Scrum
• Scrum-ban

Els mètodes àgils se centren en diferents aspectes del cicle de vida de desenvolupament de programari. Alguns se centren en les pràctiques (per exemple, XP, Programació Pragmàtica, Modelat Àgil), mentre que altres se centren en la gestió dels projectes de programari (per exemple, Scrum). No obstant això, hi ha enfocaments que proporcionen una cobertura total sobre el cicle de vida de desenvolupament (per exemple, DSDM, IBM RUP), mentre que la majoria d'ells són adequats a partir de la fase d'especificació de requisits (FDD, per exemple). Per tant, hi ha una clara diferència entre els diversos mètodes àgils en aquest sentit.

El desenvolupament àgil es recolza en un conjunt de pràctiques concretes suggerides pels mètodes àgils, que cobreixen àrees com ara els requisits, disseny, modelat, codificació, proves, gestió de projectes, processos, qualitat, etc. Algunes pràctiques àgils notables inclouen:

• Desenvolupament basat en proves d'acceptació
• Modelat àgil
• Endarreriments (Producte i Sprint)
• Desenvolupament basat en el comportament
• Equip multi-funcional
• Integració contínua
• Disseny basat en el domini
• Els radiadors d'informació (tauler Scrum, tauler de tasques, taula Burndown)
• Desenvolupament iteratiu incremental
• Programació en parella
• Planificació de pòquer
• Refactorització
• Reunions de Scrum (la planificació de Sprint, l'Scrum diari, la revisió i retrospectiva de l'Sprint)
• Desenvolupament basat en testeig
• Ttesteig àgil
• Timeboxing
• Casos d'ús
• Història de l'usuari
• Modelat basat en la Història
• Retrospectiva
• Velocitat de seguiment

L'Agile Alliance ha proporcionat una col·lecció completa online amb una guia de ruta per a les pràctiques àgils que es sol·licitin.

En la literatura, els diferents termes es refereixen a la noció de mètode d'adaptació, incloent el "mètode d'adaptació","el mètode de fragment d'adaptació" i "el mètode d'enginyeria de la situació". El Mètode de Sastreria es defineix com:

El procés o la capacitat en la qual els agents humans determinen un enfocament de desenvolupament del sistema per a una situació específica del projecte a través de canvis en la resposta, i interactua dinàmicament entre contextos, intencions, i fragments de mètode.

Potencialment, gairebé tots mètodes àgils són adequats per al mètode de confecció. Fins i tot el mètode DSDM s'està utilitzant per a aquesta finalitat i s'ha adaptat amb èxit en un context CMM. La Situació d'adequació pot ser considerada com un tret distintiu entre els mètodes àgils i els mètodes de desenvolupament de programari tradicionals, sent aquest últim relativament molt més rígid i prescriptiu. La implicació pràctica és que els mètodes àgils permeten als equips de projecte adaptar les pràctiques de treball d'acord amb les necessitats de cada projecte. Les pràctiques són les activitats i els productes que formen part d'un mètode concret. A un nivell més extrem, la filosofia que hi ha al darrere del mètode, consisteix en una sèrie de principis, que podrien ser adaptats (Aydin, 2004).

La Programació Extrema (XP) fa que la necessitat d'adaptació del mètode sigui més explícita. Una de les idees fonamentals de la XP és que cap procés s'ajusta a cada projecte, sinó més aviat les pràctiques s'han d'adaptar a les necessitats de cada projecte. L'adopció parcial de les pràctiques de XP, segons el suggerit per Beck, s'ha anat informant en diverses ocasions. Mehdi Mirakhorli proposa una pràctica d'adaptació que proporciona un full de ruta i directrius suficients per a l'adaptació de totes les pràctiques. La pràctica RDP està dissenyada per a la personalització de XP. Aquesta pràctica es va proposar per primera vegada com un treball de recerca de molt de temps en el taller APSO en la conferència ICSE 2008, és actualment l'única proposada i el mètode aplicable per a la personalització de XP. Encara que és específicament una solució per XP, aquesta pràctica té la capacitat d'ampliar a altres metodologies. A primera vista, aquesta pràctica sembla estar en la categoria de mètode d'adaptació estàtica però l'experiència amb La Pràctica RDP diu que pot ser tractada com a adaptació al mètode dinàmic. La distinció entre el mètode d'adaptació estàtica i el mètode d'adaptació dinàmica és subtil.

Els mètodes àgils tenen molt en comú amb les tècniques de desenvolupament ràpid d'aplicacions a partir dels 1980/90 com l'exposada per James Martin, entre d'altres. A més dels mètodes centrats en la tecnologia, i els mètodes centrats en els clients-i-disseny, com la creació ràpida de prototips basats en la visualització desenvolupats per Brian Willison, el treball per atraure els clients i usuaris finals facilita el desenvolupament de programari àgil.

El 2008, l'Institut d'Enginyeria de Programari (SEI) va publicar l'informe tècnic "CMMI o Agile: Per què no adoptar els dos" per deixar clar que el Capability Maturity Model Integration i Agile poden coexistir. Els processos de desenvolupament moderns que són compatibles amb CMMI també són iteratius. El CMMI versió 1.3 inclou consells per a l'aplicació de Agile i CMMI junts en el procés de millora.

S'han realitzat diverses enquestes en termes de qualitat, productivitat i satisfacció general de l'empresa. L'enquesta anomenada l'estat de la metodologia àgil o l'estat d'àgil es realitza cada any des de 2006 amb milers de participants de la comunitat de desenvolupament de programari. Dels resultats de les enquestes de 2013 es pot concloure que el 73% dels enquestats creuen que àgil ajuda a completar projectes més ràpid; el 92% creu que àgil millor l'habilitat per controlar canvis en el les prioritats dels clients; i el 87% pensa que l'àgil millora la productivitat del seu equip de desenvolupament. Una altra enquesta duta a terme anteriorment al 2006, destaca beneficis similars.^[30]

El desenvolupament de programari a gran escala amb l'àgil continua sent avui dia una àrea de recerca activa. El desenvolupament amb l'àgil s'ha vist com el més adequat per a determinats entorns, incloent-hi petits equips d'experts. Amb tot això, l'àgil ha tingut una bona recepció a tota Europa durant els últims anys.

No obstant, alguns aspectes que poden influenciar negativament en l'èxit d'un projecte àgil són:

• Els desenvolupaments a gran escala (més de 20 desenvolupadors).
• Desenvolupaments distribuïts a llocs diversos (sense emplaçament comú).
• El fet de forçar un projecte per sistemes crítics, com pot ser programari per aviònica, és una opció arriscada.

Els equips que implementen àgil sovint tenen dificultats en la transició de mètodes més clàssics com el desenvolupament en cascada. Alguns dels problemes enfrontats per equips d'implementació de processos àgils són els següents:

• Afegir històries a un sprint en progrés. És perjudicial per al flux establert per l'àgil. Scrum certament ofereix provisió per canviar les prioritats del backlog de producte a mitjan projecte, tanmateix això ha de passar entre els sprints i no durant. Si hi ha un problema que es planteja que requereix afegir-se, és millor una finalització anormal de l'sprint. Això no vol dir que la història d'un usuari no pugui ser expandida. Els equips han fer front a la nova informació que pot resultar en tasques addicionals per a una història d'un usuari. Si la nova informació impedeix que la història d'un usuari sigui llegida durant l'sprint, llavors s'hauria de dur a terme al següent sprint. No obstant això, durant la següent planificació de sprint, aquesta història ha de ser la de major prioritat respecte a les altres històries.

• Falta de suport dels patrocinadors. L'àgil sovint s'implementa com un esforç base en les organitzacions pels equips de desenvolupament de programari que tracten d'optimitzar els seus processos de desenvolupament. En no tenir el suport del patrocinador, els equips poden tenir dificultats i resistències per part dels socis de negoci o per part d'altres equips de desenvolupament i gestió.

• Entrenament insuficient. Una enquesta duta a terme per Version One troba als enquestats la insuficiència d'entrenament com la causa més important de fracassos en projectes àgils. Els equips cauen en la trampa d'assumir els processos de reducció en comparació amb altres metodologies com la cascada. Això vol dir que no hi ha regles específiques per àgil. Per altra banda, l'entrenament i formació és un requisit indispensable per dur a terme àgil.

• El paper del propietari del producte no està ben definit. El propietari del producte és responsable de representar a l'empresa en l'activitat de desenvolupament.

Un error comú és tenir el rol de propietari del producte fixat per algú de l'equip de desenvolupament. Fer que l'equip de desenvolupament ocupi aquest rol resulta en què l'equip pren les seves pròpies decisions sense una comunicació real per part de l'empresa. A més a més, les qüestions d'empreses s'intenten resoldre internament o bé hi han retards a l'hora de comunicar-se exteriorment. Aquests problemes poden resultar en problemes interns i desviar el procés de col·laboració dirigit per àgil.

• Els equips no estan focalitzats. El procés àgil requereix que els equips que estan realitzant el projecte siguin conscients dels compromisos del projecte. S'espera que durant un esprint pugui haver una tasca que no sigui de l'àrea del desenvolupador. Encara que si els membres de l'equip tenen múltiples projectes que serà difícil per a qualsevol capacitat addicional que estigui disponible per ajudar a completar l'sprint.

• Excés de preparació i/o planificació. Els equips poden dedicar massa temps en planificar o preparar les tasques. Aquest és un error comú per equips menys familiaritzats amb el procés àgil on els equips se senten obligats a comprendre completament detalladament totes les històries dels altres usuaris.

• Resolució de problemes. L'scrum diari està destinat a ser una reunió ocasional amb tots els membres de l'equip per disseminar informació. Si la resolució de problemes ocorre sovint pot involucrar a diversos membres del grup el qual no és el millor ús del temps.

• Assignació de tasques. Un dels beneficis de l'àgil és la pressa de decisions enfront dels problemes. A més, les decisions s'han de fer properes a la implementació a diferència del tradicional mètode de la cascada. Si als membres de l'equip se'ls assignen tasques per altres o massa d'hora en el procés, llavors els beneficis de la presa de decisions es poden perdre.

Un altre problema és la correcta assignació de tasques de manera que encaixin en determinats rols. Els propis membres de l'equip han de poder escollir les tasques més adients per les seves habilitats.

• L'ScrumMaster com a contribuïdor. Encara que no està prohibit per l'àgil, l'ScrumMaster s'ha d'assegurar que té la capacitat d'actual com a cap primer i no treballar en les tasques del projecte. El lloc de ScrumMaster serveix per facilitar el procés de Scrum.

Tenir l'ScrumMaster fent multi tasca pot resultar en massa canvis de context per a ser productiu. Pot perjudicar la capacitat de l'ScrumMaster per desfer tasques bloquejadores.

• Falta d'automatització de proves. Degut a la naturalesa iterativa del mètode àgil les múltiples proves per projectes són sovint necessàries.

L'automatització de mètodes d'assaig també suporta la contínua refactorització requerida per un mètode iteratiu de desenvolupament de programari. No obstant, a vegades treu massa temps als programadors pel qual no es fa sempre. Per altra banda l'automatització de proves també és compatible amb la refactorització contínua requerida pel desenvolupament de programari iteratiu. Permetir que un desenvolupador executi ràpidament les proves per confirmar que la refactorització no ha modificat la funcionalitat de l'aplicació pot reduir la càrrega de treball i augmentar la confiança en què els esforços de neteja no han introduït nous problemes.

• Permetre l'acumulació de deute tècnic. El fet de centrar-se a lliurar una nova funcionalitat pot resultat en un deute tècnic acumulat. Els equips han de permetre's un temps per solucionar defectes i refactoritzar. El deute tècnic obstaculitza les habilitats per planejar incrementant el nombre de tasques no programades com a defectes de producció, el qual desvia l'equip del progrés del projecte.

• Intent de prendre's en excés un sprint. Un concepte freqüentment confós en l'ús d'àgil és que permet el canvi continu. El backlog d'un sprint és un conjunt de feina que pot ser realitzada durant l'sprint. No necessàriament s'han de dur a terme totes les tasques. Tampoc hi pot haver un canvi continu perquè pot resultar en ineficiències degut a temps perdut, esforços i recursos invertits.

• Temps fix, recursos, abast i qualitat. L'àgil fixa un temps (la duració de l'sprint) i uns recursos mentre que l'abast i la qualitat es mantenen variables. El client o el propietari del producte sovint suggereix un abast fix per a un determinat sprint. No obstant, els equips han d'estar preparats per gestionar el temps, els recursos i l'abast (conegut com a Triangle de la gestió de projectes). Tractar d'afegir abast al temps fixat recursos de l'àgil pot resultar en la disminució de la qualitat del producte.

 

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Metodologia àgil

• Manifest àgil (en català)