on Agile Methodologies and Programming
Stimolato dal professore l’ho fatto anch’io. Di solito i risultati di questi test su di me funzionano poco, quando facevo il militare ci facevano regolarmente dei test attitudinali/caratteriali/? e regolarmente su 12 profili possibili io risultavo appartenere in egual misura a 6/7 profili contemporaneamente… :-)
My Political Views
I am a centrist social moderate
Left: 0.14, Libertarian: 0.95
Oggi ho visto l’ennesimo strepitoso intervento di Eric Ries a proposito della pratica del MVP (Minimum Viable Product). Il problema è molto chiaro: la nostra vision di prodotto potrebbe portare ad un business non sostenibile; la strategia proposta lo è altrettanto: trovare il minimo set di funzionalità in grado di poterci dare un feedback reale sulle esigenze dei nostri utenti e in che misura il nostro prodotto le soddisfa.
Maggior conoscenza acquisiamo sui nostri utenti, maggiori saranno le probabilità che la prossima funzionalità pensata/implementata sarà apprezzata (aumentando il valore dell’applicazione). Minore sarà il tempo/costo d’implementazione di una nuova funzionalità, maggiori saranno le funzionalità che potremmo utilizzare per acquisire conoscenza sui nostri utenti
Cosa possiamo fare per minimizzare i tempi/costi d’implementazione? Chiaramente possiamo intervenire da un punto di vista tecnico migliorando la nostra capacità di produrre software, mantenendo sempre pulita la nostra base di codice, migliorando costantemente gli aspetti di project automation e di autonomation, ecc… insomma avete capito
L’altra cosa che possiamo fare è splittare in maniera creativa ed aggressiva le user story esistenti del prodotto. Prima possiamo iniziare a selezionere un minimo set di user story in grado di dare dignità di prodotto al nostro progetto, poi possiamo iniziare a considerarle singolarmente e a capire cosa possiamo togliere da ogni user story conservando la possibilità di poter utilizzare il risultato come MVP
Un esempio? Avevo 10 giorni (nessuna domanda please sul perchè di questo numero magico…) di tempo per realizzare un’applicativo piuttosto complesso, ovviamente c’era di mezzo uno storage, ovviamente il cliente aveva richiesto un’interfaccia di amministrazione/gestione di questo storage e ovviamente non aveva tralasciato nessun “goodies”: utenti, gruppi, ruoli, permessi, editing, viste configurabili sui dati, ecc… praticamente mi sarebbero serviti molti più giorni di quelli a disposizione solo per questa parte accessoria del sistema. Volevo iniziare dal vero prodotto, ma volevo anche che il cliente lo potesse utilizzare da subito, così ho installato phpMyAdmin e ho fatto vedere al cliente come utilizzarlo: ho creato utenti, viste, maschere, ecc… alla fine il cliente mi ha detto che è esattamente quello che voleva :-D Ok, sono stato fortunato, ma è stata una vera epifania
Un’altro esempio un po’ più creativo? Kent Beck qualche hanno fa ha tenuto un workshop sullo split delle user story usando un esempio alquanto “ardito”: il gioco del tetris… qual’è secondo voi la prima user story per Beck? Una colonna, un quadratino 1×1 che scende a velocià costante, quando un quadratino tocca il fondo parte un altro quadratino, il nuovo fondo è il quadratino precedente, quando il fondo arriva in cima alla colonna “game over” :-D
Ancora una volta una conferma del fatto che il business (il problem team come lo chiama Ries) e la tecnologia (solution team) non si possono/devono ignorare a vicenda
Qualche settimana fa ho capito una cosa tanto semplice quanto per me importante, il miglioramento della produttività applicando una metodologia Agile si ottiene su due fronti
L’obiettivo supremo è sempre quello di massimizzare la quantità di valore consegnato nell’unità di tempo e in subordine la capacità di produrne in futuro, il resto sono chiacchere
E’ un concetto estremamente semplice, ma estremamente efficace se dovete introdurre a qualcuno le pratiche proprie delle metodologie Agili. Detto questo però se avete poco tempo a disposizione per catturare l’attenzione di qualcuno, se dovete fare un elevator pitch, vi serve qualcosa di molto immediato, vi servono delle metafore
Negli ultimi due anni ne ho raffinata una per spiegare come funziona la pianificazione e visto che è risultata essere particolarmente efficace la condivido con tutti, la scrivo come la racconto di solito
Supponiamo che dall’altro lato di quella porta (nda. di solito c’è una porta nelle vicinanze :-)) ci sia un team di programmatori che deve iniziare un progetto per il quale sono necessarie determinate conoscenze, queste conoscenze possono essere acquisite attraverso lo studio di alcuni libri, il vostro compito è quello di fornirglieli
Il materiale che vi viene dato consiste in 15m^3 di libri e di uno scatolone di 10m^3, se vi state chiedendo “esiste una metodologia in grado di far entrare 15m^3 di libri in uno scatolone di 10m^3?” la risposta è no! Anche le metodologie Agili non fanno eccezione :-)
Quindi cosa facciamo? Se seguissimo alla lettera i vincoli che ci sono stati dati e se non fossimo abbastanza svegli da misurare i volumi che abbiamo a disposizione, probabilmente spenderemo la maggior parte del nostro tempo a tentare di organizzare i libri per riuscire a farceli stare tutti nello scatolone. Una volta arrivati in prossimità della scadenza ficcheremo il maggior numero possibile di libri all’interno dello scatolone per poi spingerlo finalmente al di là della porta dove ci sono i programmatori che lo aspettano
Evidentemente non è una strategia molto furba… come possiamo migliorarla? Ci chiediamo: “qual’è il reale obiettivo di questo lavoro?” Massimizzare al quantità di conoscenza da passare al team di programmatori che sta al di là della porta, “la quantità di conoscenza erogata è indipendente dal libro?” Ovviamente no, quindi una cosa che possiamo fare è scegliere i 10m^3 di libri in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che la scelta delle user story da implementare è il primo passo verso la massimizzazione del flusso di valore)
Bene, possiamo migliorare? Ci chiediamo “ogni capitolo all’interno di un libro eroga la stessa quantità di conoscenza?” Nella maggior parte dei casi no, sicuramente non erogano conoscenza le copertine cartonate, le prefazioni, i ringraziamenti, ecc… Quindi possiamo procedere con un approcio creativo e stracciare ogni libro tenendo solo i capitoli migliori e quindi scegliere i 10m^3 di materiale in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che splittando le user story possiamo prendere la maggior parte del valore minimizzando il costo)
Ottimo! Possiamo ancora migliorare? Ci chiediamo “chi è che decide la quantità di conoscenza erogata da un testo?” Fino a questo momento siamo stati noi ma effettivamente è un assunto grave, cosa succederebbe se avessimo torto? La nostra strategia sarebbe ancora valida, ma le nostre misurazioni sarebbero pura speculazione, non possiamo essere sicuri di aver realmente erogato la maggior quantità di conoscenza possibile. “chi potrebbe valutare con maggiore accuratezza?” Sicuramente il team di programmatori che sta dietro alla porta
Quindi possiamo essere ancora più creativi e possiamo chiedere di barattare lo scatolone da 10m^3 con 10 scatoloni da 1m^3, nel primo scatolone ci mettiamo quello che noi riteniamo essere il miglior metro cubo di materiale possibile e lo spingiamo fuori dalla porta chiedendo ai programmatori di chiamarci una volta letto tutto. Quando i programmatori ci chiameranno chiederemo il loro feedback sul materiale, sulla base di queste informazioni sceglieremo cosa mettere nel prossimo scatolone. In questo modo non solo avremo una corretta valutazione del valore consegnato, ma abbiamo anche la possibilità di adattarci al contesto del progetto (nda. in questo caso stiamo dicendo che le funzionalità individuate all’inizio del progetto e la stima di valore che ne viene fatta è nella maggior parte dei casi errata e che quindi serve un reale strumento di feedback)
Secondo me funziona bene perchè
Cosa ne pensate? Possiamo ancora migliorare? :-)
Dopo aver letto un bel po’ di cose sull’argomento, questa è una perfetta sintesi
- The customer is the most important thing in your business
- The best business plan is to sell people the things they want
- Your business is successfull if your earnings are higher than your spendings
Troppo spesso le startup vengono fondate su una vision di progetto che esiste solo nelle menti degli stessi fondatori, Eric Ries dice sempre nelle sue presentazioni “vision not delusion”, che potrebbe anche essere “vision not illusion”. Il compito principale di una startup è quello di validare/raffinare nel più breve tempo possibile la propria vision di progetto confrontandosi con l’unica fonte di verità: gli utenti
VC: “Interessante la vostra idea, potete mostrarci il vostro business plan?”
Startup: “Inizialmente avevamo questo set di funzionalità, poi abbiamo eliminato queste funzionalità ed abbiamo aggiunto queste altre e siamo passati da X utenti a 3X utenti, a partire da questa informazione abbiamo modificato il nostro posizionamento nel mercato, abbiamo validato queste informazioni passando da 3X utenti a 10X utenti aggiungendo queste altre funzionalità in accordo con quanto avevamo scoperto. Ora ci aspettiamo di raggiungere i 100X utenti, quindi una revenue di Y, togliendo queste funzionalità e aggiungedo queste altre nei prossimi 2 mesi”
Questo è un business plan nel quale metterei dei soldi…