Archive for the 'Dalle trincee' Category

Piccoli burndown chart crescono

Forse ricordi un vecchio post su un mio burndown chart. Le 5 iterazioni visualizzate in quel grafico col tempo sono diventate 10 poi 12 poi 13… Anche il burndown chart è cresciuto con noi e uno dei motivi per cui è da un po’ che non scrivo qui sul mio blog è che sto scrivendo un case study – grafici compresi ;) – su questo progetto da cui, come al solito, ho imparato tantissimo.

Nel frattempo però per fortuna c’è qualcun altro che scrive in tempi più rapidi. In questo post di Michael Marus sul blog dell’ICT-KM Program (CGIAR) trovi una sua retrospettiva e un mio piccolo intervento. Buona lettura e a prestissimo!

February 17 2010 | Dalle trincee | No Comments »

Agile project management con Google Wave

Ultimamente sono sempre più disposto a ridurre gli strumenti di gestione dei progetti in cui lavoro ad un singolo spreadsheet, liberandomi da tutti i software di cui si è soliti discutere nella comunità agile e non. Anzi, a dire il vero, la mia migrazione non si sta compiendo verso fogli elettronici qualunque ma verso quelli offerti da Google Docs, per via del forte incentivo che essi stessi costituiscono alla condivisione di informazioni e alla collaborazione.

Allora, però, penso anche che Google Wave potrebbe essere un ottimo strumento per gestire progetti se quello che ci interessa è l’aderenza più alta possibile del nostro stile di gestione al Manifesto Agile. Modellare infatti le interazioni fra i componenti umani di un team in modo il più possibile destrutturato – purché aggregato, storicizzato e usabile – mantenendo intatta la possibilità di integrare queste interazioni con informazioni CPU-generated – come i log SVN – credo sia infatti la chiave per un processo sufficientemente asciutto – diremmo lean – per essere adattato ad ogni contesto in modo vincente. Il principio di umanità di cui ho parlato in passato verrebbe sicuramente onorato.

Non so ancora se assocerei una wave ad un intero progetto o una wave ad ogni singola user story. La seconda possibilità mi sembra più promettente; immagino wave che iniziano con la data user story in cui vengono man mano inclusi wireframe, screenshot, user story, commenti, chat e magari un planning game e un log svn con dei plug-in ad hoc… Le possibilità mi sembrano tante, manca qualche riscontro empirico.

Cercherò di fare presto degli esperimenti con i più arditi tra i miei clienti e collaboratori. Appena ne saprò di più ti aggiornerò su queste pagine. Tu nel frattempo non fare il tirchio eh! Se sai qualcosa batti un colpo e facci sapere anche qui!

December 17 2009 | Dalle trincee | 1 Comment »

Più realisti del re: l’Agile UX secondo gli sviluppatori

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?

November 12 2009 | Dalle trincee | 3 Comments »

Lime 2 e la svolta attesa per PHP

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!

November 11 2009 | Dalle trincee | 2 Comments »

Burning down da house

Un grafico burndown relativo ad un progetto di cui sto curando il processo

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.

September 18 2009 | Dalle trincee | 7 Comments »

Agile UX, Facebook e il refactoring delle interfacce

In un recentissimo post di Alberto Mucignat, caro amico più volte ospite di questo blog, nonché esperto progettista di interfacce, si possono leggere sintetizzati i punti salienti per capire come lavorano gli interaction designer di Facebook.

Sebbene mi piacerebbe soffermarmi sul punto

3. I designer lavorano principalmente in codice (html/css e un pizzico di php)

tradendo così la mia estrazione da sviluppatore e confermando il codice come valido (!= perfetto) formalismo per questi scopi, preferisco invece farti notare questo:

4. Non si affezionano troppo al lavoro: il software cambia continuamente.

È più di un anno che scrivo e dico che l’unica via per rendere più agile il lavoro degli interaction designers è basata su due punti:

  1. Trovare strumenti che permettano il facile refactoring dei wireframe.
  2. Adottare una filosofia di progettazione più incline al rifacimento e meno al desiderio di essere – disperatamente – up front.

Il primo vincolo potrà anche essere squisitamente tecnico – ed è solo questione di tempo, ma il secondo non è che di natura umana.

E ti pare poco!

September 17 2009 | Dalle trincee | 6 Comments »

After-market

Ciao! Forse ricordi che alla fine dello scorso maggio ho avuto il piacere di fare da coach per e-xtrategy. Dopo qualche mese, immagino, di piena dedizione, di tentativi e di errori questo è quello che mi scrive Lorenzo, che tra i ragazzi di e-xtrategy è stato quello che ha proposto agli altri di avvicinarsi ai metodi agili. continue reading »

August 24 2009 | Dalle trincee | 3 Comments »

Test funzionali con eZ Publish

