English
Stimare i costi e definire il processo di un'app è come rivedere Tempi Moderni
Perché gli sviluppatori non riescono a stimare di stimare il tempo di produzione?
Questa, come altre domande, sono lo spunto per scrivere un articolo che mi è stato ispirato dopo la lettura di un post di Ash Moran mentre navigavo per il Patch Space Blog.
Introduzione
In passato, mentre ero dirigente (settore di Sviluppo) di grandi gruppi italiani, ho cercato molte volte di comunicare al vertice aziendale che determinare su un documento (Plan) le esatte tempistche delle diverse fasi di lavoro dello sviluppo di un software è un attività abbastanza inutile e che, semmai, serve solo a far lievitare drammaticamente i costi.
Con questo non voglio affermare che le pianificazioni, e i diversi report che ci impongono le grandi aziende, sono inutili; questi report servono a fornire date di scadenza e di rilasco delle componenti in relazione ad un budget definito.
Il problema nasce quando ti capita come capo la classica persona (top-manager?) che non avendo mai neppure sviluppato un “hello world!” si ostina a cercare di voler capire cosa esattamente farai con la tua squadra e ti imporrà dei lunghi meeting in cui sarai costretto a dire numerose baggianate perchè le domande che ti faranno saranno talmente idiote da non poter far altro che costringerti a dettagliare le varie fasi del processo che tanto non comprenderanno del tutto.
Cercare di spiegare e dettagliare in anticipo le fasi di uno sviluppo software, come definire i tempi di tutte queste singole fasi (o task) a un “Manager” che si ostina a voler capire come poter fare/controllare/comprendere il tuo lavoro è come chiedere ad un compositore musicista di spiegargli come farà a comporre una canzone e quando e come arriverà alla prima , alla seconda o alla terza strofa…
Sappiamo con certezza che ad un compositore si puo’ affidare la scrittura di un’opera e l’artista al massimo potrà dirci quando ce la consegnerà ma di certo nessuno con la testa sulle spalle potrà pensare di chiedergli esattamente cosa farà , quando lo farà e di fornirgli una data esatta in cui sarà arrivato all’ ennesima nota sullo spartito.
A questo punto uno dei tanti miei ex colleghi, che casualmente leggerà questo articolo, si dirà: “bhe ma in azienda a noi non servono grandi artisti come Mozart, ma solo mediocri esecutori che devono fare esattamente quel che diciamo”.
La mediocrità è ovviamente una componente essenziale di molti cosidetti “managers” della grande o media azienda italiana, quella mediocrità che ha portato un paese di artisti e navigatori ai margini dell’impero economico e culturale.
E’ quindi abbastanza facile intuire che il mio pensierò ha basi culturali completamente diverse, poichè lo sviluppo è a mio parere sinonimo di creatività e solo la creatività applicata, unitamente alla genialità, può portare risultati duraturi e tenere alti quei fattori che fanno di un’azienda un motore economico-sociale che non si arresta neppure con le crisi.
Semmai, per parafrasare Einsten, è solo con la crisi che si sviluppa la genialità.
Stimare il tempo o il rilascio?
Non possiamo stimare il tempo per ogni singola attività nello sviluppo di software in quanto la natura del lavoro è la creazione di nuova conoscenza.
L’obiettivo di sviluppo del software è quello di automatizzare i processi. Una volta che un processo è automatizzato, esso può essere eseguito ripetutamente, e nella maggioranza dei casi, in un tempo prevedibile.
Il codice sorgente è come un progetto di produzione, il computer è come una vera e a se stante azienda, gli ingressi (dati) sono come materie prime, e le uscite (dati o programmi) sono come prodotti finiti. Quindi la chiave di volta sta nella progettazione del processo, che è un compito complesso e costoso. Una volta che il processo è stato definito e reso efficente non c’è più bisogno di riscoprire questo processo, basta acquisire il modello.
Non è in realtà sempre un problema il fatto che i tempi di sviluppo sono in parte imprevedibili, perché il rovescio della medaglia è che così è il valore restituito sarà maggiore; un software di successo può creare o salvare molto più del suo costo. Tom DeMarco, sempre citato da Ash, sostiene la necessità di concentrarsi sui progetti di alto valore proprio per questo motivo. Si noti che questo approccio ha valore come generazione di un nuova mentalità, che porterà a superare l’attuale prevalente mentalità basata quasi esclusivamente sul controllo dei costi . Questa è una questione tutt’altro che banale.
Una delle migliori spiegazioni della variabilità, e come sfruttarla per creare valore, è nei “Principi del flusso di prodotto per lo sviluppo” di Don Reinertsen.
Regola generale: prendere le stime di uno sviluppatore, raddoppiare e aggiungere un po’
Il doppio-and-add-a-bit è una regola interessante. Quando i manager fanno questo, spesso le attività vengono completate in tempo.
Voglio precisare che la pratica di stimare ogni task, o building block (come lo chiamano alcuni consulenti) puo’ portare alla richiesta di budget di gran lunga piu’ elevati del necessario; a questo proposito voglio fare un’esempio su un fatto che mi è accaduto realmente:
Qualche anno fa un grandissimo gruppo industriale mi chiese di dirigere un progetto per un portale intranet, che sarebbe stato utile ai dipendenti. Dopo le prime stime sull’utilità di un nuovo portale intranet e sopratutto dopo l’analisi degli eventuali costi risparmiati dal Gruppo con l’introduzione del self-service per i dipendenti, si cerco’ di stimare tempi e costi dello sviluppo.
Consegnai un breve rapporto, basato sulla forte esperienza pratica sul campo, in cui stimavo a spanne un budget di X euro e il rilascio graduale dei servizi entro un anno. Mi chiesero allora di dettagliare uno per uno i task , fino al singola piccola applet, e di definirne per ognuno tempi di rilascio e costi per task . Facendo questo mi ero accorto, seguendo il loro modello di stima, che in ogni singola pagina web potevano essere presenti anche una trentina di building blocks (…). Evidentemnte ho cercato di fargli capire che questa era una pratica del tutto superflua e che bastava proiettare delle medie rispetto alle esperienze pregresse e sopratutto in base al materiale disponibile e alle caratteristiche professionali del team di sviluppo.
Sono stato costretto a lasciare l’incarico quando un gruppetto di giovani consulenti d’azienda , che mai nella loro vita avevano neppure lavorato su un sisterma di sviluppo, hanno presentato un piano ben dettagliato in un mastodontico file power point (ppt) con bella grafica e in cui si definivano tutti i piccoli building block, uno per uno e si proiettavano scadenze e costo per ognuno di essi: risultato un budget da 7X euro in tre anni. Decisi di lasciare l’incarico sopratutto dopo che il mio sguardo si era soffermato su una decina di slides dedicate al servizio “calcolatrice” il cui costo era di alcuni giorni di lavoro. Ogni sviluppatore degno di questo nome sa che un building block “calcolatrice” lo si ottiene gratis e neppure si deve mostrare in un piano del genere… e questo non era neppure il fatto piu’ eclatante.
Inutile proseguire , poiche’ evidentemente il mio approccio non era piaciuto e mi sarei dovuto adattare a quello dei consulenti che hanno lasciato l’azienda qualche anno dopo, in fallimento, e con nessun portale intranet funzionante… dopo 4 anni la stessa azienda ha dovuto riaccendere il sistema precedente , e questo dopo aver speso piu’ del previsto e senza risparmiare alcun costo.
Questo racconto è importante per far capire ai decision maker che un software , come un’app per iPhone o un sito web è frutto di esperienza sul campo e questa non potrà essere mai sostituita da stime dettagliate e del tutto astratte , che spesso costringono al rispetto stretto dei tempi intermedi non curando il senso del progetto stesso.
A mio parere è proprio l’insistenza ,da parte dei top manager, ad adottare modelli di stima basati sul modello finanziario e fondato sul controllo del prodotto che hanno portato l’industria informatica italiana ad una crisi cosi’ profonda che oramai parlare di industria informatica italiana non ha neppure piu’ senso…
Non sono solo agli sviluppatori a far male le stime.
Tutti prima o poi inprovviseranno perché gli sarà affidato un compito che non hanno mai fatto prima e non saranno in grado di effettuare con successo una vera stima fino a quando non hanno acquisito esperienza.
Se non sappiamo, non sappiamo, e dobbiamo dirlo. I clienti o i capi che vedono i progressi compiuti e sono stati messi al corrente del rischio dei task (e hanno scelto di investire ) hanno molto di più fiducia nel proprio team ripetto ai clienti o ai capi che basano il loro controllo su stime.
La stima è una abilità molto importante e dovrebbe essere insegnata sopratutto a figure “junior”
Ciò che dobbiamo fare è insegnare a tutti gli sviluppatori junior il significato della parola “fatto” o “terminato”. Se un cliente o un capo viene a scoprire nel futuro, a un certo punto imprecisato, che qualcosa è stato consegnato incompiuto (possibilmente in fretta per venire incontro alla stima) cio’ non solo rende la stima controproducente, ma rende inaffidabile tutto il calendario di lavoro con l’attuale processo. Questo problema è molto comune, e può causare una significativa perdita della capacità di un team di sviluppo.
Agile Developing
Nessuna grande e consolidata azienda ha avuto risultati straordinari come quelli avuti dalle società create da adolescenti o giovani imprenditori che non avevano, fortunatamente, alcuna idea dei modelli di lavoro , e di pensiero, che erano imposti dall’establishment e dall’economia finanziaria. Pensiamo a Mark Zuckerberg | Facebook, a Larry Page e Sergey Brin | Google, Sean Parker | Napster, Plaxo, Causes e Facebook.. pensiamo a Jeff Bezos, Bill Gates o a Steve Jobs e tanti altri.
Tutti questi personaggi hanno creato il nostro futuro e, con tutta probabilità, non si sono mai adattati (per fortuna!) ai modelli aziendali e alla moda.
Negli ultimi anni , probabilmente a causa degli enormi Flop, tutte le grandi aziende hanno tentato di cavalcare l’onda della new economy e ora si ritrovano a terra, parlano molto di “Agile Developing“.
Il nome “Agile” ci arriva dall’ingegneria del software che differenzia i metodi e i modelli di sviluppo in: Metodologie pesanti per i vecchi metodi basati sul Modello a cascata, Metodologie iterative per i metodi basati sul Modello a spirale e Metodologie agili per i metodi basati sui principi definiti nell’Agile Manifesto.
Leggendo Wikipedia si scopre che il termine “Metodologie Agili” fu coniato nel 2001 proprio quando il Manifesto Agile è stato formulato e che:
” La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, progetto, implementazione, test e documentazione.
Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto”.
Se si utilizza l’approccio agile si dovrà comunicare sempre in tempo reale, preferibilmente faccia a faccia, puttosto che fare report o documenti. Componenti di un team agile sono solo le persone necessarie per portare a termine il progetto.
Mi aspetto che qualcuno mi dirà: bella scoperta , quella dell’acqua calda…
Molto probabilmente parleremo nei prossimi articoli di questo metodo che molte aziende stanno implementando , anche perche’ importato da molte società di consulenza.
