worksection
Blog
Metodologia Agile: La Madre dei Draghi oppure Tutte le Metodologie Flessibili
  •     •   14 min read

Metodologia Agile: La Madre dei Draghi oppure Tutte le Metodologie Flessibili

La sto­ria di Agile affon­da le radi­ci nel­la pub­bli­cazione del ​“Man­i­festo per lo Svilup­po del Soft­ware Agile”, com­pos­to da 12 prin­cipi fon­da­men­tali nel 2001. Sen­za dub­bio, alcu­ni approc­ci Agile era­no già appar­si pri­ma di allo­ra, ma solo questo doc­u­men­to ha sis­tem­atiz­za­to e defini­to tali aspet­ti a tal pun­to da essere uti­liz­z­abili. Anno dopo anno, nuove aziende, spe­cial­isti IT e project man­ag­er si atten­gono al Man­i­festo. Emer­gono nuovi meto­di e ver­sioni del sis­tema di svilup­po agile.

Cos’è la metodolo­gia Agile (flessibile)?

Agile è un mod­el­lo di svilup­po inter­at­ti­vo in cui il soft­ware viene cre­ato in modo incre­men­tale fin dal­l’inizio di un prog­et­to, a dif­feren­za dei mod­el­li a cas­ca­ta in cui il codice viene con­seg­na­to al ter­mine del ciclo di lavoro.

La metodolo­gia flessibile si basa sul­la sud­di­vi­sione dei prog­et­ti in pic­coli pezzi oper­a­tivi chia­mati sto­rie utente. In base alle pri­or­ità, i com­pi­ti ven­gono risolti all’in­ter­no di bre­vi cicli di due set­ti­mane (iter­azioni).

I 12 prin­cipi che cos­ti­tu­is­cono la Metodolo­gia Agile pos­sono essere rias­sun­ti in 4 idee principali:

  • Pri­or­ità alle per­sone e alla comu­ni­cazione rispet­to a stru­men­ti e processi;
  • Pri­or­ità a un prodot­to fun­zionale rispet­to a una doc­u­men­tazione abbondante;
  • Pri­or­ità alla col­lab­o­razione con i cli­en­ti rispet­to alla con­fer­ma dei contratti;
  • Pri­or­ità alla disponi­bil­ità ai cam­bi­a­men­ti rispet­to al seguire il piano iniziale.


Meto­di pro­pri di Agile:

Scrum

Il ter­mine Scrum è sta­to pre­so in presti­to dal rug­by, dove ques­ta paro­la sig­nifi­ca il meto­do di gio­co di squadra in cui tre linee ven­gono for­mate da cias­cun avver­sario che ten­ta di affer­rare la pal­la. Per un ri-approc­cio rius­ci­to, non solo è essen­ziale una buona for­ma fisi­ca: ogni gio­ca­tore scrum deve agire di con­cer­to con gli altri, con chiara con­sapev­olez­za dell’obiettivo.

Questo meto­do è uti­liz­za­to con suc­ces­so da aziende come Microsoft, Yahoo, Siemens Health­care. Un project man­ag­er di Ama­zon ha persi­no descrit­to un caso di intro­duzione di Scrum basato sull’esperienza acquisita.

Poiché Scrum è un frame­work per lo svilup­po, ogni esem­pio che segue può dif­ferire dal precedente.


