Gioco del Perfezionamento

Il Gioco di Perfezionamento (Perfection Game) è un modo per dare e ricevere dei feedback costruttivi ogni volta che volete migliorare qualcosa. E’ stato sviluppato da Jim & Michele McCarthy come parte dei loro “Core Protocols”

I passi sono i seguenti:

1. Qualcuno presenta il proprio lavoro (nella fattispecie la propria proposta di sessione) e richiede dei feedback.
2. Voi date al lavoro un voto da 1 a 10, basandovi su quanto valore potreste aggiungere. Es:. darò un voto 9/10 se posso aggiungere poco valore, un 5/10 se posso raddoppiare il valore del lavoro realizzato attualmente e 1/10 se posso realizzare il lavoro 10 meglio di quanto non sia quello attuale.
3. Spiegate cosa vi piace del risultato attuale. Cos’è che giustifica il vostro voto. Che cosa dovrebbe essere tenuto?
4. Spiegate inoltre che cosa manca per renderlo perfetto ai vostri occhi (ovvero per ottenere un 10/10). Quali azioni concrete dovrebbero essere prese per migliorare il punteggio?

Quando date un feedback

• Pensate profondamenmte nel momento in cui spiegate come poter rendere il lavoro perfetto. E’ facile fare degli appunti negativi, però è importante renderli in modo positivo.
• Spiegate il vostro ragionamento. Es. “Avrei fatto X tenendo in considerazione Y”
• Non dimenticatevi del passo “Che cosa mi piace” in modo che le parti buonedel lavoro vengano mantenute e rinforzate positivamente (“questo mi ricorda un po’ K. Lorentz ed il concetto di rinforzo positivo” NdT)
• Siare sicuri che il vostro voto rifletta chiaramente il contributo che pensate di poter offrire al miglioramento del risultato
• Effettuate un Follow e fornite feedback aggiornati una volta che il lavoro è stato modificato. Il processo iterativo porta alla perfezione (dicesi “circolo virtuoso”).

Quando ricevete un feedback

• Ringraziate la persona che vi ha dato il feedback.
• Ponete delle domande per comprendere meglio ciò che vi è stato suggerito o contestato.
• Non discutete o controbattete quanto detto da colei/lui che vi dato il feedback.
• Voi siete i responsabili per la qualità del lavoro, quindi è vostra responsabilità decidere se e come attuare i suggerimenti ricevuti dal feedback

Italian Agile Day 2010!

Venerdi’ 19 Novembre 2010 si terrà a Genova il settimo Italian Agile Day. Si tratta di una conferenza gratuita di un giorno dedicata alle metodologie Agili per lo sviluppo e la gestione dei progetti software rivolta agli sviluppatori, project leaders, IT managers, tester, architetti e coach che hanno esperienze da condividere o che iniziano solo ora ad interessarsi a queste tematiche. La giornata ha come obiettivo la conoscenza pratica, le esperienze sul campo e un attivo coinvolgimento di tutti i partecipanti. L’accesso è libero previa registrazione, i posti sono limitati. L’evento, per la quarta volta consecutiva, si auto-finanzierà.

Stime agili

Che valore utilizzate per calcolare la velocity dei vostri team agili? Nella definizione data da Mike Cohn nel bel libro “Agile Estimating and Planning” gli story point possono rappresentare “giorni ideali” oppure auspicabilmente numeri puri al fine di consentire il confronto e definire l’effort. Direi che questa tematica è estremamente importante nel contesto delle stime e delle pianificazioni Scrum ed XP.

Scrummarola – ricetta

Negli ultimi tempi la “Scrummarola” (termine derivato da Scrum e da pummarola) sta divenendo sempre più popolare; adottata e direi meglio tipica forma di involuzione (l’autore intendeva dire evoluzione. NdR) quasi ovunque si sia tentato di utilizzare Scrum in modo canonico nelle nostre regioni.

Ho pensato dunque di farvi gradito regalo, dandovi in anteprima questa ricetta tipicamente italiana.

“Prendete la nota metodologia Scrum e toglietele accuratamente due dei tre ruoli prescritti (tanto il PO non si sa neppure cosa serva e lo SM può essere rimpiazzato da un normale PM), poi nettatela bene da principi e valori agili superflui. Attenzione ad evitare che il team sia cross-functional e che si auto-organizzi.

A questo punto potete procedere con l’eliminare praticamente tutte e tre le attività e lasciare al limite solo la riunione mattutina, che al limite può servire come ulteriore pausa rispetto a quella del caffè (cioè a fare melina). Inoltre, mettete la massima cura ad evitare che rimangano residui di pratiche Ics Pi tipo TDD, Pair o altre simili facezie.
Infine, state ben attenti a non utilizzare nessuno degli artifact prescritti e in particolar modo ad evitate con sagacia e perspicacia ogni traccia di Burn Down chart.

In ultimo se volete insaporirla, potete condirla con una spolverata di pratiche PMP, un pizzico di ISO9001 ed un cucchiaino di ITIL più un velo di organizzazione burocratica e gerarchica a piacere. In alcuni team si usa anche aggiungere del “command & control” o del “cowboy programming”. Ma, lascio a voi la scelta per tali prelibatezze e ricercatezze.”

Ecco, direi che abbiamo la base di questa ricetta tipicamente italiana. Probabilmente i più incalliti agilisti diranno che così Scrum è stato snaturato ed ha perso ogni traccia agile. Ma vi posso assicurare che in cambio, questa metodologia risulta essere estremamente “snella”, anzi direi che scorre via come acqua fresca o meglio come una cascatella (waterfall NdT).

Italo Cascatelli (orto-metodista)

OpenWare

Il sito OpenWare.org è online. Spero che da questa prima emissione si doffonda un’onda di conoscenza e di cooperazione.