Sviluppo agile: di cosa si tratta?

Lo sviluppo agile di software non è cer­ta­men­te una novità e in molti settori la­vo­ra­ti­vi i metodi agili sono oramai con­so­li­da­ti. Il concetto non è però ancora chiaro a tutti. A partire da quando si può dire che un'a­zien­da lavora secondo una me­to­do­lo­gia agile? Non si tratta piuttosto di un metodo tra­di­zio­na­le fal­sa­men­te ri­pro­po­sto come concetto alla moda? Vediamo cosa si intende esat­ta­men­te per sviluppo agile nel presente articolo.

Già negli anni ’90, i team di svi­lup­pa­to­ri di software ini­zia­ro­no a lavorare con metodi che oggi possono essere con­si­de­ra­ti come sviluppo agile di software. Fino alla fine del XX secolo diversi svi­lup­pa­to­ri software e team si presero a cuore l’obiettivo di al­leg­ge­ri­re il lavoro di pro­gram­ma­zio­ne: il loro metodo divenne noto so­prat­tut­to con il termine chiave light­weight. In quello stesso periodo vennero svi­lup­pa­ti anche i metodi Scrum e Kanban, che all’epoca non vennero ancora fatti rientrare sotto il concetto di “sviluppo agile di prodotti”, poiché questa espres­sio­ne non esisteva ancora.

Nel 2001, fi­nal­men­te, si verificò una netta rottura: in occasione di un incontro co­no­sciu­to oggi con il nome di “Snowbird Meeting” (dal nome del com­pren­so­rio sciistico in cui si svolse l’incontro), 17 svi­lup­pa­to­ri scrissero il Manifesto per lo sviluppo agile di software, durante il quale unirono tutte le loro espe­rien­ze in materia di sviluppo software e di lavoro di squadra, in­di­vi­dua­ro­no delle soluzioni, de­fi­ni­ro­no dei principi e fissarono tutto sotto il concetto che oggi è sinonimo di me­to­do­lo­gia di lavoro moderno, vale a dire lo sviluppo agile di software.

