Levels of Software Success
November 8th, 2007 by 
Enri
Riporto qui dal WIKI c2 la definizione di successo di un progetto Software. In particolare mi interesserebbe sentire da voi la vostra esperienza riguardo i punti 4,5,6. Ad esempio: li avete come obiettivi o credete che non debbano riguardare il team di sviluppo? E’ possibile secondo voi raggiungerli? Quali strumenti adottate per facilitarvi? Come riuscite ad ottenere del feedback sul raggiungimento degli stessi? In che modo collaborate con il business per raggiungerli?
Particolarmente affascinante e motivante il punto 6: non accontentiamoci di consegnare piu’ valore di quanto costiamo, ma cerchiamo di organizzarci in modo da consegnare quanto piu’ valore sia possibile con le risorse a disposizione!
There are increasingly broad ways to judge the success of a software project.
- Works well enough to be used.
- Can be maintained and improved.
- Does what the stakeholders want.
- Provides value to the organization.
- Provides more value than it cost.
- Provides more value than any other use of its resources could have.
Success at each level trumps failure at the previous level, so an unmaintainable piece of software that isn’t usable but still provides value to the organization has achieved level 4. An example of this is a piece of demo-ware that’s used to get a round of funding and thrown away afterwards. For most software, though, success at lower levels is necessary to achieve success at higher levels. For a project to be minimally successful, it has to achieve level 5. Developers doing ExtremeProgramming focus on levels 1, 2, and 3. They count on the customer to attend to levels 4, 5 and 6. Other methodologies focus on level 3, too. In fact, they didn’t even say much about levels 1 and 2. They count on the programmers and the stakeholders to achieve the other levels. And we all know how that turns out: lots of projects that don’t even function, or can’t be maintained. The neat thing about XP was that it brought levels 1 and 2 into the equation.
With XP, software is actually getting built and is maintainable. But the picture won’t be complete until we bring levels 4 and 5 in as well. If we truly want to be excellent, we need to include level 6.
Posted in General | 
November 8th, 2007 at 11:36 am
Io come al solito ragiono al contrario, cerco sempre di dare il massimo del valore possibile con le mie capacità, spesso e volentieri il valore poi si rivela perfino superiore alle aspettative e l’esperienza mi insegna che il valore investito col tempo ritorna.
November 8th, 2007 at 5:48 pm
Mi piace la scala di valutazione proposta, a parte forse il punto 6, che ha una definizione così assoluta che può essere solo un desiderio a cui tendere
Invece non sono pienamente d’accordo col dire che XP si ferma al livello 3.
Per me la pratica del WholeTeam(che effettivamente all’inizio nell’elenco delle pratiche aveva il nome è più riduttivo di customer on site) è lì proprio per puntare più in alto della semplice applicazione “fatta come il cliente ha detto”.
November 9th, 2007 at 9:15 am
D’accordo con Fabio. Non sono sicuro che siano veramente livelli sequenziali. Un’applicazione che “fa quello che il cliente desidera” ed è usabile ha più valore di un’applicazione che è usabile ma non fa quello che il cliente vuole, indipendentemente dal fatto che sia più o meno manutenibile.
E poi: questi criteri di successo non sono veramente binari. Usabile, Manutenibile, Corrisponde ai desideri dell’utente sono tutte misure fuzzy. E i livelli 4,5,6 sono difficili o impossibili da misurare. Soprattutto il mitico “non avremmo potuto guadagnare di più in nessun’altra maniera” non si può misurare in alcun modo.
November 9th, 2007 at 9:23 am
Ti dirò di più: il livello 6 si può raggiungere solo se oltre a essere bravo sei anche fortunato. Perché lo stakeholder fa un investimento quando ti commissiona il lavoro, e non è detto che, ragionando a posteriori, si possa dire che l’investimento sia stato saggio. Magari investi in un prodotto che qualcuno aveva già pronto ed è uscito prima di te. Magari quella che sembrava una buona idea non piace.
November 12th, 2007 at 8:31 am
D’accordo con Fabio.
Idem. Vedi ad esempio il lavoro di Francesco con Easy Tracking 2.
D’accordo con te anche sul fatto che il modo in cui Shore ha espresso il concetto è migliorabile (vedi la possibile interpretazione binaria che ci lascia un po’ interdetti).
Ad ogni modo l’idea di fondo che mi ha spinto a scrivere il post riportando il pensiero di Shore la condivido: il team tutto dovrebbe essere reso partecipe degli obiettivi ultimi ai quali mira chi ha commissionato la costruzione del software e tenerli sempre ben presenti (=misurati?) in ogni fase dello sviluppo. Obiettivi ultimi espressi dai livelli 4,5,6. Sono d’accordo che a volte sia difficile misurarli, ma questo è dovuto in primo luogo alla scarsa esperienza che abbiamo come sviluppatori a pensare in termini di Valore rilasciato, dovuta anche ad una interazione business men / dev men che spesso è migliorabile, ad esempio condividendo i dati finanziari in possesso dei primi e interpretandoli alla luce di quanto rilasciato. Fino a quando questo aspetto non avrà raggiunto una maturità simile a quella di altre pratiche, non mi sentiro’ di poter dire che è impossibile misurare quegli aspetti nel software.
Come per ogni metrica per ottenere del feeedback efficace e utilizzabile per migliorare, è nesessario che la misura venga presa in modo regolare isolando i vari ambiti, cosi’ da cercare di ridure la complessità delle relazioni causa-effetto. Se ad esempio si misurerà il valore ritornato dal prodotto dopo qualche anno e dopo svariate release, interpretare i dati ricavando insegnamenti utili potrebbe essere molto complicato, se non impossibile. L’esempio che fai e che tira in ballo aspetti di marketing sarebbe analizzabile rilasendo alla causa solo con dati economici alla mano presi regolarmente.
Il fatto che alle varie conferenze XP sia raro trovare degli speech su questi aspetti mi fa pensare che ci sia ancora molto da esplorare. La Poppendieck è sicuramente tra i piu’ attivi in questo ambito e anche Beck spesso punta molto l’attenzione sugli aspetti piu’ di Business. Non ci resta che sperare in Francesco e nel suo Easy Tracking 2.
Credo questo sia uno degli aspetti principali su cui migliorare XP e i metodi Agili.
Per chiarire comunque anche io penso che l’obiettivo 6 sia impossibile da misurare, credo comunque che possa essere utile come obiettivo motivante ad incrementare costantemente la comunicazione e la condivisione dei dati biz-dev.
November 14th, 2007 at 11:51 am
Faccio un esempio reale accaduto qualche giorno fa.
Premetto che ci occupiamo di direct marketing.
Ci viene richiesto di implementare una feature per selezionare dei
“buoni clienti” che avranno la possibilità di ricevere un premio se
acquisteranno nel prossimo periodo.
Piccola analisi del problema, ed effettuiamo una stima. A questo punto
se gli obiettivi 4, 5 e 6 (vedi email sotto) non fossero considerati
come obiettivi
importanti da raggiungere da parte del team di sviluppo, si
incomincerebbe a sviluppare e stop.
Invece la volontà di fornire piu’ valore di quanto costi la feature ci
ha spinto a fare un’analisi sui dati in produzione per comprendere a
grandi linee il ritorno di investimento della feature stessa: quale
campione sarebbe toccato dalla manovra di marketing? Quali probabilità
ci sono che quel campione reagisca a tale manovra effettuando la
spesa? Quali sarebbero i ricavi per ogni utente che reagirebbe?
Queste tre domande e le relative risposte cercate con il cliente ci
hanno permesso di arrivare ad un numero che ci ha dato la
consapevolezza del valore della feature che andavamo ad implementare.
A volte queste analisi possono portare a decidere di non sviluppare la
feature stessa o di cercare strade alternative con soluzioni piu’
semplici o con software usa e getta.
Altre volte analisi di questo tipo ci hanno portato a trovare
“problematiche” prima oscure al cliente.
Credo che spesso si possano fare queste analisi e credo che siano
molto potenti per effettuare scelte che altrimenti sarebbero miopi
perchè non guidate dall’obiettivo ultimo del nostro lavoro.
“Se non quantifichi non capisci”: vale soprattutto per le zone dove
abbiamo molto da imparare.
Altre esperienze?
Possiamo pensare a queste analisi come ad una pratica che ogni team XP
dovrebbe coltivare? Personalmente credo di si’.
November 16th, 2007 at 8:31 am
Con l’esempio ho capito meglio il nocciolo della questione
Queste analisi sono importantissime.
Come sai il mio approccio è proprio quello dell’80-20, l’80% dell’automazione di un processo ti costa il 20% il restante 20% costa l’80%.
Tuttavia per quel 20% si possono comunque fornire, a basso costo, degli aiuti all’operatività manuale, che di fatto portano il processo a coprire il 100% delle casistiche.