Archivi categoria: produttività

Debito tecnico

Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.

Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l’abbiamo fatto male noi.

Perché, a volte, il software è fatto male? In alcuni casi, per l’incompetenza di chi lo sviluppa, problema in genere superabile con un’adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c’è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.

Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch’esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.

Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.

Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.

Automazione del conteggio dei Function Point

L’Object Management Group (OMG) ha pubblicato un documento sull’automazione del conteggio dei Punti Funzione (Function Point), la metrica più diffusa a livello internazionale per misurare le dimensioni delle applicazioni software (cioè per dare risposta alla domanda: quanto è “grande” un software?).

Il conteggio dei Function Point è utile sotto diversi punti di vista, per governare sistemi informativi complessi e misurare livelli di qualità e di produttività; viene spesso usato anche per stimare, negoziare e tenere sotto controllo i rapporti di outsourcing tra clienti e fornitori nell’ambito dello sviluppo software. Il conteggio viene svolto tradizionalmente in modo “manuale”, ed è un’attività onerosa che richiede una elevata competenza specialistica.

Il documento OMG sull’automazione del conteggio dei Function Point, in versione beta (lo stadio precedente all’emanazione come standard ufficiale), è disponibile con il titolo “Automated Function Points” sul sito del Consortium for IT Software Quality (CISQ), nella sezione riservata ai membri: l’iscrizione è gratuita e consente lo scarico del documento.

Metriche e controllo

Lord Kelvin: “Se non si può misurare, non si può migliorare”.

Tom DeMarco, in Controlling Software Projects (1986): “Non si può tenere sotto controllo ciò che non si riesce a misurare”.

Phillip G. Armour, su Communications of the ACM, June 2012, rovescia il punto di vista: “Se non si migliorano le cose, è difficile misurarle bene; sotto alcuni aspetti, non possiamo misurare ciò che non controlliamo”.

Alcuni esempi illuminanti di misurazioni dubbie citate nell’articolo: durata, produttività, costo, qualità dei progetti software.

Rispettare il tempo delle persone

Perché molte intranet aziendali sono fatte male? Perché il management non ha rispetto per il tempo sprecato dai propri dipendenti, afferma l’esperto di comunicazione internet Gerry Mc Govern.

L’articolo è da leggere, anche perché affronta il tema degli effetti negativi del lavoro straordinario sulla produttività aziendale. Nulla di nuovo, ma ben scritto ed argomentato in modo convincente.

Ma ritornando al tema, perché molti servizi internet (non intranet) offerti dalla pubblica amministrazione e da aziende in situazioni di relativo monopolio (ad esempio Trenitalia) sono fatti così male e senza rispetto per gli utenti?