Dimensional Planning nell'Agile

Negli ultimi anni ho notato che parlo sempre più spesso di "Dimensional Planning". Ho scoperto il Dimensional Planning grazie a Koen van Exem, uno dei primi agilisti belgi. Proviene dagli albori del movimento Agile (belga) e purtroppo è un po' caduto nell'oblio.

Ieri ne ho parlato con JB (Rainsberger) e Alistair (Cockburn) e mi sono reso conto che ho ancora una bella storia da raccontare a riguardo.

Prima di raccontarvela, spiegherò brevemente le basi del Dimensional Planning. L'idea di fondo è che suddividiamo le nostre Story in diverse dimensioni di implementazione. Lo facciamo perché molti dei nostri clienti vogliono una Lexus entro la fine della settimana. Ma forse non riusciamo a consegnarla. Tuttavia, possiamo offrire loro una Toyota già domani. La maggior parte dei clienti trova quest'offerta fantastica e può aspettare che siamo in grado di consegnare la Lexus (ovvero un ROI raggiunto rapidamente).

Mi piace molto il modo in cui Koen spiega il Dimensional Planning

Immagina che il tuo cliente voglia un'autostrada tra Amsterdam e Heusden. Sei piuttosto bravo a costruire autostrade, quindi inizi subito. Dopo alcuni mesi hai finito e, pieno di orgoglio, fai usare l'autostrada al tuo cliente per la prima volta. Arriva a Heusden, ma non sembra particolarmente felice. Gli chiedi quindi se le stazioni di servizio, le aree di sosta e le uscite ogni pochi chilometri vanno bene. Anche se il cliente conferma tutto, le tue domande sembrano irritarlo ancora di più. Alla fine sbotta: "Questo non è il posto dove volevo andare!"

Guardi il cartello del paese: Heusden. Non voleva andare a Heusden? Sì, voleva.

Ma si scopre che esiste un altro posto con il nome "Heusden".

I tuoi avvocati e quelli del cliente hanno ora lunghe discussioni su di chi sia la colpa e chi debba pagare per l'autostrada sbagliata. (Se hai un buon avvocato, pagherà il tuo cliente e non tornerà mai più...)

In questo caso si potrebbe lavorare bene con il Dimensional Planning. Si costruirebbe prima una strada sterrata tra Amsterdam e Heusden.

In meno di una settimana avresti già finito e avresti scoperto di aver raggiunto il posto sbagliato. Per te non è un problema, perché sapevi che ci sarebbe stato qualche malinteso. Ti informi, trovi l'altra Heusden e costruisci una nuova strada sterrata. Dopo un'altra settimana anche questa strada è pronta e scopri insieme al tuo cliente che in realtà è ancora la Heusden sbagliata. Ci sono infatti due posti con questo nome in Belgio e uno nei Paesi Bassi. Chi poteva saperlo?

Dopo un'altra settimana il tuo cliente è felice di avere finalmente una strada sterrata tra Amsterdam e la Heusden giusta. (E molto più velocemente di quanto previsto originariamente in diversi mesi.)

Anche se non ci sono ancora tutte le funzionalità, c'è già un certo guadagno da registrare, poiché il cliente può ora spostarsi tra le due sedi della sua azienda. Non è una grande strada e non si può andare particolarmente veloce, ma è molto più rapido della strada precedente con una deviazione di 100 km.

Il giorno dopo il completamento della strada sterrata inizi a lavorare a una versione in ciottolato della strada, che completi in tre settimane. Puoi anche lavorare a una versione in asfalto, catrame o autostrada. Nella maggior parte dei casi, però, i clienti non vogliono più l'autostrada una volta che traggono beneficio dalle versioni precedenti.

Sappiamo tutti che un cliente dirà sempre "Sì" se gli chiediamo se vuole un'autostrada, e che gli sviluppatori adorano lavorare su tutte le funzionalità di un'autostrada.

Nel nostro esempio dell'auto, la maggior parte delle persone preferirebbe anche la Lexus alla Toyota – fino a quando non si tratta di pagare, perché allora improvvisamente anche una Toyota va bene. E allo stesso modo, non tutti gli sviluppatori vogliono pensare costantemente a tutti i dettagli che la Lexus richiede.

Non è costoso costruire tre strade sterrate, una strada in ciottolato, una in catrame e un'autostrada?

Naturalmente è più costoso che costruire una sola autostrada. Sappiamo tutti, però, che gli errori capitano e che è comunque più economico che dover costruire tre autostrade, come succede spesso nello sviluppo di prodotti.

Con il mio metodo ci prepariamo così bene da non commettere mai errori...

Se sei sicuro e vuoi correre il rischio, puoi farlo liberamente. E anche se avrai ragione (dubito che sarà sempre così), sono abbastanza sicuro che la maggior parte dei clienti avrà già cambiato idea quando inizierai a costruire l'autostrada. E mesi prima che tu abbia anche solo iniziato a costruire, le nostre strade sterrate generano già un ritorno sull'investimento.

Suona bene in teoria. Ma funziona davvero nella pratica?

Buona domanda! Quasi dimenticavo: volevo presentare un bell'esempio dalla vita reale in questo articolo.

Ho modificato alcuni dettagli della storia per proteggere il cliente.

