Italian Agile Day 2011 schedule

Saturday 19th November 2011

  • Back to Basics: OOP and Design

    by Paolo Polce

    Non c’è Agile Software Development senza Software Developers. Rimettiamo l’attenzione sul lavoro quotidiano, da sviluppatore, che siamo chiamati a fare. In questa sessione parlerò di Design, di OOP, di coesione, messaging, commands&queries, interfaces and inheritance, puntando alla loro incredibile semplicità. Parlerò poi degli errori che si commettono nei test, nel prendere come Bibbia i pattern, nel guardare al problema dalla prospettiva errata.

    At 9:40am to 10:40am, Saturday 19th November

  • Capire e gestire il debito tecnico

    by Alan Franzoni

    Il debito tecnico è un concetto non nuovo, ma spesso, volutamente o meno, sottovalutato, ignorato, mal stimato, compreso soltanto quando è troppo tardi; può facilmente condurre al fallimento di un progetto o a ritardi incolmabili

    Non sempre viene riconosciuto: progetti ben avviati possono rallentare fino ad arenarsi sotto il suo peso, senza che lo stesso sia chiaro. Altre volte viene utilizzato intenzionalmente da parte degli sviluppatori, ma è mal comunicato alla dirigenza, e provoca una divergenza tra le aspettative di quest’ultima e le reali possibilità di sviluppo.

    Nel corso dell’intervento, dopo aver chiarito il concetto di debito tecnico, saranno identificate alcune delle sorgenti più comuni di debito, e sarà proposto un modo per visualizzarlo, esprimerlo e comunicarlo, e spiegare ciò che ne deriva (interesse, incertezza). Verranno inoltre suggeriti i casi in cui è da evitare e i casi in cui può essere opportunamente sfruttato per centrare gli obiettivi prefissati.

    At 11:00am to 12:00pm, Saturday 19th November

  • Codice Legacy, usciamo dal pantano!

    by Stefano Leli and Simone Casciaroli

    Avete mai provato la sensazione di essere immersi in una melma di codice putrido e maleodorante e di non riuscire a venirne fuori nonostante tutti i vostri sforzi?

    In questo workshop si cercherà di simulare proprio questo scenario proponendovi un esempio di progetto mal scritto e che sarete chiamati in prima persona a rifattorizzare.

    Nel nostro ruolo di coach vi faremo capire come riconoscere il codice che ha bisogno di essere migliorato, ed applicando i solid principles verrete guidati verso un buon design in grado di portarvi in acque più sicure e pulite.

    At 11:00am to 12:00pm, Saturday 19th November

  • eXtreme Programming, Timeboxing and Kanban

    by Filippo De Santis

    This speech will focus on how a PHP Company starting with XP is ending up using timeboxing and kanban, keeping alive the values and principles of an extreme programming development team.

    Not only are the programmers trying to push forward those values, but also the management is trying to build a better company through systematic communication, clear objectives, understanding of individuals and interactions, working software, customer collaboration and responsiveness to change. This talk will focus on the positive and negative experiences my colleagues and I have had during the last year as managers and developers.

    I will begin showing the problems my company had. Then, I will present the solutions we adopted to solve those problems. Finally, I will briefly explain how an activity “flows” through our workflow.

    At 11:00am to 12:00pm, Saturday 19th November

  • GARAGE BAND – Dinamiche di un team, dinamiche di una live band

    by Jacopo Franzoi

    Confronto dell’esperienza personale come musicista in un gruppo musicale (sala prove, organizzazione eventi, live e distribuzione materiale) con quanto accade in un team di sviluppo software, e mostro in che modo XP possa mitigare problemi comuni o favorire situazioni vincenti. E cosa può andare male!

    Di fatto voglio evidenziare analogie tra le dinamiche in una band musicale (vista da dentro) e quelle in un team di sviluppo software, facendo emergere in che modo XP possa mitigare problemi comuni o favorire situazioni vincenti. E sopratutto cosa può andare male.

    Ecco alcuni esempi: la tendenza ad imporre un proprio stile (vs. ownership collettiva), la fase collaborativa dell’arrangiamento (cfr. pair programming), l’impegno richiesto a discapito di altre cose (cfr. pratiche e cambio delle proprie abitudini).

    Vorrei affrontare poi alcuni possibili epiloghi nella vita di una band, ad esempio: “ragazzi, io mollo” (cfr. turnover), concerti sottopagati e “così non camperemo mai con la musica” (cfr. stime e imprevisti), accettare ingaggi in locali “commerciali” (cfr. abbandono di valori e pratiche).

    La “morale della storia” è evidenziare le caratteristiche di una “grande” live band (cfr. un team XP efficace), ovvero: gruppo coeso, con obiettivi chiari e condivisi (cfr. valori condivisi messi in pratica), che sul palco regala grande spettacolo, divertendosi (cfr. soddisfazione del cliente e divertimento nel team).

    At 11:00am to 12:00pm, Saturday 19th November

  • Is Software Evolution really Effective?

    by Francesco Cirillo

    Agile Methods propose software evolution and emergent design techniques as the key elements needed to effectively manage software development: agile processes are built on incremental development, continuous delivery, refactoring/emergent design. Nevertheless the number of mature agile teams not improving their productivity even when continuously applying and improving evolutionary practices is increasing.

    Francesco’s thesis is that evolution and emergency of design are properties we can observe but they are not generative principles: hence considering evolution and emergent design techniques as being the key factors of software production is misleading. Evolution and emergent design techniques are results of the internal construction strategy each developer applies when making each and every programming decision. This strategy can favour or prevent effective evolution: for sure if the developer is not aware of the existance of such a strategy, evolutionary development certainly leads to failure.

    Francesco began to study the effectiveness of evolution in software development in 2005 at XPLabs. The research was initially aimed at providing an explanation for biased results on a number of apparently “”well-done”" projects. XPLabs’ teams maintained process and product metrics on a pomodoro basis, thus favoring the study of the team production function for those projects. Francesco’s investigation continued on through the Anti-IF Campaign, which allowed him to study the code of all its supporters. Last but not least he gathered more data related to digital product development in etherogenous fields working as the Head of the Anti-IF Task Force, mentoring and coaching external teams in Europe.

    In order to learn how to distinguish effective evolution and practice of emergent design techniques Francesco proposes a different way of reading and applying the ROI metric using real product development data. This will help teams to identify when dysfunctional evolutionary development happens, even when they successfully applies incremental development, continuous delivery, refactoring, tdd and other related evolutionary/emergent practices.

    At 11:00am to 12:00pm, Saturday 19th November

    Coverage video

  • Corso di cucina fusion Elettro-Agile con Arduino

    by Paolo Aliverti

    Prendete una Arduino board, alcune linee di codice, una cucchiaiata di breadboard. Spolverate con dei componenti passivi. Saldate a 200° con buono stagno. Versate in una pentola e mescolate il tutto con metodo Agile. Lasciate raffreddare per pochi secondi. Servite il vostro prototipo elettronico e lasciate di stucco i vostri clienti! Ecco la ricetta per creare rapidamente prototipi elettronici su cui sviluppare i vostri prodotti di successo. Lo sviluppo Agile si puo’ applicare anche all’elettronica senza essere grandi esperti di circuiti. Durante il workshop spiegheremo come costruire un prototipo per dimostrare il nostro approccio in un contesto diverso dal software.

    At 12:10pm to 12:55pm, Saturday 19th November

  • Lean, A3 e Kaizen

    by Claudio Perrone

    Dopo il successo che questa presentazione sta riscontrando nel resto d’Europa, Claudio porta finalmente in Italia gli strumenti che forse meglio catturano l’essenza del pensiero Lean.

    In questa sessione, seguirai la storia di un sensei che sta guidando i team verso un percorso di continuo miglioramento e sta utilizzando sistemi di continuo miglioramento (Kaizen) e processi di problem solving strutturato (A3 thinking) per facilitare una trasformazione Lean a livello enterprise tuttora in corso.

    At 12:10pm to 12:55pm, Saturday 19th November

    Coverage video

  • L’usabilità delle parole

    by Yvonne Bindi

    Esistono casi in cui l’usabilità ha a che fare con le parole, con ciò che mi piace definire l’usabilità delle parole. Ci sono parole che pur appartenendo (ovviamente) alla sfera del linguaggio hanno precise conseguenze nella sfera dell’azione, come ad esempio le parole sui comandi delle interfacce. Credo si possa parlare della loro usabilità proprio perché esse si usano; si usano all’interno di un preciso contesto (quello di un’interfaccia) e con un preciso scopo e possono essere più o meno facili da usare. Un esempio, i due pulsanti in grigio sono più faticosi da usare rispetto ai secondi in rosso, anche se hanno la stessa funzione, e ciò dipende solo dalla loro parte testuale.

    Parole (o gruppi di parole) come Entra, Invia, Prosegui, Torna indietro, Guarda di nuovo, si fondono con l’azione che indicano, sono l’azione che indicano e allo stesso tempo sono parte dell’oggetto che permette l’azione (in genere un pulsante o un link), sono come gli interruttori della luce sui muri, come le manopole dei fornelli del gas, come le maniglie delle porte e ci permettono di agire e muoverci all’interno di ambienti virtuali. L’importanza della loro usabilità è lampante.

    Anche nella vita reale e quotidiana le nostre azioni sono spesso guidate o interdette da indicazioni, comandi che si esprimono attraverso della parole. Ad esempio i divieti, come il vietato entrare o il vietato fumare. Si tratta in genere di messaggi che elaboriamo con immediatezza, dati che il nostro cervello digerisce quasi senza scomodarci, producendo come risposte delle azioni.

    Queste sono le informazioni che in un ambiente reale (come una città) o virtuale (come un sito), dovremmo trovare velocemente e capire facilmente. Ma non sempre è così, anzi, alle volte sembra che ci sia chi ci si mette d’impegno per rendere difficili le cose semplici.

    Cosa vorrei raccontare? Nel mio intervento parlerò di alcuni casi di “non” usabilità delle parole. Si tratta soprattutto di esempi che ho potuto trarre dalla mia esperienza personale, da vicende di vita quotidiana, in cui parti testuali di indicazioni, tabelloni, etichette, menù, interfacce, restituiscono informazioni confusionarie, ambigue se non addirittura del tutto devianti rispetto al loro scopo reale.

    Alcuni dei casi che presenterò:

    Mi scusi dov’è il bagno?, una storia sulla forza delle parole, sulle etichette e su come funziona il nostro cervello.
    Multa assicurata ai varchi di Roma, una storia sul traffico, sull’inferenza e sulla capacità delle parole di dire il contrario di quanto affermano.
    Panini Freschi, storia di un menù un po’ confusionario e del nostro modo di leggere frettoloso e approssimativo, non solo sul web.

    At 12:10pm to 12:55pm, Saturday 19th November

    Coverage video

  • Spaghetti DevOps

    by Alessandro Franceschi

    Il movimento DevOps ha raggiunto una massa critica nel mondo IT che conta: “tutti” cercano DevOps sull’onda di un neologismo accattivante che racchiude un insieme di metodologie, processi, strumenti e approcci comportamentali che, in ultima analisi, servono a rendere il più possibile fluide e “frictionless” le operazioni IT. In Italia ci arriveremo, è la solita questione di tempo, con le modalità e le sfumature tipiche del nostro modo di fare.
    La presentazione descrive il mondo DevOps e indaga come questo possa entrare nelle realtà italiane.

    At 12:10pm to 12:55pm, Saturday 19th November

  • Startup senza falldown

    by Andrea Maietta

    Fare una app, anche se di successo, non significa fondare una startup. Una startup serve per trovare e sperimentare un modello di business sostenibile, quindi la prima cosa che i finanziatori chiedono è un business plan. Il modo migliore per prepararne uno è tirare un po’ di dadi (meglio quelli con tante facce del D&D per variare un po’ i numeri) e metterli su un foglio di calcolo, possibilmente accompagnato con una presentazione farcita di bullet point, grafici incomprensibili e descrizioni lunghissime mescolate a immagini di cattiva qualità.

    E poi? poi ci si scontra con il mercato: il nostro prodotto (o servizio) non interessa a nessuno, anche se ci abbiamo già speso un sacco di tempo, fatica e soldi. Ma ce ne siamo accorti troppo tardi (waterfall, anyone?).

    Per fortuna esistono strumenti alternativi: vedremo insieme come combinare customer development e il business model canvas per analizzare il business e verificare la bontà del modello scelto, per poi scoprire che lo sviluppo agile non è che l’implementazione del business model che ricerchiamo con il customer development.

    At 12:10pm to 12:55pm, Saturday 19th November

  • A soft skill suitcase

    by Fabio Armani

    Quale deve essere il bagaglio di soft skill che un agile coach deve conoscere e praticare, allo scopo di effettuare al meglio il proprio ruolo di mentore, coach e tutor del proprio team crossfunzionale?

    Se poi il nostro compito si estende a supportare anche il top management in un processo di Enterprise Transition Rollout, sarà necessario estendere lo spettro delle nostre conoscenze e capacità, allo scopo di raggiungere una visione sistemica di tutti gli aspetti.

    In questa sessione intendo dapprima rappresentare le principali sfide a livello di coaching nell’ambito dei team e quindi allargare l’ambito a livello Enterprise.

    Una volta rappresentato l’insieme delle problematiche approccerò e ipotizzerò alcune linee risolutive.

    At 2:30pm to 3:15pm, Saturday 19th November

  • Back to the basics hands-on

    by Antonio Carpentieri and Paolo Polce

    Guardiamo e proviamo insieme come, dove e perché i fondamentali sono tali e come ci possono aiutare a superare la linea che ci separa tra il “yes, I know” al “I do”.

    At 2:30pm to 4:25pm, Saturday 19th November

    Coverage slide deck

  • Boost your OOP with FP

    by Uberto Barbini

    Questa sessione si basa su due assunzioni:

    La maggior parte dei difetti sono causati da side-effect inaspettati sullo stato
    Dovrebbe essere considerato normale consegnare software privo di difetti.

    This talk is based on two assumptions:

    Most of the bugs are caused by unexpected state side-effects.
    It should be normal to deliver software with no bugs.

    I’ll present some interesting experiences about my architect-teamleader role, for two teams on big projects in a corporate environment. With Agile Methods it is possible to deliver quality software on time; but without the correct architecture the time it takes for every change will increase over time. I’ll present the lessons I learned.

    The problem: sw industry is in a dire situation, we cannot even agree on what is the meaning of “code quality”. One of the main reasons is that we forgot what OOP was meant to be. You can find examples of misleading definitions in popular Java books.

    OOP and FP are often seen as alternatives, but I believe FP can really help OOP go back to its origins: to simplify the encapsulation of status.

    The Solution: learn how to take full advantage of OOP+FP. I will show pratical examples of how clean our code can be. Interfaces, immutable objects, pure functions, hollywood principle entities, stateless services; they all help in keeping complexity at bay.

    The Path: how to get there from legacy code. Mostly unnoticed snippets from good books. How to use OOP to program in a Declarative way at high level, and Imperative way at low level. Most important: practice. How much time do you spend to improve your coding skill?

    At 2:30pm to 3:15pm, Saturday 19th November

  • Kaleidoscope

    by Roberto Romualdi

    Change Kaleidoscope: un approccio contestuale per il cambiamento organizzativo.

    Come gestire modifiche del modo di lavorare in un contesto organizzativo complesso? Cambiare, adattarsi ad un mercato che evolve velocemente e spesso in maniera imprevista o contraddittoria sono ormai parole d’ordine entrate a far parte della vita quotidiana di moltissime organizzazioni.

    Tra i molti framework che vengono proposti per analizzare i contesti organizzativi ve ne è uno, concepito da un gruppo di studiosi inglesi di business & organization, chiamato “Change Kaleidoscope” che in questo intervento verrà presentato nel dettaglio.

    L’idea parte dall’assunto che non sia possibile affrontare il cambiamento usando un algoritmo genericamente formulato (formulaic approach). Il motivo principale è il contesto organizzativo, sempre differente e dipendente da numerosi fattori i quali a loro volta sono in continua evoluzione (di qui l’analogia con le figure sempre differenti del caleidoscopio).

    In questa sessione saranno descritte le idee di base di quest’approccio che vede come primo passo l’analisi del contesto sulla base di alcuni indicatori osservabili (es. il tempo), che poi portano a determinare le scelte operative (design choices, ad es. lo stile da adottare per il cambiamento) e quindi il percorso da intraprendere per attuare il cambiamento. Saranno brevemente citati anche alcuni casi reali per meglio comprendere la teoria.

    At 2:30pm to 3:15pm, Saturday 19th November

  • Volevo solo scrivere codice

    by Alberto Brandolini

    Dal programmatore da solo a casa in una stanza buia, allo sviluppo software quale fattore determinante per la competitività. Cose da imparare, che non tutti vi dicono.

    At 2:30pm to 3:15pm, Saturday 19th November

  • La professione dello sviluppatore

    by Gabriele Lana

    Perché ogni 3 sviluppatori si sente la necessità di avere qualcuno che li controlli? Perché la carriera lavorativa di uno sviluppatore dura meno di quella di una ballerina classica? Se uno sviluppatore è un manovale, perché ci sono degli sviluppatori fra gli uomini più ricchi del pianeta? Perché Will Smith vorrebbe fare lo sviluppatore?

    Che lo si voglia o no, lo sviluppatore è al centro dello sviluppo del software e il software è al centro di buona parte dell’odierna attività umana. Capire il ruolo dello sviluppatore e la sua professione dovrebbe essere al centro di ogni metodo, agile e non.

    At 3:25pm to 4:25pm, Saturday 19th November

  • Overcoming Self-organization Blocks

    by Andrea Provaglio

    L’auto-organizzazione dei team è una caratteristica essenziale ed imprescindibile del mondo Agile, e che ha un suo valore anche in gruppi di sviluppo non Agile.

    Sappiamo che auto-organizzarsi è un fattore chiave per qualunque team di successo, e sappiamo che questo richiede fiducia, rispetto, disponibilità e responsabilità. Dunque, perché per molti team è così difficile raggiungere questo risultato?

    L’auto-organizzazione altera le dinamiche manager/team e all’interno dei team stessi, con possibili resistenze. La causa si trova spesso in varie abitudini mentali e comportamentali, quali: trovarsi in una cultura latente di colpevolezza; confondere guida e comando; paura di assumersi responsabilità o di perdere status; tratti collettivi.

    Questa sessione propone dei casi reali, vissuti dal relatore nella sua attività di coach per trasformazioni Agile, per illustrare alcune dinamiche che bloccano l’auto-organizzazione, le loro cause e quali sono i possibili rimedi.

    At 3:25pm to 4:25pm, Saturday 19th November

    Coverage video

  • UX e sviluppo agile – un’introduzione

    by Renato Mancuso

    Che cosa vogliono i miei utenti? Perché sono sempre scontenti? Come faccio a identificare prodotti e servizi innovativi? Scrum e XP ci dicono che è compito del product owner/onsite customer rispondere a queste domande. Purtroppo più spesso di quanto non si pensi neanche il PO/OC sembrano avere le idee molto chiare (ammesso di essere abbastanza fortunati da averne uno). Nella mia presentazione spiegherò cos’è la UX e illustrerò alcune delle tecniche di base (contextual inquiry, collaborative design, card sorting, etc…) per mostrare in che modo queste possono essere utili ad un team agile.

    At 3:25pm to 4:25pm, Saturday 19th November

  • Videogame e Agile una scelta vincente

    by Pierluigi Riti

    Il mercato dei videogame è in forte espansione. In questa sessione si parlerà di come utilizzare le metodologie Agili nello sviluppo di alcuni videogame per il web.

    Verranno presentate le problematiche della gestione di team distribuiti e cross-functional, in particolare gruppi formati sia da artisti, grafici, designer ecc., che da programmatori. Inoltre si parlerà di come creare un buon team di lavoro, per evitare che il progetto sia fallimentare sin dall’inizio. Non ci soffermeremo sul problema di una specifica API o di una specifica libreria, ma verranno affrontate problematiche più generali. Verrà spiegato come gestire mediante le metodologie Agili queste problematiche, inoltre verrà presentato come migliorare la qualità del prodotto finale. Verranno inoltre evidenziate tutte le fasi che servono alla realizzazione di un videogame, partendo dall’idea fino ad arrivare al risultato finale mostrando un esempio di quanto realizzato. Verranno introdotti alcuni software che vengono utilizzati per la realizzazione tecnico artistica del videogame.

    At 3:25pm to 4:25pm, Saturday 19th November

    Coverage video

  • Compromessi e non soluzioni, la dura vita di un commerciale agile

    by Francesco Fullone

    Uno dei più grandi problemi percepiti nel mondo agile è: “come faccio a far capire al commerciale che non può vendere un’applicazione al cliente senza aver discusso con il team di sviluppo?”. Uno dei più grandi problemi percepiti dai commerciali delle aziende agili è: “come posso far capire al team di sviluppo che senza un metro di riferimento economico non si vende nulla?”. La contrattazione è quindi necessaria non solo verso i clienti ma anche all’interno dell’azienda. Questo è il talk/confessione di un ex-sviluppatore passato al lato oscuro…

    At 4:45pm to 5:30pm, Saturday 19th November

    Coverage slide deck

  • Il grande bluff delle stime

    by Luca Grulla

    La letteratura agile ci insegna come stimare le storie sia una pratica fondamentale per il successo di un progetto. Story point, ideal hour e planning poker sono solo alcune delle tecniche che usiamo per stimare il lavoro da svolgere e per permettere al Product Owner di fare una scelta ponderata su priorita’ ed obiettivi da raggiungere. Eppure ci sono team altamente produttivi che non stimano il lavoro da svolgere.

    E…se tutta la teoria legata allo stimare agile fosse quindi un grande bluff? Se le stime fossero semplicemente una distrazione e il vero problema da risolvere fosse realmente un altro? cosa sanno questi “super team” che noi non sappiamo ?

    In questo talk partendo da esperienze reali analizzeremo la root cause che si nasconde dietro la necessita’ di stime, e capiremo quale e’ la mentalita’ che permette a determinati team di essere super performanti anche senza stime.

    At 4:45pm to 5:30pm, Saturday 19th November

    Coverage slide deck

  • Kanban = Pillola Viola

    by Gaetano Mazzanti

    Kanban [*] propone una pillola viola, né blu (nessun cambiamento), né rossa (cambiamento radicale). Kanban è un sistema per gestire il cambiamento, per evolvere dal blu al rosso in modo graduale. Il talk parte dall’osservazione che obiettivi e ragioni del cambiamento vengono sempre prima di qualsiasi metodo. Spesso si cerca invece di imporre una metodologia, un framework, a prescindere dal contesto e dalla situazione in cui deve essere applicato.

    Kanban inizia col visualizzare lo stato corrente e rappresentare cosa sta accadendo, evidenziando dove intervenire con cambiamenti graduali e non. Kanban deriva dal Lean e da questo eredita da una parte il rispetto le persone, il loro coinvolgimento e dall’altra l’applicabilità all’intera organizzazione. Si focalizza sulla produzione di valore, sulla ottimizzazione del flusso e sulla riduzione degli sprechi (esattamente in quest’ordine). Kanban è aperto e flessibile, rispetta i principi dell’Agile e limita il numero di regole imposte. Caratteristiche e responsabilità dei team e interazioni con il management sono uno degli aspetti che differenzia Kanban da altri approcci Agili.

    Ma non è tutto oro ciò che luccica: il rischio principale è di sedersi e accontentarsi di un nuovo standard appena migliore di quello iniziale. Vedremo come evitare che questo accada. La presentazione include esempi reali di cambiamenti avviati partendo dalla visualizzazione dello stato corrente, casi in cui un approccio pillola rossa non sarebbe stato possibile.

    [*] in questo talk con Kanban ci si riferisce al Kanban System for Software Development in base alla definizione di David J Anderson e alle sue successive (e ancora in corso) evoluzioni.

    At 4:45pm to 5:30pm, Saturday 19th November

  • LEGO Agile prototyping

    by Paolo Aliverti and Alessandro Graps

    E’ possibile utilizzare strumenti insoliti come i Lego per lavoro? Noi crediamo di si! e non siamo “bamboccioni”. I famosi mattoncini sono rapidi e flessibili: quanto di più AGILE esiste per prototipare un’idea e trasformarla rapidamente in prodotto. Analizzeremo i problemi del product development classico e vedremo come rendere il design agile. Esploreremo con voi un caso pratico: e non dimenticate di portare i vostri mattoncini!

    At 4:45pm to 5:30pm, Saturday 19th November

  • Unit Tests VS End to End Tests

    by Domenico Musto

    Qual è la differenza tra unit test, functional test ed end to end test? Quando e come usare gli uni o gli altri? Cerchiamo di capire come dare un valore ai test automatici per i “non sviluppatori” e che livello di affidabilità possano avere. Qual è la relazione tra un QA engineer e i test automatici? I test mi stanno dando informazioni sul reale stato di salute del sistema? Parliamo di come la presenza di test automatici possa influenzare e cambiare il processo di sviluppo.

    At 4:45pm to 5:30pm, Saturday 19th November

    Coverage video