Jeff Suther­land, l’au­tore del libro ​“Scrum. L’arte di fare il doppio del lavoro in metà tem­po”, ha dis­tin­to 8 pas­sag­gi per uti­liz­zare la metodologia:

  1. Selezionare il prod­uct own­er che è con­sapev­ole del­l’o­bi­et­ti­vo del prog­et­to e del risul­ta­to atteso.
  2. Orga­niz­zare un team — fino a 10 per­sone con le com­pe­ten­ze nec­es­sarie per creare un prodot­to operativo.
  3. Nom­i­na il Scrum mas­ter che super­vi­sion­erà il flus­so di lavoro del prog­et­to e assis­terà il team di prog­et­to nel­l’af­frontare le sfide.
  4. Creare il prod­uct back­log — per cias­cun req­ui­si­to del prodot­to, sta­bilire pri­or­ità nel­la board Agile. In questo proces­so, il ruo­lo del prod­uct own­er è essen­ziale, poiché rac­coglie le richi­este per il prodot­to affinchè il team di back­log le valuti.
  5. Pro­gram­mare sprint (iter­azioni) — fram­men­ti di tem­po per com­pletare catene def­i­nite di compiti.
  6. Orga­niz­zare incon­tri quo­tid­i­ani di quindi­ci minu­ti — chiedere a cias­cun mem­bro del team 3 domande: cosa ha fat­to ieri, cosa farà oggi, cosa osta­co­la il com­ple­ta­men­to del compito.
  7. Effet­tuare revi­sioni delle par­ti oper­a­tive del prodot­to — coin­vol­gen­do gli stake­hold­er in tali revisioni.
  8. Tenere ret­ro­spet­tive — dis­cus­sione sui prob­le­mi con ricer­ca di soluzioni dopo ogni sprint. Appli­care il piano di mod­i­fi­ca risul­tante nel suc­ces­si­vo sprint.

Ret­ro­spet­ti­va in Agile


Scrum ha 4 ele­men­ti chiave:

  • Prod­uct Back­log — elen­co dei req­ui­si­ti per il progetto 
  • Sprint Back­log — elen­co dei req­ui­si­ti da sod­dis­fare nel­l’im­mi­nente sprint 
  • Sprint Goal — obi­et­ti­vo del­lo sprint
  • Sprint Burn­down Chart — il dia­gram­ma che viene aggior­na­to man mano che i com­pi­ti ven­gono com­ple­tati. Facili­ta la com­pren­sione del­la dinam­i­ca e del liv­el­lo di avan­za­men­to del team nel progetto.

eXtreme Pro­gram­ming (XP)

Kent Beck, lo svilup­pa­tore di ques­ta metodolo­gia, ha cre­ato un meto­do di pro­gram­mazione estrema mira­to a rispon­dere ai req­ui­si­ti soft­ware volatili e a miglio­rare la qual­ità del­lo sviluppo.

È applic­a­bile solo nel cam­po del­lo svilup­po soft­ware e si basa su 4 processi:

  1. cod­i­fi­ca — sec­on­do gli stan­dard di lay­out comu­ni del team;
  2. test — i test ven­gono sostanzial­mente creati dai pro­gram­ma­tori pri­ma di scri­vere un codice che ver­rà testato;
  3. piani­fi­cazione — sia per la build finale che per le sin­gole iter­azioni. Queste ultime avven­gono medi­a­mente ogni due settimane.
  4. audizione — sia degli svilup­pa­tori che di un cliente, per elim­inare pun­ti poco chiari e definire req­ui­si­ti e valori.


Metodolo­gie Crystal

Ques­ta famiglia di metodolo­gie svilup­pa­ta da Alis­tair Cock­burn, uno degli autori del ​“Man­i­festo per lo Svilup­po del Soft­ware Agile”, è poco conosci­u­ta in alcu­ni domi­ni locali del­la ges­tione di prog­et­ti. Cock­burn pro­pone di fare la clas­si­fi­cazione per col­ori, basa­ta su un cri­te­rio come il numero di per­sone in un team: da 2 (Crys­tal Clear) a 100 (Crys­tal Red). I col­ori Mar­rone, Blu e Vio­la sono asseg­nati a prog­et­ti su larga scala.

I prog­et­ti Crys­tal devono con­for­mar­si a 3 carat­ter­is­tiche di base:
  1. spedi­zione veloce del codice oper­a­ti­vo — evoluzione del­l’idea per il mod­el­lo iter­a­ti­vo nel­lo svilup­po Agile.
  2. miglio­ra­men­to tramite rif­les­sione — una nuo­va ver­sione soft­ware viene miglio­ra­ta sul­la base delle infor­mazioni sul­la ver­sione precedente.
  3. inter­azione ​“osmot­ic” — inno­vazione di Alis­tair, una metafo­ra per comu­ni­cazione e scam­bio di infor­mazioni tra svilup­pa­tori soft­ware all’in­ter­no di una stes­sa stanza.

Ques­ta famiglia di metodolo­gie è descrit­ta in det­taglio nel libro ​“Crys­tal Clear: A Human-Pow­ered Method­ol­o­gy for Small Teams” di Alis­tair.


