Le origini di Agile

Anche se il tuo team di sviluppo non è ancora passato a metodi agili come Scrum o Extreme Programming, è molto probabile che lo stia almeno prendendo in considerazione. "Agile" affronta effettivamente alcuni dei problemi più grandi che affliggono i team di sviluppo software da decenni. Tuttavia, molti product manager, designer e anche persone del quality assurance sono inizialmente irritati da Agile, perché non sono ancora veramente familiari con i loro ruoli nei metodi agili. Questi metodi richiedono sicuramente questi ruoli, ma la confusione la attribuisco alle origini dei metodi agili. Per illustrare i problemi che "Agile" dovrebbe risolvere e per scoprire quali sfide permangono, è utile che spieghi le origini di Agile.

Molte persone sono sorprese quando scoprono da quanto tempo esiste Scrum – il metodo agile più conosciuto. È nato nel 1986 in Giappone. (Un esempio di quanto tempo possa volerci perché una nuova idea raggiunga finalmente il successo.)

Le origini di Agile risiedono nel software personalizzato

La cosa più importante, però, è che questi metodi provengono dal mondo del software personalizzato (Custom Software).

Sviluppare software personalizzato, ovvero software per uno scopo specifico e per un cliente specifico, è stato a lungo un tipo estremamente difficile di sviluppo software. In parte ciò è dovuto al fatto che i clienti notoriamente non sanno cosa vogliono esattamente. Tuttavia hanno un'esigenza e così firmano un contratto con un'azienda di software personalizzato o si siedono con i propri informatici interni, che poi dovrebbero lavorarci. Quando poi viene consegnato qualcosa, i clienti dicono fondamentalmente che non è quello che volevano e tutto ricomincia da capo, con una frustrazione ovviamente sempre maggiore. L'esigenza fondamentale persiste comunque e questo ha assicurato il lavoro a innumerevoli sviluppatori software, aziende e fornitori di servizi.

Inoltre, nello sviluppo di software personalizzato si è spesso avuto la peggio quando si trattava di assumere persone e assicurarsi i migliori talenti del software. Ciò è probabilmente dovuto in parte al fatto che i professionisti preferiscono lavorare in aziende che sviluppano software per migliaia o addirittura milioni di clienti. Il motivo è tra l'altro che i professionisti ricevono una retribuzione più alta nelle aziende dove il team di prodotto deve sviluppare prodotti software che molte persone desiderano, perché altrimenti non guadagnano. Queste aziende sanno che devono assumere persone valide per creare prodotti di successo e di conseguenza la retribuzione è proporzionata. Tuttavia, solo una piccola percentuale di sviluppatori software lavora su software standard, la maggior parte sviluppa software personalizzato.

Il vantaggio di Agile?

Poiché nel caso del software personalizzato il cliente presume di sapere cosa vuole, raramente si trova il ruolo del product manager. Allo stesso modo, non si trovano quasi mai User Experience Designer. Le ragioni sono piuttosto complesse e includono un certo grado di ignoranza (pochissimi nel mondo del software personalizzato sanno cosa fanno gli UX Designer e a cosa servono) e sensibilità ai costi (ridurre i costi lasciando che siano gli sviluppatori a fare il design). Però bisogna dire che i pochi designer che ci sono nel nostro settore vengono immediatamente presi dalle aziende di prodotto che hanno capito quanto siano importanti i designer. Quindi, per i team che sviluppano software personalizzato, quando i dirigenti finalmente capiscono di averne bisogno, non restano quasi più designer disponibili. Allo stesso modo, il quality assurance come disciplina a sé è quasi inesistente nel software personalizzato e ci si aspetta che gli sviluppatori si occupino anche del testing.

Un altro punto importante per comprendere il mondo del software personalizzato è che la maggior parte dei progetti sono relativamente piccoli e devono supportare le attività interne di un'azienda – ad es. le risorse umane, la fatturazione, la produzione ecc. Quindi tutti ambiti in cui c'è solo un numero limitato di utenti e cose come scalabilità e prestazioni normalmente non sono così importanti.

Il processo Waterfall

In passato, nel software personalizzato era necessario il processo Waterfall, perché i vari stakeholder avevano bisogno di un modo per monitorare il progresso durante il lungo processo di sviluppo delle applicazioni desiderate. A dire il vero, anche il metodo Waterfall ha qui le sue origini.

Nel software standard, che viene acquistato per le sue prestazioni e i suoi vantaggi, sono stati introdotti alcuni ruoli. Il product manager deve raccogliere e rappresentare le esigenze di tutti i clienti. I designer devono creare una User Experience utilizzabile e desiderabile e i tester del quality assurance devono verificare che il software funzioni effettivamente come promesso al cliente nella pubblicità.

La soluzione ai problemi del Waterfall è arrivata con i metodi agili

Nel software personalizzato, però, continuavano a presentarsi gli stessi problemi quando si trattava di creare qualcosa che soddisfacesse i clienti. Soprattutto per questi team, i metodi agili rappresentano un forte miglioramento. La comunicazione tra clienti e sviluppatori migliora. Il rischio viene ridotto significativamente attraverso iterazioni più piccole e frequenti. I clienti possono così scoprire molto più rapidamente se qualcosa piace loro, invece di continuare ad aspettare la fine di un lungo processo. Inoltre, i metodi agili aiutano a introdurre concetti moderni per il testing del software e a risparmiare ai team ore di creazione di documenti che comunque vengono letti a malapena e diventano rapidamente obsoleti.

Agile per software personalizzato e standard

Fondamentalmente, questi vantaggi valgono ovviamente anche per il software standard, ma sottolineo sempre che alcune cose devono essere adattate. Un altro ambito in cui ci sono state difficoltà è l'architettura o il design del software.

I metodi agili incoraggiano gli sviluppatori a non fissarsi troppo sul proprio modo di implementazione, perché tutto deve poter essere rielaborato o modificato rapidamente e facilmente. Anche se nel software personalizzato questo funziona spesso bene, questo approccio è ad esempio troppo ingenuo per grandi servizi internet che hanno centinaia, migliaia o milioni di utenti.

Non è quindi una sorpresa che molti team di sviluppo software standard abbiano avuto problemi con i metodi agili, perché le origini dei metodi agili si trovano nel software personalizzato. I molti libri, articoli e corsi che non menzionano né product manager né User Experience Designer (Interaction Designer e Visual Designer) non sono pensati per lo sviluppo di software standard.

I team che vogliono passare ai metodi agili nello sviluppo software dovrebbero quindi verificare in anticipo se l'azienda che deve aiutare la loro organizzazione comprende anche ciò che è richiesto per il software standard. Non è sempre il caso, ma spesso sì.