Vi sono delle regole per valutare la qualità di un team di sviluppo? Un noto personaggio del mondo dello sviluppo software Joel Spolsky, uno dei creatori di Microsoft Excel, propone un suo particolare criterio per saggiare le qualità del team: un semplice test, consistente in una serie di domande, alle quali gli sviluppatori devono rispondere con un si o con un no. Per ogni risposta positiva si totalizza un punto; alla fine del test il punteggio totale rende l'idea della qualità del team di sviluppo, e probabilmente della qualità del software prodotto dalla società di cui il team fa parte. Queste sono le domande di quello che possiamo chiamare il Test di Joel:

1. il team utilizza tool per il controllo dei sorgenti?
2. Esso è in grado di creare una build con un unico comando?
3. Vengono fatte build giornalmente?
4. Si lavora con una base dati dei malfunzionamenti?
5. I bug vengono corretti prima di scrivere nuovo codice?
6. Viene tenuto aggiornato lo stato di avanzamento lavoro?
7. Si lavora con un documento di specifiche?
8. L'ambiente di lavoro risulta essere tranquillo?
9. Vengono utilizzati i migliori tool disponibili sul mercato?
10. Vi sono dei tester nel team?
11. Nei colloqui dei candidati che dovrebbero entrare nel team, viene fatto scrivere del codice?
12. Vengono effettuati dei test di usabilità?

Venendo all'analisi delle domande, il controllo dei sorgenti è importante; utilizzare un tool come CVS (Concurrent Versioning System) o Svn (SubVersion) dovrebbe essere naturale, dato che detti sistemi consentono una facile gestione delle modifiche concorrenti, e una storicizzazione del codice sviluppato. In un ambiente in cui sembra che i clienti non facciano altro che continuare a cambiare idea, avere la possibilità di disporre in ogni momento di una qualsiasi delle proprie versioni del software, così come poter gestire e controllare le diverse mani che insistono su un progetto software, è garanzia di produttività e qualità.

Inoltre, quando si è dal cliente, in fase di debugging, non è più questione di bontà degli sviluppatori, quella di reagire con tempi di risposta brevi, ad ogni nuova segnalazione. Ci si imbatte in problemi risolvibili con il cambiamento di uno o due righe di codice, ma poi tutto il progetto va ricompilato, e distribuito. In questi casi è fondamentale, avere delle procedure veloci di produzione di una nuova versione. Ma anche nel lavoro di sviluppo quotidiano, è senz'altro meglio non perdere tempo con questioni che non riguardano prettamente cosa si sta sviluppando. Occorre fare uno sforzo iniziale, per poter organizzare e implementare tali procedure, che garantiranno benefici non sono nel singolo progetto, ma in tutti quelli futuri sulla stessa tecnologia. Nel prossimo articolo, saranno esaminate le restanti domande del test.

• Pubblicazioni correlate:
• 05-03-2007 Test di Joel (2/2)