Coaching http://blogs.ugidotnet.org/NicolaCanalini/category/Coaching.aspx Sviluppare software in gruppo it-IT NicolaCanalini Subtext Version 2.6.0.0 Onesta' http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/08/08/87546.aspx <p>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 <a href="http://it.wikipedia.org/wiki/Furto" target="_blank">workaround</a> 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.</p><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/87546.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/08/08/87546.aspx Wed, 08 Aug 2007 13:38:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/08/08/87546.aspx#feedback 1656 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/87546.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/87546.aspx Agility with two not co-located team http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/25/83208.aspx <p>Se&nbsp;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 ???</p> <p>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 ...</p><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/83208.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/25/83208.aspx Mon, 25 Jun 2007 13:58:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/25/83208.aspx#feedback 32 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/83208.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/83208.aspx Xp2007.org http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/14/81749.aspx <p>Durante la conferenza annuale mondiale termonucleare dedicata a xp che quest anno si svolgera' <a href="http://www.xp2007.org" target="_blank">a como</a>, <a href="http://www.xplabs.it/303010.html" target="_blank">FrancescoCirillo</a> moderera' un panel gratuito dedicato all'audience italiana. <a href="http://www.xplabs.it/904010.html" target="_blank">I dettagli</a> sul sito di XpLabs.</p><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/81749.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/14/81749.aspx Thu, 14 Jun 2007 13:13:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/06/14/81749.aspx#feedback 1474 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/81749.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/81749.aspx La strada verso l'acceptance testing http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/23/79017.aspx <p><font face="Tahoma" size="2"><em>Yeah a million miles from nowhere <br>And that's a long long way from home<br>And that's a long long way from home </em></font></p> <p><font face="Tahoma" size="1">Long Way From Home - Stevie Ray Vaughan - Brothers: Family Style - 1990</font></p><font face="Tahoma" size="2"> <p>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 ...</p> <p>&nbsp;</p> <p>- Installare un tool per l'automatizzazione degli acceptance test e provare a giocarci. </p> <p>- Scrivere degli smoke&nbsp;test:&nbsp;apri qui, usa il tal utente per fare login schiaccia questo bottone e apri quella form.</p> <p>- 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</p> <p>- Spezzare le richieste o le storie o come le si voglia chiamare richieste piu' piccole per facilitarne la testabilita'</p> <p>- Aggiungere alla lista delle cose da fare un campo "How to demo" che descriva in parole semplici come verificare il funzionamento della feature</p> <p>- Sfruttare i bug come occasione per esercitarsi a scrivere test di accettazione, cioe' ad ogni bug scrivere un test per riprodurlo</p></font><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/79017.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/23/79017.aspx Wed, 23 May 2007 11:53:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/23/79017.aspx#feedback 1662 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/79017.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/79017.aspx La legge del taglione http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/14/78186.aspx <p><font face="Tahoma" size="2"><em>occhio per occhio, <br>dente per dente, <br>mano per mano, <br>piede per piede, <br>bruciatura per bruciatura, <br>ferita per ferita, <br>livido per livido </em></font></p> <p><font face="Tahoma" size="1">Esodo 21 - Esdra lo scriba - La Torah - IV sec. a.C</font></p><font face="Tahoma" size="2"> <p>E' un comportamento vecchio come Noe'&nbsp;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. </p> <p>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.</p> <p>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).</p> <p>Che succede se hai la responsabilita' della sicurezza nei confronti di un gruppo di sviluppatori ?</p> <p>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. </p> <p>Penso che con in un team esista un altra strada percorribile.&nbsp;Nel&nbsp;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.</p></font><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/78186.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/14/78186.aspx Mon, 14 May 2007 17:41:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2007/05/14/78186.aspx#feedback 47 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/78186.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/78186.aspx Un po' di Coraggio http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/11/30/57955.aspx <p><font face="Tahoma" size="2"><em>If I told you what it takes<br>to reach the highest high,<br>You'd laugh and say "nothing's that simple"<br>But you've been told many times before<br>Messiahs pointed to the door<br>And no one had the guts to leave the temple!</em></font></p> <p><font face="Tahoma" size="1">I'm Free - The Who - Tommy - 1969</font></p> <p><font face="Tahoma" size="2">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.</p> <p>Mantenere ben distinte le idee dalla loro implementazione e' un modo per favorire il coraggio. </p> <p>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. </p> <p>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. </p> <p>Possiamo imparare molte cose riguardo all'istinto dalla musica.</p> <p>Ecco alcuni casi concreti in cui ho riconosciuto il coraggio nella mia esperienza:</p> <blockquote> <p>- Quando cancello delle linee di codice sorridendo all'idea di commentarle.</p> <p>- Quando faccio Undo Checkout e ricomincio da capo.</p> <p>- Quando chiamo il mio cliente e gli dico che "quella storia proprio non riusciamo a consegnarla" e gli chiedo di rivedere assieme il planning.</p> <p>- Quando alzo il telefono e chiamo il mio cliente per avere delle risposte sapendo che e' preferibile telefonare a satana.</p> <p>- Quando non ho paura di sbagliare e dico come la vedo io,&nbsp;indipendentemente da&nbsp;chi mi ascolta.</p> <p>- Quando sento che la soglia del rispetto e' stata superata e mi fermo e non faccio niente.</p> <p>- Quando ho il coraggio di dire di no. Ma questo merita un post dedicato ...</p></blockquote></font><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/57955.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/11/30/57955.aspx Thu, 30 Nov 2006 11:56:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/11/30/57955.aspx#feedback 1648 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/57955.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/57955.aspx Ci penso io http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/30/53377.aspx <p><font face="Tahoma" size="2"><em>Do you think it's allright, to leave the boy with uncle Ernie?</em></font></p> <p><font face="Tahoma" size="1">Do you think it's alright?&nbsp;-&nbsp;The Who&nbsp;-&nbsp;Tommy - 1969</font></p><font face="Tahoma" size="2"> <p>Bellissimo <a href="http://blogs.ugidotnet.org/luka/archive/2006/10/27/53163.aspx">questo post</a> di <a href="http://blogs.ugidotnet.org/luka/">LucaMinudel</a> in cui si&nbsp;categorizza&nbsp;il modo in cui pensiamo. Mi piace molto l'approccio semplice in cui senza scale di grigio si&nbsp;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&nbsp;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.</p></font><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/53377.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/30/53377.aspx Mon, 30 Oct 2006 14:31:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/30/53377.aspx#feedback 1935 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/53377.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/53377.aspx Meeting ovvero le riunioni http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/27/53178.aspx <p><font face="Tahoma" size="2"><em>Meet me at the coffee shop<br>We can dance like Iggy Pop<br>Another go in the parking lot<br>Freak the cheek on your hotspot</em></font></p> <p><font face="Tahoma" size="1">Coffee Shop - Red Hot Chili Peppers - One hot minute - 1995</font></p> <font face="Tahoma" size="2"> <p>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. </p> <p>1) Nella convocazione del meeting deve essere ben chiaro l'argomento che si affrontera'.</p> <blockquote> <p>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)</p></blockquote> <p>2) Deve essere presente nella convocazione un'agenda di quello che si trattera'</p> <blockquote> <p>Penso sia una cosa molto importante che puo' essere molto sintetica ma che da' l'opportunita' a tutti di venire preparati.</p></blockquote> <p>3) Puntualita'</p> <blockquote> <p>no comment</p></blockquote> <p>4) Brevita'</p> <blockquote> <p>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.</p></blockquote> <p>5) Verbale</p> <blockquote> <p>Utilissimo stilare un verbale di qullo che si e' detto specificando in fondo <strong>quello che si e' deciso</strong>. Secondo me e' opportuno che chi convoca il meeting si faccia carico di questa attivita' in modo da invogliare i partecipanti a venire.</p></blockquote> <p>ora ... in quanti meeting sono stato in cui questi 5 punti sono stati rispettati ?</p> <p>ma soprattutto ... quanti meeting ho organizzato che li rispettavano ???</p> </font><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/53178.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/27/53178.aspx Fri, 27 Oct 2006 18:34:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/10/27/53178.aspx#feedback 1634 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/53178.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/53178.aspx Professione informatico: quello che il manager vorrebbe dai developer http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/09/07/47512.aspx <p></p> <p><font face="Tahoma" size="2">Prendo spunto dal <A href="http://blogs.ugidotnet.org/AntonioGanci/archive/2006/09/06/47412.aspx">post</a> di AntonioGanci che prende spunto dal </font><A href="http://blogs.ugidotnet.org/luKa/archive/2006/09/05/47385.aspx"><font face="Tahoma" size="2">post</font></a><font face="Tahoma" size="2"> di luKa, per elencare le caratteristiche che dovrebbe avere il developer ideale dal punto di vista del manager:</font> <ul> <li><font face="Tahoma" size="2">Saper definire con precisione i tempi di consegna </font> <li><font face="Tahoma" size="2">Trasformare l'ambiente che c'e' nell'ambiente di lavoro piu' silenzioso, e spazioso che si puo', in modo faciliti la concentrazione </font> <li><font face="Tahoma" size="2">Non far interferire nelle scelte tecniche il manager in modo che il manager possa occuparsi soprattutto della gestione delle persone; </font> <li><font face="Tahoma" size="2">Avere la fiducia delle persone che gestisce </font> <li><font face="Tahoma" size="2">Non aver bisogno dell'overtime </font> <li><font face="Tahoma" size="2">Non partecipare alla formazione con atteggiamento da Vacanziero (piuttosto che lavorare ...) o ostaggio (azz c'e' il capo a sto corso ... devo andarci)</font> <li><font face="Tahoma" size="2">Incentivare la nascita di un team coeso ed affiatato</font></li></ul> <p><font face="Tahoma" size="2">Ne avete qualcuno da aggiungere? Siete d'accordo con quelli che ho scritto?</font></p><img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/47512.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/09/07/47512.aspx Thu, 07 Sep 2006 19:04:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/09/07/47512.aspx#feedback 1273 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/47512.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/47512.aspx Standup meeting http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/08/22/46516.aspx <P><FONT face=Tahoma size=2><EM>Get Up, Stand Up, stand up for your right (3 times)<BR> Get Up, Stand Up, don't give up the fight</EM></FONT></P> <P><FONT face=Tahoma size=1>Get Up, Stand Up - Bob Marley &amp; Peter Tosh - Burnin' - 1973</FONT></P> <FONT face=Tahoma size=2> <P>L'<A title="" href="http://martinfowler.com/articles/itsNotJustStandingUp.html" target="" name="">articolo</A> definitivo di <A title="" href="http://www.martinfowler.com/" target="" name="">Martin Fowler</A> sullo Standup Meeting</P> </FONT> <FONT face=Verdana size=2><P><A href="http://imhoproject.org/"><FONT face=Verdana size=1>powered by IMHO 1.3</FONT></A></P></FONT><!-- Powered by IMHO 1.3 (EN) Instant Blogger Copyright (c) 2005 A.Boschin - http://www.imhoproject.org --> <img src="http://blogs.ugidotnet.org/NicolaCanalini/aggbug/46516.aspx" width="1" height="1" /> NicolaCanalini http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/08/22/46516.aspx Tue, 22 Aug 2006 12:30:00 GMT http://blogs.ugidotnet.org/NicolaCanalini/archive/2006/08/22/46516.aspx#feedback 5 http://blogs.ugidotnet.org/NicolaCanalini/comments/commentRss/46516.aspx http://blogs.ugidotnet.org/NicolaCanalini/services/trackbacks/46516.aspx