Per què treballem amb metodologia àgil

D’on ve l’agilitat

L’any 2001, disset desenvolupadors de software es van reunir a Snowbird, Utah, per parlar d’una cosa que tots havien observat per separat: els mètodes tradicionals de gestió de projectes no funcionaven bé per fer software. D’aquella trobada en va sortir el Manifest Àgil (Manifesto for Agile Software Development), un text breu que ha acabat definint com treballa bona part de la indústria.

El manifest no és una metodologia ni un conjunt de normes. Són quatre valors i dotze principis. Els valors diuen que, tot i que els elements de la dreta tenen valor, en valorem més els de l’esquerra:

• Individus i interaccions per sobre de processos i eines.
• Software que funciona per sobre de documentació exhaustiva.
• Col·laboració amb el client per sobre de negociació contractual.
• Resposta al canvi per sobre de seguir un pla.

És important llegir-lo bé: no diu que la documentació, els plans o els contractes no serveixin. Diu que quan hi ha conflicte entre les dues coses, l’esquerra ha de guanyar.

El problema que resol

Per entendre per què això és una bona idea, cal entendre el model que substituïa. El desenvolupament en cascada (waterfall) organitza un projecte en fases seqüencials: primer s’especifica tot, després es dissenya tot, després es programa tot i, al final, es prova i es lliura. Sobre el paper és ordenat. A la pràctica té un defecte estructural: tot el feedback arriba al final, quan ja s’ha gastat la major part del temps i del pressupost.

I el feedback al final és car per una raó molt simple: el software és un producte que ningú no sap especificar del tot per endavant. El client descobreix què necessita realment quan veu el producte funcionant. Els desenvolupadors descobreixen les dificultats tècniques quan hi treballen. El mercat canvia mentre el projecte avança. En un projecte de divuit mesos en cascada, totes aquestes descobertes es fan quan ja és tard per reaccionar-hi sense refer feina.

Cicles curts, risc petit

La resposta àgil a aquest problema és treballar en iteracions curtes, normalment d’una a quatre setmanes, i que cadascuna acabi amb software que funciona a les mans del client. Un dels dotze principis ho diu literalment: la mesura principal de progrés és el software funcionant, no els documents aprovats ni les fases completades.

Aquest canvi té conseqüències en cadena:

• El risc es fragmenta. Si una iteració va per mal camí, es perden dues setmanes, no divuit mesos. Els errors de concepte es detecten quan encara són barats de corregir.
• El client valida sobre realitat, no sobre promeses. Veure una funcionalitat en marxa genera un feedback molt més útil que revisar un document d’especificacions de cent pàgines.
• Les prioritats poden canviar. Com que el pla es revisa a cada iteració, incorporar un canvi de prioritats és el funcionament normal del sistema, no una crisi. El manifest en fa un principi explícit: els canvis de requisits són benvinguts, fins i tot tard en el desenvolupament.
• Es lliura valor des del principi. El client no espera al final per tenir alguna cosa útil: les funcionalitats més importants es fan primer i es poden posar en producció abans que el projecte acabi.

Persones que parlen entre elles

El segon pilar és menys tècnic i més humà. El manifest posa els individus i les interaccions al capdavant perquè la majoria de problemes en un projecte de software no són d’eines: són de comunicació. Requisits mal entesos, supòsits no verificats, decisions preses sense qui tenia la informació.

D’aquí vénen pràctiques com la conversa directa i freqüent entre negoci i equip tècnic (un altre principi demana que treballin junts diàriament), els equips petits i autoorganitzats, i la retrospectiva: aturar-se a intervals regulars a pensar com treballar millor i ajustar-ho. Aquesta última és potser la idea més potent del manifest, perquè converteix la manera de treballar en una cosa que també s’itera i es millora, igual que el producte.

Què no és l’agilitat

Convé desfer dos malentesos habituals. El primer és que àgil no vol dir improvisar. Es planifica constantment; el que no es fa és fingir que un pla detallat a un any vista sobreviurà al contacte amb la realitat. El segon és que àgil no és sinònim de cap marc concret. Scrum, Kanban o Extreme Programming són implementacions dels valors del manifest, cadascuna amb les seves eines. Es pot seguir Scrum al peu de la lletra i no ser gens àgil, si les cerimònies es fan buides de contingut.

En resum

La metodologia àgil funciona perquè accepta una veritat incòmoda del desenvolupament de software: la incertesa no es pot eliminar, només gestionar. En lloc d’intentar predir-ho tot al principi, construeix un sistema que aprèn ràpid, amb iteracions curtes, feedback constant i el software funcionant com a única mesura fiable, i que pot canviar de direcció quan aprèn alguna cosa nova. Gairebé vint-i-cinc anys després, els quatre valors del manifest continuen sent la millor descripció breu de com es fa bon software: no seguint un procés perfecte, sinó col·laborant, lliurant sovint i adaptant-se.