Si tratta del sito web di un'azienda. Questo si trovava però in una zona completamente demilitarizzata della rete aziendale. Lì era stato creato un piccolo prodotto da vendere tramite Internet. Il Chief Financial Officer (direttore finanziario) era un grande sostenitore di questo prodotto e voleva ricevere regolarmente i dati sulle vendite. Per farlo, però, si sarebbero dovute violare le zone di sicurezza e inserire i dati di vendita nel sistema SAP.

In una grande azienda questo è un progetto piuttosto grande, che richiede sicuramente sei mesi di lavoro di sviluppo. I preparativi iniziarono con riunioni con almeno 20 persone (esperti di sicurezza, esperti SAP, sviluppatori web e un sacco di manager fino alla posizione appena sotto il CFO).

In una riunione successiva, il CFO si lamentò della scarsa visibilità dell'andamento delle vendite del prodotto nei primi sei mesi cruciali. Raccomandai quindi dei progetti collaterali temporanei utilizzando il Dimensional Planning (come nell'esempio dell'autostrada).

La versione strada sterrata:

Ogni giorno generavamo un report PDF sul web server e lo salvavamo su un floppy disc. (Ricordiamo che gran parte della rete non era collegata al server.) Ogni giorno stampavamo questo report e portavamo una copia dei dati di vendita nell'ufficio del CFO, dove uno stagista inseriva tutti i dati nel nostro sistema SAP. Il report PDF fu creato da uno dei nostri sviluppatori lo stesso giorno in cui il prodotto andò live. Alla fine della giornata avevamo già i dati per il CFO.

Il primo problema: il CFO voleva qualcosa in più; qualcosa che doveva essere chiesto al cliente sul sito web. Lo sviluppatore aveva mostrato con orgoglio il report al CFO e tornò al suo posto di lavoro. Mezz'ora dopo, sul sito web veniva richiesta l'informazione aggiuntiva e il nuovo report era pronto (senza i dati del primo giorno). Il giorno dopo uscì un articolo su un giornale e molti clienti comprarono il prodotto. Il giorno successivo arrivarono già i primi numeri e il nostro stagista cercò di trasferire i dati nel sistema SAP. Qui scoprimmo la nostra seconda Heusden. Si rivelò infatti che stavamo usando la tabella SAP sbagliata. Ci vollero alcuni giorni per correggere questo errore. Il CFO continuò a ricevere il suo report, ma nella prima settimana non fu possibile farlo con SAP. Il venerdì della prima settimana, lo stagista fu in grado di caricare i dati. Tuttavia, era un lavoro piuttosto noioso che non era affatto scalabile. (Avevamo alcune migliaia di vendite nella prima settimana.) Ora era il momento della nostra:

Versione ciottolato:

Questa volta creammo il report in formato CVS. (Ricordiamo che era prima dell'XML.) Ogni mattina lo sviluppatore che arrivava per primo in ufficio andava al web server, generava il report e lo copiava su un floppy disc. Poi prendeva il disco e caricava i dati nel nostro sistema SAP. Questa versione era più scalabile; indipendentemente da quanto avessimo venduto il giorno prima, il lavoro per il nostro sviluppatore rimaneva lo stesso. Ma anche in questa versione avevamo un piccolo problema. Uno dei campi era formattato come testo invece che come numero. (Un bug del tutto normale.)

Il lavoro doveva essere svolto personalmente ogni giorno da qualcuno. Non era automatizzato e veniva aggiornato solo una volta al giorno (per il giorno precedente).

Poi iniziarono le riunioni per la versione autostrada. Alla fine di una di queste riunioni, chiesi a un collaboratore del CFO come utilizzavano i dati e se erano soddisfatti dei numeri. Per puro caso notai che il CFO guardava i dati solo il venerdì. (Quindi non quotidianamente.) Non gli importava nemmeno di non avere i dati completi sulle vendite del giorno o della settimana.

La versione autostrada:

Fortunatamente, il giorno dopo avevo comunque una riunione con il CFO e il suo collaboratore. Parlammo dei progressi del progetto autostrada e del fatto che in realtà impediva alle persone di lavorare a un altro progetto importante. Proposi educatamente di rimanere con la versione ciottolato e di mettere in pausa il progetto autostrada. Molte persone in azienda non ne furono molto contente, perché volevano tanto lavorare a quel progetto super interessante. Il Security Officer, tuttavia, ne fu molto felice, perché così il web server poteva rimanere nella zona sicura. Alla fine, l'azienda risparmiò sei mesi di lavoro di sviluppo per un'autostrada che avrebbe messo in pericolo la rete e che non sarebbe stata realmente necessaria.

Dopo alcuni anni incontrai di nuovo il CFO. Ammise che il progetto autostrada sarebbe stato eccessivo, poiché il prodotto non aveva mai nemmeno lontanamente generato tanti soldi quanti ne sarebbero stati necessari per il progetto autostrada. Grazie al progetto strada sterrata poterono scoprire abbastanza presto che mancavano ancora gli indirizzi email dei clienti, e quella fu la cosa migliore che potesse capitare. Con quella mailing list riuscirono a vendere diversi altri servizi ai clienti negli anni successivi, e questo salvò l'azienda dal fallimento.

Questo testo proviene dal blog di Yves Hanoulle ed è stato tradotto in italiano.