Metodologia àgil

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

Les metodologies àgils o processos àgils de desenvolupament de programari (com, per exemple, XP, Scrum, DSDM, Cristal, etc.) són aquelles metodologies de desenvolupament que es basen en l'adaptabilitat de qualsevol canvi com a mitjà per augmentar les possibilitats d'èxit d'un projecte.

La majoria dels mètodes àgils intenten minimitzar el risc desenvolupant el programari en iteracions, que típicament duren d'una a quatre setmanes. Cada iteració és com un projecte en miniatura del projecte final, i inclou totes les tasques necessàries per després implementar les funcionalitats noves: planificació, anàlisi de requisits, disseny, codificació, testatge, i documentació. Mentre que una iteració pot no afegir prou funcionalitats per garantir alliberar el producte, un projecte de programari àgil pretén ser capaç d'alliberar programari nou al final de totes les iteracions. En molts casos, el programari s'allibera al final de cada iteració, especialment quan el programari és basat en la web i es pot llançar fàcilment. Malgrat tot, al final de cada iteració, l'equip reavalua les prioritats de projecte.

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

Es pot dir que aquest moviment va començar a existir a partir del febrer del 2001, quan es van reunir els representants de cada una d'aquestes metodologies i van posar en comú les seves idees en una declaració conjunta, el manifest àgil.

Visió General[modifica | modifica el codi]

La programació en parelles, una tècnica de desenvolupament àgil que utilitza XP. Nota radiadors d'informació en el fons.

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 a un equip multi-disciplinar 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 projecte 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. Múltiples iteracions podrien ser necessàries per llançar un producte o noves característiques.

Eficient i la communicació cara a cara

No importen les disciplines de desenvolupament que es requereixen, cada equip àgil contindrà un representant del client, per exemple el Responsable del Producte en Scrum. Aquesta persona és nomenat per les parts interessades perque actuï en el seu nom i fa un compromís personal d'estar disponible per als desenvolupadors per respondre a les preguntes de meitat d'iteració. Al final de cada iteració, les parts interessades i l'opinió del representant dels clients re-avalua 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 un (normalment gran) desplegament físic ubicat prominentment en una oficina, on els transeünts poden veure-ho. 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 a un equip sobre l'estat actual del seu projecte.

Circuit de retroalimentació molt curt i el 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 el que van fer el dia anterior, el que pretenen fer avui, i quines són els obstacles que tenen.

Enfocament de Qualitat

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 d'altres tècniques que s'utilitzen sovint per millorar la qualitat i millorar l'agilitat projecte.

Filosofia[modifica | modifica el codi]

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

Adaptatiu contra Predictiu[modifica | modifica el codi]

Les metodologies de desenvolupament existeixen en un continuu des de adaptatiu fins a predictiu.[1] 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-les, 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 passara 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 més 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 nomes 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 en 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'assegurara que només els canvis més importants s'afegeixin al projecte.

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

Característiques de les metodologies
Mètodes àgils Mètodes predictius Mètodes formals
Poc crítics Altament crítics Extremadament crítics
Desenvolupament sènior Desenvolupament junior Desenvolupament sènior
Els requeriments canvien sovint. Els requeriments no canvien. Requeriments limitats.
Equips petits Equips grans Els requeriments es poden modelar
Cultura que respon al canvi. Cultura que demana ordre. Alta qualitat

Desenvolupament iteratiu i Desenvolupament en cascada[modifica | modifica el codi]

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'esta 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 seguira el programa (p.e l'Scrum té com a màxim iteracions d'un mes), permet a l'equip intentar màximitzar 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.

Codi i documentació[modifica | modifica el codi]

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 disciplin 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ó"[3].

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 documnentació estàtica.[4] Scott Ambler diu que la documentació haurià de ser amb prou feines acceptable (de l'anglès Just Barely Good Enough (JBGE)[5], ja que molta documentació serià una perdua de temps, perquè habitualment els desenvolupadors no se'n refien d'una documentació molt detallada, perquè normalment no està sincronitzada amb el codi[4], d'altra banda molt poca documentació o una molt probre pot donar problemes per manteniment, comunicacio, aprenentatge, etc.

Les metodologies àgils i el canvi[modifica | modifica el codi]

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 fixes 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.

Mètodes àgils[modifica | modifica el codi]

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

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.

Pràctiques Àgils[modifica | modifica el codi]

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:

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.

El mètode sastreria[modifica | modifica el codi]

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 a 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'ha d'adaptar a les necessitats de cada projecte. L'adopció parcial de les pràctiques de XP, segons el suggerit per Beck, s'ha n'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.

Comparació entre altres mètodes[modifica | modifica el codi]

RAD[modifica | modifica el codi]

Els mètodes àgils tenen molt en comú amb les tècniques de desenvolupament ràpid d'aplicacions a partir dels 1980/90 com exposada James Martin, entre d'altres 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.

CMMI[modifica | modifica el codi]

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.

 Experiències i aprovació[modifica | modifica el codi]

Enquestes[modifica | modifica el codi]

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. Un altra enquesta realitzada anteriorment al 2006, destaca beneficis similars.[6]

Àgil a gran escala i distribuït[modifica | modifica el codi]

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.

Problemes freqüents amb l'àgil[modifica | modifica el codi]

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 pel flux establert per l'àgil. Scrum certament ofereix provisió per canviar les prioritats del backlog de producte a meitat de projecte, no obstant això 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ó d'sprint, aquesta història ha de ser la de major prioritat respecte 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. Al 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 realitzada 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 sprint pugi 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 en front als 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. Una altre problema és la correcta assignació de tasques de manera que encaixin en determinats rols. Els propis membres del 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 d'ScrumMaster serveix per facilitar el procés d'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 continua 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 en 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 es 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 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.

Enllaços externs[modifica | modifica el codi]

  1. Boehm, B.; R. Turner Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, 2004. ISBN 0-321-18612-5.  Appendix A, pages 165–194
  2. Sliger, Michele; Broderick, Stacia The Software Project Manager's Bridge to Agility. Addison-Wesley, 2008, p. 46. ISBN 0-321-50275-2. 
  3. Rakitin, Steven R.. «Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin». IEEE Computer, 34, 2001, pàg. 4. «The article titled 'Agile Software Development: The Business of Innovation'. .. is yet another attempt to undermine the discipline of software engineering. .. We want to spend all our time coding. Remember, real programmers don’t write documentation.»
  4. 4,0 4,1 Scott Ambler. «Agile/Lean Documentation: Strategies for Agile Software Development».
  5. Scott Ambler. «Just Barely Good Enough Models and Documents: An Agile Best Practice».
  6. Ambler, Scott. «Suvey Says: Agile Works in Practice». Dr. Dobb's [Consulta: 3 Novembre 2014].