Metodolo­gia di Svilup­po Soft­ware Dinam­i­co (DSDM)

Non solo una sin­go­la per­sona, né una squadra, ma un con­sorzio di 17 aziende bri­tan­niche ha lavo­ra­to allo svilup­po di DSDM. Pro­prio come la pro­gram­mazione estrema, DSDM è uti­liz­za­to prin­ci­pal­mente per creare software.

Il con­suma­tore finale (utente) ha un ruo­lo spe­ciale nel proces­so di svilup­po. Questo prin­ci­pio fon­da­men­tale è inte­gra­to dai seguen­ti prin­cipi di base:

  • rilas­ci fre­quen­ti delle ver­sioni oper­a­tive del prodotto
  • autono­mia degli svilup­pa­tori nelle decisioni
  • test durante tut­to il ciclo di lavoro.
DSDM è sud­di­vi­so in ver­sioni che ven­gono aggior­nate man mano che le tec­nolo­gie si svilup­pano e appaiono nuovi req­ui­si­ti di svilup­po soft­ware. Attual­mente l’ultima è DSDM Atern rilas­ci­a­ta nel 2007, anche se la prece­dente (del 2003) è anco­ra in servizio.

All’inizio, il team con­sid­era la fat­tibil­ità del­lo svilup­po di un’ap­pli­cazione e il suo ambito di uti­liz­zo. Poi, il lavoro viene sud­di­vi­so in tre cicli interconnessi:

  1. ciclo del mod­el­lo fun­zionale — creazione di doc­u­men­ti analiti­ci e prototipi.
  2. ciclo di prog­et­tazione e ingeg­ne­r­ia — mes­sa in fun­zione di un sistema.
  3. ciclo di imple­men­tazione — dis­tribuzione del sistema.


Svilup­po Dri­ven dalle Carat­ter­is­tiche (FDD)

Ques­ta metodolo­gia è emer­sa anche pri­ma del ​“Man­i­festo per lo Svilup­po del Soft­ware Agile”.
Sebbene FDD uti­lizzi anche il mod­el­lo di svilup­po iter­a­ti­vo, si dif­feren­zia da Agile nelle seguen­ti caratteristiche:

  • mag­giore atten­zione alla model­lazione preliminare
  • mag­giore (rispet­to ad Agile) sig­ni­fi­ca­to del­la stesura di report e grafici
  • la metodolo­gia è prog­et­ta­ta per lo svilup­po aziendale.

Svilup­po Dri­ven dalle Carat­ter­is­tiche si com­pone delle seguen­ti fasi cicliche:

  1. Creazione di un mod­el­lo gen­erale — visione del prog­et­to basa­ta su dati preliminari.
  2. Svilup­po di un elen­co di pro­pri­età — sim­i­le al prod­uct back­log nel­la metodolo­gia Scrum.
  3. Piani­fi­cazione per pro­pri­età — la com­p­lessità delle pro­pri­età viene val­u­ta­ta da cias­cun mem­bro del team.
  4. Per cias­cu­na pro­pri­età — design e imple­men­tazione tec­ni­ca – la fase finale al ter­mine del­la quale la pro­pri­età si inte­gra nel prodot­to, e il ciclo si ripete.

Svilup­po Soft­ware Snello

Lo Svilup­po Soft­ware Snel­lo è un insieme di prin­cipi di ges­tione snel­la (anziché una metodolo­gia) che mira­no ad aumentare l’ef­fi­cien­za del proces­so di svilup­po e a min­i­miz­zare i costi.

