Le tecniche “agili” o “leggere” sono diventate popolari per lo sviluppo di progetti software nuovi e innovativi. In questi nuovi contesti, le modalità di sviluppo della documentazione tecnica sono notevolmente evolute. Può essere interessante capire le ragioni e le conseguenze di questi nuovi scenari di lavoro.
Tecniche agili di sviluppo del software
I modelli più tradizionali, basati sul cosiddetto paradigma “a cascata”, si sono dimostrati inadeguati alle esigenze dell’industria del software, dove la tecnologia in costante miglioramento richiede un’elevata flessibilità e impone rapidi cambi di direzione. Infatti, l’approccio a cascata, di grande successo nei processi produttivi, prescrive una sequenza perfetta di fasi di sviluppo: requisiti, analisi, progettazione, implementazione, documentazione e test. Questa tecnica è efficace solo quando le fasi rimangono stabili e prevedibili durante l’intero processo. Errori e modifiche causerebbero passi indietro inaspettati e costosi.
Nello sviluppo del software, e forse anche in altre applicazioni guidate dalla tecnologia, le nuove idee del marketing devono essere valutate all’interno del quadro tecnologico più recente. Pertanto, le specifiche e le analisi non possono rimanere stabili, poiché devono essere ridiscusse per dimostrare il loro valore quando vengono applicate alle tecnologie emergenti.
I processi a cascata non agili sono piuttosto lenti, impongono una rigida separazione dei ruoli, scoraggiano la cooperazione tra i vari reparti e possono persino favorire i conflitti tra i team, ad esempio tra il reparto marketing e quello tecnico o tra i gruppi di sviluppo e di collaudo (i comunicatori tecnici cercano sempre di fare la pace, non è vero?).
Per questo motivo, a partire dalla metà degli anni Novanta, sono stati proposti nuovi metodi agili che utilizzano processi più iterativi e incrementali per sviluppare il software.
Nel 2001, il Manifesto Agile ha presentato i principi del nuovo approccio:
- Persone e interazioni invece di processi e strumenti
- Software realizzabile invece di una documentazione di sviluppo esaustiva (prototipazione rapida)
- Cooperazione con il cliente invece di negoziazioni contrattuali
- Reazione ai cambiamenti invece di seguire un piano rigido.
- Metodi agili e metodo Scrum
Il metodo Agile è composto da diverse metodologie. Tra queste, l’approccio Scrum prevede piccoli team altamente interattivi e inter-funzionali possono ottenere ottimi risultati lavorando come un’unità, come una formazione di mischia nel rugby (Scrum).
Già negli anni Novanta, il metodo Scrum è stato applicato con successo in diversi progetti e si è rapidamente diffuso. Il metodo si basa sulle seguenti regole:
- Un team Scrum è in genere composto da cinque a nove persone, tra cui uno Scrum Master, vari ingegneri di sviluppo e di test e almeno un technical writer.
- Il Product Owner raccoglie i requisiti in un backlog di funzionalità ordinate per priorità.
- Lo sviluppo è organizzato in brevi iterazioni, chiamate Sprint, durante le quali si intende completare un insieme selezionato dei requisiti a più alta priorità.
- Gli sprint sono pianificati in dettaglio e durano alcune settimane, in genere un mese, per fornire regolarmente una release di prodotto funzionante (e documentata!).
- Durante lo sprint, il team Scrum lavora in stretta collaborazione e si riunisce frequentemente, persino ogni giorno (daily scrum) per discutere e risolvere rapidamente eventuali problemi.
- La documentazione rilasciata alla fine di ogni sprint, anche se preliminare, è utilizzabile da chiunque lavori con il software.
Nuovi compiti e opportunità per i redattori tecnici
Almeno un technical writer fa parte di ogni Scrum team e segue lo sviluppo del prodotto fin dall’inizio. Questa è un’ottima notizia. Credo che nell’approccio tradizionale “a cascata” tutti noi abbiamo sofferto del fatto di essere coinvolti solo molto tardi nel processo di sviluppo del prodotto. Ci affannavamo a capire di cosa si trattasse e poi ci affrettavamo a documentare il prodotto finale senza avere alcuna possibilità di contribuire in modo intelligente alle attività di sviluppo.
Con Scrum, il ruolo dei technical writer come parte del gruppo di sviluppo può essere notevolmente più importante. Oltre alla documentazione del prodotto vero e proprio (i classici manuali d’uso), la nostra esperienza può supportare gli sviluppatori e i tester nella realizzazione di una migliore documentazione del progetto, ovvero documenti di analisi e progettazione del software.
Inoltre, i technical writer possono interagire con gli sviluppatori e fornire importanti commenti sull’usabilità e la facilità d’uso del software. Molti di noi hanno scoperto che le funzioni difficili da documentare devono essere reingegnerizzate prima di poter produrre la relativa documentazione!
La pianificazione e il monitoraggio delle attività sono molto dettagliati durante gli sprint e sono necessarie stime precise per tutti i compiti di documentazione. La pianificazione costringe i redattori tecnici, così come tutti gli altri membri del team, a migliorare le proprie capacità di stima.
Possono essere richieste nuove abilità tecniche che vanno oltre le classiche capacità professionali degli scrittori tecnici. A seconda del progetto software, può essere utile una conoscenza specifica di nuovi standard e tecniche software relative al progetto. È necessario avere o sviluppare competenze sufficienti per seguire attivamente le riunioni quotidiane con gli specialisti del software e interagire con loro in modo efficace.
Differenze culturali e necessità di nuove competenze tecniche
Lavorare in un team Scrum può essere un cambiamento per la maggior parte dei redattori tecnici. Se vi piace lavorare a casa, in silenzio e in perfetta solitudine, allora Scrum non fa per voi, perché richiede continue interazioni con il team e riunioni quotidiane.
Nei nuovi team Scrum, uno scontro culturale può verificarsi proprio all’inizio, quando ci si deve incontrare ogni giorno con sviluppatori e tester del software. In alcuni casi, questi ingegneri potrebbero inizialmente non vederci di buon occhio, considerandoci una sorta di alieni all’interno del team e magari trascurando del tutto l’importanza dei nostri compiti di documentazione.
In genere, però, la collaborazione quotidiana per raggiungere un obiettivo comune aiuta a sviluppare armonia e simpatia tra i membri del piccolo team. Nonostante le possibili difficoltà iniziali, dobbiamo sforzarci di contribuire al team con tutta la nostra esperienza e competenza.
Come compito principale, dobbiamo assicurarci che i compiti di documentazione siano definiti correttamente all’inizio di ogni sprint e poi procedere al loro completamento. Inoltre, dobbiamo essere disposti ad aiutare al di là delle nostre normali mansioni: ad esempio, possiamo correggere una specifica software, disegnare o controllare un diagramma complesso, aiutare a scrivere una relazione di progetto e così via. Ricordate che il team scrum può vincere o perdere solo nel suo insieme.
Si noti che, a differenza delle tecniche precedenti, la documentazione del prodotto viene sviluppata dal basso verso l’alto, seguendo i rilasci degli sprint mensili. Ogni iterazione deve consegnare un prodotto completo, anche se possibilmente minimo, compresa la documentazione. Pur rimanendo concentrati sulle singole caratteristiche che vengono rilasciate, dovremmo usare la nostra esperienza per tenere a mente il quadro generale, cioè gli obiettivi globali della documentazione.
Conclusioni
La metodologia Scrum può dare luogo a prestazioni straordinarie in un ambiente creativo, vivace ed empatico. Per contribuire a far sì che ciò accada, dobbiamo impegnarci per il team, imparare con umiltà e insegnare con rispetto e comprensione.
In altre parole, come nel rugby, dobbiamo spingere in avanti il più possibile e, allo stesso tempo, contribuire al coordinamento della squadra, che è essenziale per garantire che la “mischia” proceda in modo armonioso e alla fine vinca la partita.
Se ti può interessare questo tema, contattaci per un approfondimento libero da impegni.
Alcuni riferimenti classici
1) http://www.agilemanifesto.org.
2) The New Product Development Game di Hirotaka Takeuchi e Ikujiro Nonaka, in The Harvard Business Review.
3) Sviluppo software agile con SCRUM di Ken Schwaber e Mike Beedle, Prentice Hall. Di questo testo, esiste anche un breve interessante estratto in italiano qui.
