Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Metodologie di sviluppo software: essere pragmatici

pittogramma Zerouno

Metodologie di sviluppo software: essere pragmatici

11 Nov 2013

di Adriano Comai

Qual è il modo migliore per sviluppare software? Agile, lean, a cascata? Scrum, Extreme Programming, Kanban, Unified Process?
Le discussioni sugli approcci non finiscono mai, anche se spesso sono dibattiti interni tra specialisti, che toccano poco le pratiche reali all’interno delle organizzazioni.

È ormai diffusa la consapevolezza del fatto che non esiste “un” metodo migliore, “il” (solo) approccio da seguire sempre nello sviluppo software. Gli ambiti in cui si sviluppa, le tipologie di prodotti da realizzare, gli interessi delle persone e delle organizzazioni coinvolte nei progetti sono troppo diversi perché esista davvero l’”one size fits all”, la taglia unica che va bene per tutti.
In alcune situazioni, di prodotti critici per la vita umana o per aspetti economici, il livello di affidabilità dei sistemi e la tracciabilità dei requisiti sono essenziali; in altri contesti, ciò che conta davvero è la tempestività con cui si riesce ad anticipare o a rispondere alle mosse della concorrenza. In qualsiasi ambito, inoltre, i progetti vengono realizzati dall’interazione di persone e gruppi che si trovano a interagire avendo vincoli e obiettivi diversi, che possono portarli a collaborare efficacemente o, quando va male, a situazioni di conflitto.
Come fare, allora, a determinare quale sia l’approccio migliore da usare in una determinata situazione? La tipica risposta di chi ha esperienza è “Dipende dal contesto…”. È vero, ma si tratta di una risposta che lascia insoddisfatto chi deve prendere decisioni nelle situazioni concrete. Cosa si intende per contesto? Quali sono i criteri in base ai quali vanno fatte le valutazioni e le scelte?
Negli ultimi anni sono nate due iniziative internazionali per tentare di dare risposte a queste domande. La prima, in ordine di tempo, è Semat, Software Engineering Method and Theory, ideata da Ivar Jacobson e condotta nell’ambito dell’Object Management Group (Omg).
L’obiettivo principale di Semat è di rifondare l’ingegneria del software rendendo possibile il confronto tra i diversi approcci: in modi diversi e usando termini diversi, tutte le metodologie devono affrontare la gestione dei requisiti, il controllo sull’avanzamento dei lavori, la verifica sulla qualità dei risultati. L’iniziativa intende portare alla luce questi elementi comuni per consentire un confronto dei diversi approcci e per permettere di combinarne le pratiche per generare adattamenti alle esigenze di ogni progetto in modo rigoroso ed efficace.
È stato così prodotto un “kernel”, un nocciolo che contiene e descrive gli elementi essenziali per lo sviluppo software, chiamato Essence, pubblicato da Omg come standard in versione beta nel luglio 2013 (vedi riquadro nella pagina a fianco), e già usato come riferimento in numerosi curricula formativi di università internazionali.
L’iniziativa più recente è The New Deal, nome che riecheggia il “patto” che il presidente Usa Franklin D. Roosevelt concordò con le parti sociali per uscire dalla crisi economica degli anni trenta del novecento.
Il “New Deal” per lo sviluppo software è un Manifesto, firmato da alcuni tra i maggiori esperti internazionali (tra gli altri Grady Booch, Philippe Krutchen, Bill Curtis), che sostiene l’esigenza di un maggiore pragmatismo per superare la confusione generata dalla varietà delle proposte metodologiche. In particolare, secondo i firmatari del Manifesto, bisogna evitare ogni atteggiamento fideistico nei confronti degli approcci, derivante dal considerarli in modo astratto e indipendente dalle situazioni concrete in cui bisognerebbe calarli.
Lo sviluppo software non avviene in un mondo ideale, ma in contesti socio-economici reali, dove la cultura delle persone e delle organizzazioni gioca un ruolo primario e le circostanze cambiano nel tempo: se non si tiene conto di questi aspetti concreti, la scelta di un approccio metodologico può portare a una crescita dei rischi e a risultati negativi per i progetti. Diventa quindi necessario uscire dal confronto tra approcci basato sulla capacità retorica dei loro sostenitori, e trovare delle unità di misura utili per valutare l’efficacia delle loro proposte in situazioni concrete.
Se queste due iniziative porteranno a risultati concreti lo si potrà valutare solo a medio-lungo termine, perché purtroppo il campo dello sviluppo software è soggetto al periodico manifestarsi di nuove proposte metodologiche che promettono di cambiare tutto e risolvere ogni problema. Di certo, però, il richiamo alla realtà della pratica e alla misurabilità dei risultati concreti costituisce un passaggio positivo verso una maggiore maturità del settore.

 


Semat

l kernel di Semat comprende sette aspetti fondamentali per ogni attività di sviluppo software:

  • Opportunità – gli obiettivi che si intendono raggiungere
  • Stakeholder – i soggetti che possono ottenere vantaggio svantaggi dal sistema
  • Requisiti – le caratteristiche desiderate per il sistema
  • Sistema software – l’oggetto da realizzare
  • Lavoro – le attività da svolgere
  • Gruppo di lavoro – responsabile per lo svolgimento del lavoro
  • Modo di lavorare – metodi e pratiche usati dal gruppo di lavoro


Per ogni aspetto del kernel sono definiti degli stati di avanzamento, cioè delle condizioni in cui ci si può trovare. Ad esempio per l’aspetto “requisiti” gli stati previsti sono:  concepito, descritto, coerente, sufficiente, soddisfacente  soddisfatto


Il manifesto “The New Deal

Noi sottoscritti affermiamo che è necessario diventare più pragmatici nei metodi e metodologie di sviluppo software. Chi opera nello sviluppo software è pronto per un “nuovo patto”, che riduca la confusione che ostacola il suo lavoro.

Affermiamo che:

  • I pregiudizi basati sulla fede nel seguire metodi specifici hanno effetti negativi sui risultati dei progetti
  • Le pratiche comunemente accettate sono preferibili ai metodi etichettati come brand
  • In concreto bisogna adattare il proprio approccio basandosi sul contesto dell’attività e sulla cultura dell’organizzazione in cui si opera
  • I progetti software vanno governati in circostanze che cambiano dinamicamente
  • È la collaborazione nell’intera catena del valore del software che rende possibile l’efficienza complessiva.

Per far progredire il nostro settore proponiamo di:

  • Studiare le attività di sviluppo software come sistemi socio-economici e socio-tecnici
  • Sostituire la retorica fine a se stessa con l’evidenza empirica di efficacia delle pratiche
  • Rivelare la natura contestuale e culturale delle pratiche di sviluppo software
  • Promuovere principi di leadership basati su previsioni oneste di risultati e incertezze
  • Promuovere i miglioramenti socioeconomici come fattore primario dello sviluppo software.

* Adriano Comai, esperto in metodologie di sviluppo software, www.analisi-disegno.com

Adriano Comai

Articolo 1 di 3