Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Lean anche io! No tu no! - Italian Agile Days 2013Andrea Scavolini
Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia:
Lean anche io!
No tu no!
Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Cosi come non si può prescindere dal buon design quando si progetta un software, allo stesso tempo va fatta estrema attenzione al consumo di risorse, alle performances, all’affidabilità, criteri che nell’ubiquità del software non possono mai essere dati per scontato. Vediamo come approcciare questi problemi.
Perchè l’approccio accademico al software impone spesso di ragionare “a risorse infinite”, mentre nella realtà dei fatti questo non è vero? Abbiamo la possibilità di intercettare rapidamente il degrado del software e il consumo di risorse? In questo talk vorremmo condividere alcune esperienze di team atte a misurare la “febbre” del software, ovvero discutere di alcuni indicatori che possono dare un buon feeling sullo stato di salute del software che stiamo sviluppando, monitorando i quali possiamo far avvicinare l’approccio accademico, teorico a quello pratico e di produzione.
Lean anche io! No tu no! - Italian Agile Days 2013Andrea Scavolini
Slide presentate a Italian Agile Day(s) 2013 di Reggio Emilia:
Lean anche io!
No tu no!
Sessione incentrata sulla condivisione dell'esperienza di transizione verso un modello Lean in progetti reali di consulenza per grandi aziende dove spesso molte delle pratiche e delle metodologie proposte in ambito agile sono difficilmente applicabili. L’obiettivo è mostrare i successi ottenuti (sia per il team di sviluppo che per gli utenti), condividere i nostri fallimenti, i problemi incontrati e le sfide aperte per offrire un punto di vista su come può essere affrontata la transizione ad un modello agile in contesto di relazione grande cliente-fornitore.
Talk presentato all'Italia Agile Day il 30/11/2013 a Reggio Emilia.
I valori di Agile sono come i principi alla base della cucina. In questa presentazione sono presentati alcuni ingredienti agili da amalgamare con cura.
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
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
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Metaware & Agile - Un Dev Team può creare valore (solo per il cliente?)Ciro Donato Caiazzo
In quanti modi un team di sviluppo Agile può creare valore?
In questa presentazione è proposto un caso di successo di applicazione delle metodologie Agile per la creazione di team per sviluppare progetti e prodotti software con un focus particolare sul continuous improvement e l’ innovazione tecnologica creando valore per il cliente, l’ azienda e i talenti geek.
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
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.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Le trasformazioni subite dal mercato nel corso degli ultimi anni hanno reso il Customer Experience Management un imperativo strategico fondamentale da seguire da parte delle aziende in quanto la qualità non è più sufficiente per garantire un vantaggio competitivo e la nuova via per differenziarsi è la capacità di far vivere al consumatore un’esperienza complessiva appagante e superiore in modo tale da soddisfarlo completamente.
Proprio per tali ragioni l'attenzione alla Customer Experience sta assumendo un ruolo sempre più centrale all'interno delle organizzazioni in quanto un miglioramento complessivo nella gestione dell’esperienza del cliente si traduce in un miglioramento dell'immagine aziendale e in un aumento del fatturato nel lungo periodo; è infatti dimostrato che i clienti stessi riconoscono un valore economico alla CX e sono disposti a riconoscere un “premium price” all’azienda per poterne beneficiare.
Nella realizzazione degli strumenti necessari per la gestione e l’ottimizzazione della CX (Mappatura dei touchpoint, collocazione di questi nei processi, quantificazione della qualità dei processi, costruzione dei percorsi cliente, misurazione e individuazione dei gap) e nella creazione di una strategia di Customer Experience Management è stato individuato un approccio in 5 fasi:
–Mappatura dei processi vista cliente
–Individuazione dei gap rispetto alla CX ideale
–Revisione dei singoli punti/momenti di contatto con il cliente
–Gestione strutturata del customer feedback e dei Big Data
–Creazione di una funzione interna di CX
Questa presentazione descrive un viaggio nel project management dalla produzione di massa di Ford fino allo Scrum utilizzato nella produzione di software.
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
Secondo incontro del Roma-xpug nel quale si effettuerà una 'round-table' sui valori e i principi che sono alla base delle metodologie Lean e Agili. L'incontro prevede una breve presentazione di Fabio Armani a cui seguirà un panel aperto per scambiarsi opinioni e esperienze.
Second Meeting of the Rome-xpug in which we'll make a 'round-table' on the values and principles that are the basis of Lean and Agile methodologies. The meeting includes a short presentation by Fabio Armani, followed by an open panel to exchange views and experiences.
Metaware & Agile - Un Dev Team può creare valore (solo per il cliente?)Ciro Donato Caiazzo
In quanti modi un team di sviluppo Agile può creare valore?
In questa presentazione è proposto un caso di successo di applicazione delle metodologie Agile per la creazione di team per sviluppare progetti e prodotti software con un focus particolare sul continuous improvement e l’ innovazione tecnologica creando valore per il cliente, l’ azienda e i talenti geek.
Agile requirements - alla ricerca del filo rosso (iad 2013)Fabio Armani
requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.
Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.
Come abbiamo introdotto la metodologia agile, attraverso SCRUM, in una piccola agenzia web multi progetto seguendo un approccio lean per gestire sia i team che i progetti.
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.
Manifesto per lo Sviluppo Agile di SoftwareAmmLibera AL
In Ingegneria del SW, per metodologia agile (o leggera) o metodo agile si intende un particolare metodo per lo sviluppo del software che coinvolge quanto più possibile il committente, ottenendo in tal modo una elevata reattività alle sue richieste.
Esistono un certo numero di tali metodologie e la Agile alliance, formatasi nella stesura del manifesto in oggetto, è una organizzazione no-profit creata allo scopo di diffonderle.
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo Agile di Software (Agile Software Development Manifesto). I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti erano accomunati della necessità di trovare un'alternativa ai pesanti processi di sviluppo software e alla stesura della relativa documentazione.
Questo ebook presenta i 12 punti del Manifesto, corredato dalla presentazione di Jim Highsmith, pubblicato in inglese su http://agilemanifesto.org/ , e nel libro tradotta in italiano.
Le trasformazioni subite dal mercato nel corso degli ultimi anni hanno reso il Customer Experience Management un imperativo strategico fondamentale da seguire da parte delle aziende in quanto la qualità non è più sufficiente per garantire un vantaggio competitivo e la nuova via per differenziarsi è la capacità di far vivere al consumatore un’esperienza complessiva appagante e superiore in modo tale da soddisfarlo completamente.
Proprio per tali ragioni l'attenzione alla Customer Experience sta assumendo un ruolo sempre più centrale all'interno delle organizzazioni in quanto un miglioramento complessivo nella gestione dell’esperienza del cliente si traduce in un miglioramento dell'immagine aziendale e in un aumento del fatturato nel lungo periodo; è infatti dimostrato che i clienti stessi riconoscono un valore economico alla CX e sono disposti a riconoscere un “premium price” all’azienda per poterne beneficiare.
Nella realizzazione degli strumenti necessari per la gestione e l’ottimizzazione della CX (Mappatura dei touchpoint, collocazione di questi nei processi, quantificazione della qualità dei processi, costruzione dei percorsi cliente, misurazione e individuazione dei gap) e nella creazione di una strategia di Customer Experience Management è stato individuato un approccio in 5 fasi:
–Mappatura dei processi vista cliente
–Individuazione dei gap rispetto alla CX ideale
–Revisione dei singoli punti/momenti di contatto con il cliente
–Gestione strutturata del customer feedback e dei Big Data
–Creazione di una funzione interna di CX
La modellizzazione delle Personas e la creazione degli scenari d'uso sono tra i fondamenti del User centered design. In questa presentazione riportiamo alcun i esempi di Personas e alcune note su come impostare un test di usabilità con risorse limitate.
La lezione tenuta da Michela Perotti e Elena Zordan alla School of Management del Politecnico di Milano su come sia possibile progettare con le persone.
Brochure aziendale LinkMe late2016.
LinkMe è una soware house milanese specializza nello
sviluppo di prodotti digitali, web e mobile, utilizzando linguaggio
Javascript. Preparata, aggiornata e abile nel trasformare in codice
le idee del cliente.
Processo EVO: http://www.sketchin.ch/it/blog/design/evo-evolutive-experience-design.html
Presentazione di lancio del nuovo processo di evolutive user experience design effettuata al Method Camp 2011 di Lugano.
Lean Web Solutions with WP [versione italiana]Carlo Beschi
Slide della mia presentazione al Wordcamp Milano 2011 su "Soluzioni web Lean con WordPress"
(http://wordcamp.it/milano2011/thank-god-its-friday-wordcamp-programma-del-27-maggio-2011/)
Dimitri favre #noprojects - Modern software development focuses on Teams and...Dimitri Favre
Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019
Tecniche Di Troubleshooting Nei Sistemi DistribuitiK-Tech Formazione
Questo seminario sulle tecniche di troubleshooting fa rientra nella collaborazione fra K-Tech (http://www.k-tech.it/) e la Facoltà di Ingegneria dell’Università Roma TRE, nell’ambito delle attività della Consulta.
Il seminario presenta come risolvere problemi tipici dei sistemi distribuiti che avvengono in produzione. Insieme agli esempi pratici si presenta anche un metodo per il troubleshooting che assicura una maniera veloce ed efficace per la determinazione dei problemi ed in generale per la gestione delle performance applicative. Il metodo si basa sulle evidenze del monitoraggio e pone l'accento sulla qualità delle informazioni raccolte in produzione, il fattore più determinante, assieme al tempo, per tutto il processo di troubleshooting. Questo materiale è preso da un corso di più giorni offerto da K-Tech s.r.l. Il corso ha lo scopo di mostrare agli Application Server Administrator (ASA) cosa fare per rendere possibile la risoluzione dei problemi in breve tempo e cosa evitare attraverso il confronto dei risultati di queste azioni. Gli esempi pratici mostrano come applicare correttamente il metodo e selezionare gli strumenti più adatti in ogni singolo caso.
Per conoscere le iniziative di K-Tech seguiteci sul nostro sito: http://www.k-tech.it/
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?
Le attuali metodologie di User centered design e Agile design permettono la progettazione e la realizzazione di prodotti e servizi digitali di ottima qualità garantendo un controllo sul processo di sviluppo, contemporaneamente però risultano troppo lente o troppo poco focalizzate per realizzare esperienze digitali che si adattino alle trasformazioni del mercato e dei bisogni degli utenti nel tempo.
Questi approcci si concentrano sul rilascio di una prima versione del prodotto o del servizio, trascurando le potenzialità che quello stesso prodotto potrebbe avere se valorizzato nel tempo.
Oggi i prodotti e i servizi digitali di successo sono quelli che riescono ad evolvere costantemente l'esperienza offerta nei confronti dell'utilizzatore finale. Si rende dunque necessario riadattare le metodologie tradizionali di progettazione sviluppate nel mondo del design industriale verso nuove forme di processo più costanti ed efficaci.
La User experience evolutiva è un nuovo processo di progettazione per sviluppare prodotti e servizi digitali che reinterpreta le attuali metodologie e si focalizza maggiormente sull'evoluzione dell'esperienza d'uso che punta a migliorare nel tempo il prodotto a cui si applica.
La proposta di questo processo consiste nel trovare un equilibrio virtuoso tra successo ed efficacia e si concentra sulla possibilità di migliorare quest'ultimo in base alle esigenze degli utenti, sull'attenta verifica dell'efficacia del prodotto o del servizio dopo il suo primo rilascio e sulla sua evoluzione nel tempo al fine di valorizzarne al massimo grado le potenzialità.
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
Consigli su come sviluppare e rilasciare App di Qualità:
1 portare utenti finali nel progetto di sviluppo, 2 elementi da considerare in fase di testing, 3 progettare un'interaction design di successo, 4 dall'idea all'app di successo, 5 azzerare il tasso di abbandono.
Noi conosciamo Kanban e Scrum come metodologie di gestione Agile. Lo Scrumban unisce le migliori caratteristiche di entrambi i metodi, combinando la natura prescrittiva dello Scrum e la capacità di miglioramento dei processi del Kanban, consentendo ai team di avvicinarsi allo sviluppo Agile e di migliorare costantemente i loro processi
Better Software 2010 - Applicazione pratica di un processo di sviluppo Agile ...Paolo Quaglia
Nel panorama delle Metodologie Agili esistono molteplici processi di sviluppo (es XP e SCRUM) che ereditano ed interpretano in maniera leggermente diversa i principi espressi dal Manifesto Agile.
Il talk approfondirà la tematica dell’implementazione reale e pratica di un processo di sviluppo Agile derivato dalle metodologie citate, ma customizzato per adattarlo alle esigenze aziendali e alla tipologia dei nostri progetti.
Verranno approfonditi i ruoli e le responsabilità individuati dal processo, le competenze soft necessarie, le fasi, i singoli passi e gli output, cioè gli artefatti prodotti, siano essi documenti, codice, test automatici, etc.
Verranno trattati anche la documentazione, che ha la caratteristica di essere il più snella possibile, ed i tool software che vengono utilizzati per la gestione e controllo dei progetti.
Lo scopo è quello di fornire un case study di implementazione reale (anche da un punto di vista contrattuale) approfondendo i pro ed i contro di questa metodologia, per dar possibilmente vita ad una discussione costruttiva sull’argomento.
Nelle prime due ore parleremo di nozioni teoriche su qualità, agile, XP e analizzeremo come caso reale i processi di produzione software interni alla mia azienda. Alla fine della prima parte parleremo dei problemi che abbiamo incontrato nell’applicare XP e lascerò spazio per ascoltare i problemi che voi avete incontrato nei vostri processi di produzione software. Nella seconda parte vedremo come abbiamo risolto alcuni dei nostri problemi, approfondiremo alcune pratiche che utilizziamo con esempi concreti e alla fine proveremo insieme a risolvere alcuni dei vostri problemi raccolti nella prima parte.
Ideato nasce nel 2008. All’inizio eravamo in quattro, dopo due anni siamo in 7. Che cosa facciamo? In particolare siamo un’azienda di servizi e il nostro servizio principale è lo sviluppo di applicazioni php. PHP è l’unico linguaggio di programmazione che usiamo per tutti i nostri progetti.
Ok, la frase sembra molto bella, ma che cosa significa qualità per noi?
Waterfall: è il modello a casacata, come dice la parola stessa. Prima raccolgo i requisiti, dall’intervista faccio il design dell’applicazione, il design fatto di UML, Diagrammi di Flusso, E/R, lo do in mano ai programmatori che lo implementano. Una volta sviluppata tutta l’applicazione, faccio i test di quality & assurance per garantire che le funzionalità siano uniformi ai requisiti raccolti e se è tutto ok la consegno al cliente. Punti deboli: difficile da cambiare a metà dell’opera, assenza di feedback, basata sui contratti piuttosto che sul software funzionante. Persone troppo specializzate che pur lavorando in team lavorano individualmente. Iterative and incremental: come waterfall ma iterativo. Ogni iterazione si ripete il processo waterfall. Punti deboli: come il waterfall, ma in grado di raccogliere i feedback più rapidamente, peccato che cmq poi non si riesca a cambiare. Agile: lo vedremo in maniera più approfondita nelle prossime slide
Qualità in economia, ingegneria e produzione ha una interpretazione pragmatica come la non-inferiorità o superiorità di qualcosa. La qualità è un attributo percettivo, condizionale e un po 'soggettivo e può essere interpretato in maniera diversa da persone diverse. Allora io ho provato a chiedere al mio team che cosa qualità significasse per loro, e sono uscite cose molto interessanti.
Raccolgo le user stories e le appiccico / scrivo alla lavagna
C’è già qualcuno che si è fatto la stessa domanda e dalla sua risposta è nato il Manifesto Agile. Il manifesto agile si basa su 4 principi cardini che dal nostro punto di vista definiscono l’intervallo di qualità. Rispettando questi principi sicuramente si produrrà un software di qualità. (Leggi i principi e spiegali uno ad uno=)
Dal manifesto agile sono nate scuole di pensiero differenti. Noi abbiamo sposato la causa XP. XP significa Extreme Programming. Per produrre software di qualità non bisogna essere mediocri ma estremi!!
Comunicazione: comunicazione chiara all’interno e all’esterno del team, tra sviluppatori e clienti, tra sviluppatori e management, tra sviluppatori stessi. Se incontriamo dei problemi chiediamo aiuto agli altri, magari conoscono già un modo per risolverlo. Semplicità: Qual è la cosa più semplice che può funzionare? Impariamo a lavorare su quello che necessita oggi, senza pensare al domani, domani è il futuro e prevedere il futuro non è semplice. Lavorando sulle funzionalità di oggi lasceremo il nostro sistema il più semplice possibile. Proviamo a far emergere il design piuttosto che fare design upfront. Feedback: le direzioni prestabilite tendono a cambiare facilmente. Ma per capire se devo cambiare ho bisogno di feedback. I feedback possono essere di tanti tipi: dal team, dai test, dal cliente, dal management. Devo essere predisposto alla richiesta di feedback, perché solo cambiando strada più volte arriverò alla meta ambita. Rispetto: Se i membri del team non credono negli altri. Se qualche membro non crede nel progetto, XP non può funzionare. In un team il contributo di qualsiasi persone è importante e il principio di umanità è quello che conta. Se il cliente non crede nel team, o non ne ha fiducia, XP non può funzionare. Coraggio: il coraggio è la capacità di reagire alla paura. Se sai che c’è un problema, fallo emergere e con coraggio prova a trovare una soluzione. La paura blocca, il coraggio ti fa muovere. Coraggiosa è anche la capacità di cambiare. Come disse Jacopo una volta, un paracadutista è coraggioso perché ha imparato a controllare la sua paura grazie al paracadute. Impariamo a controllare le nostre paure, trovando i nostri paracaduti.
XP utilizza dei principi come ponte tra i valori e le pratiche, e viceversa. Improvement? Design perfetto non esiste Reflection? Il team non lavora e basta ma si chiede perchè e come.
Il nostro team ha deciso di utilizzare XP, ma per farlo ha deciso prima di tutto di condividere i valori del manifesto agile e i valori di XP.
Andiamo a vedere nel dettaglio le tre fasi di processo e per ogni fase analizzeremo le attività interne.
La scrittura delle storie è una delle fasi più importanti. La caratteristica della user story è che si basa sulle funzionalità e non sull’architettura. La user story è indipendente, testabile, unica, stimabile Le storie si scrivoni nelle story card, noi usiamo i post-it
La scritture delle storie si fa o dal cliente o nei nostri uffici. I ruoli coinvolti sono (leggi ruoli). Le pratiche che si utilizzano sono (leggi pratiche) e spiega la dinamica di come avviene. Racconta esperienza LF.
Racconta esperienza LF. Al cliente si fanno decidere le priorità di business. A casa stimiamo la complessità con il Poker Game. Attraversole priorità di business e la conoscenza della complessità si decidono le priorità: Disegna grafico del planning. (Importanza/Difficoltà)
Racconta esperienza Mide (Planning in montagna). Le storie vengono scritte in un foglio excel e su redmine il nostro sitema di project managemente. Usiamo due strumenti, perché redmine non riesce a misurare bene le performance, cmq stiamo cercando un modo di usarne uno solo.
Le riunioni si fanno in skype call con il Product Owner. Il product Owner decide quale storia mettere dentro quella iterazione, gli sviluppatori le riordinano sempre in base alla difficoltà. Gli sviluppatori suddividono le storie in task, quotano i task in pomodori (racconta della tecnica del pomodoro) e riempiono il buffer dell’iterazione. Se parte del buffere resta vuoto, non si riempie, si riempie solo quando effettivamente si è sicuri che è vuoto.
I task vengono messi sul foglio excel e prioritizzati in base alla priorità delle storie. Spesso i task sono trasversali alle storie
Parlia di un esempio quotidiano in ideato. Dallo stand-up meeting, al prendersi in carico una storia. Come il team lavora in più progetti. Deploy ad ogni task chiuso. Build automatica. Il perno nel team. Parlare con il cliente e negoziare lo scope quotidianamente (la negoziazione dello scope non è un’attività commerciale). Il team si autoorganizza e gestisce il budget, misurando le proprie perfomance. Problemi vari con figure Junior.
La demo spesso la facciamo in conference call facendo il deploy dell’applicazione in una macchina staging. Durante la fase di demo si mostra ogni singola storia e si richiede feedback dal cliente. Se la storia è ok, essa viene accettata dal cliente, altrimenti si raccolgono i feedback e si mettono nel backlog.
Spiegare in maniera dettagliata come facciamo il deploy dalla nostra macchina alla macchina di produzione. Prima il server viene tunato dal sistemista.
Difficoltà nel pianificare progetti che dovrebbero essere fatti parallelamente… soprattutto o pianifico o lavoro!
Se tutto il team lavora che offre supporto al cliente? I clienti tendono ad interrompere il lavoro per qualsiasi piccola cosa e spesso hanno semplicemente voglia di fare due chiacchiere o capire fattibilità su piccoli progetti o modifiche. La segretaria non è la persona giusta, l’account spesso non ne capisce molto… ma allora chi ci vuole?
Il Feedback è uno dei valori più importanti, ma quando il cliente non si fa trovare come si fa? Lo sviluppatore è pragmatico, il cliente spesso ha bisogno invece di persone amichevoli che lo facciano sentire protetto e al sicuro. A quel punto allora la sua disponibilità aumenta.
Problema quando lavoriamo con le agenzie di comunicazioni, o con fornitori che lavorano waterfall o peggio senza alcun processo e buon senso.
Come posso collaborare con professionisti remoti che hanno deciso di lavorare da casa loro o dalla loro città?
Come faccio a stimare quanto ci metto a fare una certa cosa, se ho a che fare con una scatola nera? Semplicemente non lo faccio, ho bisogno che il cliente investa nel mio studio se vuole che utilizzi la sua scatola nera, altrimenti il rischio è troppo alto.
In una piccola azienda c’è la tendenza a pensare che gli sviluppatori possano fare più cose contemporaneamente. Ma è solo un’illusione. Fai l’esempio dello sviluppatore che lavora su un progetto e un altro cliente ha bisogno di un’altra piccola cosa.
Telefonate, email, skype, twitter, facebook, riunioni, comunicazioni…. Come combattere contro le distrazioni?
Raccolgo sulla lavagna i problemi di chi è in aula.
Pianifica i progetti a medio e lungo termine In nuovi progetti più lunghi di una iterazione ci aiuta nella creazione di un nuovo team di lavoro Supporta l'account nella creazione di preventivi e contratti Aiuta i team nel creare continuamente un ambiente che irradi informazioni sullo stato dell'azienda Filtra e smista i contatti dei clienti, offrendo un supporto di primo livello In piccoli progetti, nuovi o di supporto pianifica le attività del pronto soccorso E' il product owner del pronto soccorso, decidendone le priorità di sviluppo
Racconta l’esperienza quotidiana del pronto soccorso. Da Paolo che Pianifica allo sviluppatore che chiude il Kanban.
Comuniazione, feedback, confronto…
Fai vedere il foglio excel che utilizziamo, faccio vedere il foglio di lf.
Racconto l’esperienza di LF, della montagna di Evolution-Travel, di Tripshake Bonanno, di Bookerang
Racconta che cos’è la tecnicha del pomodoro. Ansia del tempo che passa VS capacità di utilizzare il tempo.
Racconta del Poker Game, dei giorni ideatli della regola dell’80/20 faccio vedere il foglio di LF.
Racconto dei post-it dei progetti, del release manager, dei server monitorati, di hudson e del nabaztag.
Misurare le performance è fondamentale. Burndown chart, velocity del team. Faccio vedere foglio LF.
Utilzzo massivo di SVN.
La tecnicha dei test automatici. Introduci ai test unitari, test funzionai e test di regressione. Parla degli strumenti che utilizziamo. PHPUnit, Lime, Symfony TestBrowser, Selenium.
Macropianificazione nel medio e lungo termine per dare continuità al team.
Para di hudson.
Che cos’è, perché farlo. Racconta che cosa ci diciamo noi la mattina.