Coaching

Onesta'

NicolaCanalini — Wed, 08 Aug 2007 13:38:00 GMT

Ho visto alcuni miei colleghi rendere a spallate la macchinetta che distribuisce merendine, patatine e cioccolatismi vari. In sostanza hanno scoperto quello che e' stato definito un workaround per mangiare a scrocco. Credo che se fosse possibile valutare l'onesta' delle persone in un colloquio io darei alla cosa la massima importanza. Piu' mi guardo intorno piu' mi accorgo che l'onesta' e' rara e sottovalutata. Parlando con un amico qualche giorno fa mi sono sentito dire che il contrario di onesta' e' furbizia.

Agility with two not co-located team

NicolaCanalini — Mon, 25 Jun 2007 13:58:00 GMT

Se disponi di un team offshore e vuoi adottare un metodo agile puoi assumere una societa' locale al team remoto che si occupi di coaching. Ho sentito questa idea in questi giorni ma non mi sembra affatto praticabile. Come puoi sapere che il coach remoto condivida i tuoi valori ??? Ci deve essere un altro modo. Molte societa' stanno affrontando l'opportunita' di un team remoto, non e' ancora chiaro un possibile pattern per essere agili ne conosco casi di successo. Forse Thoughtworks ...

Xp2007.org

NicolaCanalini — Thu, 14 Jun 2007 13:13:00 GMT

Durante la conferenza annuale mondiale termonucleare dedicata a xp che quest anno si svolgera' a como, FrancescoCirillo moderera' un panel gratuito dedicato all'audience italiana. I dettagli sul sito di XpLabs.

La strada verso l'acceptance testing

NicolaCanalini — Wed, 23 May 2007 11:53:00 GMT

Yeah a million miles from nowhere And that's a long long way from homeAnd that's a long long way from home Long Way From Home - Stevie Ray Vaughan - Brothers: Family Style - 1990 Nella mia esperienza l'acceptance testing e' un obiettivo difficile da raggiungere che prevede un forte commitment da parte del team di sviluppo e un pesante coinvogimento dell'utente. In questi anni in cui il team in cui lavoro si e' impegnato sul proprio processo di sviluppo non abbiamo fatto passi significativi in questa direzione. Ecco alcune idee che possono servire da sprone per entrare in questo mondo. Credo che il percorso che porta all'adozione delle pratiche di acceptance testing sia dipendente da ogni singola situazione/team, non ho nessuna presunzione di tracciare una strada valida per qualcuno. Solo idee sparse ... - Installare un tool per l'automatizzazione degli acceptance test e provare a giocarci. - Scrivere degli smoke test: apri qui, usa il tal utente per fare login schiaccia questo bottone e apri quella form. - Scrivere la lista delle cose da fare in maniera comprensibile all'utente. Questo aiuta a concentrarsi sulle funzionalita' e su come testarle piuttosto che sulla loro implementazione - Spezzare le richieste o le storie o come le si voglia chiamare richieste piu' piccole per facilitarne la testabilita' - Aggiungere alla lista delle cose da fare un campo "How to demo" che descriva in parole semplici come verificare il funzionamento della feature - Sfruttare i bug come occasione per esercitarsi a scrivere test di accettazione, cioe' ad ogni bug scrivere un test per riprodurlo

La legge del taglione

NicolaCanalini — Mon, 14 May 2007 17:41:00 GMT

