Ecco la presentazione che ha accompagnato il mio intervento venerdì scorso all’Italian Agile Day. Incredibilmente anche stavolta ce l’ho fatta in tempi che non richiedono la datazione al carbonio-14.
Ieri Italian Agile Day 2009. Grande affluenza, grande curiosità . Alle domande “chi usa qualche metodo agile?” poste al pubblico fra un talk e l’altro le mani alzate sono ancora poche, pochissime, ma l’alta partecipazione di ieri è un segnale di tendenza favorevole. E va bene così.
Della mia giornata – che lascia ancora una volta frustrato il desiderio di ubiquità – questi sono stati i momenti decisivi. continue reading »
Ringraziando la simpatica compagine di bit Time per la simpatia e l’accoglienza durante lo svolgimento di ITDevCon 2009, pubblico – stavolta entro i 6 mesi! – le slide che hanno accompagnato il mio intervento.
To benefit from engaging with users you have to be willing to change your idea. We’ve always encouraged founders to see a startup idea as a hypothesis rather than a blueprint. And yet they’re still surprised how well it works to change the idea.
Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.
Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum:
When someone is determined, there’s still a danger that they’ll follow a long, hard path that ultimately leads nowhere.
You want to push forward, but at the same time twist and turn to find the most promising path. One founder put it very succinctly:
Fast iteration is the key to success.
One reason this advice is so hard to follow is that people don’t realize how hard it is to judge startup ideas, particularly their own. Experienced founders learn to keep an open mind:
Now I don’t laugh at ideas anymore, because I realized how terrible I was at knowing if they were good or not.
You can never tell what will work. You just have to do whatever seems best at each point. We do this with YC itself. We still don’t know if it will work, but it seems like a decent hypothesis.
Mi sembra evidente che qui si alluda ad una serie di valori e principi ampiamente previsti ed esaltati nel compendio culturale dei metodi agili.Ci sono riferimenti alla capacità di accogliere il cambiamento, alla necessità di iterazioni strette per avere feedback frequente e via dicendo.
Il passaggio che mi ha colpito di più però è questo
Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. [...] Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum
Trovo importantissimo ribadire l’importanza di uno scope mutevoleche ci permetta di ridefinire il problema (il backlog, il lavoro da fare) dinamicamente per poi trovare soluzioni possibili. Un po’ come poter correggere la rotta di una nave deviata da una forte corrente. Un po’ anche come capire definitivamente la differenza fra indaffarato e produttivo.
Nell’ordine Alberto, Gianandrea e Davide mi hanno segnalato questo articolo di Jakob Nielsen, tonicissimo guru della progettazione dell’esperienza utente (User eXperience), dell’usabilità e dello user centred design. Lasciando i commenti più specifici a chi di UX se ne intende assai più di me, ho letto con molto interesse il report di Nielsen, a valle delle molte esperienze e discussioni che ho vissuto al riguardo in questo 2009 che volge al termine e di cui hai potuto scorgere alcuni riflessi tra le pagine di questo blog.
Voglio condividere però il mio punto di vista, senza dubbio centrato sullo sviluppo agile, nel più ristretto ambito di soli due punti esposti da Nielsen.
Primo punto: risulta che il grado di soddisfazione dei partecipanti allo studio fosse leggermente più alto con metodi meramente iterativi piuttosto che anche agili. Trovo questo dato perfettamente in sintonia con quanto ho affermato più volte quest anno sul tema delle metodologie agili usate insieme allo user centred design. Gli interaction designer mancano ancora delle tecniche, degli strumenti – meno – e dei principi culturali – di più – per avere un approccio al proprio lavoro che li sostenga nell’abbandonare i propri semi-lavorati, i deliverable già creati. Quindi, pur percependo forte il valore dei processi agili, trovano ancora più confortevoli i metodi semplicemente iterativi, i quali, ovviamente, sono vissuti già come rivoluzionari da chi abituato a lavorare waterfall.
Secondo punto:
Developers rated the user experience impact on the deliverable’s quality at 4.3, whereas UX people rated it at 4.0 (again on a 1–5 scale, with 5 best). Developers said productivity increased somewhat with UX involvement (3.3), whereas UX rated this only slightly higher at 3.4.
La mia esperienza di progetti con un forte orientamento all’utente, con specialisti UX inseriti nel team, è stata altrettanto positiva. Io vedo l’attività degli interaction designer come un preziosissimo supporto alla scrittura delle user story e mi fa piacere vedere come questo valore sia percepito dagli sviluppatori in modo perfino più forte che dagli interaction designer stessi!
Ho imparato a ritenere la fase della scrittura delle user story una delle più cruciali – se non la più cruciale – per la buona riuscita di ogni progetto. Sei consapevole del valore di requisiti non solo ben espressi, ma anche già confezionati in un formato che supporti il team nella fase di sviluppo? Ti è chiaro come l’attività centrata sull’utente sia un grimaldello precisissimo per violare la serratura troppo spesso chiusa della riduzione razionale dello scope, del controllo del budget e, in ultima analisi, del successo del tuo progetto?
Una buona notizia per i (saggi) sviluppatori PHP: è stata rilasciata la prima alpha di Lime 2, il nuovo framework per unit test e functional test in PHP. Promette davvero bene, con un raffinato e moderno sistema per generare stub e mock object. Mi pervade un profondo senso di… disaccoppiamento!
ITDevCon è una conferenza Europea dedicata interamente a Delphi e alle tecnologie ad esso collegate.
[...]
Durante le due giornate di intensa formazione programmatori, analisti e software architect avranno la possibilità di scegliere fra le tre sessioni parallele della conferenza e confrontarsi con esperti di fama nazionale ed internazionale provenienti da realtà eterogenee che permetteranno loro di valutare punti di vista molto differenti tra loro.
Così recita la homepage del sito di ITDevCon 2009 e devono avere intenzioni di eterogeneità molto serie, visto che hanno invitato a parlare di extreme programming, scrum e metodologie agili in genere perfino me, che ho scritto le mie ultime righe in Delphi nel 1997!
Sarà quindi un piacere perfino maggiore presentare giovedì 12 novembre il talk intitolato Un approccio per unificarli tutti: cosa significa sviluppo agile in cui cercherò di porre l’accento sugli aspetti cross-tecnologici dei processi agili e sul vero baricentro metodologico: valori e principi. L’abstract del talk recita
Lo sviluppo agile è ormai un concetto diffuso e un termine sulla bocca di molti. Fortunatamente indipendente dalla tecnologia, questo approccio al nostro lavoro permette un notevole incremento del tasso di successo di un progetto software. Ma facciamo un passo indietro e cerchiamo di capire: abbiamo capito bene cosa significa sviluppo agile? In questo talk introduttivo Jacopo Romei spiegherà le pratiche Extreme Programming e i principi e i valori che sono il vero nocciolo dello sviluppo agile.
Mercoledì e giovedì, insomma, a Verona sarà un bel sondare un’altra comunità non-Java sui temi agili. Ti troverò lì?
Rieccomi finalmente dopo un breve periodo di assenza per un po’ di post in fila, per condurti, ma soprattutto condurmi, verso la prossima edizione del più importante evento italiano sui metodi agili come Scrum, Extreme Programming e Lean Software Development, l’Italian Agile Day 2009. Sarò infatti presente per la prima volta all’annuale evento come speaker con una sessione dal titolo Tutti i miei sbagli. E quelli di qualcun altro.
Sarà un talk autobiografico inverso in cui, senza pudore e senza nemmeno temere il ridicolo – che pur talvolta sfiorerò, toccherò, supererò? – racconterò non i successi dei miei ultimi anni da coach bensì ogni possibile esperienza negativa, cercando di vedere insieme a te perché le cose vadano male, perché possano andare male nonostante ci si ritenga agili e cosa ne pensi il pubblico di agilisti e non.
Se il principio di esposizione ha portato tanti benefici ai software open source, chissà che non faccia bene cominciare a mostrare i propri bug anche nel contesto del management. Il carattere del talk sarà fortemente suicida, in cerca della figuraccia, dell’errore da principiante… Per scoprire e ricordarmi da una parte che sono un principiante e dall’altra che un sano galileismo non teme auto-osservazione retrospettiva, per crescere ancora.
Mi metto alla gogna con le mie stesse mani. Nella fossa dei leoni per giunta. Porta i pomodori!
Con spirito schizofrenico da una parte e prudenza giuridica dall’altra – non abbiamo ancora bene capito cosa potremo ben scrivere – Francesco e io vi presentiamo il blog dedicato al nostro libro Pro PHP Refactoring with Test Driven Design. Poi magari non vi potremo scrivere niente di rilevante; poi magari non vi scriveremo niente che non si possa scrivere sui nostri rispettivi blog; poi magari non ci verrà niente in mente di interessante da scrivere; però oh, noi intanto lo abbiamo tirato su, con buona pace degli spider di Google.
Siamo già a caccia di lettori replicanti, non umani. Alla faccia di Rick Deckard!
Un grafico burndown relativo ad un progetto di cui sto curando il processo
Questo è un burndown chart disegnato appena prima di pranzo, oggi. Lo sto pubblicando per diversi motivi:
Mi sembrava abbastanza chiaro e quindi, di base, adatto alla sua stessa diffusione.
Dimostra che è possibile disegnarne uno in 5-6 minuti, segando le gambe quindi a tutte le pigrizie possibili. In futuro sarei comunque disposto a faticare anche un po’ di più per vedere quell’espressione di chiarezza acquisita sul volto di tutti: clienti, sviluppatori e interaction designer: “Ah, effettivamente così rende proprio il senso di quello che accade quando aggiungiamo feature selvaggiamente!”. Credo si riferisse alla 4 iterazione, secondo te?
Trovo piacevole constatare come il passo del progetto sia tutto sommato costante, rendendo chiaro come le oscillazioni della project velocity e della – più rara – ristima delle user story si compensino caoticamente suggerendomi di essere meno paranoico sul valore di project velocity ottenuto di iterazione in iterazione.
Tu? Ci leggi altro? Scrivimi le tue considerazioni, mi interessano moltissimo.