Questo insieme include i seguen­ti 7 prin­cipi fondamentali:

  1. elim­i­nazione delle perdite — tut­to ciò che non aggiunge val­ore al prodot­to per il con­suma­tore finale.
  2. for­mazione con­tin­ua — lo svilup­po con­tin­uo di un team miglio­ra le pos­si­bil­ità di adem­pi­men­to effi­ciente dei compiti.
  3. pren­dere deci­sioni il più tar­di pos­si­bile — si dà pri­or­ità a soluzioni delib­er­ate, ben svilup­pate e basate su conoscen­ze acquisite, piut­tosto che a quelle spontanee.
  4. con­seg­na rap­i­da — questo è sostanzial­mente il prin­ci­pio fon­da­men­tale del mod­el­lo iterativo.
  5. raf­forza­men­to del team — uno dei prin­cipi fon­da­men­tali del ​“Man­i­festo…” affer­ma che le per­sone e le loro inter­azioni sono più impor­tan­ti di pro­ces­si e stru­men­ti. Un team di prog­et­to è la migliore garanzia per il com­ple­ta­men­to rius­ci­to dei compiti.
  6. integrità e qual­ità — è nec­es­sario real­iz­zare un prodot­to orig­i­nale di alta qual­ità per non spre­care tem­po e risorse in ulte­ri­ori test e cor­rezione di bug.
  7. visione di un quadro com­p­lessi­vo — un prog­et­to non può essere sud­di­vi­so in par­ti sep­a­rate sen­za com­pren­dere lo sta­to attuale del­lo svilup­po, così come le final­ità, il con­cet­to e le strate­gie del soft­ware sviluppato.


Ver­sioni delle metodolo­gie di svilup­po Agile

Model­lazione Agile (AM)

La Model­lazione Agile è un insieme di val­ori, prin­cipi e pratiche per la model­lazione software.
AM è uti­liz­za­to come un ele­men­to nelle metodolo­gie di svilup­po soft­ware com­plete — ad esem­pio, nel­la pro­gram­mazione estrema o nel­lo Svilup­po di Appli­cazioni Rapide.

La Model­lazione Agile ha le seguen­ti carat­ter­is­tiche fondamentali:
  • inter­azione effi­cace tra le par­ti inter­es­sate del progetto;
  • ricer­ca di svilup­pare la soluzione più sem­plice di tutte quelle pos­si­bili, che sod­dis­fi tut­ti i requisiti;
  • ricezione con­tin­ua di feedback;
  • cor­ag­gio di pren­dere deci­sioni e di esserne responsabili;
  • real­iz­zare di sapere asso­lu­ta­mente tutto.


Proces­so Uni­fi­ca­to Agile (AUP)

AUP è una ver­sione sem­pli­fi­ca­ta di un’al­tra metodolo­gia di svilup­po soft­ware — il Proces­so Uni­fi­ca­to Razionale (RUP). Dal 2012, è sta­to sos­ti­tu­ito dal Dis­ci­plined Agile Deliv­ery (DAD), ma AUP è anco­ra pre­sente qua e là.
Scott Ambler, l’au­tore del­la metodolo­gia, ha evi­den­zi­a­to i seguen­ti pun­ti chi­ave nel Proces­so Uni­fi­ca­to Agile:
  • Il tuo team sa cosa fa;
  • La sem­plic­ità viene pri­ma di tutto.
  • Con­for­mità ai prin­cipi del­la metodolo­gia di svilup­po flessibile.
  • Focus sulle attiv­ità di val­ore per il progetto.
  • Indipen­den­za nel­la scelta degli strumenti.
  • Con­fig­u­razione per­son­al­iz­za­ta di AUP per i req­ui­si­ti di un prog­et­to specifico.


Meto­do Dati Agile (ADM)

ADM è un insieme di metodolo­gie di svilup­po soft­ware iter­a­tive che enfa­tiz­zano la for­mazione dei req­ui­si­ti e delle soluzioni in un prog­et­to attra­ver­so la col­lab­o­razione di diver­si team. Come AUP, ques­ta metodolo­gia non è autonoma.

Il prin­ci­pio del Meto­do Dati Agile è defini­to da sei fondamentali:
  1. Dati — la base per la creazione di qual­si­asi applicazione.
  2. Prob­le­mi in un prog­et­to — pos­sono essere indi­vid­uati solo se l’o­bi­et­ti­vo del prog­et­to e il con­cet­to sono chiara­mente compresi.
  3. Grup­pi di lavoro — oltre al team base di svilup­pa­tori, ci sono grup­pi azien­dali che sup­por­t­ano altri grup­pi di lavoro.
  4. Unic­ità — non esiste metodolo­gia per­fet­ta, quin­di ogni prog­et­to richiede di com­bina­re stru­men­ti prove­ni­en­ti da metodolo­gie diverse.
  5. Lavoro di squadra — il lavoro con­giun­to è molto più effi­ciente del­l’at­tiv­ità individuale.
  6. “Sweet spot” — ricer­ca del­la soluzione otti­male di un prob­le­ma (“sweet spot”) evi­tan­do estremi.

