[CleanCode] Il test di Joel: 12 domande per migliorare il tuo codice

Hai mai sentito parlare del SEMA? Si tratta di un sistema, piuttosto esoterico a dire il vero, per misurare l’abilità di un team di sviluppo di software. No, aspetta! Non cercare di informarti sul SEMA! Ti ci vorrebbero almeno sei anni solo per cominciare a capire di che si tratta. Così ho preferito inventarmi il mio personalissimo, poco scientifico e inadeguato test per la valutazione della qualità di un team di sviluppo software. La cosa interessante di questo test è che richiede al massimo tre minuti, così con tutto il tempo che puoi risparmiare puoi iscriverti a un corso di medicina.

Il test di Joel

  1. Utilizzi un prodotto per il controllo del versioning dei file?
  2. Riesci a compilare un intero programma con un solo comando?
  3. Crei almeno una build al giorno?
  4. Hai un sistema di gestione dei bug?
  5. Sei solito risolvere i bug prima di scrivere del nuovo codice?
  6. Hai un programma di sviluppo aggiornato?
  7. Hai un documento di specifiche?
  8. I tuoi programmatori lavorano in un ambiente tranquillo?
  9. Ti servi dei migliori prodotti presenti sul mercato?
  10. Hai dei tester nel tuo team?
  11. Durante il colloquio, fai scrivere del codice a chi si presenta per far parte del tuo team?
  12. Fai eseguire dei test di usabilità a sorpresa?

La cosa interessante del Test di Joel, è che ti permette facilmente di dare una risposta a ogni domanda, sia essa sì o no. Non hai bisogno di immaginarti il numero di righe di codice che sei in grado di produrre al giorno, o il numero medio di bug che riesci a chiudere. Basta che assegni al tuo team un punto per ogni “sì”. Purtroppo, la cosa brutta di questo test è che non dovresti assolutamente utilizzarlo, in modo da evitare possibili svenimenti.

Un punteggio complessivo di 12 rappresenta la perfezione, 11 è invece tollerabile, ma realizza 10 o meno e stai certo che andrai incontro a problemi piuttosto seri.
La verità, purtroppo, è che la maggior parte dei team di progetto realizza punteggi compresi tra 2 e 3 e ha bisogno veramente di un grande supporto, dato che compagnie come Microsoft viaggiano a ritmi da 12 a botta.

È ovvio che quelli elencati non sono gli unici fattori che concorrono al successo o al fallimento di un team: per esempio, qualora avessi a disposizione un team eccezionale per la realizzazione di un software che comunque non interessa a nessuno, bé la gente non lo acquisterebbe lo stesso.
Ed è anche possibile che un team di imbranati, incapace a rispondere affermativamente a una sola delle mie domande, riesca comunque a produrre un software fantastico, capace di cambiare il mondo. In ogni modo, non considerando questi fattori esterni, è un dato di fatto che se ottieni un 12 secco, potrai contare su un team disciplinato e capace di consegnare il prodotto in qualunque momento.

1. Utilizzi un prodotto per il controllo del versioning?

Ho utilizzato dei programmi di versioning commerciali ho utlizzato CVS, che è un software libero e, lasciamelo dire, anche un prodotto valido. Ma se non utilizzi alcuno di questi prodotti, finirai per impazzire nel tentativo di far lavorare insieme i tuoi programmatori. I tecnici non hanno alcun modo per sapere su cosa hanno lavorato i propri colleghi e non è sempre facile ripristinare la versione corretta dei file. L’altra cosa interessante dei programmi che gestiscono il versioning, è che i file stessi vengono salvati direttamente sui computer di ogni programmatore: infatti non mi è mai capitato di sentire di un progetto gestito con uno di questi programmi per il quale siano stati persi dei file.

2. Riesci a compilare un intero programma con un solo comando?

Con questa domanda intendo dire: in quanti passaggi riesci a mettere insieme una build, una versione funzionante del tuo programma, partendo dalla versione più recente dei tuoi file? I team più preparati hanno sempre a disposizione un singolo script col quale estrarre tutti i file necessari dal sistema di versioning; ricompilare ogni singola riga del codice; creare i file EXE necessari (e in tutte le varie versioni, lingue, combinazioni #ifdef), creare il sistema di installazione e infine creare il prodotto finale nel suo supporto destinatario, CD-ROM, sito Web statico, qualunque cosa.

Qualora questo processo richiedesse più di un solo passaggio, sarebbe incline a qualche errore. Infatti, quando sei vicino al rilascio devi avere a disposizione un sistema veloce per fissare ‘l’ultimo’ baco, compilare l’ultimo EXE, ecc. Se ti servono 20 passaggi diversi per compilare il codice, lanciare il programma di installazione, ecc., rischi di impazzire e di commettere errori stupidi.
[…]

3. Crei almeno una build al giorno?

Ogni tanto capita che quando si usa un programma di controllo del versioning dei file, qualche programmatore salvi accidentalmente un file sbagliato, capace di danneggiare una build. Per esempio, creano un nuovo file sulla loro macchina e tutto sembra funzionare alla perfezione, ma poi si dimenticano di salvare questo file nel sistema di versioning che gestisce il codice finale. Così, una volta spento il proprio PC se ne vanno a casa, ovviamente contenti per il lavoro svolto. Solo che nessun altro può più lavorare e così se ne vanno a loro volta tutti a casa, ovviamente tutti con una piva lunga così.

Danneggiare una build è una cosa molto brutta (e anche molto comune) ed è quindi molto utile produrre almeno una nuova build al giorno, in modo da essere certi che nessun danno del genere possa passare inosservato. Quando si lavora con team numeroso, un modo per assicurarsi che i bachi bloccanti siano sistemati al volo, è programmare la realizzazione di una nuova build ogni giorno all’inizio del pomeriggio, indicativamente all’ora di pranzo. Il team fa tutti gli aggiornamenti possibili della repository dei file prima di andare a pranzo e, quando torna, ecco pronta la nuova build. Se il processo ha funzionato, grandioso!
Tutti estraggono l’ultima versione dei file e ricominciano a lavorare. Se qualcosa è andato storto, amen, lo si può mettere a posto, ma nel frattempo il team può continuare a lavorare sulla versione precedente della build, quella funzionante.

Quando lavoravo con il team di Excel, avevamo una regola interna per la quale chiunque fosse responsabile di una build non funzionante, avrebbe, come punizione, monitorato la produzione di tutte le successive build, finché qualcun altro non si fosse reso responsabile di un malfunzionamento. Era un buon incentivo per evitare di combinare guai e anche un buon sistema per fare in modo che tutti, a turno, gestissero il processo di building e che, conseguentemente, imparassero come funziona.
Se vuoi approfondire questo argomento, prova a leggere il mio articolo intitolato “Le build giornaliere sono tue amiche

4. Hai un sistema di gestione dei bug?

Non mi importa come la pensi. Se sviluppi del codice, persino in un team composto solo da te stesso, senza servirti di un database col quale gestire i bug conosciuti del sistema, finirai per rilasciare del codice di bassa qualità. Molti programmatori ritengono di essere in grado di ricordarsi a memoria tutti i bug. È una stupidata. Io non sono in grado di ricordarmi più di due o tre bug alla volta e già domani mattina, piuttosto che nel momento del rilascio, stai certo che me li sarò dimenticati. È fondamentale tenere traccia formale dei bug.

I sistemi per la gestione dei bug possono essere semplici o complicati, ma le informazioni minime e imprescindibili che devi avere a disposizione devono essere quantomeno le seguenti:

  • modalità completa di riproduzione del bug
  • comportamento atteso
  • comportamento errato individuato
  • responsabile della soluzione

Se la complessità del sistema di gestione dei bug è l’unico motivo per cui non ne adotti uno, allora preparati cinque colonne in un file Excel e servitene. Per approfondimenti sulla gestione dei bug, leggi “Il tracking dei Bug senza sforzi

5. Risolvi i bug prima di scrivere nuovo codice?

La primissima versione di Microsoft Word per Windows era stata considerata come un “corteo funebre”. È stato un progetto interminabile. Era continuamente in ritardo. Tutto il team lavorava fino a orari impossibili, mentre il progetto continuava a essere rimandato, ancora e ancora e ancora, e ancora… uno stress pazzesco. Quando quella dannata cosa è stata finalmente rilasciata, dopo anni di attesa, Microsoft ha mandato l’intero team a riposarsi a Cancun, dopodiché si è soffermata a fare una seria autocritica.

Quel che hanno scoperto è che i responsabili di progetto erano stati talmente insistenti nell’attenersi al programma di sviluppo, che i programmatori avevano dovuto scrivere codice infischiandosene di qualsiasi processo di produzione, finendo così per realizzare del pessimo codice, anche perché la fase dedicata alla risoluzione dei bug non faceva parte del programma di sviluppo approvato. Non c’è stato alcun tentativo di tenere sotto controllo il numero dei bug. Semmai il contrario.
[…]

Per correggere il problema, Microsoft ha deciso di adottare una metodologia mirata all’ottenimento di un numero di bachi pari a zero. Molti degli sviluppatori dell’azienda si sono messi a ridere, perché con questa decisione sembrava quasi che il management pensasse che loro potevano ridurre il numero di bug per volontà divina. In effetti zero bug significava che in un qualunque momento del processo, la priorità massima doveva essere eliminare i bug, ancora prima di scrivere del nuovo codice. Ed ecco il motivo.

Generalmente, più tempo lasci passare prima di fissare un baco, più questo ti costerà (sia in termini economici, sia di tempo).

Per esempio, se fai un errore di sintassi o di scrittura che il compilatore è in grado di individuare, è molto facile da sistemare.

Quando hai a che fare con un baco del codice che hai individuato subito dopo averlo scritto, ti è sempre facile risolverlo, dato che il codice è ancora molto fresco nella tua mente.

Se invece trovi un baco nel codice che hai scritto qualche giorno fa, probabilmente ti ci vorrà un po’ più di tempo per eliminarlo, anche se una volta riletto il tuo codice ti verrà sicuramente in mente tutto e, conseguentemente, sarai in grado di sistemare il baco in un lasso di tempo non particolarmente lungo.

Ma se trovi un baco in un codice che hai scritto qualche mese fa, probabilmente ti sarai dimenticato le motivazioni per cui hai prodotto quel codice e conseguentemente ti risulterà molto complicato correggerlo. Dopo tutto questo tempo, potresti essere impegnato a correggere il codice di qualcun altro, che magari si trova in vacanza ad Aruba e in questo caso la risoluzione di quel baco diventerà come la scienza: lenta, metodica e meticolosa e non potrai nemmeno fare ipotesi sul tempo che ti ci vorrà per scoprire la cura.

E infine, se trovi un baco nel codice di un programma che è già stato pubblicato, rischi di dover affrontare delle spese incredibili per metterlo a posto.

Ecco una ragione per sistemare i bachi appena si presentano: perché richiede molto meno tempo. Eccone un’altra, che nasce dal fatto che è molto più facile definire quanto tempo ci vorrà a scrivere del nuovo codice rispetto a sistemare un bug. Per esempio, se ti chiedessi quanto tempo ci puoi mettere a scrivere il codice necessario a mettere in ordine alfabetico una lista, sono certo che mi sapresti dare una stima piuttosto precisa. Ma se ti chiedessi quanto tempo ci metti per sistemare quel bug che non fa funzionare il tuo programma quando Internet Explorer 5.5 è installato, non riusciresti nemmeno a tirare a indovinare, perché non sai (per definizione) qual è la causa del bug. Ci possono volere tre giorni come due minuti.

Questo implica che se ti sei dato una scadenza per la soluzione di una lunga lista di bug, questo programma non può essere realistico. Ma se hai già sistemato tutti i bug conosciuti e quel che manca riguarda solo il codice nuovo, allora il tuo programma potrebbe essere molto, ma molto più accurato.

Un’altra cosa molto bella del tenere il numero dei bachi nell’intorno dello zero, è che puoi essere molto più rapido nel rispondere al mercato. Alcuni programmatori ritengono questo fattore l’equivalente di essere pronti a rilasciare il prodotto in un qualunque momento. E in effetti, se un tuo concorrente introduce una nuova funzionalità talmente grandiosa da portarti via tutti i clienti, puoi semplicemente inserire a tua volta la funzionalità e rilasciare il nuovo software in un batter d’occhio, senza dover prima mettere a posto un gran numero di bug accumulati precedentemente.

6. Hai un programma di sviluppo aggiornato?

Il che ci porta a parlare di programmazione. Se per una qualsiasi ragione il tuo codice è importante per il business, allora ci sono un sacco di ragioni per cui è importante far sapere all’area commerciale quando il tuo codice sarà finalmente pronto. Gli sviluppatori sono tendenzialmente poco iniclini a stabilire delle scadenze. “Quando è pronto, è pronto!” sono soliti gridare ai responsabili del business.

Sfortunatamente, però, questo tipo di informazione non è sufficiente. Ci sono una marea di decisioni e di programmi che il commerciale deve fare ben prima di rilasciare il codice: pubblicare delle demo, fare delle presentazioni alla forza vendita, programmare la pubblicità, ecc. e l’unico modo che hanno per fare tutto questo è avere a disposizione un bel programma aggiornato dello stato dei lavori.

L’altra ragione cruciale per cui è importante avere a disposizione un programma di sviluppo, è che ti costringe a decidere quali funzionalità svilupperai, spingendoti a non considerare le funzionalità meno importanti, piuttosto che realizzarle alla meno peggio e pubblicarle così come sono.

[…]

7. Hai un documento di specifiche?

Scrivere le specifiche è come usare il filo interdentale: tutti concordano sul fatto che sia una buona idea, ma alla fine nessuno lo fa.

Non so con precisione perché sia sempre così, ma credo che fondamentalmente dipenda dal fatto che i programmatori non sopportano di dover scrivere dei documenti. Il risultato è che, quando un team composto da soli tecnici si trova ad affrontare un problema, preferisce esprimere la propria soluzione attraverso il codice piuttosto che mediante la scrittura di un documento. È molto più facile che si tuffino a testa bassa a produrre codice piuttosto che a scrivere delle specifiche.

Quando si è ancora a livello di design, se si incontrano dei problemi è molto semplice risolverli scrivendo poche righe di testo. Mentre quando il codice è scritto, il costo necessario per risolvere i problemi è drammaticamente più alto, sia dal punto di vista emotivo (la gente odia buttare via del codice) sia da quello temporale e così spesso si è un po’ riluttanti a risolvere realmente questi problemi. Il software che non nasce partendo da un documento di specifiche, spesso finisce per essere disegnato malamente e il suo programma di sviluppo finisce per essere decisamente poco attendibile. Sembra che il problema di Netscape sia stato proprio questo: poiché le prime quattro versioni avevano finito per diventare un vero e proprio casino, il management ha stupidamente deciso di buttare via tutto il codice prodotto e ricominciare da capo. Dopodiché ha fatto esattamente lo stesso di errore con Mozilla, riuscendo a creare un vero e proprio mostro che, una volta uscito da ogni controllo, ci ha messo svariati anni prima di arrivare allo stato di Alpha.

La mia teoria vuole che questo tipo di problematiche possa essere superato semplicemente insegnando agli sviluppatori a essere degli scrittori un po’ meno riluttanti e, magari, mandandoli a fare un bel corso di scrittura. Un’altra soluzione è assumere qualche bravo program manager capace di scrivere le specifiche di progetto. In ogni caso, dovresti sempre cercare di mettere in pratica la regola “niente codice senza specifiche”.
[…]

8. I tuoi programmatori lavorano in un ambiente tranquillo?

I guadagni in termini di qualità e produttività che derivano dal concedere agli sviluppatori un ambiente di lavoro calmo e tranquillo, sono stati lungamente documentati. Persino il classico libro di software management Peopleware documenta in modo approfondito questi vantaggi. Ecco come funziona. Sappiamo tutti più che bene che i migliori sviluppatori danno il proprio meglio quando riescono a scrivere di “getto”, uno status conosciuto anche come “trance produttiva”, dove i programmatori sono completamente concentrati sul proprio lavoro e assolutamente sconnessi dal mondo che li circonda. In quello stato perdono il senso del tempo e producono delle cose grandiose grazie alla concentrazione assoluta che hanno raggiunto. Scrittori, programmatori, scienziati e persino giocatori di baseball possono raccontarti di cosa voglia dire essere in trance produttiva.

Il problema è che entrare in trance produttiva non è molto facile. Se provi a misurare il tempo necessario per raggiungere il massimo livello di produttività, vedrai che ci si mettono in media non meno di 15 minuti. A volte, soprattutto se sei stanco o hai già prodotto parecchio lavoro creativo nel corso della giornata, ti è proprio impossibile raggiungere quello stato e così finisci per passare il resto della giornata lavorativa a guardare nel vuoto, a navigare sul Web o a giocare a Tetris.

L’altro problema è che è molto facile perdere la trance produttiva. Rumore, telefonate, l’ora di pranzo, il dover guidare cinque minuti fino al primo Starbucks per il caffé e interruzioni dovute ai propri colleghi (soprattutto queste ultime) sono tutte situazioni che interromperanno la tua concentrazione. Se un tuo collega ti fa una domanda, provocandoti un minuto di interruzione, ma facendoti anche perdere la concentrazione in modo che ti ci vuole mezzora prima di riprenderla, la tua produttività complessiva sarà stata messa a serio rischio. Se ti ritrovi in uno di quegli ambienti incasinati, come quelli che le dotcom adorano creare, dove i ragazzi del marketing urlano come matti al telefono, seduti al fianco dei programmatori, la tua produttività andrà a farsi benedire, dato che le continue interruzioni impediranno agli sviluppatori di raggiungere lo stato di trance produttiva.

Per i programmatori questa condizione è particolarmente complicata. La produttività dipende dalla capacità di cogliere, in un brevissimo lasso di tempo, i piccoli elementi distinti presenti nella propria memoria a breve termine. Ogni piccola interruzione può far sì che questi piccoli elementi arrivino e scompaiano immediatamente. Quando ricominci a lavorare non ti ricordi niente di quelle piccole cose (come la nomenclatura che stai utilizzando, o dove stavi per implementare l’algoritmo di ricerca) e devi cercare di ricordarti queste cose, finendo per rallentarti finché non riesci a recuperare la tua velocità.

E una semplice questione algebrica. Possiamo dire (dato che l’esperienza sembra darci ragione) che se interrompiamo uno sviluppatore per un minuto, nella realtà stiamo bruciando non meno di 15 minuti di produttività. Per esempio, proviamo a mettere due sviluppatori, Jeff e Mutt, in un open space, uno a fianco all’altro.
Mutt non riesce a ricordarsi il nome della versione Unicode della funzione strcpy. Potrebbe cercarlo, cosa che gli porterebbe via 30 secondi, o potrebbe chiedere a Jeff, portandogli via 15 secondi. Dato che siede proprio a fianco di Jeff, chiede a lui. Jeff si distrae e perde 15 minuti di produttività (per salvare 15 secondi di Mutt).

Ora proviamo a separarli e a metterli in uffici diversi, dotati di muri e porte. Ora, quando Mutt non si ricorda il nome di quella funzione, può ricercarlo, cosa che gli richiede nuovamente 30 secondi, o può chiedere a Jeff, che questa volta richiede 45 secondi e comporta anche il doversi alzare (che non è un compito molto semplice considerando la media della forma fisica dei programmatori!). Così decide di cercarlo da solo. In questo modo Mutt perde 30 secondi di produttività, ma noi salviamo 15 minuti di quella di Jeff. Ahhh!

9. Utilizzi i migliori prodotti presenti sul mercato?

Scrivere codice in un determinato linguaggio è una delle ultime cose che non si possono fare servendosi di un qualunque computer da casa. Se il tuo processo di compilazione richiede più di una manciata di secondi, allora il fatto di possedere uno degli ultimi e più potenti computer potrebbe farti risparmiare parecchio tempo. Persino se la compilazione richiede solo 15 secondi, gli sviluppatori si annoieranno da matti mettendosi a leggere The Onion, mentre il compilatore gira e rilegge il codice, finendo per distrarti alla morte e farti perdere un sacco di ore di produttività.

Debuggare il codice della GUI servendosi di un unico monitor è devastante se non impossibile. Utilizzare due monitor per scrivere il codice della GUI è senz’altro più intelligente.

Gran parte dei programmatori ha spesso necessità di manipolare delle immagini per realizzare delle icone per le barre di comando e la maggior parte dei programmatori non ha a disposizione un editor di immagini decente. Cercare di servirsi di Microsoft Paint per modificare le bitmap è assurdo, ma alla fine è la cosa che fa la maggior parte dei programmatori.

Nel mio ultimo posto di lavoro, l’amministratore del sistema continuava a inviarmi delle email automatiche con le quali si lamentava del fatto che stavo utilizzando più di (beccati questa) 220 megabyte di spazio sul server. Gli ho fatto gentilmente notare che, considerando il costo attuale degli hard disk, il costo di quello spazio-disco era certamente inferiore a quello della carta igienica che avevo utilizzato. Buttare via anche solo 10 minuti per fare pulizia nelle mie directory sarebbe stato un incredibile spreco di produttività.

Team di sviluppo di livello superiore non mettono mai i propri programmatori alle prese con queste piccole torture. Persino disturbi insignificanti come quelli derivanti dall’utilizzo di programmi inadeguati fa sì che i programmatori si ritrovino a lavorare malamente e borbottando. E lasciami dire che un programmatore insoddisfatto è certamente un programmatore poco produttivo.

Inoltre, gli sviluppatori possono essere facilmente esaltati proprio dalla concessione dalle ultime, più innovative soluzioni tecnologiche. Posso assicurare che si tratta di un modo decisamente più economico per far lavorare bene queste persone, piuttosto che concedergli degli stipendi sempre più alti per farli ugualmente felici!

10. Hai dei tester nel tuo team?

Se nel tuo team non sono presenti dei tester, almeno uno per ogni due o tre sviluppatori, i casi sono due: o sei sul punto di rilasciare del software pieno di bug, o stai sprecando un sacco di soldi, pagando 100 dollari l’ora a dei programmatori per del lavoro che potrebbe essere fatto per 30 dollari l’ora da un tester. Risparmiare sui tester è talmente una stupidata da un punto di vista economico, che sono veramente stranito dal fatto che certa gente ancora non se ne sia resa conto. Il Capitolo 22 approfondisce questa questione.

11. Durante il colloquio, fai scrivere del codice a chi si presenta per far parte del tuo team?

Assumeresti mai un mago senza prima avergli chiesto di farti vedere qualcuno dei suoi trucchetti? Naturalmente no. Sceglieresti mai il catering per il tuo matrimonio senza prima aver assaggiato qualcuno dei loro piatti? Ne dubito proprio (a meno che non si tratti di Nonna Papera, che però ti odierebbe a morte se non le lasciassi preparare la sua formidabile torta di mele).

Tuttavia, ogni giorno i programmatori vengono assunti solo sulle basi di impressionanti curriculum, o perché chi gli fa il colloquio semplicemente si diverte a parlare con loro. O gli vengono poste delle domande banali (“qual è la differenza tra CreateDialogO e DialogBoxQ?”), alle quali si potrebbe rispondere dando un veloce sguardo alla documentazione. Non ti interessa se hanno imparato migliaia di banalità sulla programmazione; vuoi solo sapere se sono in grado di scrivere del codice. O, peggio ancora, gli si fanno delle domande “AHA!”: quel tipo di domande che sembrano ovvie quando conosci la risposta, ma che sono impossibili se non la conosci.

Per cortesia, piantala di fare così. Fai quel che ti pare durante i colloqui, ma fai scrivere al tuo candidato qualche riga di codice (per qualche ulteriore consiglio, prova a leggere il mio Corso di sopravvivenza al colloquio di lavoro, che compare nel Capitolo 20 di questo libro).

12. Fai eseguire dei test di usabilità a sorpresa?

Un test di usabilità a sorpresa viene fatto acchiappando il primo sventurato che passa nel corridoio di fronte al tuo ufficio, per fargli fare un test di usabilità del codice che hai appena prodotto. Se fai questo test con cinque persone, riuscirai a scoprire il 95 percento dei problemi di usabilità del tuo codice.

Una buona interfaccia utente non è così difficile da disegnare come potresti credere ed è fondamentale se vuoi che la gente adori e compri il tuo prodotto. Prova a leggere il Capitolo sulla UI design, una breve introduzione per programmatori.

Ma la cosa più importante riguardo all’interfaccia utente è che se fai vedere il tuo programma a un gruppetto di persone (e cinque o sei persone sono effettivamente un gruppetto sufficiente), potrai scoprire rapidamente i principali problemi che lo affliggono. Anche se le tue competenze sulla UI sono scarse, finché continuerai a servirti di questo test di usabilità a sorpresa (che per altro non costa proprio nulla), stai certo che la tua interfaccia utente risulterà molto, ma molto migliore.

Quattro modi per utilizzare il test di Joel

  1. Dai un voto al tuo team e fammelo sapere, così posso cominciare a spettegolare.
  2. Se sei il responsabile di un team di software, servitene come di una checklist, per essere certo che il tuo team lavori al meglio delle sue possibilità. Quando inizierai ad ottenere qualche 12, potrai lasciare il team da solo e focalizzarti sulle attività necessarie a impedire che la gente del commerciale non gli stia troppo addosso.
  3. Se stai decidendo se prendere in carico un nuovo progetto, chiedi ai potenziali componenti del team quanto hanno ottenuto nel test. Se il punteggio è troppo basso, sii certo di avere l’autorità necessaria per sistemare la questione, altrimenti finirai per diventare frustrato e improduttivo.
  4. Se sei un investitore nell’atto di fare una doverosa analisi per valutare la qualità di un team di sviluppatori, o se la tua azienda sta pensando di fondersi con un’altra, questo test può fornire delle indicazioni sostanziali sul fatto che sia opportuno o meno investire.

Tratto da Joel e il Software – Mondadori (2005)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


quattro + = 6