Tuesday, November 14, 2006 

Slip Charts

Software development is a learning process, yet we are often asked for early estimates. In several cases, those estimates turn out to be wrong, because we didn't have enough information. In pathological companies, estimates are considered promises. In more enlightened (should I say realistic :-) companies, estimates are periodically reframed.
It's very common for early estimates to be overoptimistic, so when we review an estimate it's usually to add more effort. Unless we can shrink requirements, or unless we can find a smarter way to satisfy requirements (which is usually what I try to do), we have to postpone delivery.
When the project has high complexity and high uncertainty, it's not uncommon to slip several times, as more and more knowledge is gained. Of course, at some point we have to understand if we are going somewhere, or if we simply don't know how much it's gonna take. A useful, cheap, and simple way to get a better understanding of slippage is to draw a slip chart. You simply add one point every time you review your estimate. On the x axis, you have the current date; on the y, you have the expected delivery date.

Here is a real slip chart (from a real project)

as you can see, after less than one month, the estimate was increased by about one month. Then it remained fixed up, to delivery. After a few reviews, the confidence in making the deadline increases.

Here is another real slip chart (same product as above, but different project):

now, that's a troubled project. The team is learning a lot along the road, but not enough to give better estimates. As you can guess, it wasn't really finished when it was declared finished.

Although learning to read a slip chart (and its counterpart, the slip/lead chart) is easy, if you want to squeeze every ounce of information from the chart, I suggest that you read an excellent book from Gerald Weinberg, "Quality Software Management Vol. 2". Well, if you're any serious about software project management, you probably want to read all the 4 volumes anyway :-).

