Il Rischio
Mentre ascolto un pò di sano heavy metal e mentre lavoro ad un progetto di ecommerce in java per un cliente (ed è solo martedi sera!), mi rendo conto che parte della mia giornata lavorativa degli ultimi 5 mesi l’ho passata gestendo solo una cosa: il rischio. Il rischio è parte della mia quotidianità. Come gestire il rischio e come applicarlo al test di un software determina il successo o il fallimento di un progetto. Ci sono tre modi per gestirlo.
1) Non esiste la parola “mai”. Qualunque cosa succeda, si deve essere pronti a rimodellare le proprie strategie. Il rischio è sempre pronto a far casini e si deve sempre lavorare per minimizzare il suo impatto sul progetto. Qualcosa, prima o poi, sia una nuova funzionalità, una nuova richiesta, nuovi o vecchi bugs, metteranno il progetto a rischio.
2) Ci saranno sempre bugs. Ho trovato tutti i difetti del software? No??? Non importa, perchè è impossibile e non esiste un software bug-free. Perchè? Primo, perchè dal lato dello sviluppo dell’equazione, si deve gestire il cambiamento della tecnlogia, un design o un’architettura complessa, la difficoltà di integrare sistemi diversi, e così via. Secondo, perchè l’errore umano è un fattore critico. Anche se parte del codice te lo genera l’IDE, qualcuno deve sistemare e sviluppare nuovo codice, quindi visto che è umano, genererà degli errori. Visto che devo concentrarmi nel testare un software, devo trovare quelli che mettono il progetto più a rischio. Questo richiede concentrazione.
3) La domanda giusta non è “cos’è il rischio”, ma “qual è il rischio oggi?”!!!
Nessun progetto di sviluppo software è statico. Chi pensa di definire a priori uno schema di progetto e non modificarlo più, sbaglia. Rischia. Il progetto è se stesso in continuo cambiamento. Per essere vincenti, si deve saper rispondere alle richieste del cliente e integrare nuove tecnologie. Si può provare ad anticipare tutto in tempo, ma durante i test, si impara sempre qualcosa di nuovo e si deve cambiare piano di lavoro per incorporare nuovi test o migliorare quelli attuali in base al rischio in cui si trova il progetto. Questi rischi cambiano di livello ed importanza in base alla fase del progetto. All’inizio il rischio può essere solo che il software è un pò buggoso, o che le interfacce da e per altri sistemi non siano giuste. Dopo, a progetto avanzato e sviluppo ultimato, il rischio maggiore è che le nuove modifiche rompono le architetture iniziali.
Gestire il rischio di un progetto non vuol dire suddividere le persone tra sviluppatori, testers, application designers, chi fa l’architettura, chi si relaziona con i clienti, chi pulisce i cessi e chi si prende i meriti. Gestire il rischio di un progetto vuol dire anche gestire con flessibilità progettuale le rigidità architetturali. Non è facile. Lo sto imparando ancora adesso. Lo sarà ancora tra parecchi anni, perchè non c’è una regola per fare di un progetto un’avventura vincente. L’importante, è non tirarsi mai indietro davanti ad un problema (tecnologico, di ruolo, personale, di progetto) e fare gruppo. 😉
