Menu
Menu
Contattaci
Dal 2006 la nostra azienda ha come obiettivo quello di riuscire a trasformare l’entusiasmo di un progetto in una soluzione tecnologica che diventi un vero e proprio strumento per evolvere o accelerare il business dei nostri clienti.
Vai su GiunecoIl manifesto AGILE descrive dove e come porre l’attenzione nello sviluppo del software; tuttavia, negli anni successivi alla sua definizione, questi concetti sono stati espressi e descritti in framework o metodologie in grado di guidarne l’applicazione pratica; i due più noti ed utilizzati sono SCRUM e Kanban (con la K maiuscola).
Questi framework sono stati ideati e pensati per essere applicati in quei contesti in cui erano più necessari, ovvero in grandi società di prodotto che si trinceravano dietro a contratti e processi.
Il framework SCRUM è molto efficace per team che collaborano ad un unico obiettivo ben definito, ovvero team di prodotto o progetti molto ampi. Uno dei principali compiti del team è armonizzare il lavoro e rendere costante e prevedibile il tempo di sviluppo. All’interno della vita del team ci sono dei momenti specifici in cui questo si riunisce per stimare le storie e/o le epiche, per analizzare i singoli task, etc… Tutto questo è necessario affinché il Product Owner possa dare la corretta priorità alle attività da sviluppare, al fine di rispondere al meglio alle richieste del business. È importante notare che in questo contesto il tempo speso nelle attività di stima non è tempo perso, poiché permette di identificare tutte quelle azioni che portano il maggior valore con il minore sforzo.
Il ciclo di vita appena descritto differisce da quello di una società di servizi, a partire dal primo contatto con il cliente. In una società di servizi, quasi immancabilmente il cliente, che sta chiedendo di svolgere un lavoro su commessa, pronuncia la fatidica frase:
“ma quanto mi costa?”
Esistono molte tecniche per gestire questa domanda e nei prossimi articoli approfondiremo i contratti agili, gli workshop e la composizione dei team; per adesso limitiamoci ad asserire che accettiamo la sfida di trovare una risposta. Riflettendoci meglio, quante volte ci è capitato di ingaggiare un meccanico, idraulico, imbianchino muratore o artigiano qualsiasi, senza chiedere “ma più o meno quanto vado a spendere?”? Quasi mai.
Ho provato quindi a mettermi in gioco e rispondere alla stessa domanda che anche io pongo quando ingaggio un professionista.
È importante sottolineare che tali risposte sono frutto di esperienza maturata sul campo e tentativi fatti in prima persona, mettendoci in gioco come azienda.
Intraprendere un percorso simile è un investimento che va valutato con attenzione e razionalmente, deve essere intrapreso con lo scopo di perfezionare questa metodologia con il tempo, avendo ben chiaro l’obiettivo: l’ottenimento di profondi benefici in termini di qualità, business e skills professionali.
L’azienda però deve esser conscia e pronta a prendersi in carico eventuali rischi o costi imprevisti, in modo da poterli assorbire senza gravare sul cliente, qualora la metodologia inizialmente testata non dia nel breve termine i frutti sperati. In questo modo, tramite esperimenti e soluzioni plasmate per la propria realtà, si potrà trovare la perfetta via per applicare la metodologia agile in azienda.
Prima però di addentrarci nel vivo della questione economica, vediamo in questo articolo due approcci che abbiamo sperimentato: il tipo “ligio alle scritture” e il tipo “spregiudicato”.
Il primo approccio è stato quello del “ligio alle scritture”; ovvero implementare in maniera dogmatica quanto descritto da SCRUM. Ho quindi chiesto al Product Owner di fare una full immersion di qualche ora con il cliente e confrontarsi con il team per produrre epiche, user story e relative stime di effort, utili a produrre un preventivo “a corpo”. Dopo qualche tentativo abbiamo capito che:
Durante una retrospettiva ci è risultato chiaro che stavamo cercando di dare priorità al processo/tool, ovvero SCRUM, invece di dare la precedenza alla collaborazione con il cliente ed alla creazione di software di valore per esso. Dopo aver sperimentato e misurato questa strategia, abbiamo deciso di cambiare rotta.
Il secondo approccio che abbiamo percorso è stato: niente progetti, niente preventivi, solo lavoro di team. Dopo vari approfondimenti sulla letteratura (come ad esempio “Extreme Contracts” di Jacopo Romei), abbiamo provato a proporre ai nostri clienti il “nostro” contratto Agile.
Ci siamo posti, come obiettivo più importante, quello di aiutare il cliente a guidare la roadmap di sviluppo in modo da massimizzare il valore creato, fornendo un PO che potesse riferirsi direttamente ai decision maker e un team cross funzionale che avesse al suo interno tutte le competenze necessarie. Questo ci permette di mantenere i prezzi di mercato senza abbassare la qualità del prodotto.
Abbiamo proposto, lavorato e tutt’ora usiamo questo tipo di contratti con alcuni dei nostri clienti selezionati; tuttavia, esistono delle condizioni necessarie per renderli efficaci e profittevoli per entrambi. Prendiamo per esempio un classico contratto “money for nothing and changes for free”. Questo tipo di contratto stabilisce un prezzo per un team cross funzionale che sia in grado di produrre un determinato ammontare di valore ad intervalli regolari. Nel caso in cui ci siano cambi di pianificazione, non esistono vincoli se non quello di tenere costante il valore per unità di tempo. Tipicamente stimiamo le user story e andiamo a dichiarare un numero di storie per sprint; in questo modo, se il cliente vuole cambiare priorità ad una attività, dovrà semplicemente interfacciarsi con il PO e scambiarla con un’altra con la stessa stima.
Anche in questo tipo di ingaggio con il cliente, le sfide sono molteplici:
Per questo tipo di contratto selezioniamo clienti che abbiano già un rapporto con noi e con cui abbiamo creato un rapporto di fiducia, oppure clienti di cui conosciamo il dominio applicativo. Questo ci permette di essere fin da subito efficaci nella pianificazione.
Oltre a questo, valutiamo la capacità del cliente di stare al passo con lo sviluppo senza creare quei vuoti di lavoro complicati da gestire. Infine, come organizzazione del lavoro e delle maintenance abbiamo chiesto ai team di ricavarsi degli spazi per gestire tutto il ciclo di vita del software. Questo frammenta un po’ il lavoro, ma permette alle persone di avere la possibilità di imparare e crescere non relegando alcuni team alla maintenance.
Purtroppo alcuni clienti non accettano comunque questi tipi di contratti, soprattutto al primo approccio.
Nel prossimo appuntamento parleremo di come abbiamo cercato di rispondere meglio alla domanda
“ma quanto mi costa?”
ma non solo, approfondiremo anche il tema
“Come creare dei team agili”
ed infine faremo una panoramica su come siamo riusciti a implementare in maniera efficace la metodologia agile in Giuneco.
Segui Giuneco sui social