[Agile] Ecco a voi la migliore metrica sulla PRODUTTIVITA


Sto cercando di riportare tutto al segno '-'.
La differenza, il concetto di togliere. L'agilità porta con se un insieme di buone pratiche ma la vera novità è l'insieme di principi: ce lo siamo detti così tante volte.
Aggiungiamo allora nel nostro elenco il principio di secchezza.
Perchè bisogna togliere tutto il codice commentato, tutto il tempo usato per scrivere javadoc, per scrivere test il cui fine è quello di superare delle metriche. Ci siamo abituati ad avere tutto, togliamo ai nostri sviluppatori la gui, diamogli il mouse per 10 minuti al giorno, giusto per staccare la testa. Togliamo loro potenza di macchine, non regaliamogli ram, nè cpu. Scriveranno software leggero o periranno. Impareranno ad avere confidenza sul codice senza lanciare un application server in locale. Bisogna togliere il journal se non è utile come lo si scrive, togliere il pair se uno dei due dorme, togliere i test di accettazione se il cliente non li scrive o non contribuisce a scriverli.

Manager di tutto il mondo alla ricerca della metrica perfetta sulla produttività, qui c'è la vostra risposta: obbligate i vostri sviluppatori assetati di risorse a scrivere file non piu grandi di 5K, vedrete magie. E non parlo solo di codice, ma anche di configurazione.

E' solo in ristrettezze di risorse che si aguzza l'ingegno.

Togliamo il tempo agli sviluppatori e chiediamo loro risultati se si distraggono con mail, giochi, messenger.
Dobbiamo sentire la rabbia quando duplichiamo: cancelliamo dal nostro vocabolario frasi come: "basta copiare questa cosa" e trasformiamole in: "CHE PALLE, devo anche copiare questa cosa". Basta "spero di farcela entro oggi"! Basta interi, dobbiamo dare risposte booleane: sì. no.
Quando il manager ci chiede se possiamo aggiungere user stories all'iterazione, quando dobbiamo decidere se prenderci il rischio di un nuovo progetto, quando dobbiamo scegliere se assumere o no una persona: SI o NO. Non c'è forse, non c'è magari.

Togliamo framework che fanno cose 'GRATIS', anzi, togliamo la parola 'gratis'. Togliamo la sacra famiglia del fallimento hibernate, struts, spring.

Sempre di piu aggiungiamo tecnologia per risolvere problemi, e ci inventiamo soluzioni barocche con generics, con annotations, con aspect oriented programming, con librerie di test con interfaccie fluenti. Siamo così alti sui trampolini della tecnologia che qualche settimana fa miei nuovi colleghi hanno dovuto fare uno spike su come si esegue una connessione jdbc pura in java per fare delle semplici query.
Non ci serve nulla di piu di una manciata di concetti sul paradigma object oriented. Altro che easy mock per esplorare come gli oggetti possono parlarsi: carta e penna! Anzi, togliamo anche carta e penna, lasciamo solo il cervello.

1 commento:

Unknown ha detto...

Ciao Tommaso,

mi è piaciuto il post, specialmente la pate sullo spike per Jdbc (molto realistica) e sul limite a 5k, anche se sarei curioso di vedere cosa riuscirebbero ad inventare per gabbarlo certi sviluppatori.

Su Spring/Hibernate/Struts e compagnia bella... il problema è che il vantaggio si vede al crescere della dimensione del progetto. Paghi di più nella prima iterazione, ma (in teoria) recuperi dopo. Sarebbe bello se il punto di break even fosse fisso, riconoscibile e misurabile, ma così non è... però concordo con te che ci portiamo una valigia troppo gonfia.

Brando