Note: looking at the slip chart can give you precious information, but information without action is useless. Now, action is always context-dependent. For the real project above, my suggested action would have been (I've seen the slip charts too late) at least to exclude the project from the next delivered version of the product, and possibly to schedule a design review to understand what was really going on. Of course, removing a single project from the next version of a requires some configuration management discipline (which was in place), and in this case it certainly mandates that the development had to be done outside the baseline (so, sorry, no continuous integration).
But then, when you have high technical uncertainty, continuous integration is not necessarily a good practice (quite the opposite, I would say). Continuous integration is good when you have high uncertainty on functional requirements, because you can (ideally) get early feedback from users. It's also good for low-uncertainty projects, because in this way you don't add additional uncertainty (from late integration). But it's not a silver bullet, and should not be applied blindly "by the book".

Labels: ,

Comments:
PCPNSDS - Povere considerazioni personali nello sviluppo del software

Che si tenda a sforare i tempi previsti per la realizzazione di un progetto è all'ordine del giorno. Se abbiamo svolto programmazione non semplicemente a scopo didattico, ma per soddisfare qualche esigenza "real life" - come si ama dire - beh allora ci siamo resi conto subito che per progetti poco più che banali si tende a disattendere le date di consegna. Ovviamente perché tanti fattori incidono sul completamento entro i termini attesi.

Prima di tutto nelle stime non viene considerato a sufficienza il fattore umano (salute, defezioni, sovrastima degli skills, turn over, ecc. ecc.).

Non capita quasi mai che qualcuno annunci di aver ultimato in anticipo un prodotto poiché favorevoli congiunture ne hanno consentito il prematuro completamento (i.e. una vincita inaspettata di codice sorgente, che faceva proprio al caso nostro, da innestare senza problemi nel prodotto che stavamo realizzando :-). Le botte di c..o capitano solo nei nostri sogni...

Perché nelle stime non si considerino a fondo i fattori di rischio che porteranno a ritardi non lo so. O forse si. Di solito si tende a fornire al marketing tempi di consegna non troppo dilatati perché altrimenti i progetti, che tanto stimolano la nostra creatività, verrebbero ridimensionati oppure differiti (= cestinati).
 
Rimanendo strettamente sul fattore umano (inteso come ferie, necessita' di spostarsi con urgenza su altri progetti, ecc), ne parlavo in un post di qualche tempo fa mostrando come si entri facilmente in loop.
Va detto pero' che:
- da un lato, un management che non conosce la reale capacita' produttiva dell'azienda non potra' prendere decisioni corrette. Qualche piccola misura aiuterebbe tantissimo, tuttavia sono ancora poche le aziende che misurano (e quando misurano, spesso peccano nel versante opposto, di voler tracciare troppo [perdendo di realismo]). Ne parlavo, appunto nel post di cui sopra.
- dall'altro, gli sviluppatori sono troppo pavlovianamente condizionati a promettere l'impossibile per essere ritenuti "bravi". Qui c'e' veramente un gran bisogno che gli sviluppatori acquisiscano maggiori conoscenze di management, anche se non sono manager (d'altra parte, gli sviluppatori non vorrebbero forse che il management comprendesse i reali problemi dello sviluppo?).
- dall'altro ancora, le stime hanno una incertezza intrinseca, occorre imparare a gestirla correttamente. Le slip chart sono utili proprio per visualizzare un trend e capire meglio che sta succedendo, dopodiche' bisogna agire...
Solo una parola sul fatto che i progetti verrebbero ridimensionati: sarebbe giustissimo, e sarebbe compito nostro aiutare il marketing a trovare il miglior punto di equilibrio tra costo e valore, creando progetti che si autofinanziano il prima possibile.
A concetti analoghi accennavo in un altro vecchio post
 
Come sempre i commenti sono ottima occasione per ulteriori approfondimenti e/o rispolverare vecchi argomenti, dato che non per tutti la memoria ha una capacità di ritenzione illimitata...

Aggiungo solo un'altra povera riflessione.

Spesso il successo di una cosa sembra frutto più di minori errori nell'agire che di maggiore perizia e conoscenza sul da farsi.

Mi vengono in mente le sperimentazioni in campo medico...
 
un management che non conosce la reale capacita' produttiva dell'azienda non potra' prendere decisioni corrette

E' molto difficile che i manager sappiano con precisione "quanto" produce uno sviluppatore o un team. I numeri cambiano da progetto a progetto. Credo che sia compito degli sviluppatori comunicare la propria produttivita' momento per momento, con un piccolo sforzo possono fornire misure molto utili.

gli sviluppatori sono troppo pavlovianamente condizionati a promettere l'impossibile per essere ritenuti "bravi"

Esatto, capita spesso. Ed e' ridicolo perche' cio' che si chiede loro e' un comportamento piu' "normale" possibile.
Alla fine i "bravi" sono quelli che rispettano i tempi, ed e' una cosa difficile da capire (digerire) da parte di molti sviluppatori.
 
Sono sicuramente d'accordo sull'utilità degli slip chart, vorrei però aggiungere la mia opinione sugli ultimi commenti che
non mi trovano invece del tutto d'accordo.

Innanzitutto non ritengo che necessariamente le stime debbano cambiare (aumentare) nel tempo; a mio avviso, nella maggior
parte dei casi le stime variano poichè variano i requisiti. Che poi in ogni progetto di complessità non banale i requisiti varino nel tempo è un altro discorso, ma questo non implica che la stima iniziale non fosse corretta e/o attendibile.

Semplicemente bisogna prendere atto che cambiando i requisiti si incide sul "triple constraint" di un progetto, e possibilmente adottare una buona metodologia di sviluppo che ci permetta di assorbire i cambiamenti al meglio.
E' d'altronde superfluo sottolineare che in taluni casi non si può assolutamente aumentare la stima di un progetto poichè magari altri vincoli (aggressione del potenziale mercato, lanci pubblicitari, ecc...) ci impongono di rispettare la data
finale pena il fallimento del progetto (o un notevole ridimensionamento degli introiti).

La prima eccezione porta ovviamente a corredo un'altra banale(?) considerazione: le stime devono essere state fatte da un
bravo professionista. E, prendendo spunto da un'intervista di Parnas, nel nostro settore non abbiamo bisogno di sviluppatori,
ma di bravi sviluppatori. Qui si potrebbe innestare tutto un lungo discorso sul fatto che i bravi professionisti devono essere pagati per quel che valgono e che al momento in Italia non mi sembra che ci sia una corsa al rialzo delle tariffe (anzi...) per accaparrarsi i migliori professionisti sul mercato... eppure nessuno si meraviglia, se ad es. un bravo medico per una visita di 1/2 ora chiede 150 euro... ok, sento già Carlo che mi ricorda di non sconfinare in considerazioni politiche e simili e quindi chiudo la parentesi.

Aggiungo solo un paio di ulteriori note. Sul fatto che sarebbe auspicabile che gli sviluppatori conoscessero un minimo di
project management sono completamente d'accordo. Sarei ancora più d'accordo però sul fatto che chi è realmente addetto a
svolgere il ruolo di project manager facesse bene il suo lavoro, magari anche facendo preliminarmente l'analisi dei rischi (quantitativa e qualitativa, a voler esagerare?).

Finisco sottoscrivendo in pieno quando Carlo dice "Solo una parola...". Quanti dovrebbero leggere e fare tesoro di quella
frase...
 
michele:nel nostro settore non abbiamo bisogno di sviluppatori,
ma di bravi sviluppatori.


Questa frase mi ricorda un po' l'altra "siamo sotto organico". Così come non ho mai visto un'organizzazione che fosse ad organico (sono tutte da gravemente a insopporttabilmente sotto organico nella lora valutiazione - la mia è disperatamente sotto organico), tutte le organizzazioni non hanno bisogno di di tanti X, ma di pochi bravi X.

Però quelle che sopravvivono sono quelle che possono accontentarsi di "un po' di mediocri X" (purtroppo, ma sic transit gloria mundi.)

E d'altra parte, con la corsa a pagare la gente sempre meno, si possono tenere solo i mediocri o le anime belle (che pure hanno i loro problemi). In questo concordo con Michele, ma non mi pare ci possa far niente, almeno finchè non ci trasferiamo tutti,armi e bagagli a bangalore (a meo che nel frattempo non si cominci a far software in SzeChuan).

sax
 
X saxappeal: in realtà si potrebbero fare tante cose, ma tutte esulano da discussioni essenzialmente tecniche come è invece nello spirito di questo blog. Certo sono d'accordo che non sia facile, ma come mi piace ripetere, mutuando la frase dal mondo della finanza, "nessun pasto è gratis".
 
ci trasferiamo tutti,armi e bagagli a bangalore

Lavoro anche con colleghi di Bangalore, e sto tanto bene qui.
 
Provo a dare una risposta cumulativa.

Citrullo: nota che io non parlo quasi mai di "produttivita'" perche' e' un termine su cui e' difficilissimo intendersi, in quanto e' legato da un lato alla singola persona, dall'altro al problema che sta affrontando la singola persona. In questo senso contingente preferisco parlare di progresso, ed a questo punto hai ragione, e' compito degli sviluppatori comunicare il proprio progresso e discutere con i manager come proseguire.
Resta invece vero che i manager devono, a preventivo, fare i conti con la realta' (che include ferie, possibilita' di malattia, probabilita' o certezza che le persone non siano al 100% sul progetto, ecc). Qui qualche piccola misura storica puo' aiutare a creare piani piu' realistici.

Michele: siamo quasi sempre d'accordo su questi temi :-). Aggiungo solo alcuni chiarimenti.
Sicuramente una stima che cambia perche' cambiano i requisiti non era "sbagliata". Tuttavia le stime sono talvolta errate perche' risolvendo il problema [che non cambia] ci si rende conto che alcune assunzioni non erano vere. Questo capita con facilita' nella manutenzione di software complesso, ma anche quando esistono requisiti prestazionali stretti e pochi metodi quantitativi per calcolare a priori se l'idea ipotizzata funzionera'.
In generale, cio' che e' sbagliato in questi casi e' pretendere che non ci sia incertezza, sparando un numero piu' o meno calcolato, piu' o meno stimato, piu' o meno in linea con quello che altri sono disposti ad accettare.
Non a caso anche nell'approccio BetterEstimate suggerisco di dare una stima come range [min, max], ma di dare anche una stima di confidenza su min e max [anche perche' molte persone preferiscono dare un range stretto (di cui non sono molto sicuri) piuttosto che un range ampio di cui sono certi].

Sax: per ragioni imperscrutabili :-) cio' che scrivi mi ricorda una cosa detta da un personaggio che non amo particolarmente, ma che nello specifico mi era piaciuta abbastanza da farmi strappare il foglio dell'intervista (per tenerlo). Diceva piu' o meno "non e' la Cina a fare concorrenza a noi, siamo noi a fare concorrenza alla Cina continuando certe produzioni manifatturiere".
Ora, e questo fa il pari con quel che dice Michele, non si tratta di spostarsi in Cina, in India, ecc, ma di rendersi conto che certe figure professionali sono sempre meno interessanti. Il nerd lo troviamo ovunque. L'ingegnere in costante antagonismo verso l'azienda, verso il marketing, verso il management, ecc, anziche' vedersi aumentato lo stipendio ha un clear and present danger di vedere il suo ruolo ricoperto da un indiano altrettanto bravo e meno rompiscatole. I bravi progettisti, che capiscono che la progettazione e' un'arte complessa e sempre piu' innestata con la concezione del prodotto e quindi anche con il marketing, difficilmente si troveranno in difficolta'...

Tornando un istante su quel che diceva Michele, siamo tutti [credo :-)] d'accordo che un management realmente competente sia una assoluta necessita' non tanto per sopravvivere (come diceva Sax, qui basta un tot di mediocrita') ma per prosperare, che e' un obiettivo piu' interessante :-)). E qui finisce davvero che si va nella politica, perche' non a tutti piace l'idea della prosperita' :-))) [non andro' oltre nemmeno se punzecchiato :-)].
 
Post a Comment

<< Home