Proces­so Uni­fi­ca­to Essen­ziale (EssUP)

È sta­to svilup­pa­to da Ivar Jacob­son, uno scien­zi­a­to svedese, per miglio­rare il Proces­so Uni­fi­ca­to Razionale.


EssUP uti­liz­za il con­cet­to di prat­i­ca che include:

  • sce­nario d’u­so — descrizione del com­por­ta­men­to di un sistema.
  • svilup­po iter­a­ti­vo — creazione di pezzi oper­a­tivi del codice in bre­vi cicli nel­l’ar­co di poche settimane.
  • pratiche di team — mirate a unire il team e ad aumen­tarne l’efficienza.
  • pratiche pro­ce­du­rali — ad esem­pio, ​“Pen­sa in grande, inizia in pic­co­lo” oppure ​“Coin­vol­gi gli stake­hold­er nei pro­ces­si aziendali”.
In una for­ma o nel­l’al­tra, tutte le pratiche sono pre­sen­ti nelle metodolo­gie RUP e CMMI, nonché nel­la metodolo­gia di svilup­po flessibile.

Get­ting Real (GR)

Ques­ta è una metodolo­gia effi­cace per start­up e team all’avvio, che sug­gerisce il mas­si­mo uti­liz­zo di carat­ter­is­tiche speci­fiche pro­prie di pic­coli prog­et­ti e aziende, come la mobil­ità, la flessibil­ità, la ricer­ca di nuove soluzioni, l’assen­za di una ger­ar­chia rigi­da e con­fusa, ecc. 
Jason Fried e David Hans­son, fonda­tori del­la 37signals Com­pa­ny (attual­mente Base­camp), han­no defini­to Get­ting Real come un sis­tema per risol­vere com­pi­ti fat­tibili, che è infine sem­plice, com­pren­si­bile e funzionale.

GR è un mix di una dozzi­na di stru­men­ti di svilup­po agile uti­liz­za­ti per min­i­miz­zare i seguen­ti aspetti:

  • alter­na­tive
  • opzioni e impostazioni
  • strut­tura aziendale
  • riu­nioni
  • promesse.
Una tale con­cezione stra­or­di­nar­ia non è diven­ta­ta main­stream, sebbene alcu­ni dei suoi ele­men­ti siano sta­ti fusi in altre metodologie. 

OpenUP (OUP)

Ques­ta è una metodolo­gia di svilup­po soft­ware indipen­dente dagli stru­men­ti e pri­va di una strut­tura rigi­da, che for­nisce tali pratiche:

  • mis­urare la veloc­ità di oper­azione del team;
  • tenere riu­nioni quo­tid­i­ane e ret­ro­spet­tive al ter­mine delle iterazioni;
  • con­cet­to di micropas­si e test antic­i­pati uti­liz­zan­do checklist;
  • metodolo­gia di Svilup­po Basato su Mod­el­li Agile (AMDD).
Queste pratiche ven­gono real­iz­zate sul­la base di quat­tro principi:

  1. ric­on­cil­i­azione degli inter­es­si e rag­giung­i­men­to del­la visione comune nel lavoro congiunto;
  2. miglio­ra­men­to con­tin­uo attra­ver­so feed­back costante;
  3. focus sul­l’ar­chitet­tura del­l’ap­pli­cazione nelle fasi iniziali per min­i­miz­zare i rischi;
  4. max­i­miz­zazione del val­ore per il con­suma­tore finale.




Indi­ca­tori Agile

Data la diver­sità degli stru­men­ti, delle pratiche, dei meto­di e delle metodolo­gie Agile, dob­bi­amo scegliere uno stru­men­to che ci aiu­ti a deter­minare quan­to siano effi­caci cias­cuno di essi. 
Le met­riche ven­gono uti­liz­zate come tale strumento.