Certe volte il mio contributo – sempre modesto – alla diffusione delle metodologie agili lo porto su territori molto astratti, tecnici ma anche umani, se non quando perfino filosofici. Altre volte il contributo che ho l’occasione di offrire è invece più materiale, concreto, di basso livello, operativo.

Stavolta sono felice di aver condiviso con Francesco una parte significativa dello sforzo necessario a creare il primo framework per test funzionali per eZ Publish, il celeberrimo sistema di gestione contenuti scritto in PHP.

Inutile dire che la concretezza dello strumento è già una soddisfazione per se, ma a tutto ciò si aggiunge la certezza di aver ancora una volta alimentato il fruttuoso rapporto di collaborazione che da più di un anno mi vede coinvolto in un gruppo allargato davvero stimolante, attivo, concreto e – perché no – simpatico.

Sono soddisfazioni, lasciamelo scrivere. Quando vorrai unirti a noi, sarai il benvenuto.

August 17 2009 | Dalle trincee | No Comments »

Il costo dell’interesse per il cliente in un progetto agile

A commento dell’ultimo post di Luca, leggo:

Pero Luca, il cliente che ti “paga per fare un lavoro” non vuole (in alcuni casi certo) fare il cliente Agile perchè potrebbe obbiettare: perchè dovrei fare io il uto lavoro ?
Perche dovrei essere presente nella fase di analisi/refactoring del progetto ?
Potrebbe obbiettare che è un costo che devi gestire tu esecutore …

Ho pensato di rispondere così:

Beh, dipende dall’approccio.

Quando chiedo ad uno studio di architettura di progettarmi una casa è uso per lo studio affiancarsi a me e assorbire le mie esigenze, proprio per evitare di farmi un lavoro sbagliato e io sono ben contento di farmi fare la casa dei miei sogni e non quella dei sogni di qualcun altro. :)
Per non parlare del rapporto tipico fra proprietario della casa e la ditta di lavori edili incaricata di tirarla su! Sapete quanto spesso accade che i muratori tirino su un pezzo di casa diverso da come lo intendeva il proprietario? Molto, molto spesso… Per questo chi paga ha interesse a essere sempre presente (nei limiti dell’utile, è più che ovvio) sul cantiere.

Oppure c’è la figura del consulente personale, come il medico, l’avvocato. Conoscete un avvocato difensore che possa lavorare bene senza avere il proprio cliente al proprio fianco? O un medico che non concordi, fra tutte le alternative possibili, la cura migliore per il particolare paziente con il paziente stesso?

Oppure c’è il supermercato.
Vado allo scaffale, mi fido, accetto la produzione studiata peraltro comunque sull’utenza – ma su base statistica e non personale, e torno a casa con un prodotto molto economico ma identico a quelli di centinaia di migliaia di altri clienti.

Un sito web può mai permettersi di essere uguale ad altri?
Il lavoro del medico è quello operativo di farti prendere la medicina tutte le sere o quello consultivo di fare la giusta analisi in tua presenza della tua specifica patologia?
Se investo denaro – quello serio – lo sparo su un missile fire & forget o la villetta in cui vorrò passare il resto della mia vita me la curo e coccolo dal primo mattone in su?

Un’azienda di sviluppo software non è un’azienda di esecutori. Gli esecutori sono le CPU. Chi fa sviluppo vende analisi e progettazione, da fare al fianco del committente nel suo stesso interesse. [...]

Tu che dici? Sei d’accordo?

July 09 2009 | Dalle trincee | 3 Comments »

Un nuovo ferro nella cassetta PHP?

Caro sviluppatore, capo progetto, product owner di sistemi scritti in PHP, è con sentimento misto di curiosità, entusiasmo e sollievo che posso scrivere oggi qui di Symfony Dependency Injection, il dependency injection container (DIC) di Symfony Components.

Sono anni che aspetto questo momento, da quando al PHP London discutevo con Marcus Baker (quello di SimpleTest per intenderci) della sua implementazione di un DIC minimo.

Non so ancora nulla, non so nemmeno ancora se mi piacerà, ma so che questi sono giorni importanti. Sono giorni in cui un progetto PHP serio pubblica un componente con intenzioni serie che ha senso che sia impiegato in applicazioni serie. E questo è un bene, oggettivamente. È un sintomo di grande salute per la comunità PHP.

Da oggi i team impegnati con PHP potranno decidere se usare un DIC o meno, compiendo scelte legittime su ambo i fronti. Io intanto corro a documentarmi. Fosse mai che si riesca ad aumentare la manovrabilità dei miei progetti di sviluppo!

Che poi la maggior parte della comunità PHP corra il serio rischio di fare spallucce e di ignorare la novità senza scegliere nessuna direzione, beh… la questione dell’ignavia è stata risolta 700 anni fa da Sensei Alighieri.

Tu invece scegli la consapevolezza, no?

July 01 2009 | Dalle trincee | 1 Comment »

« Prev - Next »