martedì 17 agosto 2010

Gmail Zero-eMail-Zen



Per lavorare in modo efficiente cerco di configurare la mia casella di posta in modo efficace tramite l'applicazione di pochi piccoli accorgimenti che il client web di Gmail rende semplici ma che si possono usare anche tramite altri client di posta.

L'accorgimento più importante per tenere una casella di email il più possibile pulita (almeno per ora) è cercare di non lasciare le email ad attendere nell'inbox.
Seguendo anche i consigli di Merlin Mann, ad esempio di questo video (e seguendo i consigli di GTD),

Ogni email deve finire il prima possibile (subito!) in uno dei seguenti modi:
1) essere cancellata / archiviata
2) ottenere una risposta
3) essere inoltrata / delegata a qualcuno
4) essere rimandata a più tardi senza rimanere nell'inbox
5) causare un tuo lavoro - ogni tanto purtroppo bisogna lavorare - ed eventualmente una risposta a riguardo


Alcune di queste azioni hanno bisogno di una persona attiva - non ho ancora capito se lo sono davvero - ma altre per fortuna possono essere almeno in parte automatizzate.
Fra le cose che ho configurato nel mio ambiente Gmail, le più importanti sono (fra parentesi segnalo l'obiettivo che aiutano a raggiungere):
a) Le email che arrivano da indirizzi di lavoro vengono etichettate come tali in modo che si possano più facilmente ritrovare, archiviare all'occorrenza per nasconderle anche come non lette e poi essere facilmente recuperate la mattina successiva. (1, 4)
b) Le email per le quali aspetto una risposta, le etichetto con una label "waiting" e le mando in copia nascosta anche a me, in modo che tramite un filtro possa archiviarle e tenerne traccia nella vista "waiting". (3)
c) Gli appunti che scovo in giro per il web cerco di salvarli tramite l'ottimo strumento gratuito springpadit.com ma se mi trovo ad avere accesso solo alla posta, mi mando una email con subject "memo" e filtro tale email archiviandola ed etichettandola pronta per essere letta più tardi.
d) Sto anche usando un prodotto in beta che aiuta molto, si chiama boomerang4gmail, e anche se non è fondamentale avere un tool del genere, aiuta molto poter rimandare o delegare stando attenti a verificare se si è ricevuto una risposta. Vale la pena farci un giro. (3, 4)
e) Uso un gran bel gruppo filtri per cancellare / archiviare molte newsletter et similia non richieste che non voglio nemmeno mettermi a controllare o su notifiche da social web che voglio controllare solo quando decido io. (1)

Tutto questo dovrebbe servire a passare meno tempo sulla posta e più tempo sul proprio lavoro e sulle cose che più interessano, senza però lasciare in uno stato disastroso la propria inbox

venerdì 29 gennaio 2010

Metriche del software

Obiettivi possibili delle metriche:
1) Provare a predirre la quantità di nuovi moduli o modifiche da sviluppare
2) Valutare lo sforzo impiegato per svilupparlo

E' da valutare prima di tutto quanto tempo si può impiegare nella misura delle metriche per non generare un overhead nella generazione di queste statistiche.



Predirre la quantità di nuovi moduli o modifiche da sviluppare


Predirre in base ai requisiti
Per il primo caso ci si può basare sui Punti Funzione.
Questo metodo è difficile da usare e può portare a valutazioni disparate a seconda delle interpretazioni dei requisiti, della variabilità dei requisiti stessi [4][5].

A parte il peso, comunque, la valutazione delle interfacce da costruire e la valutazione di tutti gli input e output da implementare può avere un valore ma deve essere considerata la volatilità dei requisiti che si vanno a implementare, per cui gli Unadjusted Function Points (UFP) possono risultare differenti a seconda della variabilità dei requisiti esposti.

