Quando si scelgono delle software metric da inclundere nel proprio metrics plan ci si dovrebbe sempre porre alcune domande in modo da ottenere il miglior risultato possibile. A proporre queste domande è il developer Red Hat James Falkner, che si occupa principalmente della community open source che gravita intorno all'azienda di Raleigh, esaminiamole una per una:
"Queste nuove software metric saranno d'aiuto per arrivare agli obbiettivi desiderati?"
Si tratta di un quesito semplice da porsi, queste nuove software metric hanno una qualche tipo di relazione con l'obbiettivo scelto dal team? Se la risposta è negativa allora forse è il caso di scartare l'adozione o, al limite, dargli un'importanza minore rispetto ad altri aspetti. Le software metric che non aiutano a misurare i progressi sono uno spreco di tempo e di risorse.
Questo punto ci permette di passare direttamente alla seconda domanda ovvero:
"Quando sono accurate le nuove software metric?"
Per essere efficaci le metric devono essere molto precise. Ad esempio, nel caso in cui si volesse quantificare i download di un programma sicuramente si vorrà visualizzare il numero di "singoli download" e non il numero di GB scaricati complessivamente dai server, quindi il dato ottenuto dalle software metric deve essere accurato e semplice da consultare.
"Che relazione c'è tra la software metric che ci interessa e le altre?"
Comprendere bene le relazioni tra le varie software metric può essere vitale per il successo o il fallimento di un progetto. Ad esempio, uno dei principali obbiettivi dei progetti open source è di innovarsi attirando nuovi sviluppatori che possano portare il loro ventaglio di esperienza all'interno del team.
È possibile notare come l'aumento di collaboratori corrisponda con la riduzione dei tempi di attesa per i un commit. Quindi è evidente che se si vuole attirare nuovi sviluppatori dentro il proprio progetto è bene dedicare più risorse per la gestione dei commit e delle patch da inserire nel repository principale, in modo da rendere sempre più partecipi i developer interessati a contribuire attivamente.
Questo però può produrre un effetto collaterale, ovvero con l'arrivo di nuovi sviluppatori e di nuovo codice può anche aumentare notevolmente la presenza di bug e dunque questo inciderà sulla user experience degli utenti e sui tempi di rilascio delle nuove versioni.
"Cosa fare se la scelta di una software metric si rivela un errore?"
Prevede gli effetti dell'adozione di una metric è sicuramente una buona strategia che permette di andare a creare una serie di "ammortizzatori" nel caso qualcosa vada storto. Ovviamente esistono diversi modi per affrontare un fallimento, tutto dipende dal contesto in cui ci si ritrova, è possibile cambiare tipi di metric oppure collaborare in modo stretto con il proprio team di developer per eliminare alla radice i bug e i problemi, magari organizzando anche sessioni di QA con il resto del team per realizzare nuove forme di test.
Il modo migliore per scegliere una software metric è probabilmente parlare con i propri collaboratori e chiedere loro cosa pensano in merito all'adozione di una nuova metric, in modo da avere più punti di vista e comprendere i loro effetti e la loro possibile efficacia a lungo termine. In questo modo non solo si potrà ottenere un prodotto migliore, ma si riuscirà anche a motivare maggiormente il proprio team che si sentirà partecipe nelle decisioni generali.
Via James Falkner