Agile quackery a brief history of the worst ways to cure everythingStefano Leli
Da una decina di anni a questa parte Agile ha acquisito una popolarità tale da essere considerato oggi mainstream. Con la crescita della popolarità sono anche arrivati quelli che gli inglesi chiamano "quack", ovvero sedicenti professionisti che spacciano soluzioni preconfezionate promettendo di risolvere tutti i mali del mondo. Certificazioni di ogni tipo abbondano e strumenti di ogni sorta nascono come funghi.
In questo talk faremo un viaggio nel tempo tornando ai primi anni 2000, quando si sono iniziati a sviluppare i primi interessi attorno all'agilità e a formare le prime comunità, compresa quella italiana.
Lo scopo è quello di fare una riflessione critica su come è cambiata l'agilità in questi anni e su come il mercato sia oggi molto più orientato ad un approccio basato su modelli pronti all'uso rispetto ad uno volto alla sperimentazione e al pragmatismo.
Vedremo insieme come poter andare oltre questa ricerca spasmodica di soluzioni agili preconfezionate e cosa dovreste pretendere in un processo di adozione dell'agilità dai vostri coach e consulenti.
Agile goes Hollywood - Un approccio empirico alle trasformazioni agiliStefano Leli
Durante anni di lavoro abbiamo evidenziato la presenza di pattern durante le trasformazioni. Caso per caso abbiamo implementato esperimenti diversi che ci indicano la presenza di un possibile percorso comune. Nel talk vorremmo dare evidenza di tale percorso e un approfondimento di uno degli aspetti tipici delle trasformazioni, la necessità di misura del grado di agilità.
CREDITS: Cynefin framework and Ritual Dissent to "Dave Snowden"
Una struttura a componenti, o a silos, si organizza, tipicamente, aggiungendo livelli di specializzazione e di controllo in base alle richieste. Questo approccio porta ad una complessità sempre maggiore della struttura fino ad un rallentamento o addirittura blocco della capacità produttiva.
I feature teams, al contrario, con le loro caratteristiche di cross-funzionalità, maggior produzione di valore, pianificazione semplificata, auto organizzazione e orientamento al prodotto scalano con semplicità.
Nel workshop sperimenteremo i diversi approcci in modo da fornire i concetti essenziali in maniera esperienziale con l’utilizzo di tecniche di lego serious play nello sviluppo di un prodotto concreto.
Scrum XP è sempre più la metodologia di riferimento per i team e alcuni concetti sono divenuti di uso comune per chiunque operi nel mondo dell’IT (sia piccole realtà sia grandi aziende). Tra questi spiccano termini come user story e Product Backlog.
L’utilizzo delle user story ha sempre più spesso rimpiazzato i tradizionali documenti di specifiche funzionali e gli use case, mentre il Product Backlog è diventato lo strumento per tracciare tutto ciò che riguarda la realizzazione di un Prodotto.
Eppure entrambi hanno una serie di punti deboli. In questo talk mi concentrerò da una parte sulla difficoltà di avere un quadro completo ed evoluto a partire dal Backlog che è aihme piatto e mono dimensionale e dall’altro parlerò di cosa vuol dire veramente avere un approccio iterativo e incrementale nello sviluppo di un sistema.
L’utilizzo delle Kanban Board nella gestione dello sviluppo software sta crescendo notevolmente ma molto spesso quando si prova a introdurle nascono molti dubbi e non si è mai certi di come partire.
Come e perché funzionano? Quali concetti ci sono dietro? Come possiamo iniziare ad adottarle senza grossi mal di testa?
In questo workshop risponderemo a queste domande e proveremo insieme a disegnare la nostra prima board.
Lo scopo è quello di fornire concetti chiari e applicabili fin da subito.
Dinosaur Carpaccio - How to implement valuable micro-requirementsStefano Leli
Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story. Molti team, ancora oggi, faticano a realizzare storie piccole e quando ci provano finiscono spesso con l'ottenere ‘layer’ dell’architettura orizzontale e non micro soluzioni verticali che attraversino tutti gli strati (dalla UI alla persistenza). Tale situazione fa si che l'assunto iniziale decada e il valore portato al cliente nella migliore delle ipotesi non sarà continuo (nella peggiore nullo).
La comunicazione tra le persone è il primo valore dell’Agile. Trasmettere la vision di un’idea è molto difficile. Attraverso i Canvas è possibile non solo condividere la vision ma anche il viaggio che porterà alla realizzazione dell’intero prodotto.
Adottando i vari Canvas come il Business Model Canvas, il Lean Canvas e il Product Canvas è possibile definire e condividere le ipotesi iniziali, validarle sul mercato misurando i risultati e confrontarle con i risultati attesi. I Canvas quindi non solo ci aiutano nella parte iniziale del progetto ma ci accompagnano per tutto il ciclo di vita del prodotto evolvendo con esso.
Questi concetti non sono strettamente legati al software ma possono essere applicati in contesti differenti.
Durante questo workshop vedremo insieme come, partendo da un’idea, si possa realizzare un prototipo di applicazione mobile in meno di due ore… il tutto sotto forma di gioco.
Agile quackery a brief history of the worst ways to cure everythingStefano Leli
Da una decina di anni a questa parte Agile ha acquisito una popolarità tale da essere considerato oggi mainstream. Con la crescita della popolarità sono anche arrivati quelli che gli inglesi chiamano "quack", ovvero sedicenti professionisti che spacciano soluzioni preconfezionate promettendo di risolvere tutti i mali del mondo. Certificazioni di ogni tipo abbondano e strumenti di ogni sorta nascono come funghi.
In questo talk faremo un viaggio nel tempo tornando ai primi anni 2000, quando si sono iniziati a sviluppare i primi interessi attorno all'agilità e a formare le prime comunità, compresa quella italiana.
Lo scopo è quello di fare una riflessione critica su come è cambiata l'agilità in questi anni e su come il mercato sia oggi molto più orientato ad un approccio basato su modelli pronti all'uso rispetto ad uno volto alla sperimentazione e al pragmatismo.
Vedremo insieme come poter andare oltre questa ricerca spasmodica di soluzioni agili preconfezionate e cosa dovreste pretendere in un processo di adozione dell'agilità dai vostri coach e consulenti.
Agile goes Hollywood - Un approccio empirico alle trasformazioni agiliStefano Leli
Durante anni di lavoro abbiamo evidenziato la presenza di pattern durante le trasformazioni. Caso per caso abbiamo implementato esperimenti diversi che ci indicano la presenza di un possibile percorso comune. Nel talk vorremmo dare evidenza di tale percorso e un approfondimento di uno degli aspetti tipici delle trasformazioni, la necessità di misura del grado di agilità.
CREDITS: Cynefin framework and Ritual Dissent to "Dave Snowden"
Una struttura a componenti, o a silos, si organizza, tipicamente, aggiungendo livelli di specializzazione e di controllo in base alle richieste. Questo approccio porta ad una complessità sempre maggiore della struttura fino ad un rallentamento o addirittura blocco della capacità produttiva.
I feature teams, al contrario, con le loro caratteristiche di cross-funzionalità, maggior produzione di valore, pianificazione semplificata, auto organizzazione e orientamento al prodotto scalano con semplicità.
Nel workshop sperimenteremo i diversi approcci in modo da fornire i concetti essenziali in maniera esperienziale con l’utilizzo di tecniche di lego serious play nello sviluppo di un prodotto concreto.
Scrum XP è sempre più la metodologia di riferimento per i team e alcuni concetti sono divenuti di uso comune per chiunque operi nel mondo dell’IT (sia piccole realtà sia grandi aziende). Tra questi spiccano termini come user story e Product Backlog.
L’utilizzo delle user story ha sempre più spesso rimpiazzato i tradizionali documenti di specifiche funzionali e gli use case, mentre il Product Backlog è diventato lo strumento per tracciare tutto ciò che riguarda la realizzazione di un Prodotto.
Eppure entrambi hanno una serie di punti deboli. In questo talk mi concentrerò da una parte sulla difficoltà di avere un quadro completo ed evoluto a partire dal Backlog che è aihme piatto e mono dimensionale e dall’altro parlerò di cosa vuol dire veramente avere un approccio iterativo e incrementale nello sviluppo di un sistema.
L’utilizzo delle Kanban Board nella gestione dello sviluppo software sta crescendo notevolmente ma molto spesso quando si prova a introdurle nascono molti dubbi e non si è mai certi di come partire.
Come e perché funzionano? Quali concetti ci sono dietro? Come possiamo iniziare ad adottarle senza grossi mal di testa?
In questo workshop risponderemo a queste domande e proveremo insieme a disegnare la nostra prima board.
Lo scopo è quello di fornire concetti chiari e applicabili fin da subito.
Dinosaur Carpaccio - How to implement valuable micro-requirementsStefano Leli
Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story. Molti team, ancora oggi, faticano a realizzare storie piccole e quando ci provano finiscono spesso con l'ottenere ‘layer’ dell’architettura orizzontale e non micro soluzioni verticali che attraversino tutti gli strati (dalla UI alla persistenza). Tale situazione fa si che l'assunto iniziale decada e il valore portato al cliente nella migliore delle ipotesi non sarà continuo (nella peggiore nullo).
La comunicazione tra le persone è il primo valore dell’Agile. Trasmettere la vision di un’idea è molto difficile. Attraverso i Canvas è possibile non solo condividere la vision ma anche il viaggio che porterà alla realizzazione dell’intero prodotto.
Adottando i vari Canvas come il Business Model Canvas, il Lean Canvas e il Product Canvas è possibile definire e condividere le ipotesi iniziali, validarle sul mercato misurando i risultati e confrontarle con i risultati attesi. I Canvas quindi non solo ci aiutano nella parte iniziale del progetto ma ci accompagnano per tutto il ciclo di vita del prodotto evolvendo con esso.
Questi concetti non sono strettamente legati al software ma possono essere applicati in contesti differenti.
Durante questo workshop vedremo insieme come, partendo da un’idea, si possa realizzare un prototipo di applicazione mobile in meno di due ore… il tutto sotto forma di gioco.
User stories writing - Codemotion 2013Stefano Leli
The document provides information on user stories, including what they are, how to write them, and best practices. Some key points:
- A user story is a high-level definition of a requirement written from the user's perspective that provides enough information for developers to estimate effort. It focuses on who needs what and why, not how.
- User stories should follow the INVEST criteria: independent, negotiable, valuable, estimable, sized appropriately, and testable. Acceptance criteria define when a story is complete.
- Epics are large stories that need to be broken down into smaller stories over multiple iterations. Themes group related stories.
- Best practices for writing stories include keeping them
The document discusses what user stories are and how they are used in agile software development. It defines user stories as high-level descriptions of requirements that provide just enough information for developers to estimate the effort to implement them. It emphasizes that user stories are not detailed specifications, but rather focus on capturing the user's perspective and defining value. The document also covers best practices for writing effective user stories, including using the INVEST criteria of being Independent, Negotiable, Valuable, Estimable, Small, and Testable. It discusses other agile planning techniques like epics and themes that group related user stories.
Codice legacy, usciamo dal pantano! @iad11Stefano Leli
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.
This document describes an XP planning game simulation to be used for training purposes. Participants will play in teams as customers and developers to estimate user stories, plan iterations, implement stories within a time limit, and provide feedback. The goal is to measure the team's velocity and have participants experience different agile roles. The document outlines the terminology used, such as story points, business value, and acceptance tests. It provides instructions for developers to estimate stories, customers to plan iterations, and developers to implement stories within iterations. A retrospective will be held after each iteration to review lessons learned about estimating accuracy and using velocity for future planning.
Il project manager e lo sviluppo agile. Separati in casa?Stefano Leli
Qual é il ruolo del project manager nell'agile? Quali sono i suoi "nuovi" compiti? Perchè mai un PM dovrebbe appoggiare il cambiamento verso l'agile? Cercheremo di rispondere a questi e ad altri quesiti attraverso un gioco di ruolo: un PM tradizionale, uno agile e il pubblico come giuria...che lo scontro abbia inizio!!!
Manage software dependencies with ioc and aopStefano Leli
The document discusses managing software dependencies through inversion of control (IoC) and aspect-oriented programming (AOP). It describes how dependencies can make software rigid, fragile, and difficult to maintain. It then shows how to decouple dependencies using IoC patterns like dependency injection and AOP to address cross-cutting concerns.
User stories writing - Codemotion 2013Stefano Leli
The document provides information on user stories, including what they are, how to write them, and best practices. Some key points:
- A user story is a high-level definition of a requirement written from the user's perspective that provides enough information for developers to estimate effort. It focuses on who needs what and why, not how.
- User stories should follow the INVEST criteria: independent, negotiable, valuable, estimable, sized appropriately, and testable. Acceptance criteria define when a story is complete.
- Epics are large stories that need to be broken down into smaller stories over multiple iterations. Themes group related stories.
- Best practices for writing stories include keeping them
The document discusses what user stories are and how they are used in agile software development. It defines user stories as high-level descriptions of requirements that provide just enough information for developers to estimate the effort to implement them. It emphasizes that user stories are not detailed specifications, but rather focus on capturing the user's perspective and defining value. The document also covers best practices for writing effective user stories, including using the INVEST criteria of being Independent, Negotiable, Valuable, Estimable, Small, and Testable. It discusses other agile planning techniques like epics and themes that group related user stories.
Codice legacy, usciamo dal pantano! @iad11Stefano Leli
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.
This document describes an XP planning game simulation to be used for training purposes. Participants will play in teams as customers and developers to estimate user stories, plan iterations, implement stories within a time limit, and provide feedback. The goal is to measure the team's velocity and have participants experience different agile roles. The document outlines the terminology used, such as story points, business value, and acceptance tests. It provides instructions for developers to estimate stories, customers to plan iterations, and developers to implement stories within iterations. A retrospective will be held after each iteration to review lessons learned about estimating accuracy and using velocity for future planning.
Il project manager e lo sviluppo agile. Separati in casa?Stefano Leli
Qual é il ruolo del project manager nell'agile? Quali sono i suoi "nuovi" compiti? Perchè mai un PM dovrebbe appoggiare il cambiamento verso l'agile? Cercheremo di rispondere a questi e ad altri quesiti attraverso un gioco di ruolo: un PM tradizionale, uno agile e il pubblico come giuria...che lo scontro abbia inizio!!!
Manage software dependencies with ioc and aopStefano Leli
The document discusses managing software dependencies through inversion of control (IoC) and aspect-oriented programming (AOP). It describes how dependencies can make software rigid, fragile, and difficult to maintain. It then shows how to decouple dependencies using IoC patterns like dependency injection and AOP to address cross-cutting concerns.
2. “Refactoring is the process of changing a
software system in such a way that it does not
alter the external behavior of the code yet
improves its internal structure.”
Martin Fowler
3. Principi del Refactoring
• Migliorare il design del codice
• Eliminare le duplicazioni
• Rendere il codice più leggibile e facile da modificare
Single Responsibility Principle (SRP)
Una classe dovrebbe avere una sola ragione per
cambiare
4. Regole
• Tempo a disposizione 25 minuti
• I test devono restare verdi
• I test non possono essere modificati
6. Classe CaloriesCalculator
namespace Kata
{
public class CaloriesCalculator {
private readonly List<Food> foods;
private readonly Person person;
public CaloriesCalculator(Person person, List<Food> foods) {
this.person = person;
this.foods = foods;
}
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++) {
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 /* calories in one kilometer */ * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
}
}
7. Classe CaloriesCalculator
Responsabilità Collaborazioni
Validazione delle componenti Classe Food
Costruzione del report di stampa Classe Person
Calcolo delle calorie di una lista di cibi Classe FirstException
Calcolo dei Km da percorrere Classe SecondException
CRC Card Classe CaloriesCalculator
Il refactoring verterà sulla:
suddivisione di responsabilità (aumentare la coesione)
diminuzione delle collaborazioni con le classi applicative (diminuire l'accoppiamento)
Favorendo in questo modo un:
maggiore riuso del codice
maggiore robustezza del programma
8. Magic Number
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
9. Uso parziale di costanti
public class Person
{
public const int MEDIUM_SIZE = 2;
public const int FAT = 3;
public const int SLIM = 1;
public Person(string name, int kg) {
this._name = name;
this.kg = kg;
}
private string _name;
public string Name {
get { return _name; }
set { _name = value; }
}
private int kg;
public int Kg {
get { return kg; }
set { kg = value; }
}
public int Size {
get
{
if (kg > 130) return 3;
if (kg < 50) return 1;
return MEDIUM_SIZE;
}
}
}
10. Cicli
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
11. Nomi di variabili metodi e classi
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
12. Information Hiding
public class Food
{
public string Name;
public double Kg;
public Food(string name, double kg)
{
this.Name = name;
this.Kg = kg;
}
}
13. Responsabilità:
Validazione
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
14. Responsabilità:
Calcolo delle calorie e dei Km
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
15. Responsabilità:
Costruzione del report
public string Result() {
string str = "Diet Report for " + person.Name +":n";
double cal = 0.0;
for (int i = 0; i < foods.Count; i++)
{
Food food = foods[i];
str += food.Name + " - " + food.Kg + "n";
if ("".Equals(food.Name)) throw new FirstException();
if ("apple".Equals(food.Name)) cal += food.Kg * 15 * 10;
if ("magicPill".Equals(food.Name)) cal -= 10;
if ("candy".Equals(food.Name)) cal += food.Kg;
}
str += "Total: " + (double)cal + " kcaln";
str += "kilometers to be run: " + 90 * person.Size / cal;
foreach (Food type in foods) {
if ("".Equals(type.Name)) throw new FirstException();
if (person.Kg > 1000) throw new SecondException();
}
return str;
}
18. Primi Passi
• Effettuate le operazioni individuate in precedenza
(Naming, Information Hiding….)
• Creata la classe Meal
• Responsabile della validazione di una lista di Food
• Aumenta la coesione tra le classi
• Creata la classe Dietist
• Funge da “Mediator”
• Lascia aperti scenari ad estensioni future (DI, etc.)
19. Validazione
Assegnata alla classe Person la responsabilità
della propria validazione
Adottato l'utilizzo del pattern Visitor per la
validazione dei Food:
Permette di aggiungere nuovi
comportamenti indipendenti dalla struttura
dati
Diminuisce la complessità della struttura
dati
20. Calcolo delle Calorie
Utilizzo del pattern strategy per il calcolo delle
calorie:
Maggior grado di disaccoppiamento tra
l'implementazione dell'algoritmo e la sua
esecuzione
Possibilità di incapsulare più strategie o
algoritmi in classi separate semplicemente
implementando le apposite interfacce.
21. Costruzione dei Report
Utilizzo del pattern template per modellare le
logiche di reporting:
Permette di separe le parti invarianti da
quelle varianti di un algoritmo.
Rende facile l'aggiunta di un nuovo report.
Basta implementare il template di base e
definire le parti varianti
Per favorire l'information hiding è stata
aggiunta l'interfaccia IDietReport