Spesso la difficoltà di trovare un buon Analista dipende dalla difficoltà di astrarsi e di concentrarsi sul problema al fine di identificarlo al meglio possibile, per poi procedere a ragionare sulla soluzione solo in un secondo momento. Questo comporta spesso di iniziare a lavorare con specifiche faraginose o fortemente incomplete o addirittura sbagliate.
![]()
Quando il software arriva in fase di test, spesso i bug segnalati non sono veramente bug, ovvero non sono causati dall’implementazione o da una soluzione sbagliata, ma sono causati da specifiche sbagliate. In questo caso il tempo buttato via è spesso molto elevato, perché intere parti di software vanno rifatte.
Purtroppo spesso questo è il modo standard di procedere, si attende di avere il software in fase di test, quindi con tutte le specifiche implementate, per poi capire durante l’uso di test che le specifiche stesse sono sbagliate :(. In questo scenario sempre più sono convinto che usare Mockup della UI aiuta chi “sta ricoprendo il ruolo di analista” a ragionare con “qualche cosa sotto” per capire meglio il problema. Da una parte i mockup operano già nel dominio della soluzione, ma spesso far ragionare le persone sulle UI aiuta a “elicitare” i requisititi veri. Un buon analista dovrebbe quindi avere una eccezionale capacità di astrazione, in modo da poter effettuare ragionamenti sul dominio del problema, senza avere nulla di concreto in mano.
La cosa strana è che spesso, quando si chiede di spendere maggiore tempo sull’individuazione dei requisiti, la risposta è “abbiamo poco tempo, bisogna iniziare subito a scrivere del codice”, paradigma che è totalmente sbagliato perchè porta ad un allungamento dei tempi del progetto, spesso notevoli.
Purtroppo esiste ancora l’illusione che il codice scritto in “fretta e furia” sia la soluzione all’annoso problema di avere tempi di realizzazione stretti, senza capire che meno tempo si ha, meglio lo si deve usare.
L’ALM, questa tecnica sconosciuta.
Gian Maria.