Calcolo dei punti:
I punti vengono calcolati in base a interfacce interne (come tabelle di un proprio database), interfacce esterne (web services o interfacce gestite dal di fuori dei confini dell'applicazione - più comuni nelle nostre applicazioni) e tre tipi di processi che elenco di seguito:
EI - External Input: processo elementare di input di dati dall'esterno, ad esempio tramite un form o tramite un file xml esterno (come quelli di alfresco)
EO - External Output: processo elementare di output verso l'esterno (in genere verso l'utente) che necessitano di una logica più o meno complessa per la generazione dei dati
EQ - External Inquiry: come EO ma non necessita di logica nell'applicazione per il calcolo dei dati da mostrare. Questi vengono solo recuperati e dati all'esterno.

Gli UFP possono poi essere pesati in base a un indice VAF che ripende da varie considerazioni sul software che si sviluppa. Questo indice può variare considerevolmente il risultato dei punti funzione e spesso è criticato per la sua soggettività. I pesi da valutare sono fondamentali per la giusta pesatura e dipendono anche molto dalla esperienza del valutatore.
Più una metrica dipende dall'esperienza del valutatore, più non si può considerare una metrica ma una stima. [7]

Purtroppo la fonte principale [A] è una fonte chiusa, a pagamento, probabilmente anche per i corsi e certificazioni che propone.





Alcune considerazioni a prima vista

Le nostre interfacce interne sono poche. La maggior parte dei processi prendono dati da fonti esterni alle nostre applicazioni e non abbiamo nostri database.

In generale i punti funzione non valutano gli interventi non funzionali e il lavoro di alcuni può essere meno facilmente valutato tramite questo strumento (interventi sulla performance, sullo stile di visualizzazione, etc.)

Il processo è molto incentrato sugli output e gli input e la valutazione di processi Machine to Machine, processi schedulati e altri processi non funzionali devono essere valutati in modo speciale (ad esempio come output non verso l'utente).

Gli interventi di manutenzione (evolutiva o correttiva) possono essere valutati ma hanno un valore molto relativo. Per la misura di questo tipo di interventi si può valutare una funzione più ragionata come [9] ma risulta poi quantomeno difficile il confronto con i punti calcolati per nuove funzioni.





Valutare lo sforzo, le ore impiegate per sviluppare software


Per valutare il codice sviluppato si possono usare varie metriche.
Avendo la fortuna di lavorare con Eclipse ci si può avvalere di plugin come quello a [2] per calcolarle senza troppi sforzi.

Probabilmente la cosa migliore e più utile sarebbe pesare vari criteri per il calcolo dello sforzo totale (S):
1) Il numero di classi create e modificate ha un peso (CC)
2) La complessità del codice sviluppato (tramite ad esempio la complessità ciclomatica di McCabe) ha un peso (McC)
3) Le linee di codice vanno pesate in una valutazione (LOC)
4) Si deve quindi pesare in base al numero di punti funzione valutati (UFP)
es di funzione per un intervento:



S = UFP  \times \alpha CC  \times \beta LOC  \times \gamma McC



Il risultato può essere pesato in base a dei feedback dovuti a parametri quali quelli che seguono.
A) Le ore dichiarate dalla persona come lavorate su un certo task possono essere valutate eventualmente per un confronto nel tempo col risultato ottenuto dalle metriche.


B) Allo stesso modo, il numero delle ore previste per la lavorazione di una certa funzione possono essere confrontate eventualmente nel tempo con i risultati delle metriche per la correzione delle previsioni stesse e per la valutazione delle metriche ottenute.


Nota: per una valutazione più giusta, bisognerebbe prendere in considerazione nel lavoro svolto, la mantenibilità del codice prodotto, in modo da favorire la tendenza verso un codice più mantenibile che garantisce meno lavoro la volta successiva. [3] Purtroppo gli strumenti che ho trovato per eclipse che calcolano l'indice di mantenibilità sono a pagamento.


Sarebbe auspicabile avere un modulo software che calcola quanto sopra in modo da non dover impiegare tempo nella valutazione ma il calcolo dei punti funzione probabilmente implica per forza una valutazione della persona in base ai requisiti e si può arrivare solo all'uso di un form da riempire online [6].




Riferimenti: