Ci sono bug e bug. Alcuni si nascondono nel codice e possono essere trovati prima che arrivino al cliente, altri emergono dall’integrazione dei sistemi e possono essere gestiti in modo che non facciano danni in produzione, altri ancora invece sfuggono inesorabilmente.
Il Test Driven Development è una pratica sempre più diffusa, ci consente di scrivere software che funziona e che può evolvere più rapidamente e facilmente. Tuttavia, sebbene sia una pratica test-first, viene spesso utilizzata quando ormai è troppo tardi e quell’ultima categoria di bug ha già prodotto il suo effetto.
Si tratta infatti degli errori che si celano nelle pieghe dei requisiti e delle specifiche. Le buone notizie sono due: anche i requisiti e le specifiche possono essere “testati” prima ancora di scrivere una sola riga di codice, anche questi test possono essere automatizzati.
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
This document provides specifications and application guidance for Mini DIPIPM Ver.4 intelligent power modules. It includes:
1. Specifications for the PS21767 module such as maximum ratings, thermal resistance, electrical characteristics, and protective functions.
2. Guidelines for circuit design including interface circuits, wiring methods, mounting, and thermal calculations.
3. Recommendations for key parameters like shunt resistance and bootstrap circuits.
4. Details on an interface demo board and packaging for the Mini DIPIPM Ver.4 series.
Collaborazione, Decisionalità e Gestione della Complessità nel Tempo: cosa ...Commit University
Vuoi migliorare la gestione dei progetti a lungo termine con team multidisciplinari e prendere decisioni rischiose in modo sicuro e ponderato? Non perderti il nostro workshop gratuito!
Antonio Dell’Ava, Frontend Developer di eDreams Odigeo, condividerà strategie per aiutarti a ottimizzare la collaborazione nel tuo team, scegliere gli strumenti giusti per ogni situazione e garantire l’evoluzione del progetto nel tempo
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Design of experiment represent the properly approach and method to test and validate business ideas.
This a collection of easy to set up experiments you can build by tomorrow: from fake doors to smoke test and the most relevant brain triggers to engage people and users into your testing funnel
Sometimes you want to do Domain-Driven Design, but the bad guys are against you. Sometimes you need tobe the bad guy. This is Domain-Driven Design in a bloody brownfield scenario.
This document provides specifications and application guidance for Mini DIPIPM Ver.4 intelligent power modules. It includes:
1. Specifications for the PS21767 module such as maximum ratings, thermal resistance, electrical characteristics, and protective functions.
2. Guidelines for circuit design including interface circuits, wiring methods, mounting, and thermal calculations.
3. Recommendations for key parameters like shunt resistance and bootstrap circuits.
4. Details on an interface demo board and packaging for the Mini DIPIPM Ver.4 series.
Collaborazione, Decisionalità e Gestione della Complessità nel Tempo: cosa ...Commit University
Vuoi migliorare la gestione dei progetti a lungo termine con team multidisciplinari e prendere decisioni rischiose in modo sicuro e ponderato? Non perderti il nostro workshop gratuito!
Antonio Dell’Ava, Frontend Developer di eDreams Odigeo, condividerà strategie per aiutarti a ottimizzare la collaborazione nel tuo team, scegliere gli strumenti giusti per ogni situazione e garantire l’evoluzione del progetto nel tempo
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
2006
Prima serata di una serie di Talk serali all' ERLUG (Emilia Romagna Linux User Group) Presentazione delle Metodologie Agili (confronto con la situazione esistente)
Presentazione delle Pratiche Agili
Esempio d'applicazione di tecniche Agili
Agile e OSS distribuito
eXtreme Programming
Design of experiment represent the properly approach and method to test and validate business ideas.
This a collection of easy to set up experiments you can build by tomorrow: from fake doors to smoke test and the most relevant brain triggers to engage people and users into your testing funnel
Questa presentazione era finalizzata alla spiegazione del metodo di progettazione e prototipazione in un lavoro come quello di Cartella Clinica Informatizzata. L'idea da divulgare ai committenti è quella di mettere al centro l'utilizzatore del prodotto, capire le sue necessità, il suo contesto di utilizzo e massimizzare l'efficacia e l'efficienza nella sua esperienza d'uso.
I 7 fondamentali per approcciare al design for additive manufacturingSimone Ravaglia
In che modo posso ottenere il massimo risultato utilizzando le tecnologie addittive?
Devi conoscere i 7 fondamentali!
Che cosa sono? Sono le sette dimensioni che vanno prese in considerazione prima della produzione proprio per evitare problematiche durante la stampa o ritrovarci con delle parti che da un punto di vista economico non sono convenienti.
In questo articolo ti mostro quali sono le cose da non sottovalutare durante il tuo progetto pilota.
La centralità della Customer Experience rappresenta uno degli elementi fondamentali per il successo di un'azienda.
Oggi generare valore per i nostri utenti non significa soltanto interrogarsi sui loro bisogni; occorre focalizzarsi sull'intera esperienza che il nostro utente vivrà prima, durante e dopo l'interazione con il prodotto o servizio.
Nell'ambito dello sviluppo agile del software, questa esigenza si traduce, in primo luogo, nella necessità di acquisire una profonda conoscenza dei propri utenti e, in secondo luogo, nell'usare questa conoscenza per generare ipotesi, che andranno implementate e validate iterazione dopo iterazione.
In questo scenario la collaborazione tra il designer e il resto del team diventa fondamentale, a partire dalla generazione delle ipotesi iniziali, che andranno, prima di tutto, validate dal punto di vista della fattibilità tecnologica.
Durante il meetup risponderemo, con una serie di esempi concreti, a quattro principali domande:
1. Cosa significa "generare valore" per l'utente finale oggi?
2. Quali strumenti abbiamo a disposizione per conoscere e formulare le nostre ipotesi?
3. Quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per gli utenti finali?
4. Come possiamo integrare le competenze dello UX design all'interno dei nostri team Scrum?
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Lo sai che si può fare DDD in Javascript grazie a Typescript? Visual Studio e...Marco Parenzan
Scrivere Object Oriented è ora possibile anche in Javascript con Typescript. E in generale bisogna concentrarsi nello scrivere codice di valore e non "autogenerato" dallo scaffolding. Capiamo come si fa riscrivendo un vecchio gioco della Licasfilm!
Master presentazione 1 come nasce un'ideasculling77
Piccola presentazione il cui tema è l'illustrazione di come VIRGOSISTEMI gestisce i Clienti e le loro esigenze fino a farle diventare dei prodotti finiti.
Loosely Coupled Complexity - Unleash the power of your domain modelFrancesca1980
Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
Questa presentazione era finalizzata alla spiegazione del metodo di progettazione e prototipazione in un lavoro come quello di Cartella Clinica Informatizzata. L'idea da divulgare ai committenti è quella di mettere al centro l'utilizzatore del prodotto, capire le sue necessità, il suo contesto di utilizzo e massimizzare l'efficacia e l'efficienza nella sua esperienza d'uso.
I 7 fondamentali per approcciare al design for additive manufacturingSimone Ravaglia
In che modo posso ottenere il massimo risultato utilizzando le tecnologie addittive?
Devi conoscere i 7 fondamentali!
Che cosa sono? Sono le sette dimensioni che vanno prese in considerazione prima della produzione proprio per evitare problematiche durante la stampa o ritrovarci con delle parti che da un punto di vista economico non sono convenienti.
In questo articolo ti mostro quali sono le cose da non sottovalutare durante il tuo progetto pilota.
La centralità della Customer Experience rappresenta uno degli elementi fondamentali per il successo di un'azienda.
Oggi generare valore per i nostri utenti non significa soltanto interrogarsi sui loro bisogni; occorre focalizzarsi sull'intera esperienza che il nostro utente vivrà prima, durante e dopo l'interazione con il prodotto o servizio.
Nell'ambito dello sviluppo agile del software, questa esigenza si traduce, in primo luogo, nella necessità di acquisire una profonda conoscenza dei propri utenti e, in secondo luogo, nell'usare questa conoscenza per generare ipotesi, che andranno implementate e validate iterazione dopo iterazione.
In questo scenario la collaborazione tra il designer e il resto del team diventa fondamentale, a partire dalla generazione delle ipotesi iniziali, che andranno, prima di tutto, validate dal punto di vista della fattibilità tecnologica.
Durante il meetup risponderemo, con una serie di esempi concreti, a quattro principali domande:
1. Cosa significa "generare valore" per l'utente finale oggi?
2. Quali strumenti abbiamo a disposizione per conoscere e formulare le nostre ipotesi?
3. Quali metriche possiamo utilizzare per validare e misurare il valore dei nostri prodotti per gli utenti finali?
4. Come possiamo integrare le competenze dello UX design all'interno dei nostri team Scrum?
Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum.
Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco.
Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-)
Commenti e miglioramenti sempre ben accetti!
Lo sai che si può fare DDD in Javascript grazie a Typescript? Visual Studio e...Marco Parenzan
Scrivere Object Oriented è ora possibile anche in Javascript con Typescript. E in generale bisogna concentrarsi nello scrivere codice di valore e non "autogenerato" dallo scaffolding. Capiamo come si fa riscrivendo un vecchio gioco della Licasfilm!
Master presentazione 1 come nasce un'ideasculling77
Piccola presentazione il cui tema è l'illustrazione di come VIRGOSISTEMI gestisce i Clienti e le loro esigenze fino a farle diventare dei prodotti finiti.
Loosely Coupled Complexity - Unleash the power of your domain modelFrancesca1980
Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.
Agile Project Management - the Board Game workshopGiulio Roggero
Agile workshop based on the board game "Agile: the Board Game" -
http://code.google.com/p/agile-the-board-game
(Italian Version).
During this 1day workshop participants embrace the Agile values and Lean principles using the Agile board game and the A3 Airplane game.
The spirit of the workshop is learning by doing.
You can download and use freely these slide under CC3 License.
Agile è entrato nel gergo comune di molte aziende che hanno a che fare con progetti IT. Questa è una buona cosa: il termine è conosciuto e accettato come una buona prassi, le persone sono ben disposte ad adottare metodi e pratiche che consentono di migliorare la gestione del ciclo di vita di un prodotto software e sono favorevoli al cambiamento.
Quando però si parte veramente mi sono trovato in diverse situazioni dove Agile si limitava alla parte “persone” e “organizzazione” ma non entrava nel merito di come si sviluppa il codice!
La provocazione “Stop Meeting, Start Coding” vuol ridurre all’essenziale i momenti di confronto e concentrarsi a scrivere buon codice, insieme!
In questo talk presenterò alcune buone pratiche di coding che favoriscono anche l’efficacia organizzativa.
Scrivere software per il business si riduce essenzialmente a due problemi. Capire il vero problema da risolvere, e trovare soluzioni interessanti, senza trasformare la cosa in un percorso ad ostacoli.
2. 2
“Mi serve per domani, ma è facile…”
Ho un elenco di scontrini.
Obiettivo
Nel caso degli scontrini con cross selling (ossia con prodotti appartenenti a categorie
diverse, ma acquistati nella stessa transazione), voglio sapere quali scontrini contengono la
categoria B e la categoria W e che altre categorie contengono
3. 3
“Fatto!”
• Welcome Change: siamo un team agile, il cambiamento è il nostro pane quotidiano
• Delight your customer: soddisfare il cliente è la nostra priorità
• Feel good!: detto, fatto… Flash Gordon? Sei fuori!
4. 4
“Però non mi torna”
Ad esempio: lo scontrino 43136 contiene sia B (tre referenze) che C (una referenza)
ma non compare tra i risultati
Perché?
5. Agenda di oggi
Introduzione
Cos’è ATDD
5
La matrice dei test
Dov’è ATDD
La Triade
Chi fa ATDD
Test-first! Test-when??!!
Quando si fa ATDD
A chi serve veramente?
Perché si fa ATDD
Restiamo in contatto
Condividiamo i nostri esperimenti
10. Requisiti testati e testabili
10
Gli AT non sono test di accettazione tradizionali
Non sono eseguiti dall’utente finale dopo l’implementazione, al fine di verificare se il sistema funziona secondo le specifiche
contrattualizzate
Gli AT non sono System Tests
Non sono test scritti dai tester leggendo il documento dei requisiti
Gli AT non sono Acceptance Criteria
Non sono informali
Gli AT sono indipendenti dall’implementazione
Validano innanzitutto i requisiti, e poi possono essere usati per testare l’implementazione
Gli AT sono definiti collaborativamente
Nascono dalla stretta collaborazione tra cliente/utente, sviluppatore e tester e sono il pilastro su cui fondare una comune
comprensione del dominio dell’applicazione
Ok, I want to do the thing right, but how I know it is the right thing?
11. L’albero della conoscenza
11
… dei requisiti
DDD
Specification by Example BDD
Executable Specifications
Evans
Adzic North
Beck / XP
12. Tanti nomi, una sola cosa?
12
ATDD – Acceptance Test Driven Development:
Il focus è sul concetto di “accettazione” e su quello di verifica. E’ naturale il nesso con i cosiddetti Acceptance Criteria, che
sono parte essenziale della DoR (Definition of Ready) e della DoD (Definition of Done)
BDD – Behaviour Driven Development (North):
L’attenzione è sul comportamento del sistema. È forse l’acronimo più popolare.
Specification by Example (Adzic):
La definizione di Adzic si libera del “DD” e mette al centro il processo di costruzione delle specifiche tramite esempi
Executable Specifications:
Qui l’accento è sulla “specifica” come vero e proprio test eseguibile e automatico
DDD – Domain Driven Design:
Ubiquitous language! Conoscere il dominio per avere il dominio
Una questione di punti di vista
17. 17
Ecco la nostra triade
Senza dimenticare il “quarto uomo”
Mario Volubile Luca Codice Mara Scrupoli Aldo Portafogli
Stakeholder Developer Tester Chief Financial Officer
19. Alla ricerca di un linguaggio comune
19
Dal dominio del linguaggio al linguaggio di dominio
20. Gherkin
20
Gherkin Script: GWT
Gli script Gherkin sono una forma strutturata di linguaggio quotidiano
Given – indica qualcosa che è dato per vero nello scenario
When – indica un evento nello scenario
Then – indica il risultato atteso
“And” e “But”
Per migliorare la leggibilità sono supportate anche le parole chiave “And” e “But”
Comprensibilità
Le clausole sono espresse nel linguaggio e con la sintassi naturali e quindi sono comprensibili anche da chi si occupa di
business e non di coding.
DSL
Le clausole Gherkin finiscono per costituire un “Domain Specific Language” del tutto indipendente dal linguaggio di
programmazione usato per l’implementazione
Dato che è scritto in Gherkin, quando leggo lo scenario, allora lo capisco
23. Subito!
23
Identificare i desirements
Associarli ad un obiettivo di business
Sfidarli “by example”
“Se sopravvivono allora vanno bene” (Charles Darwin… credo)
Un computer farà quello che gli dici, non quello che vuoi… meglio dirla giusta
29. Allo stakeholder
29
Dai Desirements ai Requirements, e poi giù fino alle Specifications: non è più un viaggio solitario
Costruire esempi aiuta a chiarire le idee
I casi-limite come strumento di stress dei miei desideri
Come sapere se l’obiettivo è raggiungibile: si può fare, e se sì, costerà tantissimo?
Come sapere se ho ottenuto proprio ciò che mi serve?
Idee chiare, amicizia lunga
30. Al team di sviluppo
30
Finalmente sono sicuro che sto implementando la cosa giusta
Il valore di ciò che consegno è stato esplicitato
Posso sapere quando ho finito
Posso sapere se ho rotto qualcosa
Ehi… ma questi sono i regression test… wow!
“Ragazzi, chi si becca il task della documentazione? Ah… non c’è nessun task della documentazione…”
Beh sì… ci piace vincere facile
31. A tutti i protagonisti
31
“Panico: dobbiamo rivedere quella funzione sviluppata tre mesi fa. Qualcuno si ricorda qualcosa?”
“Sto leggendo gli acceptance test. Rifammi la domanda tra qualche minuto.”
“Panico: non trovo più i miei appunti. Come si è deciso di integrare quel processo nella procedura degli acquisti?”
“Sto leggendo gli acceptance test. Rifammi la domanda tra qualche minuto.”
“Panico: ci siamo accorti che questo nuovo processo non va bene. Qualcuno si ricorda com’era prima?”
“Sto leggendo la versione precedente degli acceptance test. Rifammi la domanda tra qualche minuto.”
“Panico: abbiamo una quality issue su questo articolo di due anni fa. Quali erano le norme di compliance implementate a
sistema all’epoca?”
“Sto leggendo quella versione degli acceptance test. Rifammi la domanda tra qualche minuto.”
Perché la memoria è corta
32. A chi verrà
32
“Ciao! Sono il nuovo sviluppatore. Da quale di queste seicento classi comincio per capirci qualcosa?”
“Lascia stare il codice per ora… qui trovi gli acceptance test. Se fossi in te partirei dalla funzione X”
“E’ cambiato il nostro referente presso il cliente… chi gli spiega come funziona il sistema?”
“Gli mando il link alla wiki, e poi se serve qualche approfondimento ci parlo direttamente”
Ai posteri la facile sentenza
34. 34
Restiamo in contatto
Condividiamo i nostri esperimenti
Indirizzo
V.le Venezia 111
33100 Udine (UD)
Telefono
0432 23 48 38
Email / Website
gmarchetti@emme4.com
www.emme4.com
35. 35
La mia prima scelta La mia prima scelta
WTF
...forse l’avevo già fatta
La mia prima scelta
ok...
c’è un dannato bug nella
funzione di ranking
Letture
“Non ti preoccupare mai della teoria fintantoché il sistema fa ciò che si è supposto faccia” – Robert A. Heinlein
36. 36
By Example al quadrato Alla radice del problema Se non siete convinti
Testimonianze convincenti dalla
trincea!
Letture
“In teoria, la pratica e la teoria rappresentano la stessa cosa. In pratica ciò non è vero” – Yogi Berra