Il team di ricerca e sviluppo (R&D) è il team più grande all’interno della Business Unit System Integration (SI) di Wuerth Phoenix. Siamo responsabili dello sviluppo, manutenzione e della alta qualità di software per i nostri clienti. Inoltre, cooperiamo con il team di Service&Support per supporti di secondo livello.
Dalla sua istituzione, il dipartimento SI è stato uno dei dipartimenti con un grado di crescita maggiore tra tutte le Business Unit di Wuerth Phoenix. Questa rapida crescita ha influenzato anche il nostro team e ci ha forzato a fronteggiare molteplici sfide in diversi campi, tra le quali: distribuzione del carico di lavoro, stabilire le priorità tra i vari task, uso efficiente del tempo, trasferimento del know-how e un costante aumento di collaboratori.
Per mantenere bassa la delivery time e, allo stesso tempo, mantenere alta la qualità del prodotto e la motivazione dei collaboratori, abbiamo dovuto prendere una decisione è da qui che è nata l’idea dell’Agile Transformation.
Prima di tutto abbiamo riorganizzato il nostro team: da tanti e piccoli team specializzati su un’unica specifica di prodotto ad un unico R&D team. Questo nuovo team è più flessibile e permette una migliore allocazione delle risorse e del know-how. Finalmente, nella primavera del 2016, la nostra organizzazione è passata ad essere da “waterfall” a “full agile development”.
Questa trasformazione agile, capitanata dal professor Werner Wild, ben conosciuto per il suo “agile expertise” nel mondo IT, ha avuto un grande effetto sull’approccio ai problemi e sul modo di apportare miglioramenti.
Per poter dare al lettore un quadro generale dettagliato e semplice, ciascuno dei seguenti capitoli tratterà una tematica diversa, dai processi di sviluppo ai cambiamenti dell’organizzazione, passando per i nostri obiettivi.
Metodo Agile & Task Management
Come primo step abbiamo cercato le radici dei nostri limiti e una possibile soluzione applicabile per risolverli, tenendo in considerazione anche le necessità del team. Sin dall’inizio abbiamo optato per i principi Lean Software Development come base e un’organizzazione Multi-Kanban per il Task Management (per questo argomento ci sarà un post dedicato). Come supporto digitale abbiamo utilizzato il software stack di Atlassian (BitBucket, JIRA, Confluence, e HipChat)per l’organizzazione di source code, problemi e informazioni.
Per tener traccia in ogni momento dell’andamento della riorganizzazione ci siamo muniti di tre lavagne Kanban e due grandi monitor per le nostre Dashboard/Andon. Poi abbiamo provveduto a suddividere la nostra giornata lavorativa in 4 fasce orarie, di due ore ciascuna, e ci siamo sforzati di rispettare queste suddivisioni al fine di minimizzare le interruzioni.
Una volta terminati i preparativi, abbiamo finalmente avuto prova di ciò che già sospettavamo durante le analisi: la tendenza a dare priorità a troppi problemi simultaneamente, con il rischio di entrare in un circolo vizioso in cui tali problemi vengono continuamente “prioritizzati” ma difficilmente vengono sistemati.
Avere una rappresentazione visiva sulla lavagna Kanban dei compiti permette di avere più sotto controllo la situazione e subito dopo l’installazione e’ stata una grande soddisfazione per tutti vedere giorno dopo giorno quei compiti ridursi di numero. Una volta raggiunto un certo minimo di task sul Kanban, abbiamo potuto fissare un limite di carico di lavoro contemporaneo in corso (massimo di task per ogni step).
A questo punto abbiamo deciso di quantificare anche il massimo carico di lavoro per ogni compito, che può essere dalle due ore ai due giorni. Per questo abbiamo anche suddiviso i problemi più complessi in più problemi minori, e raggruppato compiti che non durano come minimo due ore. I vantaggi derivati da questo sistema sono molteplici:
- Prevedibilità: quando un problema è complesso e finisce nella coda di sviluppo attivo, il tempo che impiega per essere risolto non supererà i due giorni.
- Consegne veloci: valore aggiunto per i clienti grazie alla possibilità di essere sempre aggiornati sulle nuove release
- Eliminazione degli sprechi: un compito incompleto non aggiungerà mai valore al prodotto. Visto che adesso completiamo e rilasciamo continuamente, i nostri prodotti traggono profitto direttamente dai nuovi sviluppi.
- Qualità: tre step su quattro del nostro Kanban principale sono collegati alla qualità prodotta (sviluppo, test e revisione)
Automazione
Il nuovo processo automatizzato del code deployment richiede un controllo qualitativo adeguato e similmente automatico. Non solo pero’ rilasciamo e testiamo continuamente, ma siamo anche riusciti ad automatizzare tanti passaggi ripetitivi che, se eseguiti manualmente, richiedono molto tempo. Per ogni task automatizzato usiamo Jenkins (prima Hudson), che sarà il tema di una prossima serie di articoli. Al momento vi offro una breve anteprima:
- Integrazione continua: nasce direttamente dai nostri dipartimenti di sviluppo e supporto
- Deployment continuo: Deployment automatico di nuovi pacchetti, direttamente da BitBucket che gestisce anche il repository di destinazione.
- Test continuo: Integration- e UnitTests (+ 4 Selenium istanze) eseguiti ogni volta che viene eseguito un commit, in combinazione con la notifica di fallimento sul nostro Dashboard/Andon per soddisfare i principi Lean Developments “Fail Fast”.
Ogni giorno ci impegnamo a riconoscere i task ripetitivi e cerchiamo di capire il modo migliore per poterli automatizzare e risparmiare tempo. Questo è un processo di ottimizzazione continuo, quindi non sarà mai completo. Ciononostante, il tempo dedicato alla creazione degli script tenderà a diminuire e il tempo recuperato grazie alle soluzioni automatizzate verrà impiegato per altri ordini. Esempi pratici del nostro lavoro quotidiano consistono in full-release, auto-generazione di cartellini Kanban e rilevamento del tempo.
Visualizzare l’insieme
Per monitorare ed avere un feedback immediato sulla gestione delle emergenze, progressi, ultime release, jenkins jobs, metriche ecc…, utilizziamo una soluzione open source facile da gestire e facile da estendere Dashing che viene esposta sulla Dashboard nel nostro ufficio. Anche questo argomento verrà trattato approfonditamente in un articolo a parte.
Riunioni giornaliere e retrospettive settimanali sono state introdotte per condividere le informazioni, auto valutarsi, identificare i rallentamenti nel processo, pianificare eventi e risolvere collettivamente i problemi importanti. Questo permette anche ai nuovi membri del team di ottenere le informazioni e le abilità necessarie in meno tempo.
Inoltre, cerchiamo di documentare tutto, non solo nel codice, ma anche in Atlassian Confluence, al fine di incoraggiare tutti i membri del team a lavorare su argomenti poco conosciuti. Il risultato è che tutti i componenti del team acquisiscono esperienza e conoscenza su ogni progetto.
Obiettivi
Siamo partiti da un sistema obsoleto e insieme abbiamo identificato le cause e, grazie alla guida del professore Wild, abbiamo impostato degli obiettivi strategici che, una volta raggiunti, causano allo stesso tempo la risoluzione delle diverse problematiche.
Per esempio, l’imposizione del tempo massimo di risoluzione di un task a 1-6 Timeslot (massimo 2 giorni), che permette di prevedere il tempo e l’impegno necessario. Anche la lavagna Kanban permette al team di ristrutturare il carico di lavoro, riducendo gli sprechi dovuti al cambiamento di contesto e task non finiti, così da risparmiare tempo e soldi.
L’automatizzazione dei task ha permesso di contrastare gli sprechi e, nonostante abbiamo investito parecchio tempo nella sua realizzazione, già adesso possiamo apprezzarne i benefici. Se prima manualmente si impiegava 1 ora per rilasciare un pacchetto (dall’ultimo commit al rilascio sul repository RPM), adesso ci si mette 3 minuti al massimo.
Test automatici e manuali, pair programming e code reviews hanno un impatto significativo sulla qualità del codice.
In conclusione, grazie alla trasformazione Agile abbiamo implementato un ambiente che ci permette di rispondere tempestivamente ed efficacemente ai cambiamenti e alle novità. Personalmente lo considero un grande successo.
Benjamin Gröber
R&D Software Architect at Wuerth Phoenix
Hi, my name is Benjamin, and I'm Software Architect in the Research & Development Team of the "IT System & Service Management Solutions" Business Unit of Würth Phoenix.
I discovered my passion for Computers and Technology when I was 7 and got my first PC. Just using computers and playing games was never enough for me, so just a few months later, started learning Visual Basic and entered the world of Software Development. Since then, my passion is keeping up with the short-lived, fast-paced, ever-evolving IT world and exploring new technologies, eventually trying to put them to good use. I'm a strong advocate for writing maintainable software, and lately I'm investing most of my free time in the exploration of the emerging Rust programming language.
Author
Latest posts by Benjamin Gröber
25. 11. 2022
Development
What is the perfect development team size?