Quando l’agile diventa impacciato
Waterfall, o agile? A livello programmativo queste due metodologie si pongono l’una all’opposto dell’altra… due facce di un solo scopo comune, ovvero produrre di più, meglio e in minor tempo, ma con differenti approcci alla base. Il primo (detto in poche parole, dato che il Diario non è un blog tecnico), più tradizionalista, consiste in un classico top-down, una cascata di analisi, progettazione e solo infine sviluppo e test. Analisi dei requisiti, analisi funzionale, analisi tecnica, gantt di sviluppo sono solo alcuni dei volti di questa metodologia che ormai si ritiene appartenere più al passato e a sostituire con un metodo meno rigido, e pertanto più facilmente malleabile una volta che ci si trova a sviluppo avviato con change request tali da mutare gli stessi requisiti. L’agile movement (il quale a sua volta è un insieme di approcci differenti) consiste appunto nella soluzione alla rigidità di cui sopra, con una programmazione maggiormente team-based che affondi le radici nella collaborazione reciproca (ed esperta) piuttosto che nella figura a piramide composta da capo progetto, analisti, sviluppatori senior e infine junior/stagisti, ciascuno dei quali racchiuso in un ruolo ben specifico. Avere infatti a disposizione un team di persone capaci, le quali possano dirottare il loro lavoro a richieste in corso, può permettere non solo di evitare blocchi totali del flusso del più tradizionalistico waterfall (il quale davanti a una CR dovrebbe ritornare in cima), ma anche stravolgere le attività di un team intero rallentando l’intero processo. Ma sarà sempre vero che l’agile è sempre… agile?
No, affatto! Questa metodologia è complessa da adottare e richiede un’ampia conoscenza del mezzo (il linguaggio) e dello scopo (ciò che si sta facendo), altrimenti ci si ritrova a fare e rifare le cose mille volte, a riprenderne le basi in mano ridiscutendo tutto perché non si erano compresi i requisiti, a duplicare codice inutilmente perché non si ha una visione d’insieme… e quant’altro di peggiore possa accadere nella programmazione. Il tutto a un punto tale che vien da chiedersi perché non tornare a un più tranquillo waterfall, che in un tal scenario sarebbe anche molto più efficace e rapido. Una della cose peggiori che possa capitare, secondo il mio pensiero, è dover riscrivere un’applicazione non causa richieste mutevoli, ma a causa di incomprensioni, di analisi non capite, di requisiti fraintesi alla base. E’ così che infatti il codice inizia a diventare un continuo “rimescolare le carte”, col rischio che non diventi solo illeggibile (al che ci si riduce all’uso smodato di commenti per cercare di risolvere il tutto… e quando si iniziano a commentare cicli “for” e “if” la cura diviene anche peggiore del male), ma anche costoso da mantenere (e questo fa diventare d’improvviso tutti impacciati, invece che agili).
L’analisi (intesa come comprensione del problema e dello scenario di sviluppo) non deve essere una fase sottovalutata nell’agile, ma anzi deve esserne la base sebbene non nella forma rigida del waterfall. Se non si sa cosa si deve fare, come si può farlo in modo corretto?
