The Agile Manifesto
Al llarg de la història, i molt especialment al segle XX, quan un grup de creadors ha volgut plasmar les seves revolucionàries idees estètiques en un programa, ha elaborat un manifest, normalment buscant la provocació i la polèmica. Les avantguardes en van plenes: el manifest futurista de Marinetti, el surrealista de Breton, el dadà de Tzara, el cubista d'Apollinaire, el constructivista de Gabo i Pevsner, l'amorfista de Picabia...
Això que en la literatura, l'art, l'arquitectura, el cinema i la política és moneda corrent, també es dóna en altres àmbits. En el camp de la informàtica, per exemple. El febrer de 2001, en el marc d'una trobada informal al parador The Lodge at Snowbird a les muntanyes Wasatch de Utah, un grup d'experts formaren The Agile Alliance i gestaren el Manifesto for Agile Software Development (conegut popularment com Agile Manifesto), que ha acabat per revolucionar la forma d'abordar els projectes d'enginyeria del software professional.
Fins aleshores el desenvolupament de software havia seguit un patró en cascada, amb una seqüència de fases ben definides: (1) captura de requeriments, (2) anàlisi funcional i disseny, (3) desenvolupament, (4) test, (5) instal·lació i (6) manteniment. De totes elles la més important era l'anàlisi i disseny, que tenia per objectiu deixar definida completament tota la funcionalitat del projecte i planificar amb antelació totes les eventualitats que poguessin donar-se. En projectes de gran envergadura aquesta fase podia durar mesos i fins i tot anys. Malgrat que s'establien fites durant el procés per a que el client pogués controlar l'evolució del projecte, el cert és que (a) el client no disposava d'una versió (parcial) de l'aplicació fins molt temps després d'haver començat el projecte, i (b) la introducció de canvis en etapes avançades del projecte era molt dolorosa perquè obligava a revisar tot el treball que ja havia estat donat per tancat i mobilitzava recursos que, en haver finalitzat la seva tasca, potser ja no estaven disponibles.
El manifest d'aquests autodenominats «anarquistes» —entre els que s'hi comptaven gurús com Kent Beck, Martin Fowler, Robert C. Martin, Ward Cunningham, Alistair Cockburn i Andrew Hunt— trencava amb aquesta filosofia i proposava una forma radicalment nova de gestionar els projectes informàtics. No era una revolució tècnica —tot i que se'n seguirien avenços molt rellevants—, sinó conceptual. Els principis del desenvolupament àgil entroncaven amb els de l'Extreme Programming introduïts uns anys abans per un dels signants, Kent Beck, així com amb altres metodologies que han acabat per aixoplugar-se sota el paraigües d'aquest terme. Els promotors proposaven lliurar aviat i de forma freqüent software estable i de qualitat, així com ser capaços d'adaptar-se a nous requeriments dels clients fins i tot en fases avançades del desenvolupament. Per això, la col·laboració entre tècnics i experts en el negoci no ha de limitar-se a la fase inicial sinó que ha de ser present durant tot el cicle de vida del projecte. I com es duu a terme tot això? Doncs els ideòlegs no donaven un conjunt de normes inflexibles, però sí que apostaven per un seguit de «bones pràctiques»: actualitzacions diàries en el control de versions, compilació automàtica i notificació immediata dels errors (de manera que es pugui reaccionar d'immediat), ús generalitzat de tests automatitzats (que requereix d'una arquitectura amb poc o cap acoblament entre capes), èmfasi en el refactoring i l'ús de patrons de disseny, documentació limitada al mínim indispensable, infraestructura creada sota demanda, propietat compartida del codi (tothom té permís per treballar sobre qualsevol part del projecte), treball en parella per a problemes complexos... La idea és que al final de cada iteració —de dues setmanes a un mes— l'equip estigui en condicions de lliurar un programari que hagi passat per totes les etapes de la cascada (és a dir, analitzat, dissenyat, implementat i provat), però que contingui únicament una part de la funcionalitat total del projecte.
Els informàtics, probablement la comunitat professional més dinàmica que existeix, van acollir la idea amb simpatia i es van posar a treballar per a crear eines que desenvolupessin en profunditat aquests conceptes. Avui dia l'àrea ja està prou madura i qualsevol equip que vulgui implantar la metodologia àgil disposa d'un corpus de literatura i d'un conjunt d'eines que li faciliten molt la feina. Entre elles, cal destacar els volums generalistes (Cockburn, Martin, Larman, Subramaniam i Hunt, entre molts altres); els llibres (Duvall) i les eines (Team Foundation Server, MSBuild) per a la integració contínua; els llibres (Beck, Meszaros) i les eines (la família xUnit per al Unit Testing, els frameworks per treballar amb mock objects) per al desenvolupament guiat per tests; llibres (el pioner dels Gang of Four, Fowler) sobre patrons de disseny; llibres (Fowler, Kerievsky) i eines (Resharper) sobre refactoring; etc. També s'ha definit com ha de ser la gestió de projectes àgils: l'Scrum (Beedle i Schwaber), i Mary i Tom Poppendieck han proposat una variant d'aquesta filosofia, el Lean software development, inspirada en l'exitós model de producció de Toyota. Tot plegat va estimular també el treball amb altres eines que encaixaven bé en aquest esquema, com l'object-relational mapping (Hibernate) o els anomenats contenidors amb inversió de control i injecció de dependències (Spring, PicoContainer…). Essent com és una tècnica incardinada en la programació orientada a objectes, també es va reimpulsar el treball intensiu de modelatge, sistematitzat en l'anomenat domain-driven design (Evans, Nilsson). Des d'aleshores han aparegut webs especialitzades, revistes, congressos, etc.
És enganyós dir que la programació àgil s'oposa al tradicional desenvolupament planificat o disciplinat, perquè sembla donar a entendre que aquell és anàrquic o indisciplinat, quan la realitat és que segueix protocols molt sistemàtics. És més correcte assenyalar la contraposició entre un model predictiu (el de cascada) i un d'adaptatiu (l'àgil). Tampoc s'ha de confondre el desenvolupament àgil amb el «cowboy coding»: els equips àgils segueixen controls de qualitat molt rigorosos i practiquen el refactoring amb assiduïtat. Encara s'han de vèncer algunes reticències entre mànagers i directius, que si bé accepten encantats el fet que es pugui lliurar programari al client aviat i de manera cíclica, sovint no estan disposats a pagar el preu que això comporta, sobretot en temps destinat a dissenyar tests automàtics o a renunciar a treballar amb molts júniors per la complexitat i exigència de l'entorn tècnic. També els clients han d'acostumar-se a l'escassa documentació generada en un projecte àgil. Poc a poc, però, la programació àgil va imposant-se en els projectes més ambiciosos com el nou paradigma.
Això que en la literatura, l'art, l'arquitectura, el cinema i la política és moneda corrent, també es dóna en altres àmbits. En el camp de la informàtica, per exemple. El febrer de 2001, en el marc d'una trobada informal al parador The Lodge at Snowbird a les muntanyes Wasatch de Utah, un grup d'experts formaren The Agile Alliance i gestaren el Manifesto for Agile Software Development (conegut popularment com Agile Manifesto), que ha acabat per revolucionar la forma d'abordar els projectes d'enginyeria del software professional.
Fins aleshores el desenvolupament de software havia seguit un patró en cascada, amb una seqüència de fases ben definides: (1) captura de requeriments, (2) anàlisi funcional i disseny, (3) desenvolupament, (4) test, (5) instal·lació i (6) manteniment. De totes elles la més important era l'anàlisi i disseny, que tenia per objectiu deixar definida completament tota la funcionalitat del projecte i planificar amb antelació totes les eventualitats que poguessin donar-se. En projectes de gran envergadura aquesta fase podia durar mesos i fins i tot anys. Malgrat que s'establien fites durant el procés per a que el client pogués controlar l'evolució del projecte, el cert és que (a) el client no disposava d'una versió (parcial) de l'aplicació fins molt temps després d'haver començat el projecte, i (b) la introducció de canvis en etapes avançades del projecte era molt dolorosa perquè obligava a revisar tot el treball que ja havia estat donat per tancat i mobilitzava recursos que, en haver finalitzat la seva tasca, potser ja no estaven disponibles.
El manifest d'aquests autodenominats «anarquistes» —entre els que s'hi comptaven gurús com Kent Beck, Martin Fowler, Robert C. Martin, Ward Cunningham, Alistair Cockburn i Andrew Hunt— trencava amb aquesta filosofia i proposava una forma radicalment nova de gestionar els projectes informàtics. No era una revolució tècnica —tot i que se'n seguirien avenços molt rellevants—, sinó conceptual. Els principis del desenvolupament àgil entroncaven amb els de l'Extreme Programming introduïts uns anys abans per un dels signants, Kent Beck, així com amb altres metodologies que han acabat per aixoplugar-se sota el paraigües d'aquest terme. Els promotors proposaven lliurar aviat i de forma freqüent software estable i de qualitat, així com ser capaços d'adaptar-se a nous requeriments dels clients fins i tot en fases avançades del desenvolupament. Per això, la col·laboració entre tècnics i experts en el negoci no ha de limitar-se a la fase inicial sinó que ha de ser present durant tot el cicle de vida del projecte. I com es duu a terme tot això? Doncs els ideòlegs no donaven un conjunt de normes inflexibles, però sí que apostaven per un seguit de «bones pràctiques»: actualitzacions diàries en el control de versions, compilació automàtica i notificació immediata dels errors (de manera que es pugui reaccionar d'immediat), ús generalitzat de tests automatitzats (que requereix d'una arquitectura amb poc o cap acoblament entre capes), èmfasi en el refactoring i l'ús de patrons de disseny, documentació limitada al mínim indispensable, infraestructura creada sota demanda, propietat compartida del codi (tothom té permís per treballar sobre qualsevol part del projecte), treball en parella per a problemes complexos... La idea és que al final de cada iteració —de dues setmanes a un mes— l'equip estigui en condicions de lliurar un programari que hagi passat per totes les etapes de la cascada (és a dir, analitzat, dissenyat, implementat i provat), però que contingui únicament una part de la funcionalitat total del projecte.
Els informàtics, probablement la comunitat professional més dinàmica que existeix, van acollir la idea amb simpatia i es van posar a treballar per a crear eines que desenvolupessin en profunditat aquests conceptes. Avui dia l'àrea ja està prou madura i qualsevol equip que vulgui implantar la metodologia àgil disposa d'un corpus de literatura i d'un conjunt d'eines que li faciliten molt la feina. Entre elles, cal destacar els volums generalistes (Cockburn, Martin, Larman, Subramaniam i Hunt, entre molts altres); els llibres (Duvall) i les eines (Team Foundation Server, MSBuild) per a la integració contínua; els llibres (Beck, Meszaros) i les eines (la família xUnit per al Unit Testing, els frameworks per treballar amb mock objects) per al desenvolupament guiat per tests; llibres (el pioner dels Gang of Four, Fowler) sobre patrons de disseny; llibres (Fowler, Kerievsky) i eines (Resharper) sobre refactoring; etc. També s'ha definit com ha de ser la gestió de projectes àgils: l'Scrum (Beedle i Schwaber), i Mary i Tom Poppendieck han proposat una variant d'aquesta filosofia, el Lean software development, inspirada en l'exitós model de producció de Toyota. Tot plegat va estimular també el treball amb altres eines que encaixaven bé en aquest esquema, com l'object-relational mapping (Hibernate) o els anomenats contenidors amb inversió de control i injecció de dependències (Spring, PicoContainer…). Essent com és una tècnica incardinada en la programació orientada a objectes, també es va reimpulsar el treball intensiu de modelatge, sistematitzat en l'anomenat domain-driven design (Evans, Nilsson). Des d'aleshores han aparegut webs especialitzades, revistes, congressos, etc.
És enganyós dir que la programació àgil s'oposa al tradicional desenvolupament planificat o disciplinat, perquè sembla donar a entendre que aquell és anàrquic o indisciplinat, quan la realitat és que segueix protocols molt sistemàtics. És més correcte assenyalar la contraposició entre un model predictiu (el de cascada) i un d'adaptatiu (l'àgil). Tampoc s'ha de confondre el desenvolupament àgil amb el «cowboy coding»: els equips àgils segueixen controls de qualitat molt rigorosos i practiquen el refactoring amb assiduïtat. Encara s'han de vèncer algunes reticències entre mànagers i directius, que si bé accepten encantats el fet que es pugui lliurar programari al client aviat i de manera cíclica, sovint no estan disposats a pagar el preu que això comporta, sobretot en temps destinat a dissenyar tests automàtics o a renunciar a treballar amb molts júniors per la complexitat i exigència de l'entorn tècnic. També els clients han d'acostumar-se a l'escassa documentació generada en un projecte àgil. Poc a poc, però, la programació àgil va imposant-se en els projectes més ambiciosos com el nou paradigma.
Cap comentari:
Publica un comentari a l'entrada