Agile Methodologies: Quando, Dove e Perche’ utilizzarle.

Quando e’ meglio utilizzarle e quando no. Le mie considerazioni.

Introduzione

Ho appena finito di leggere questo articolo (Inutilità del Diagramma di Gantt – http://blogs.ugidotnet.org/manuel0081/archive/2013/03/09/inutilita-del-diagramma-di-gantt.aspx) che ho trovato molto utile e molto interessante e che mi trova pienamente d’accordo. L’articolo descrive come i diagrammi di Gantt in alcune situazioni aziendali possono essere spesso sopravvalutati. Ho pensato quindi di scrivere un articolo simile orientato metodologie agili, descrivendo il mio punto di vista e le mie considerazioni, il mio pensiero e soprattutto i casi in cui preferisco utilizzarle e quando no.
Spesso accade di sentire parole chiave come SCRUM, AGILE, SPRINT, LAVAGNA “alla macchinetta del caffè”. Senza approfondire questi importanti argomenti e sottovalutandone i contenuti, si rischia di arrivare a parlare di nulla e di trasformare ogni parola in qualcosa di inapplicabile e addirittura, a volte, deleterio. Non deve essere un argomento che va di moda, ma dovrebbe al contrario essere sviscerato, analizzato e compreso, per fare in modo che la sua applicazione possa essere utile e, soprattutto, vincente. Perchè stiamo parlando di team e situazioni reali, quindi applicare le regole, significa avere anche una profonda conoscenza del mezzo.
Prima di iniziare a scrivere le mie considerazioni vorrei fare un’importante considerazione: questi sono appunto miei pensieri e, vanno valutati come tali. È una parte della mia esperienza avuta sul campo.L’articolo non vuole essere una critica a nessuno ma un punto di raccolta da condividere per capire se le mie osservazioni sulla loro scelta sono corrette oppure no.
Scrivo da fan e da utilizzatore accanito di queste metodologie: le utilizzo da anni e non potrei farne a meno.
Cerchiamo di capire quanto voglio dire analizzando, passatemi il termine, i momenti:

Prima di scegliere

Quando mi trovo di fronte ad una scelta di uno strumento o, come in questo caso, la metodologia corretta da utilizzare nella fase di sviluppo, cerco sempre di capire se tale scelta mi porterà benefici oppure no. Sembra banale la scelta ma molte volte è quella più difficile, e molto spesso è sottovalutata tanto da arrivare a non rendersi nemmeno conto di non essersi nemmeno soffermati un minuto. Uno strumento o una metodologia scelta in maniera errata potrebbe causare non solo rallentamenti e sviluppi erronei, ma, nei casi peggiori, anche il fallimento.
A mio modesto parere si dovrebbe tenere conto di alcuni punti fondamentali che in futuro ci aiuteranno a prendere la giusta decisione. Alcuni troveranno i punti seguenti in contrasto tra loro e contro qualsiasi metodolgia di lavoro; purtroppo la realtà aziendale è sempre molto diversa dall’idea teorica (e ogni business ha il suo set di regole ben diverse) e tutti i buoni propositi vanno a farsi benedire.
Ecco cosa mi fa scegliere se utilizzare o no una metodologia durante lo sviluppo del progetto, perchè è di questo che si sta parlando:

  • Durata del progetto: In un progetto dove il ciclo di sviluppo ha una durata inferiore al mese, l’utilizzo di metodologie agili, secondo me, è controproducente: I processi da adottare in metodologie come scrum, posso portare ad un prolungamento del processo di sviluppo e possono portare ad uno stress.
  • Team a disposizione: Il team è molto importante perchè è l’apparato operativo del progetto stesso. Un team rodato e che lavora insieme da anni è un ottimo punto a favore della scelta, ma se si disponesse di un team nuovo, nel quale le persone non hanno mai lavoraro tra loro, sarebbe meglio trovare un compromesso. Il mio consiglio è di utilizzare sempre team misti: dove ci sono membri esperti e membri non esperti: in questo modo si ha la possibilità di far crescere il team. Non userei queste metodologie in un team nuovo: specialmente in un team formato da soli consulenti: ho notato che è molto difficile far lavorare un gruppo di consulenti con queste metodologie (per esempio ho notato che molte volte tra consulenti si fa fatica a chiedere un aiuto: si ha paura molte volte che la richiesta di aiuto venga vista come fattore negativo). Altre volte la condivisione di conoscenza è molto difficoltosa: alcune persone hanno paura di condividere tecniche o conoscenza per continuare ad essere indispensabile ai fini del progetto. Quest’ultime affermazioni sono molto significative per soddisfare a pieno un requisito nell’utilizzo di queste metodologie: IL CORAGGIO.
  • Livello del team: Anche il livello del team ha una rilevanza non meno importante sulla scelta. Il livelo di competenza e conoscenza deve essere per il 70% del team comunque. Non possiamo avere due marce differenti per lavorare. Anche se è vero che se il team ha una disposizione propositiva esso può avere anche due ritmi diversi e chi ha un livello maggiore aiuterà (anche implicitamente) gli altri a crescere.
  • Conoscenze della metodologia: è importante che almeno la maggior parte del team sia consapevole su cosa vuol dire agile e su come si lavora. E che abbia avuto almeno una minima esperienza di lavorazione su questo. Partire senza queste basi è molto difficile portare al completamento un progetto.
  • Formazione: In un team nuovo ho tempo di effetturare della formazione sulle metodologie prima di iniziare? Se la risposta è negativa allora la scelta è da analizzare meglio: Come detto, devo avere almeno una parte del team che abbia avuto esperienza o almeno conosca queste metodologie. Utilizzare senza una base è pericoloso per la riuscita del progetto: Possono essere utilizzate in maniera non corretta e possono fare perdere tempo. Inoltre devo mettere in conto che durante il progetto ci sara’ anche sessioni di apprendimento. Se posso fare questo allora posso iniziare a lavorare in agile.
  • Budget: Un budget limitato (sia di tempo che di denaro) implica un’analisi delicata per la scelta di queste metodologie. Il loro utilizzo, la maggior parte delle volte, porta ad aumenti di tempo e di costi.
  • Cliente: Il cliente, essendo il destinatario dello sviluppo, ha necessità di entrare nel progetto in termini di comprensione dello stesso. Prima di tutto bisogna far capire al cliente quali sono i benefici della scelta. Questo è molto complesso in contesti dove il risparmio è condizione imprenscindibile. Una durata maggiore e costi diversi non sempre vengono apprezzati, anche se in cambio si ha un progetto robusto, un progetto testato. Se il cliente vuole tutto e subito allora non è possibile nemmeno prendere in cosiderazione la metodologia.
  • Struttura aziendale: Anche la struttura aziendale può essere influente. Siamo sicuri che i nostri manager, i nostri pm e addirittura l’organizzanzione anziendale siano in grado di poterci garantire serenità nel lavoro in agile. Le frasi “deve essere pronto per ieri” o “il più presto possibile” non esistono con queste metodologie (anche se secondo me non devono mai esistere). Una metedologia di questo tipo può solo danneggiare la serenità degli sviluppatori in queste situazioni.

Perchè le scelgo e perchè non le scelgo… che dilemma!

Il paragrafo precedente dovrebbe rispondere a queste due domande ma molte volte, anche se si hanno a disposizione tutti i pezzi del puzzle per prendere una decisione, rispondere può apparire ancora difficile.
Quando sono io a decidere, cerco prima di tutto di capire quale team ho a disposizione. Può succedere che per un progetto viene chiesto di usare Agile, con carta bianca, ma la risposta è negativa e quindi, si sceglie di non usarle. Perchè? Perchè il progetto ed il team non sempre sono adatti. E questo capita quando gli sviluppatori si preoccupano più della lavagna e dei post-it (o dello strumento software) che del progetto stesso. Ma non solo, anche quando il team non ha una cultura tale da poter seguire le metodologie; nessuno le conosce profondamente o nessuno le ha mai utilizzate prima. Formare i PM, il team e cercare un PO adatto risulterebbe, di conseguenza, troppo dispendioso e dispersivo per il progetto. Risultato, non c’è il tempo. Se poi aggiungiamo che in molti casi il meeting giornaliero è utilizzato come momento di ritrovo e non come sincronizzazione, il progetto ne risentirà senz’altro.

Troviamo un compromesso

Anche se succedono cose come quelle appena descritte, quello che cerco di fare sempre è trovare un compromesso. Le agile methodologies sono formate da un’insieme di leggi e di processi. Anzi alcune volte utilizzo queste due parole durante la formazione per non spaventare le persone con paroloni che vogliono dire tutto e niente.
Utilizzare processi e leggi è forse la cosa più complessa e molte volte invece di portare benefici determinano effetti negativi sul progetto. In contesti disorganizzati inserire un nuovo piccolo processo, o una nuova piccola legge può portare effetti positivi oltre che a formare le persone. E quindi a volte è meglio affrontare un cambiamento strutturale del processo di sviluppo step by step, per fare in modo di non spaventare l’organizzazione in essere.
Quello che faccio è cercare di utilizzare sempre il meglio di ogni metodologia:
Facciamo un altro esempio: parliamo di un cliente il cui problema principale è la comunicazione. L’obbiettivo è applicare una metodologia in un team in cui appunto, la comunicazione è un po’ trascurata. A causa della mancanza di conoscenza da parte del team delle metodologie agili, si può cercare di introdurle poco alla volta evitando di entrare a “gamba tesa”. Quello che potremmo fare è provare a creare la comunicazione prima di tutto, con il team, introducendo i morning meeting; Questo molto spesso ha risposta positiva, e quindi apre lo spiraglio per l’introduzione di una nuova figura: il product owner (P.O.) che cerca di intermediare il business con lo sviluppo. Con questi primi passi si riesce a far comunicare gli elementi del team tra di loro (Adesso almeno sannno cosa stanno facendo) e si crea un muro di protezione tra le richieste del businness e quelle del team. In questo modo si evita che chiunque entri in ufficio chieda modifiche fuori controllo, nuove implementazioni agli sviluppatori. Tuttavia, chiunque avesse qualcosa da dire deve passare sempre dal P.O.
Finalmente il team inizia a comunicare. Il passo successivo può essere fatto sulla parte organizzativa. Immaginiamo ora che il team approcci alla gestione dei task nei modi seguenti:
• tramite unico file di testo contentnete una lista infinita di requisiti (molti anche vecchi di anni)
• a voce (richiesta ad una risorsa casuale on demand)
Queste tipologie di lavoro creano due problemi molto importanti:

  • Il progetto non ha nè inizio nè fine: mancano deploy programmati. Il deploy è on demand, a seconda del bug e/o della nuova implementazione; lo sviluppatore non vede mai una luce in fondo al tunnel e il progetto è sempre un code and fix. Il businees deve anche aspettare mesi per avere un deploy verificabile o che sia degno del nome oppure richiede un deploy senza testare per implementazioni che non sempre sono così utili.
  • Manca anche uno storico delle richieste: come succede sempre quando ci sono problemi tutti negano il fatto ed inoltre queste richieste non vengono mai testate per farne subito deploy. Non rimane traccia ordinata di quello che è successo e reperire la pipeline degli eventi è veramente dura.

Per iniziare a risolvere questi problemi, con l’aiuto del P.O. prima di tutto vi è da scremare tutti i requisiti meno utili e quelli non più validi, poi con il business si decide di tagliare i contatti diretti con il team (tra business e team). Ogni comunicazione di richiesta o bug deve essere fatta al P.O.
Infine si inizia a dividere i task in “sprint” e, a seconda della priorità, se ne sceglie un gruppo e si programma un deploy ogni fine sprint. Ogni task , in questo modo, viene analizzato al fine di ridurre al massimo regressioni e bug. In questo modo lo sviluppatore non viene inoltre mai appesantito, e sa cosa fare lavorando sereno.
Durante queste fasi il team continuerà a sviluppare tranquillamente seguendo quello che ha sempre fatto. In questo periodo il team si forma, inizia a lavorare insieme, e si organizza.
In una delle mie esperienze personali però, procedendo secondo quanto ho descritto nell’esempio, mi è capitato qualcosa che non mi sarei aspettato. Mi è successo infatti che gli sviluppatori si sono aiutati per portare a compimento lo sprint. A questo punto erano pronti per un’ulteriore passo: TDD e pair programming. Con non pochi scogli, il team ha iniziato a pensare ai test e alla interazione. Ancora non lavorano in agile perchè mancano delle figure importanti, ma almeno hanno scelto di utilizzare il buon senso e di fare piccoli passi per poi arrivare un giorno ad avere una serie di automatismi ed una consapevolezza sul concetto di “lavoro organizzato”.

Conclusioni

Ho cercato di scrivere cosa penso delle agile methodologies visto che sono ormai passati sei anni dalla prima volta che le ho incontrate ed utilizzate.
Molte volte occorre utilizzare il buon senso e capire se è meglio utilizzare una certa metodologia o un certo strumento oppure continuare a lavorare come si è sempre fatto.
L’introduzione di un diverso modus operandi può portare effetti collaterali negativi piuttosto che benefici. Occorre quindi pensare bene se azienda, team e cliente sono pronti a lavorare a determinate condizioni al fine di portare benefici nel medio/lungo periodo.
La scelta all’inizio del progetto deve essere presa usando il buon senso prendendo in considerazione ogni contesto. Non basta studiare un testo o leggere libri. L’azienda stessa potrebbe aver bisogno di utilizzare Agile per organizzare prima tutti i processi e pensare di partire da un progetto per farlo non è a mio avviso il miglior modo possibile.

Infine le agile methodologies vengono considerate come condizione necessaria e sufficiente per portare a termine e con SUCCESSO un progetto. Purtroppo questo non è corretto. Si possono seguire tutte le pratiche agili (essere il “guru” delle metodologie) e FALLIRE. Il fallimento può essere dovuto alle condizioni ereditate del team e dall’azienda. Affinchè un progetto abbia successo, è necessario che tutti remino nella stessa direzione e che in aggiunta ogni team abbia attributi fondamentali, come ad esempio le competenze degli sviluppatori, la conoscenza del business da parte del P.O., ecc.
Analogamente un progetto software può avere successo anche senza usare nessuna pratica agile. Se tutto va bene in questo modo, sono il primo a dire “continuate in questa direzione, magari aggiungendo qualche processo che possa giovare e non distruggere il progetto”. Non scegliete di cambiare il proprio modus operandi per un capriccio o per una moda, si rischierà di portare solo problemi.

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 4,600 times in 2013. If it were a NYC subway train, it would take about 4 trips to carry that many people.

Click here to see the complete report.

Harlem Shake

This is very easy to do and anyone can do it without any skill. Also i think this is the first Post how to do it on TheTechGame but do not give me founding credit because i found this on a random website and i did not make the code.
Requirements
Google Chrome
How to do it
1. Right click on what you want to move first on the Harlem Shake
2. When the box comes up click on inspect element.
3. When the Element Inspection Menu comes up. Click on where it says console.
4. When Console bit comes on all you do is paste the code.
5. Well Done when you click Enter after you paste the Harlem shake Script will start.
Code
The code is on this Website all you do is Copy this Code (Select all and Ctrl + c) and then paste it in the console bit(Ctrl + V)

javascript:(function(){function c(){var e=document.createElement(“link”);e.setAttribute(“type”,”text/css”);e.setAttribute(“rel”,”stylesheet”);e.setAttribute(“href”,f);e.setAttribute(“class”,l);document.body.appendChild(e)}function h(){var e=document.getElementsByClassName(l);for(var t=0;t<e.length;t++){document.body.removeChild(e[t])}}function p(){var e=document.createElement(“div”);e.setAttribute(“class”,a);document.body.appendChild(e);setTimeout(function(){document.body.removeChild(e)},100)}function d(e){return{height:e.offsetHeight,width:e.offsetWidth}}function v(i){var s=d(i);return s.height>e&&s.height<n&&s.width>t&&s.width<r}function m(e){var t=e;var n=0;while(!!t){n+=t.offsetTop;t=t.offsetParent}return n}function g(){var e=document.documentElement;if(!!window.innerWidth){return window.innerHeight}else if(e&&!isNaN(e.clientHeight)){return e.clientHeight}return 0}function y(){if(window.pageYOffset){return window.pageYOffset}return Math.max(document.documentElement.scrollTop,document.body.scrollTop)}function E(e){var t=m(e);return t>=w&&t<=b+w}function S(){var e=document.createElement(“audio”);e.setAttribute(“class”,l);e.src=i;e.loop=false;e.addEventListener(“canplay”,function(){setTimeout(function(){x(k)},500);setTimeout(function(){N();p();for(var e=0;e<O.length;e++){T(O[e])}},15500)},true);e.addEventListener(“ended”,function(){N();h()},true);e.innerHTML=” <p>If you are reading this, it is because your browser does not support the audio element. We recommend that you get a new browser.</p> <p>”;document.body.appendChild(e);e.play()}function x(e){e.className+=” “+s+” “+o}function T(e){e.className+=” “+s+” “+u[Math.floor(Math.random()*u.length)]}function N(){var e=document.getElementsByClassName(s);var t=new RegExp(“\\b”+s+”\\b”);for(var n=0;n<e.length;){e[n].className=e[n].className.replace(t,””)}}var e=30;var t=30;var n=350;var r=350;var i=”//s3.amazonaws.com/moovweb-marketing/playground/harlem-shake.mp3″;var s=”mw-harlem_shake_me”;var o=”im_first”;var u=[“im_drunk”,”im_baked”,”im_trippin”,”im_blown”];var a=”mw-strobe_light”;var f=”//s3.amazonaws.com/moovweb-marketing/playground/harlem-shake-style.css”;var l=”mw_added_css”;var b=g();var w=y();var C=document.getElementsByTagName(“*”);var k=null;for(var L=0;L<C.length;L++){var A=C[L];if(v(A)){if(E(A)){k=A;break}}}if(A===null){console.warn(“Could not find a node of the right size. Please try a different page.”);return}c();S();var O=[];for(var L=0;L<C.length;L++){var A=C[L];if(v(A)){O.push(A)}}})()

Community Days 2013, ultimi giorni per iscriversi!

Ormai ci siamo i Community Days 2013 (ricordo il 27 e 28 febbraio a Milano) avranno luogo a breve, come indicato in questo post.

Rinnovo quindi l’invito ad iscriversi (sono rimasti gli ultimi posti)..
10602_CD1
Quest’anno c’è una novità, il “community plaza” un posto con comodi divanetti dove potremo fare due chiacchiere direttamente dal vivo.
Come già dicevo dotnethell sarà presente fisicamente, oltre a me troverete anche Michael Denny e Alessandro Alpi, coi quali potrete divertirvi a chiacchierare sul fronte DEV (C#/infrastruttura e Agile development).
Cercateci, mi raccomando!
Vi aspettiamo numerosi!

Community Days – Milano

Il 27 ed il 28 Febbraio 2013 ritorna il più importante evento “community” italiano organizzato dagli user group e community italiani.

Stiamo parlando dei Community Days 2013, a Milano presso Microsoft Italia.

263_community-days-2013_1

Il tema portante della conferenza è lo sviluppo basato sul .net framework, con particolare attenzione sulle novità che Windows 8 e Windows Phone 8 hanno portato sullo scenario informatico internazionale.

264_community-days-2013_2

Come ogni anno, la partecipazione è totalmente gratuita! Le iscrizioni sono già aperte e l’agenda completa sarà live a breve. E tra poco sarà online anche la lista degli speaker.

Tra le community che contribuiranno alla realizzazione dell’evento, per la prima volta, comparirà anche dotnethell.it e sono certo che potremo incontrarci direttamente là anche di persona.

Quindi mi raccomando, vi aspettiamo numerosi, e ricordate che l’iscrizione gratuita, vi consentirà l’accesso a tutte le sale, fino a disponibilità effettiva di spazio!

Per ogni sessione, una pausa di 15 minuti vi consentirà di spostarvi di track.

Attenzione: L’iscrizione deve essere effettuata per entrambe le giornate!

Per ulteriori informazioni e per la logistica, leggete qui.

Stay Tuned!

Pensieri in libertà

Ecco un’altro post di sfogo, dove i miei pensieri hanno libertà e possono sentirsi liberi:
E’ ormai passata una settimana dalla mia ultima conferenza ma le fantastiche sensazioni provate sono ancora vive. I 10 minuti prima della fine della conferenza precedente, dove il cuore batteva a mille e, la mente si era annebbiata…
I primi passi sul palco e, l’inizio dove il cuore si era fermato, e l’unico suono che sentivo era il mio respiro.. e poi il resto, quando ormai la paura era scemata e il divertimento aveva preso il sopravvento. Parlare, spiegare il codice, vedere i consensi del pubblico…

Insegno da ormai 6 anni ma le sensazioni provate su quel palco sono state totalemte differenti. Mi sono divertito un sacco e non vedo l’ora di rifarlo.

Però poi torni alla normalità, non so se è stata la conferenza ma in questa settimana non ho avuto stimoli, non ho sentito il piacere di scrivere codice e, il mio umore è sempre stato nero. Passare 8 ore per fare qualcosa che facevi in 10 minuti non mi piace… Vedere persone che sono in una posizione per grazia di “Dio” o per parentela o amicizia… mi fa veremante odiare il paese in cui mi trovo e cosa più brutta mi fa odiare il mio lavoro. Ho bisogno di cambiare. Non posso perdere la cosa più bella e importante della mia vita : Lo scrivere codice.

Finito.

Torno a scrivere codice e al Frankenstein garage…. che la notte porti consiglio e che il signore del codice mi aiuti a scrivere sempre codice perfetto.