occhio per occhio, dente per dente, mano per mano, piede per piede, bruciatura per bruciatura, ferita per ferita, livido per livido Esodo 21 - Esdra lo scriba - La Torah - IV sec. a.C E' un comportamento vecchio come Noe' ed e' anche un comportamento psicologico diffusissimo. Se qualcuno piu' o meno intenzionalmente ti da' fastidio, in maniera naturale e piu' o meno coscientemente cercherai di fare un dispetto a questa persona. Un pattern classico degli ambienti di lavoro e' questo: Arrivi tardi al lavoro, il tuo capo te lo fa notare e ti riprende. Da quel momento devi sforzarti di non guardare l'orologio quando il tuo capo entra in ufficio. Altro caso tipico e' quando sbagli una procedura o una checklist, se te lo fanno notare diventerai il test automatico vivente delle procedure o delle checklist di chi ti ha fatto il cicchetto. Scambiando l'ordine dei fattori il risultato non cambia. (Questa frase e' chiaramente inutile ma fa sempre un bell'effetto e poi serve per allungare un po' questo post). Che succede se hai la responsabilita' della sicurezza nei confronti di un gruppo di sviluppatori ? Secondo me se imponi decisioni di sicurezza crei i presupposti per aprire buchi di sicurezza ancora piu' grandi di quelli che cerchi di tappare. E' opinione condivisa che 100% sicuro sia un'utopia, esagerando (davvero ?) si puo' pensare che intraprendere azioni volte alla sicurezza sia il modo migliore per causare magari involontariamente un incidente. Penso che con in un team esista un altra strada percorribile. Nel team si deve coltivare la sensibilita' alla sicurezza senza imposizioni esterne. Per farlo e' indispensabile la fiducia. Un altro modo che puo' essere utile e' partire dalla sicurezza del codice. Per un developer il codice e' cosa sacra per cui vale la pena di "spendere" energie.

Un po' di Coraggio

NicolaCanalini — Thu, 30 Nov 2006 11:56:00 GMT

If I told you what it takesto reach the highest high,You'd laugh and say "nothing's that simple"But you've been told many times beforeMessiahs pointed to the doorAnd no one had the guts to leave the temple! I'm Free - The Who - Tommy - 1969 Il coraggio e' uno dei 4 valori di Xp. Ho fatto fatica a capire il significato del coraggio in un team Xp. Mentre Semplicita', Comunicazione e Feedback hanno implicazioni cosi' forti da saltare immediatamente all'occhio, il coraggio mi sembrava meno decisivo. Ecco cosa penso su questo valore. Mantenere ben distinte le idee dalla loro implementazione e' un modo per favorire il coraggio. Puo' essere compito di un coach il separare in momenti di comunicazione differenti l'ideazione dalla concretizzazione; niente uccide di piu' la creativita' dalle difficolta' pratiche. Per questo motivo secondo me molti musicisti che non sono anche ottimi strumentisti abbandonano lo strumento quando compongono. Molto probabilmente non sanno che stanno riconoscendo la forza dell'idea rispetto allo sforzo della sua implementazione, probabilmente sono guidati dall'istinto. Possiamo imparare molte cose riguardo all'istinto dalla musica. Ecco alcuni casi concreti in cui ho riconosciuto il coraggio nella mia esperienza: - Quando cancello delle linee di codice sorridendo all'idea di commentarle. - Quando faccio Undo Checkout e ricomincio da capo. - Quando chiamo il mio cliente e gli dico che "quella storia proprio non riusciamo a consegnarla" e gli chiedo di rivedere assieme il planning. - Quando alzo il telefono e chiamo il mio cliente per avere delle risposte sapendo che e' preferibile telefonare a satana. - Quando non ho paura di sbagliare e dico come la vedo io, indipendentemente da chi mi ascolta. - Quando sento che la soglia del rispetto e' stata superata e mi fermo e non faccio niente. - Quando ho il coraggio di dire di no. Ma questo merita un post dedicato ...

Ci penso io

NicolaCanalini — Mon, 30 Oct 2006 14:31:00 GMT

Do you think it's allright, to leave the boy with uncle Ernie? Do you think it's alright? - The Who - Tommy - 1969 Bellissimo questo post di LucaMinudel in cui si categorizza il modo in cui pensiamo. Mi piace molto l'approccio semplice in cui senza scale di grigio si definiscono 4 modi (e solo 4) di pensare. E' molto utile per capire, poi e' ovvio che non e' tutto cosi' bianco o nero. Non riesco a capire quale delle 4 scelte definisce meglio il mio modo di pensare, mentre riesco bene a categorizzare altre persone che lavorano con me. Mi piacerebbe che qualcuno mi dicesse in che quadrante sto.

Meeting ovvero le riunioni

NicolaCanalini — Fri, 27 Oct 2006 18:34:00 GMT

Meet me at the coffee shopWe can dance like Iggy PopAnother go in the parking lotFreak the cheek on your hotspot Coffee Shop - Red Hot Chili Peppers - One hot minute - 1995 Spesso leggo di sviluppatori di software che si lamentano di dover partecipare a riunioni che ritengono inutili. Una cosa che mi disturba ancora di piu' e' quando in un meeting qualcuno si comporta come se fosse la prima volta che sente l'argomento della riunione. Secondo me quando si partecipa ad una riunione lo si dovrebbe fare per portare un contributo e non semplicemente per ascoltare. Credo che siano pochi gli ingredienti per rendere piu' efficaci i meeting. 1) Nella convocazione del meeting deve essere ben chiaro l'argomento che si affrontera'. Questo si puo' esprimere nel titolo, basta fermarsi un minuto a pensarlo. Non mi piacciono le riunioni che si intitolano "stato del progetto" o "brainstorming" (sono casi reali presi dalla mia esperienza) 2) Deve essere presente nella convocazione un'agenda di quello che si trattera' Penso sia una cosa molto importante che puo' essere molto sintetica ma che da' l'opportunita' a tutti di venire preparati. 3) Puntualita' no comment 4) Brevita' Non riesco a concepire un meeting piu' lungo di un'ora, impossibile restare concentrati. I meeting di un'ora sono comunque un'eccezione molto piu' efficaci quelli di mezzora. 5) Verbale Utilissimo stilare un verbale di qullo che si e' detto specificando in fondo quello che si e' deciso. Secondo me e' opportuno che chi convoca il meeting si faccia carico di questa attivita' in modo da invogliare i partecipanti a venire. ora ... in quanti meeting sono stato in cui questi 5 punti sono stati rispettati ? ma soprattutto ... quanti meeting ho organizzato che li rispettavano ???

Professione informatico: quello che il manager vorrebbe dai developer

NicolaCanalini — Thu, 07 Sep 2006 19:04:00 GMT

Prendo spunto dal post di AntonioGanci che prende spunto dal post di luKa, per elencare le caratteristiche che dovrebbe avere il developer ideale dal punto di vista del manager: Saper definire con precisione i tempi di consegna Trasformare l'ambiente che c'e' nell'ambiente di lavoro piu' silenzioso, e spazioso che si puo', in modo faciliti la concentrazione Non far interferire nelle scelte tecniche il manager in modo che il manager possa occuparsi soprattutto della gestione delle persone; Avere la fiducia delle persone che gestisce Non aver bisogno dell'overtime Non partecipare alla formazione con atteggiamento da Vacanziero (piuttosto che lavorare ...) o ostaggio (azz c'e' il capo a sto corso ... devo andarci) Incentivare la nascita di un team coeso ed affiatato Ne avete qualcuno da aggiungere? Siete d'accordo con quelli che ho scritto?

Standup meeting

NicolaCanalini — Tue, 22 Aug 2006 12:30:00 GMT

Get Up, Stand Up, stand up for your right (3 times) Get Up, Stand Up, don't give up the fight Get Up, Stand Up - Bob Marley & Peter Tosh - Burnin' - 1973 L'articolo definitivo di Martin Fowler sullo Standup Meeting powered by IMHO 1.3