Per la mag­gior parte dei prog­et­ti, queste 4 cat­e­gorie di met­riche saran­no sufficienti:

  1. Pro­dut­tiv­ità — si asso­cia alle met­riche Veloc­i­ty e WIP. La pri­ma potrebbe non adat­tar­si a tut­ti i prog­et­ti, poiché si misura il numero di com­pi­ti ese­gui­ti per iter­azione, ma le iter­azioni non sono uguali. La met­ri­ca Work-in-Progress definisce il lim­ite dei com­pi­ti in diverse fasi: e più è alto, peg­gio va;
  2. Pre­vi­sione — la met­ri­ca Capac­i­ty, che con­siste nel deter­minare il numero di ore per­fette disponi­bili nel prossi­mo sprint. Di con­seguen­za, è pos­si­bile capire la quan­tità di tem­po disponi­bile per il lavoro, il gra­do di effi­cien­za nel com­ple­ta­men­to dei com­pi­ti, così come piani­fi­care il numero di com­pi­ti per uno sprint;
  3. Qual­ità — ad esem­pio, l’indice di sta­bil­ità dei req­ui­si­ti che viene cal­co­la­to dal­la for­mu­la = (Numero totale di req­ui­si­ti azien­dali orig­i­nali + Numero di req­ui­si­ti alterati nel tem­po for­ni­to + Numero di req­ui­si­ti aggiun­ti + Numero di req­ui­si­ti sot­trat­ti) / (numero totale di req­ui­si­ti orig­i­nali). Ques­ta met­ri­ca è uti­liz­za­ta per deter­minare il tem­po spe­so nel rielab­o­rare i compiti;
  4. Val­ori — ques­ta met­ri­ca viene cal­co­la­ta indi­vid­ual­mente in ogni caso, a sec­on­da del for­ma­to del prog­et­to. Ad esem­pio, nel­la start­up AirBnb, il numero di foto di alta qual­ità scar­i­cate è sta­ta scelta come met­ri­ca per deter­minare il val­ore finale del prodot­to per gli uten­ti. Poiché questo numero aumen­ta­va, il numero di uten­ti cresce­va in proporzione.
Le regole applic­a­bili alle met­riche sono le stesse di quelle per altri stru­men­ti Agile.

Non esiste una sin­go­la met­ri­ca che sia uni­vo­ca­mente cor­ret­ta e per­ti­nente per il tuo progetto.


Le met­riche devono essere riv­iste con­tin­u­a­mente, quelle obso­lete devono essere elim­i­nate e nuove devono essere aggiunte all’oc­cor­ren­za. Dovreb­bero essere com­pren­sive e disponi­bili per l’in­tero team sen­za trasfor­mar­si in un obi­et­ti­vo in sé. Le met­riche per il solo gus­to delle met­riche sono una cat­ti­va soluzione.



Smontare Miti: Agile

La popo­lar­ità del­la metodolo­gia di svilup­po flessibile ha gio­ca­to un brut­to tiro e i miti su deter­mi­nati aspet­ti di Agile pos­sono essere visti anche su por­tali spe­cial­iz­za­ti. Fac­ciamo chiarezza!

Mito N.1: Agile si adat­ta a tut­ti i progetti.

Questo è il mal­in­te­so più asserti­vo. Un sin­go­lo meto­do Agile di per sé non apporterà val­ore al prodot­to, né motiverà il team.

Mito N.2: Agile sfa­vorisce la documentazione.

La metodolo­gia di svilup­po Agile non sfa­vorisce la doc­u­men­tazione, nega la doc­u­men­tazione come obi­et­ti­vo in sé. Quan­do si trat­ta di selezionare la doc­u­men­tazione come mez­zo di comu­ni­cazione, Agile favorisce effet­ti­va­mente la comu­ni­cazione personale.

Mito N.3: Agile e piani­fi­cazione sono incompatibili.

Questo mito è con­tes­ta­to da even­ti di piani­fi­cazione quo­tid­i­ani con stand-up di 10 minu­ti, così come da piani­fi­cazioni iter­a­tive che si svol­go­no ogni due set­ti­mane, riu­nioni sprint, ecc.

Mito N.4: Agile richiede molte rielaborazioni.