Quando si ini­zia­ro­no a mettere in di­scus­sio­ne i metodi di sviluppo di software per poi spe­ri­men­ta­re con il Manifesto Agile un nuovo modo di definire il progetto di lavoro, ci si è da subito posti l’obiettivo di lavorare in maniera più fles­si­bi­le, più creativa e più pro­dut­ti­va. Invece di seguire una procedura pia­ni­fi­ca­ta, lineare e bu­ro­cra­ti­ca come nei metodi tra­di­zio­na­li (ad esempio il modello a cascata, nello sviluppo agile si decide di sud­di­vi­de­re il progetto e di con­se­guen­za di at­tri­bui­re al team di pro­gram­ma­to­ri molta più re­spon­sa­bi­li­tà.

Inoltre, si ab­ban­do­na­no quasi del tutto i grandi progetti: invece di tra­scor­re­re mesi o ad­di­rit­tu­ra anni intorno alla rea­liz­za­zio­ne di un prodotto, i team agili dedicano solo poche settimane a una fase del lavoro. Il risultato è un prodotto finito, un ag­gior­na­men­to o una parte di un programma che può essere pre­sen­ta­to al cliente. Nel Manifesto Agile sono stati con­cor­da­ti dodici principi e quattro valori perché tutto questo si possa ef­fet­ti­va­men­te rea­liz­za­re.

I valori dello sviluppo agile di software esprimono gli obiettivi sui quali i team devono rimanere fo­ca­liz­za­ti durante il lavoro di sviluppo. Sono annotati come coppie in antitesi dove entrambi gli aspetti sono im­por­tan­ti, ma ce n’è sempre uno che è superiore all’altro:

• In­di­vi­duals and in­te­rac­tions over processes and tools: le persone coinvolte e la loro reciproca col­la­bo­ra­zio­ne sono più im­por­tan­ti della richiesta di un de­ter­mi­na­to processo o strumento.
• Working software over com­pre­hen­si­ve do­cu­men­ta­tion: è im­por­tan­te avere un prodotto finale fun­zio­nan­te. La do­cu­men­ta­zio­ne del lavoro ha un’im­por­tan­za se­con­da­ria.
• Customer col­la­bo­ra­tion over contract ne­go­tia­tion: lo sviluppo agile di prodotti deve pre­oc­cu­par­si mag­gior­men­te di sod­di­sfa­re le esigenze del cliente, piuttosto che della ne­go­zia­zio­ne dei contratti.
• Re­spon­ding to change over following a plan: si presume che lo sviluppo del software debba adattarsi a continui cam­bia­men­ti. Può rivelarsi ne­ces­sa­rio, dunque, ribaltare un piano fissato in pre­ce­den­za.

Questi valori vanno con­si­de­ra­ti un mantra. Non for­ni­sco­no istru­zio­ni precise, ma ricordano agli svi­lup­pa­to­ri gli aspetti da tenere sempre in con­si­de­ra­zio­ne nella pro­du­zio­ne: lavorare in team, fo­ca­liz­zar­si sul software, dare priorità al cliente, essere fles­si­bi­li ai cam­bia­men­ti. Tutti gli altri aspetti, seppur im­por­tan­ti, vanno su­bor­di­na­ti a questi punti.

I dodici principi del Manifesto Agile sono istru­zio­ni più concrete e for­ni­sco­no in­for­ma­zio­ni ag­giun­ti­ve ed estendono le idee espresse nei valori. Ma anche in questo caso non possiamo parlare di un vero e proprio manuale d’istru­zio­ni, poiché non è questo che si propone di essere il manifesto. I principi sono molto ampi e servono a di­stin­gue­re metodi agili da metodi non agili.

• Sod­di­sfa­zio­ne del cliente: grazie a una pub­bli­ca­zio­ne tem­pe­sti­va e costante, secondo il concetto di Con­ti­nuous Delivery il cliente deve sentirsi sod­di­sfat­to in ogni momento.
• Fles­si­bi­li­tà: i team agili vedono nel cam­bia­men­to un aspetto positivo, anche se questo può com­por­ta­re ritardi al processo di sviluppo. Fare degli adat­ta­men­ti con il metodo agile a seconda delle esigenze che cambiano consente di offrire al cliente un risultato van­tag­gio­so.
• Consegna: il software fun­zio­nan­te viene con­se­gna­to nell’arco di poche settimane o mesi. Un arco di tempo più breve è sempre ben accolto.
• Coo­pe­ra­zio­ne: svi­lup­pa­to­ri e colleghi del settore vendite devono lavorare a stretto contatto. Il manifesto agile prevede meeting ogni giorno.
• Supporto: occorre creare un ambiente idoneo affinché gli individui siano motivati e i team creativi possano lavorare bene. Per questo è ne­ces­sa­rio sup­por­tar­si a vicenda e, so­prat­tut­to, avere la fiducia da parte dei superiori.
• Cultura del dialogo: la co­mu­ni­ca­zio­ne diretta è il modo migliore per passarsi in­for­ma­zio­ni nella maniera più efficace possibile e senza incorrere in malintesi. Parlarsi di persona permette di porsi domande a vicenda e di evitare di trarre con­clu­sio­ni sbagliate.
• Successi: il successo di un team si misura prin­ci­pal­men­te con la pub­bli­ca­zio­ne di software fun­zio­nan­ti.
• So­ste­ni­bi­li­tà: lo sviluppo deve essere portato avanti in maniera costante. A tal fine tutte le parti coinvolte, e non solo gli svi­lup­pa­to­ri, devono con­ti­nua­re a lavorare sulle pub­bli­ca­zio­ni.
• Qualità: gli svi­lup­pa­to­ri devono sempre fare in modo che i loro prodotti sod­di­sfi­no gli standard più elevati dal punto di vista tecnico e pro­get­tua­le.
• Sem­pli­ci­tà: il lavoro va sem­pli­fi­ca­to il più possibile. Scartare tutto ciò che risulta superfluo aiuta a snellire il processo e, quindi, a ottenere risultati migliori.
• Or­ga­niz­za­zio­ne: se i team hanno la pos­si­bi­li­tà di or­ga­niz­zar­si au­to­no­ma­men­te, si possono ottenere risultati straor­di­na­ri.
• Re­tro­spet­ti­va: un aspetto im­por­tan­te dello sviluppo agile di software è mettere in di­scus­sio­ne in qualsiasi momento aspetti trattati in pre­ce­den­za. Al fine di mi­glio­ra­re co­stan­te­men­te il lavoro del team, è opportuno che i com­po­nen­ti si scambino re­go­lar­men­te in­for­ma­zio­ni sul proprio metodo di lavoro e che adattino, di con­se­guen­za, il proprio approccio.

Nell’ambito dello sviluppo agile di software si sono con­so­li­da­te alcune pratiche per applicare il metodo agile al proprio team o azienda. “Sviluppo agile” resta soltanto un concetto col­let­ti­vo. Si possono ri­scon­tra­re molte di queste tecniche di sviluppo agile di software ad esempio in contesti quali Scrum, Kanban, Extreme Pro­gram­ming, Feature Driven De­ve­lo­p­ment, Behaviour Driven De­ve­lo­p­ment o Chrystal.

• Backlog: il metodo agile prevede di tenere traccia di tutti i compiti che non vanno ancora eseguiti e che non sono in corso di la­vo­ra­zio­ne. Questo perché si procede per fasi brevi di lavoro. Invece di occuparsi di più attività nello stesso momento o di assegnare un preciso margine di tempo a ogni attività entro un piano più grande, si dispone di un pool fles­si­bi­le in back­ground. Da questo elenco il team può scegliere il compito suc­ces­si­vo da eseguire.
• Re­tro­spet­ti­ve: i meeting regolari non sono solo un principio astratto ma, secondo il metodo agile, fanno con­cre­ta­men­te parte dell’attività quo­ti­dia­na. In par­ti­co­la­re, Scrum è noto per avere una pro­gram­ma­zio­ne fissa per le varie riunioni. Soltanto se il team affronta quo­ti­dia­na­men­te sfide e problemi, come anche i successi, può mi­glio­rar­si nel lungo termine.
• User Story: la richiesta di fo­ca­liz­zar­si sul cliente o sull’utente può essere sod­di­sfat­ta soltanto ri­vol­gen­do­si alla sua storia. Qui viene spiegato in maniera semplice come deve essere una funzione per ri­spon­de­re all’esigenza dell’utente. Questa de­scri­zio­ne viene annotata in una co­sid­det­ta Story Card e tutte queste cartelle vengono or­ga­niz­za­te in una Story Map.
• Agile Testing: nello sviluppo agile di software, l’attività di test è con­si­de­ra­ta parte in­te­gran­te del processo di sviluppo. So­li­ta­men­te il prodotto viene testato dal team al termine di un’ite­ra­zio­ne (fase di lavoro breve) prima di essere con­si­de­ra­to “finito” e ri­la­scia­to al cliente. Dopodiché comincia l’ite­ra­zio­ne suc­ces­si­va relativa a una nuova funzione.
• Pro­gram­ma­zio­ne in coppia: nella pro­gram­ma­zio­ne in coppia si applica il principio dei quattro occhi. Due svi­lup­pa­to­ri con­di­vi­do­no una po­sta­zio­ne di lavoro. Mentre uno scrive il codice, l’altro ne verifica l’im­mis­sio­ne. Ciò comporta si­cu­ra­men­te un maggior dispendio di tempo (l’esa­mi­na­to­re potrebbe scrivere da solo il codice), ma dovrebbe con­sen­ti­re un minor numero di errori nel codice.
• Ti­me­bo­xing: alcune forme di sviluppo agile hanno rigidi termini di scadenza. Scrum è, anche in questo caso, un esempio in cui gli sprint hanno una durata ben definita. Al termine di questi, il team deve pre­sen­ta­re un prodotto finito. È ne­ces­sa­rio, quindi, pro­get­ta­re e se­le­zio­na­re le attività in modo opportuno.

Ci sono ancora molte altre tecniche che si possono ri­scon­tra­re nei metodi agili. Tutte si pre­fig­go­no l’obiettivo di rendere più efficace il flusso di lavoro e di aumentare la qualità del prodotto.

Dai suoi so­ste­ni­to­ri l’approccio dello sviluppo agile di software viene promosso come unica pos­si­bi­li­tà di svi­lup­pa­re prodotti og­gi­gior­no. Tuttavia non è sempre la soluzione ideale per tutti i team e aziende. A seconda della si­tua­zio­ne aziendale, gli svantaggi po­treb­be­ro superare i vantaggi.