La metodolo­gia di svilup­po soft­ware Agile prevede la rielab­o­razione in due forme: rielab­o­razione dei req­ui­si­ti (gli uten­ti capis­cono ciò di cui han­no davvero bisog­no) e rielab­o­razione del soft­ware (i team di svilup­pa­tori trovano modi migliori per scri­vere e prog­ettare appli­cazioni). Ma questo è il caso che si incon­tra anche in altre metodolo­gie! Inoltre, una novità Agile come il mod­el­lo iter­a­ti­vo serve a ridurre l’in­fluen­za neg­a­ti­va del­la rielaborazione.


Van­tag­gi e svan­tag­gi del­l’u­so di Agile

Van­tag­gi:

  1. coin­vol­gi­men­to degli stake­hold­er — il team diven­ta più capace di com­pren­dere i req­ui­si­ti del cliente. Inoltre, la con­seg­na pre­coce e fre­quente del soft­ware aumen­ta la fidu­cia degli stake­hold­er nel team di prog­et­to e rende il coin­vol­gi­men­to nel prog­et­to più profondo.
  2. con­seg­na pre­coce e preved­i­bile — il mod­el­lo di svilup­po basato su iter­azioni (in bre­vi peri­o­di che van­no da 1 a 6 set­ti­mane) offre flessibil­ità e sti­mo­la il rilas­cio del prodotto.
  3. focus sul val­ore com­mer­ciale — col­lab­o­razione con il cliente assi­cu­ra che il team com­pren­da come ren­dere il prodot­to di val­ore per il con­suma­tore finale.
  4. miglio­ra­men­to con­tin­uo del­la qual­ità — test durante ogni iter­azione con la sud­di­vi­sione del­la build finale in par­ti sep­a­rate del codice oper­a­ti­vo facil­i­tano il miglio­ra­men­to e l’e­lim­i­nazione degli errori soft­ware pri­ma del rilas­cio del prodot­to finale.

Svan­tag­gi:

  • req­ui­si­ti rig­orosi per il team e i cli­en­ti — sen­za una stret­ta inter­azione tra il team di prog­et­to e gli uten­ti, è impos­si­bile garan­tire il rilas­cio di un prodot­to di alta qual­ità con alto val­ore. Inoltre, l’ab­bon­dan­za di stru­men­ti e meto­di Agile pre­sup­pone che il team deb­ba essere esper­to per la loro cor­ret­ta introduzione.
  • non adat­to per out­sourc­ing e per prog­et­ti in cui i parte­ci­pan­ti inter­agis­cono tra loro solo in modal­ità online.
  • il ris­chio che la ver­sione finale del soft­ware non ven­ga mai rilas­ci­a­ta — sor­pren­den­te­mente, questo svan­tag­gio deri­va da van­tag­gi di Agile come lo svilup­po iter­a­ti­vo e il miglio­ra­men­to con­tin­uo del prodotto.
  • fal­lisce sen­za una chiara visione degli obi­et­tivi azien­dali del prog­et­to — poiché un team Agile è guida­to dagli stake­hold­er, è impos­si­bile svilup­pare un prodot­to sen­za un obi­et­ti­vo e un con­cet­to chiara­mente definiti.

Appli­cazioni

Non tut­ti i servizi o pro­gram­mi di ges­tione prog­et­ti saran­no adat­ti per la ges­tione prog­et­ti basa­ta su Agile, poiché cias­cuno di essi ha le sue carat­ter­is­tiche specifiche. 

Se la tua azien­da è un’a­gen­zia di mar­ket­ing & pub­blic­ità, design, SEO o dig­i­tale, puoi uti­liz­zare il servizio saas di Work­sec­tion affinché l’in­tero team vi operi. Fino­ra siamo sta­ti rac­co­man­dati da COXO Dig­i­tal, Roy­al ® Adver­tis­ing e Prozorro.

Ecco un paio di sug­ger­i­men­ti per con­fig­u­rare Agile in Worksection:

  1. con­fig­u­rare tag e sta­ti che sono nec­es­sari per il lavoro nel­la tua azien­da. Gli sta­ti pos­sono essere: in cor­so, con­trol­lo, com­ple­ta­to, rielab­o­razione nec­es­saria, criti­co, fun­zion­al­ità, paga­men­to dovu­to. I tag spes­so sono: lay­out, test­ing, pro­duzione, con­cet­to, codice.
  2. creare il back­log del prog­et­to e lo sprint del progetto.
  3. creare com­pi­ti e check­list pre­lim­i­nari, schizzi, ecc. nel backlog.
  4. durante gli incon­tri, deter­minare i com­pi­ti del­lo sprint e trasferir­li dal back­log allo sprint. 
  5. uti­liz­zare l’ac­ces­so ospite dei cli­en­ti ai com­pi­ti in modo da avere sem­pre feed­back coor­di­na­to e per­ti­nente sul progetto. 
  6. con­trasseg­nare le per­sone respon­s­abili nei com­pi­ti affinché cias­cun col­le­ga sap­pia la sua area di respon­s­abil­ità e si sen­ta coin­volto nel­l’e­si­to del­lo sprint.




Verdet­to

Gra­zie alla metodolo­gia di svilup­po soft­ware agile, i pic­coli team di prog­et­to guadag­nano la mas­si­ma effi­cien­za. L’Ag­ile si real­iz­za attra­ver­so altri meto­di flessibili come Scrum, XP, Lean, ecc.

Non può essere imple­men­ta­ta in fret­ta, da un team ines­per­to, in un breve las­so di tem­po,
ma una vol­ta introdot­ta, Agile miglior­erà l’in­ter­azione tra IT e busi­ness, sti­mol­erà il rilas­cio del prodot­to sul mer­ca­to e aumenterà il val­ore del prodot­to per il con­suma­tore finale. 





⇆

esc
Condividere
или
Worksection Next
Niente più ricerche di file persi nelle chat – Worksection 2.0 porterà ordine nel tuo lavoro.
Che immagine familiare: la scadenza si avvicina, il file esiste sicuramente, ma non riesci a ricordare dove esattamente. Forse in Slack, forse nell'email, forse qualcuno l'ha caricato su Google Drive...
7 settembre 2026   •   2 min read
Worksection Next
Scadenze mancate di nuovo? Scopri come Worksection 2.0 ti aiuta a evitarle.
Lunedì, sembra che la settimana sia pianificata bene. Entro mercoledì, un compito urgente rompe l'intero programma. Entro venerdì, diventa chiaro che la scadenza, che doveva essere la settimana prossima...
30 agosto 2026   •   6 min read
Worksection Next
Non riesci a vedere chi sta lavorando su cosa e a quale fase sono i compiti? Worksection 2.0 aiuta a tenere tutto sotto controllo.
Il manager sta chiedendo informazioni riguardo al progetto. Cosa si fa di solito in questi casi? Prima di tutto, devi controllare il gestore delle attività, poi ricordare che qualcosa è stato discusso...
19 agosto 2026   •   9 min read
Inizia ora
Inserisci la tua vera email 🙂
Annulla
Progetti Sezione di lavoro Teoria Sviluppo del team Gestione del Progetto Gestione del progetto Colloquio Di più 105...
Progetti Sezione di lavoro Teoria Sviluppo del team Gestione del Progetto Gestione del progetto Colloquio Gestione attività Gestione delle attività Tracker del tempo Clienti Squadre Esperienza Kanban Diagramma di Gantt Scuola WS Progetti Confronto Inserimento Compiti Produzione snella Commenti Timer Contabilità del tempo Report Sviluppo dei leader Video Consigli Integrazione Aggiornamento Pianificazione Mischia Agile Calendario Stati Team creativi Marketing Processo aziendale Gestione del cloud Etichette Gestione delle Risorse Umane Messaggio File ESSO ACCORTO Partenariato Sottocompiti UI Top 10 Produttività Asana Jira Azioni promozionali Lavoro online Cascata Priorità Metodologie Security Contabilità finanziaria IOS Android Filtro Basecamp Lavoro da remoto Ricerca Trello Priorità Bitrix24 Marketing su Internet Notifiche Agenzia digitale Architettura Liste di controllo Contabilità delle spese Migrazione Dipartimenti Auto-sviluppo Elenco delle attività Roman.ua Design Media Interfaccia Piano Sistema di gestione aziendale Colloquio Documenti Ruoli Responsabile API Infografiche Sviluppo del team Immagine Ingegneria Connessioni Controllo del tempo Reazioni Emoji App Importa Sincronizzazione Aziende di servizio SEO Controllo Revisione Efficienza del team Spese Diritti Esportare Google Compiti urgenti Kaizen OKR