Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo sviluppo software

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo sviluppo software"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Ingegneria del Software Le storie utente ed altre tecniche per la specifica dei requisiti negli approcci Agili per lo Anno Accademico 2011/2012 Candidato: Marcello Traiola matr. N I

2 II

3 Sommario Introduzione... 4 Capitolo 1 - La nascita dei metodi agili I principi dei metodi agili Attenzione ai requisiti! Scriviamo i requisiti... 9 Capitolo 2 - Tre metodi a confronto SCRUM Flow La specifica dei requisiti in SCRUM È fatto? Persone, non processi! Uno sguardo al processo di XP La specifica dei requisiti in XP The Planning Game L anima di XP L approccio di Crystal Crystal Clear Crystal Orange Crystal Orange/Web Capitolo 3 - Confronti e conclusioni Un analisi trasversale Supporto alla gestione del processo Guida pratica o concetti astratti? Approccio standard o adattivo? Quanta innovazione? Conclusioni Bibliografia Articoli scientifici Sitografia III

4 Introduzione Il rapido progresso tecnologico che ha caratterizzato gli ultimi decenni ha portato all introduzione dell informatica nella quasi totalità dei settori, che riguardano sia prodotti sia servizi. Un software avanzato che assista la produzione è, ormai, requisito fondamentale per ogni azienda che voglia creare prodotti di qualità con tempi e costi ridotti. Come sono sviluppati i software in grado di supportare in maniera adeguata la produzione? Le varie fasi del cosiddetto ciclo di vita del software sono oggetto di studio da molti anni e, secondo il contesto in cui vengono analizzate, presentano diverse peculiarità. La progettazione di un sistema critico per il controllo della stabilità di un velivolo, ad esempio, necessita che tutti i requisiti siano meticolosamente analizzati per verificare che le varie interazioni non compromettano la sicurezza; ciò richiede una lunga fase di analisi dei requisiti alla fine della quale si avrà un idea chiara e definitiva dei requisiti del sistema. «Quando questo approccio pesante [ ] [è] applicato a sistemi aziendali di piccole e medie dimensioni, l overhead richiesto [è] così alto che a volte [domina] il processo di sviluppo del sistema» [Sommerville 2007]. 4

5 Si comprende facilmente, infatti, come un azienda, influenzata dall andamento dei mercati e vincolata al rispetto di specifiche norme giuridiche, debba operare repentini cambi di rotta e prendere decisioni spesso in contrasto fra loro. Tutto ciò si riflette sul software. Un approccio come quello citato in precedenza necessita che i requisiti siano completamente definiti, cosa che avviene raramente in contesti del genere. Adottare soluzioni di sviluppo pesanti può portare a sviluppare software di qualità nei tempi stabiliti ma non garantisce che siano ancora utili. Nascono, quindi, i metodi agili. In questo testo ci si propone di esaminare il processo di analisi dei requisiti per alcuni fra i metodi agili più conosciuti e utilizzati. S introdurrà il concetto di metodo agile per poi proseguire con la presentazione di tre fra i metodi più famosi (SCRUM, extreme Programming e Crystal) ponendo l attenzione su come avviene la specifica dei requisiti. Infine si metteranno in luce pregi e difetti dei metodi descritti e si concluderà con un confronto. 5

6 Capitolo 1 La nascita dei metodi agili Negli anni 90 alcuni sviluppatori software proposero nuovi metodi di sviluppo che presero il nome di metodi agili. Il motivo principale per cui divenne necessario trovare un nuovo modo di fare software fu che, con i metodi tradizionali, «si impiegava più tempo per decidere come il sistema sarebbe stato sviluppato piuttosto che per lo sviluppo e il test del programma» [ Sommerville 2007]. L idea comune che unisce tutti i metodi agili è quella di sviluppo e consegna incrementale per cui durante la produzione si attraversano più di una volta tutte le fasi del ciclo di vita del software ( sviluppo ciclico ). Il software sarà sviluppato e consegnato per incrementi, ognuno dei quali implementerà una nuova funzionalità testata e pronta per essere commercializzata. In questo modo si 6

7 guadagna il feedback degli utenti così da comprendere più a fondo pregi e difetti del prodotto realizzato. 1.1 I principi dei metodi agili Individuals and interactions over processes and tools. Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Questi quattro punti rispecchiano ciò che i firmatari del manifesto agile (www.agilemanifesto.org) considerano importante nella creazione del software. Gli individui e le interazioni fra essi sono più importanti dei processi e degli strumenti poiché i progetti sono fondati sulle persone: queste devono essere motivate e devono lavorare in un ambiente che garantisca adeguato supporto. Si deve preferire un software funzionante a una documentazione esaustiva: quale metro migliore per misurare il progresso del rilascio frequente di software funzionante! Meglio collaborare col cliente piuttosto che negoziare un contratto: una conversazione face to face elimina fraintendimenti e rende tutti uniti per raggiungere gli obiettivi. Seguire un rigido piano rende meno flessibili, pertanto anche a stadi di sviluppo avanzati i cambiamenti vanno accolti per favorire la competitività del cliente. 7

8 1.2 Attenzione ai requisiti! Mentre in passato si dava molta importanza alla specifica minuziosa dei requisiti, l avvento dei metodi agili propone di prestare maggiore attenzione al fare piuttosto che al progettare. Questa proposta, nata per venire incontro a esigenze di sviluppo veloce del software, è stata fraintesa. La continua richiesta di programmi avanzati ed evoluti ha portato all eccesso opposto: «doing requirements takes time time that could be spent writing code and users often feel better if they think that people are working [ ] on their problems» [Ken Orr IEEE software 2004] ovvero: Analizzare requisiti prende tempo tempo che potrebbe essere speso scrivendo codice e gli utenti spesso si sentono più sereni pensando che le persone lavorino sui loro problemi. Si è giunti, dunque, a considerare quasi superflua l analisi dei requisiti sacrificando la comprensione del progetto cui si lavora in favore della sua rapida creazione. Ken Orr, nell articolo Agile Requirements: Opportunity or Oxymoron? pubblicato sulla rivista IEEE Software nel 2004, osserva come un analista, invece di assumere il ruolo passivo di scrivere ciò che gli utenti chiedono, dovrebbe aiutarli a inventare i requisiti. Infatti dice obiettivi e vincoli che il sistema deve rispettare spesso non sono chiari agli utenti, per cui c è bisogno che qualcuno li guidi attraverso il processo di analisi. Neil Maiden e Alexis Gizikis (Centre for HCI Design, City University, London) insieme a Suzanne Robertson (The Atlantic Systems Guild) nell articolo Provoking Creativity: Imagine What Your Requirements Could Be Like (IEEE Software, vol. 21, no. 5, 2004, pp ) riportano i risultati dell esperienza fatta lavorando con EUROCONTROL (European Organisation for the Safety of Air Navigation). L obiettivo era di progettare e implementare RESCUE (Requirements Engineeringwith Scenarios for User-centered Engineering), un processo per determinare i requisiti di interesse per gli utenti, applicandolo ad un sistema che fornisce assistenza computerizzata ai controllori di traffico aereo per risolvere potenziali conflitti tra velivoli (CORA-2). 8

9 Per stimolare la creatività i progettisti hanno coinvolto membri del team e stakeholders in quelli che chiamano workshop. Durante il primo di questi sono stati invitati esperti di design tessile e compositori musicali per incoraggiare confronti e analogie tra i due settori e CORA-2. Durante il secondo un esperto fabbricante di giochi Lego ha introdotto oggetti a caso durante discussioni su scenari di risoluzione dei conflitti tra velivoli allo scopo di provocare pensiero creativo. Per il terzo, infine, è stato invitato un fusion chef a discutere il legame fra ingredienti non convenzionali facendoli assaggiare; lo chef ha inoltre dato dimostrazione della cucina fusion preparando un pranzo che ha messo in luce le differenze tra gli ingredienti ma anche la loro complementarietà. Ogni workshop, inoltre, partiva con attività mirate a creare il giusto ambiente per sviluppare pensiero creativo; tra queste le più singolari: palloncini per incoraggiare al gioco e all interazione, shouting sessions per contrastare inibizioni e incoraggiare il lavoro di gruppo, ascolto di musica rilassante. Da questo studio sono emerse le grandi difficoltà degli utenti nel definire i requisiti per i propri software e il ruolo centrale che gli analisti dovrebbero avere nel guidarli attraverso il processo. 1.3 Scriviamo i requisiti Come abbiamo finora descritto, le tecniche agili hanno avuto un impatto molto forte sul processo di definizione dei requisiti. Ora occupiamoci di comprendere le novità che sono state introdotte nella documentazione dei requisiti. Gli stakeholder scrivono le cosiddette storie utente e ciò spesso accade durante i workshop. Ogni storia utente Storie Utente [Maiden and Jones, IEEE Software, vol.27 no.3, 2010, pp ] è scritta su una cartolina di 9

10 dimensioni contenute (3x5 pollici) poiché semplicità e brevità sono caratteristiche precipue delle storie utente. Ognuna descrive un requisito in maniera semplice dal punto di vista dell utente senza specificare troppi particolari. Ciò lascia spazio alla comunicazione faccia a faccia durante la quale si definiscono meglio gli obiettivi di ogni requisito. Ogni progetto genera molte storie utente in modo che sia semplice selezionarle e gestire i requisiti da implementare. Lan Cao e Balasubramaniam Ramesh nello studio condotto sull utilizzo dei metodi agili nella specifica dei requisiti (RE, requirements engineering ), hanno identificato sette pratiche di RE utilizzate dalle 16 organizzazioni prese in esame [IEEE Software vol.25 no.1 January/February 2008, pp , Agile Requirements Engineering Practices: An Empirical Study ]. Ognuna di queste presenta lati positivi e negativi: Comunicazione faccia a faccia invece di specifiche scritte o Benefits: I clienti guidano il progetto in direzioni inaspettate quando le loro richieste mutano in seguito a cambi di environment. Il tempo sprecato per consultare la documentazione, ora superflua a causa dei cambiamenti ricorrenti, è utilizzato in maniera più produttiva. o Challenges: È difficile che il cliente sia sempre disponibile per un incontro e ciò pone dei rischi come la possibilità di avere requisiti non ben sviluppati o, addirittura, sbagliati. L effettiva comunicazione dipende, oltre che dalla disponibilità, anche della fiducia reciproca tra team e cliente. Infine se i clienti interessati al prodotto sono più di uno non è facile raggiungere compromessi che mettano tutti d accordo in cicli di sviluppo brevi. Specifica dei requisiti iterativa o Benefits: «I think the difference for me came in the quality of the software [and] the stability of the software. [ ] I think the agile [RE] lent itself to [ ] a very robust rich implementation of features [ ] [for] the first time»: le parole di un cliente, che confronta l esperienza agile con quella 10

11 tradizionale, mettono in luce il rapporto di fiducia tra team e cliente che nasce dai continui incontri e il conseguente piacere di quest ultimo nel vedere soddisfatte le proprie aspettative. I requisiti diventano più chiari e comprensibili grazie all immediato coinvolgimento del cliente quando necessario. o Challenges: Complessità nello stimare costi e tempi: ottenere supporto manageriale in progetti di questo tipo non è semplice. La poca documentazione prodotta può causare vari problemi come la difficoltà di migliorare il software e coinvolgere nuovi membri nel team. Requisiti non funzionali sono spesso mal definiti poiché l attenzione è focalizzata sulle funzionalità principali e requisiti come scalabilità, manutenibilità, portabilità, sicurezza o performance sono ignorati. Frequenti cambi di priorità dei requisiti o Benefits: Siccome nella RE agile la priorità dei requisiti è scelta in base alle esigenze di mercato come sono intese dal cliente, la partecipazione di quest ultimo alla realizzazione fornisce in ogni ciclo di sviluppo motivazioni, di tipo economico, per l implementazione di un requisito piuttosto che di un altro. o Challenges: D altro canto gestire la priorità dei requisiti guardando al mercato come unico obiettivo può causare problemi riguardanti requisiti non funzionali come stabilità, sicurezza, efficienza, scalabilità, etc. La continua pianificazione cambia il modo di gestire i requisiti o Benefits: Il continuo confronto tra team e cliente fornisce maggior consapevolezza riguardo al lavoro svolto poiché in ogni incontro l attività di pianificazione assume ruolo fondamentale. Per questo motivo la maggior parte dei cambiamenti richiesti sono «usually more a case of tweaks spelling, little graphical things for example, color, positioning». 11

12 o Challenges: Siccome l architettura scelta durante le prime fasi del processo produttivo diventa inadeguata in alcuni casi con il cambiare dei requisiti, progettarne una nuova aggiunge costi al progetto. Spesso neanche il refactoring, che semplifica il codice senza compromettere le funzionalità, riesce a porre rimedio a problemi di architettura. Uso di prototipi o Benefits: Invece di perdere tempo a scrivere documentazione dettagliata si mostra al cliente il lavoro svolto per discuterne la validità. o Challenges: È complicato manutenere e aggiornare i prototipi e causa problemi con requisiti come scalabilità, sicurezza e robustezza. Sviluppo guidato dai test (TDD). o Benefits: Creare dei test prima di creare il codice che li supererà «allows you to be more adventurous in terms of making changes and trying out ideas» poiché si ha un feedback immediato del lavoro svolto. o Challenges: Gli sviluppatori non sono abituati a scrivere i test prima del codice. Sono necessarie una profonda comprensione dei requisiti e una collaborazione intensiva tra sviluppatori e clienti. Utilizzo review meetings e acceptance tests o Benefits: I review meeting riportano prima di tutto i progressi del progetto al cliente e agli stakeholder e danno la possibilità di capire se il progetto procede verso l obiettivo desiderato. Inoltre fiducia e confidenza tra cliente e team si fortificano. o Challenges: Spesso è difficile implementare gli acceptance test a causa della difficoltà di far riferimento ai clienti che li hanno sviluppati. Emerge, dunque, che la differenza fondamentale tra RE tradizionale e RE agile è che quest ultima sfrutta un approccio iterativo per scoprire i requisiti e non segue un rigido piano di sviluppo. Ciò è dovuto al fatto che, in alcuni ambienti, ottenere 12

13 specifiche molto precise è praticamente impossibile oppure addirittura inutile in quanto è probabile che cambino. Osservando i risultati dello studio di Cao e Ramesh si capisce come la novità più apprezzata in ambienti del genere sia l intensiva comunicazione che porta il team a comprendere i desideri del cliente e rende lo sviluppo più dinamico e adattabile. 13

14 Capitolo 2 Tre metodi a confronto In questo capitolo si cercherà di analizzare, per ogni metodologia agile proposta, il processo di specifica dei requisiti al fine di fornire un punto di vista utile, nel capitolo successivo, ad analizzare differenze e somiglianze e a comprendere in quali situazioni una metodologia possa essere più utile rispetto a un altra. 2.1 SCRUM Flow Prima di parlare del processo di specifica dei requisiti in SCRUM occupiamoci di dare un quadro generale del processo e delle persone che portano al rilascio del software. Partiamo analizzando lo SCRUM Team composto da Product Owner, Team e SCRUM Master. o Il Product Owner è una persona che rappresenta il committente. È responsabile della gestione del Product Backlog e ha il compito di massimizzare il valore del lavoro svolto dal team. Le sue decisioni devono essere rispettate affinché il suo lavoro sia efficace. o Il Team è composto di più persone (in genere tra 3 e 9) che lavorano per produrre un incremento del prodotto da consegnare alla fine di uno sprint. Il 14

15 team è organizzato in maniera autonoma ed è cross-funzionale. Ogni membro ha le stesse responsabilità degli altri a prescindere dal ruolo svolto. o Lo SCRUM Master ha, da una parte, il ruolo di leader per il team e, dall altra, d intermediario tra il team e coloro che non ne fanno parte. Ha il compito di verificare che il team comprenda e applichi le regole di SCRUM e quello di riconoscere quali interazioni tra il team e gli stakeholder sono utili e quali no. Lo Sprint è considerato il cuore di SCRUM. È un periodo durante il quale il team produce un incremento del prodotto secondo le priorità imposte dal Product Backlog allo scopo di rilasciare sul mercato funzionalità complete e testate. Lo Sprint consta, oltre che di quella di sviluppo, di più fasi: o Sprint Planning Meeting: riunione durante la quale sono pianificate le attività da svolgere durante lo Sprint. Partecipa l intero SCRUM Team. La prima delle due fasi dell incontro è incentrata su cosa sarà fatto durante lo Sprint: il Product Owner presenta i punti del Product Backlog partendo da quelli a priorità maggiore e, in base anche all ultimo incremento e alle performance precedenti del Team, si definisce l Obiettivo di Sprint (o Sprint Goal) che sarà perseguito. Il numero di punti del Product Backlog che saranno considerati nello Sprint Goal e, quindi, implementati è deciso esclusivamente dal Team poiché nessuno conosce meglio le sue potenzialità. La seconda fase della riunione è incentrata sul come si porterà a termine il lavoro in programma. In questa fase nasce lo Sprint Backlog fatto dalle voci selezionate dal Product Backlog e dal piano per la consegna. Si progetta il lavoro necessario all implementazione dei requisiti scelti e, se risulta troppo o troppo poco, si possono ridiscutere con il Product Owner le voci selezionate dal Product Backlog. 15

16 La durata di un Meeting è di otto ore per uno Sprint di un mese. Se lo Sprint dura meno, si avrà una riduzione proporzionata della durata del Meeting. o Daily Scrum: Riunione giornaliera di 15 minuti (ogni giorno nello stesso posto e alla stessa ora) utile al Team di Sviluppo per definire e sincronizzare le attività della giornata in base al lavoro svolto il giorno precedente. Durante la riunione ci si accerta che il lavoro svolto sia sempre in linea con lo Sprint Goal. Lo SCRUM Master assicura e disciplina lo svolgimento della riunione che è condotta, però, esclusivamente dal Team. L obiettivo principale della riunione, in fondo, è quello di migliorare le comunicazioni all interno del team per eliminare ostacoli come incomprensioni o malintesi nel pieno rispetto delle metodologie agili. o Sprint Review: Incontro che avviene al termine di uno Sprint per esaminare l incremento prodotto e modificare, se necessario, il Product Backlog. Prendono parte alla riunione anche gli stakeholder. Si tratta di un colloquio informale atto a suscitare i commenti dei partecipanti e a spronare la collaborazione. Durante lo svolgimento il Team riporta l evoluzione dello Sprint evidenziando i problemi incontrati e le soluzioni trovate. In base al lavoro prodotto, il Product Owner fa delle stime sul tempo ancora necessario e discute col Team di eventuali accorgimenti da fare. Il risultato è un Product Backlog riesaminato e aggiornato. La durata dell incontro è di quattro ore per uno Sprint di un mese. Se lo Sprint dura meno, si avrà una riduzione proporzionata della durata dell incontro. o Sprint Retrospective: È una riunione di tre ore (dopo uno Sprint di un mese) che riguarda esclusivamente il Team SCRUM. Lo scopo di tale incontro è far si che il Team guardi a se stesso in modo critico e adatti il proprio atteggiamento secondo i problemi che emergono per trovare soluzioni in maniera più 16

17 semplice. Lo SCRUM Master incoraggia tale attività e invita il Team a individuare pratiche per rendere più efficace e divertente lo Sprint successivo. SCRUM Flow [Ken Schwaber, Agile Project Management with Scrum, Microsoft Press 2004] La specifica dei requisiti in SCRUM Quello di Product Backlog è il concetto intorno a quale gira il processo di specifica dei requisiti in un ambiente di che sfrutta l utilizzo di SCRUM. Il termine indica la lista di requisiti ottenuta a valle di una discussione tra il team di sviluppo e il cosiddetto Product Owner, che rappresenta il soggetto committente ed è l unico responsabile del Product Backlog. La caratteristica precipua del Product Backlog è di non essere mai completo ma, piuttosto, sempre in continua evoluzione in base alle modifiche che i requisiti subiscono con l avanzare del progetto e alla priorità che essi assumono. Ciò che si trova alla base di questa caratteristica è la consapevolezza che lo sviluppo del software in sé porta alla luce problematiche non prevedibili nell analisi iniziale, cosa che compromette anche le stime dei tempi di sviluppo più accurate. 17

18 Gli elementi presenti nel Product Backlog sono spesso ordinati per priorità, rischio, valore, necessità; in cima alla lista, in genere, si trovano gli elementi più discussi dal team, quindi più conosciuti e consolidati, che saranno trattati per primi. Al concetto di Product Backlog è strettamente legato quello di Sprint. Questo termine indica la finestra temporale alla fine della quale sarà rilasciato un incremento del prodotto potenzialmente utilizzabile che implementa parte delle funzionalità. La durata di uno Sprint è molto limitata (in genere massimo un mese) in accordo al principio di rilascio graduale che contraddistingue le metodologie agili. In questo modo ogni funzionalità realizzata è testata a fondo prima del rilascio per garantire che soddisfi le specifiche richieste. Al termine di ogni Sprint ha luogo una riunione ( Sprint review ) in cui si discute il lavoro fatto durante lo Sprint appena concluso e si concorda il lavoro che sarà fatto durante il successivo. Il Product Backlog in questa fase si evolve in accordo con quanto emerso durante lo Sprint. Alla fine di questa fase, dunque, si ottiene una lista aggiornata dei requisiti che il software deve soddisfare e si conosce quale sarà il lavoro da svolgere durante lo Sprint che sta per cominciare È fatto? Presupposto fondamentale per la buona riuscita dell analisi dei requisiti e per un buon test delle funzionalità implementate è la condivisione del concetto astratto di fatto (cfr. done in inglese). Com è naturale, la definizione di un concetto astratto è difficilmente condivisa da tutti, motivo per il quale concetti espressi in poche parole, magari scritte, spesso sono confusi con altri secondo la personale interpretazione. Citando Mike Cohn: «Written words are misleading - they look more precise than they are» [Cohn 2009] ovvero Le parole scritte sono fuorvianti sembrano più precise di quanto non lo siano. Definire, dunque, un interpretazione comune del concetto di fatto giova enormemente al processo di sviluppo giacché porta i membri del team a perseguire un obiettivo comune e a lavorare in armonia giovandosi ognuno del lavoro degli altri. 18

19 Si può facilmente capire, quindi, come diverse interpretazioni del concetto di completezza incidano sulla stima dei tempi necessari allo sviluppo di una funzionalità e, di conseguenza, sulla scelta di quanti e quali elementi del Product Backlog trattare in uno Sprint Persone, non processi! Il processo di produzione tradizionale è diviso in fasi ben distinte sulle quali è difficile ritornare una volta concluse. Per quanto riguarda la specifica dei requisiti quest approccio produce un documento preciso e puntuale in cui le richieste del cliente hanno una forma ben definita e vanno a tutti i costi rispettate. Ciò porta gli sviluppatori a sentirsi costretti a implementare ciò che il documento prescrive e non a condividere gli obiettivi che tale documento hanno prodotto. SCRUM pone l attenzione più sulle persone che sul processo di produzione giacché quest ultimo dipende dalle persone che lo intraprendono. Prendere in considerazione un processo produttivo in maniera assoluta porta inevitabilmente a un calo della qualità del prodotto o, quantomeno, ad avere tempi di produzione più lunghi. Riportiamo le parole di Mike Cohn per comprendere meglio il concetto appena espresso: One of the goals of shifting to Scrum is to get the whole team working together toward the goal of delivering a great product. We want to strip our development process of bad habits that work against this goal. Written documents create sequential hand-offs, which deprive the team of a unity of purpose. One person (or group) defines the product; another group builds it. Two-way communication is discouraged. Through the written document, one team member is saying, "Here's what to do," and others are expected to do it. This type of master-and-servant relationship is unlikely to create strong feelings of engagement on the part of the servants. Rather than feeling responsible for the success of the product, they feel responsible for doing what is described in the document. Discussions have the 19

20 opposite effect: Whole team discussions lead to greater buy-in by all team members [Cohn 2009]. 2.2 Uno sguardo al processo di XP Diamo ora un rapido sguardo all intero processo produttivo di extreme Programming (XP d ora in poi) in cui la specifica dei requisiti s innesta. Oltre alle fasi di Esplorazione e Pianificazione racchiuse nel Planning Game che vedremo nei prossimi paragrafi, il processo XP consta di altre quattro fasi: o Iterazioni verso il primo rilascio: fase caratterizzata da più iterazioni che portano alla prima versione del software pronta per essere utilizzata. Sono selezionate le storie e sono prodotti test funzionali per ogni iterazione. o Fase di produzione: durante la produzione potrebbe presentarsi la necessità di ridurre il tempo dedicato a ogni iterazione, di creare test prestazionali e di cambiare storie (dopo una discussione col Cliente). o Manutenzione: fase in cui il processo si trova per la maggior parte della sua vita; mentre il sistema è in esecuzione, si sviluppano nuove funzioni in modo da non interrompere l erogazione dei servizi implementati e aggiungerne di nuovi. o Morte: questa fase terminale sopraggiunge quando i clienti non sono più in grado di produrre storie oppure quando il sistema non è più in grado di soddisfare le necessità del cliente. È la fase in cui bisogna necessariamente produrre documentazione. 20

21 2.2.1 La specifica dei requisiti in XP «We will plan by quickly making an overall plan, then refining it further and further on shorter and shorter time horizons years, months, weeks, days. We will make the plan quickly and cheaply, so there will be little inertia when we must change it» [Beck 1999]. La specifica dei requisiti in XP è un processo che avviene durante la fase individuata dal termine The Planning Game. Questa pratica si basa su alcuni principi cardine: Pianificare in modo dettagliato esclusivamente il prossimo rilascio: si può pensare alle iterazioni successive ma assolutamente non nei dettagli. Assumere responsabilità, non darle: il manager non può assegnare il lavoro, è ogni membro del team che deve decidere cosa può fare. La stima dei tempi di realizzazione deve essere fatta da chi realizza. Ignorare le dipendenze tra le parti del progetto: progettare come se le parti potessero cambiare in ogni istante. Pianificazione orientata alle priorità: il cliente non ha bisogno di molti dettagli per fissare le priorità. 21

22 2.2.2 The Planning Game L obiettivo della pianificazione in XP è di eliminare imbarazzi e screzi tra clienti e sviluppatori e incoraggiare la comunicazione. Ciò è conseguenza del fatto che non esistono regole, per quanto flessibili, che possano eliminare le emozioni dalle persone. È importante che esistano regole al fine di ricordare come ci si dovrebbe comportare e di fornire un riferimento comune nel caso in cui le cose non procedano per il giusto verso. Ognuna delle due parti, clienti e sviluppatori, deve rispettare l altra e solo in un ambiente di fiducia si può lavorare in maniera serena. È necessario, quindi, avere delle regole che suggeriscano come impostare i rapporti, ma è essenziale che rimangano dei suggerimenti in modo che, se il rapporto diventa ben saldo, si possano anche modificare o rimuovere. o Obiettivo: obiettivo del gioco è massimizzare il valore del software prodotto. Dal valore del software si deve stimare il costo dello sviluppo e i rischi che si corrono. o Strategia: Il team tende a investire meno possibile per mettere in produzione le funzionalità principali il più velocemente possibile con strategie atte a ridurre i rischi. Quando al cliente diviene chiaro quali sono le funzionalità più importanti il team può immediatamente metterle in produzione. o I pezzi del gioco: I pezzi del plannig game sono le story card (in figura). Ogni storia descrive, nel modo più semplice possibile, una funzionalità che il sistema dovrebbe implementare. Seguendo questa pratica si avrà un inquadramento generale della questione e non si creeranno rigidi schemi da seguire. 22

23 Story Card [Kent Beck, 1999, Extreme Programming Explained: Embrace Change ] o I giocatori: Come si è già intuito, devono esserci due giocatori, il Cliente (decide come il sistema deve essere) e lo Sviluppo (realizza il sistema). o Le mosse: il gioco ha fondamentalmente tre fasi Esplorazione: in questa fase i partecipanti si rendono conto di ciò che il sistema dovrebbe fare. Il Cliente scrive una storia descrivendo cosa dovrebbe fare il sistema, lo Sviluppo stima il tempo d implementazione. Nel caso la stima non sia possibile o ci siano parti più importanti rispetto a altre, si divide la storia in più parti. Impegno: il Cliente propone una data di rilascio e lo Sviluppo s impegna a rispettarla. In questa fase il Cliente organizza le card per valore, lo Sviluppo le organizza per rischio e comunica il tempo necessario per realizzarle. Alla luce dei risultati, poi, il Cliente sceglie le card da includere nell iterazione. Aggiornamento: all inizio di ogni iterazione il Cliente sceglie le storie da implementare che formino un sistema funzionante. Se lo Sviluppo si accorge di essersi sopravvalutato può chiedere al Cliente di rivedere le storie da implementare alla luce delle nuove 23

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Processi di Sviluppo Agile Origini dello Sviluppo Agile Proposta di un gruppo di sviluppatori che rilevava una serie di criticità degli approcci convenzionali: Troppa rigidità dei

Dettagli

Sviluppo Agile. Prof. Filippo Lanubile. Processo software

Sviluppo Agile. Prof. Filippo Lanubile. Processo software Sviluppo Agile I processi (di sviluppo) del software bisogni nuovi o modificati Processo software Prodotto software nuovo o modificato Un processo software descrive quali sono le attività che concorrono

Dettagli

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

Introduzione all Ingegneria del Software

Introduzione all Ingegneria del Software Introduzione all Ingegneria del Software Alessandro Martinelli alessandro.martinelli@unipv.it 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software

Dettagli

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland

The Scrum Guide. La Guida Definitiva a Scrum: Le Regole del Gioco. Ottobre 2011. Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland The Scrum Guide La Guida Definitiva a Scrum: Le Regole del Gioco Ottobre 2011 Sviluppata e sostenuta da Ken Schwaber e Jeff Sutherland Indice Scopo della Guida Scrum... 3 Overview di Scrum... 3 Scrum Framework...

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti

Poca documentazione: uso di Story Card e CRC (Class Responsibility Collabor) Collaborazione con il cliente rispetto alla negoziazione dei contratti Sviluppo Agile [Cockburn 2002] Extreme Programming (XP) [Beck 2000] Sono più importanti auto-organizzazione, collaborazione, comunicazione tra membri del team e adattabilità del prodotto rispetto ad ordine

Dettagli

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami

Echi da Amsterdam. Titolo: Sintesi presentazioni Metodologia Agile. Sintesi del Leadership Meeting e dell EMEA Congress 2009. Relatore: Bruna Bergami Echi da Amsterdam Sintesi del Leadership Meeting e dell EMEA Congress 2009 Titolo: Sintesi presentazioni Metodologia Agile Relatore: Bruna Bergami PMI NIC - Tutti i diritti riservati Milano, 19 Giugno

Dettagli

Approcci agili per affrontare la sfida della complessità

Approcci agili per affrontare la sfida della complessità Approcci agili per affrontare la sfida della complessità Firenze, 6 marzo 2013 Consiglio Regionale della Toscana Evento organizzato dal Branch Toscana-Umbria del PMI NIC Walter Ginevri, PMP, PgMP, PMI-ACP

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

Coaching. Nicola Moretto

Coaching. Nicola Moretto nicola.moretto@xpeppers.com XP Coach Coach Tecnico Scrum Master Coach Sistemico Evolutivo Coach Ontologico Trasformazionale Agile Coach Coach Puro Scrum Master Uno Scrum Master: Rimuove le barriere.

Dettagli

Gestione del gruppo di lavoro: motivazione e coaching

Gestione del gruppo di lavoro: motivazione e coaching Gestione del gruppo di lavoro: motivazione e coaching Il team Un gruppo di persone che: condividono uno scopo, hanno un obiettivo in comune collaborano, moltiplicando le loro risorse condividono i vantaggi

Dettagli

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1

Scrum. Caratteristiche, Punti di forza, Limiti. versione del tutorial: 1.0. www.analisi-disegno.com. Pag. 1 Scrum Caratteristiche, Punti di forza, Limiti versione del tutorial: 1.0 Pag. 1 Scrum è uno dei processi agili (www.agilealliance.com) il termine è derivato dal Rugby, dove viene chiamato Scrum il pacchetto

Dettagli

Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One - Oracle

Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One - Oracle FACOLTÀ DI INGEGNERIA RELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA SPECIALISTICA IN INGEGNERIA GESTIONALE Implementazione e gestione del transitorio nell introduzione di un sistema ERP: il caso Power-One

Dettagli

Agile in tough economic times. Agile in tough. Slide 1 30 April 2009

Agile in tough economic times. Agile in tough. Slide 1 30 April 2009 Slide 1 Indice Storia Agile di una startup nel nostro progetto Qual e il valore aggiunto di Agile nei periodi di incertezza Conclusioni Slide 2 Non disclosure agreement Ho firmato un NDA che non mi permette

Dettagli

Agili, snelli e scattanti!

Agili, snelli e scattanti! Agili, snelli e scattanti! Dipartimento di Scienze Odontostomatologiche 4 Giugno 2013 Emiliano Soldi PMP, PMI-ACP, CSM Agile Practice Leader & Coach http://www.emilianosoldipmp.info @EmilianoSoldi Agile

Dettagli

Progetto di Informatica III

Progetto di Informatica III Progetto di Informatica III Sviluppo Agile (Agile Software Development) Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Metodologia agile Agile Manifesto Che cos è l agilità

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

Quali passi per introdurre l Agile in azienda?

Quali passi per introdurre l Agile in azienda? Quali passi per introdurre l Agile in azienda? Garantire reattività e prontezza in uno scenario sempre più dinamico Quali passi per introdurre l Agile in azienda? White Paper Nell attuale contesto di mercato,

Dettagli

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore

METODI AGILI IL CONTROLLO DI GESTIONE PER. Loredana G. Smaldore METODI AGILI PER IL CONTROLLO DI GESTIONE 1 Fonte: Smaldore, L.G. (2014), Metodi «Agili» per il Controllo di Gestione, in Busco C., Giovannoni E. e Riccaboni A. (a cura di), Il controllo di gestione. Metodi,

Dettagli

Ingegneria del Software T. 2. Analisi orientata agli oggetti

Ingegneria del Software T. 2. Analisi orientata agli oggetti Ingegneria del Software T 2. Analisi orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2.

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2. Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Judgment. Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement.

Judgment. Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement. Judgment Ogni giorno prendiamo migliaia di decisoni, dalle più banali alle più importanti. Ma quante di queste sono giuste? hoganjudgement.com 2014 Hogan Assessment Systems PERSONALITÀ E DECISIONI I problemi

Dettagli

ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA ROB THOMSETT EXTREME PROJECT MANAGEMENT WORKSHOP ROMA 7-9 MAGGIO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it EXTREME

Dettagli

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9

Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 15: P.M.: metodologie di progetto Prof.ssa R. Folgieri email: folgieri@dico.unimi.it folgieri@mtcube.com 1 Modelli di conduzione

Dettagli

LA SICUREZZA E IMPORTANTE

LA SICUREZZA E IMPORTANTE DISC PROFILO VERDE INTRODUZIONE Le persone con un alto profilo comportamentale VERDE preferiscono lavorare all interno di strutture esistenti e collaborare con gli altri. Il VERDE vuole sentirsi sicuro

Dettagli

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 20 gennaio 2009 INDICE Sezione Contenuto 1. Il programma Responsible Care: scopo e campo di applicazione

Dettagli

> Team Types / Leadership Styles Report. Nome: Peter Sample

> Team Types / Leadership Styles Report. Nome: Peter Sample > Team Types / Leadership Styles Report Nome: Peter Sample Data: 14 aprile 2009 Stile di Gruppo Introduzione Questo report riassume gli stili preferiti nel gruppo dal Sig. Sample sulla base del suo profilo

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

LABORATORIO 30 aprile. Date

LABORATORIO 30 aprile. Date LABORATORIO 30 aprile Date Laboratorio E un gioco che si chiama XP game materiale, manuali istruttori, etc... sono tutti disponibili online (vi darò i riferimenti) centrato su spiegare alcuni concetti

Dettagli

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione.

PEOPLE CARE. Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. La Compagnia Della Rinascita PEOPLE CARE Un equipe di professionisti che si prendono cura dello sviluppo delle RISORSE UMANE della vostra organizzazione. PEOPLE CARE Un equipe di professionisti che si

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Ottimizzare Agile per la. agility made possible. massima innovazione

Ottimizzare Agile per la. agility made possible. massima innovazione Ottimizzare Agile per la agility made possible massima innovazione Agile accelera l'offerta di innovazione Lo scenario aziendale attuale così esigente e in rapida evoluzione ha enormemente amplificato

Dettagli

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup

Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Sviluppo AGILE di una applicazione: dalle User Stories alla creazione collaborativa di un Mockup Giuseppe Chiazzese CNR - Istituto per le tecnologie didattiche Modulo: Introduzione agli strumenti web per

Dettagli

La Guida a Scrum. La Guida Definitiva a Scrum: Le Regole del Gioco. Luglio 2013. Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland

La Guida a Scrum. La Guida Definitiva a Scrum: Le Regole del Gioco. Luglio 2013. Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland La Guida a Scrum La Guida Definitiva a Scrum: Le Regole del Gioco Luglio 2013 Sviluppata e mantenuta da Ken Schwaber Jeff Sutherland Table of Contents Scopo della Guida a Scrum... 3 Definizione di Scrum...

Dettagli

COMPETENZE DI BASE ICF Aggiornamento 2009

COMPETENZE DI BASE ICF Aggiornamento 2009 COMPETENZE DI BASE ICF Aggiornamento 2009 Le 11 competenze di base del coaching sono state sviluppate per permettere una migliore comprensione delle competenze e degli approcci utilizzati nell ambito della

Dettagli

Classificazione Nuovo Esame PMP

Classificazione Nuovo Esame PMP Notizie sul nuovo esame PMP a partire dal Agosto 0 Classificazione Nuovo Esame PMP Questo è il link al documento del PMI: Crosswalk Between Current and New PMP Classifications del PMI Di seguito trovi

Dettagli

Virtual Teams @Tetra Pak. PMI NIC Branch Emilia Romagna e Marche Bologna, 8 aprile 2011

Virtual Teams @Tetra Pak. PMI NIC Branch Emilia Romagna e Marche Bologna, 8 aprile 2011 Virtual Teams @ PMI NIC Branch Emilia Romagna e Marche Bologna, 8 aprile 2011 Chi é Paola Botti g Nata e vissuta a Modena g Dipendente dal 1980 g g g Dal 2003 Director Sales Support, Supply Chain operations

Dettagli

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES

ARIES. Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES Architettura per l'implementazione rapida dei Sistemi Aziendali. Presentazione della metodologia ARIES ARIES è una metodologia per implementare rapidamente sistemi informativi aziendali complessi,

Dettagli

10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi. Report riservato a Manager, Imprenditori e Professionisti

10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi. Report riservato a Manager, Imprenditori e Professionisti 10 Le Nuove Strategie Fondamentali per Crescere nel Mercato di oggi Report riservato a Manager, Imprenditori e Professionisti Nel 2013 hanno chiuso in Italia oltre 50.000 aziende, con un aumento di oltre

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

Innovazione di processo e di prodotto in un azienda del settore domotica

Innovazione di processo e di prodotto in un azienda del settore domotica Innovazione di processo e di prodotto in un azienda del settore domotica Marco Catuozzo (Responsabile R&D, sede di Erba) Mauro Sarchi (Project Leader applicazioni multimediali embedded, sede di Erba) Bticino

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Seminario Metodi Agili per la gestione dei progetti per Decision Makers

Seminario Metodi Agili per la gestione dei progetti per Decision Makers Seminario Metodi Agili per la gestione dei progetti per Decision Gestire la complessità, adattarsi al cambiamento. Velocemente. Questa è la sfida quotidiana di ogni manager, sia in campo IT che in tutti

Dettagli

Software solido e usabile: come integrare ingegneria dell usabilità e del software

Software solido e usabile: come integrare ingegneria dell usabilità e del software Software solido e usabile: come integrare ingegneria dell usabilità e del software Giorgio Brajnik e Andrea Baruzzo Dip. di Matematica e Informatica Università di Udine e Interaction Design Solutions srl

Dettagli

Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it. Ing.Ezio MIOZZO

Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it. Ing.Ezio MIOZZO Verona 18 novembre 2010 Ing. Ezio MIOZZO www.ingmiozzo.it 1 Indice Il contesto Metodologie Agili L extreme Project Management Lean Thinking o pensiero Snello Convergenza dei vari approcci 2 Contesto Da

Dettagli

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano.

Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. Project Portfolio Management e Program Management in ambito ICT: la verifica di fattibilità del Piano. di: Enrico MASTROFINI Ottobre 2004 Nella formulazione iniziale del Piano Ict sono di solito inseriti

Dettagli

The Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture The Zachman Framework for Enterprise Architecture Introduzione Una delle sfide più importanti che un impresa moderna deve affrontare è quella del cambiamento. Considerando la necessità di cambiamento dal

Dettagli

Il Working Partnership

Il Working Partnership Il Working Partnership Il Working Partnership è uno strumento/risorsa per tutti coloro che sono interessati allo sviluppo e al miglioramento del lavoro di partnership. Lo strumento deriva da un precedente

Dettagli

L ENTUSIASMO E IMPORTANTE

L ENTUSIASMO E IMPORTANTE DISC PROFILO GIALLO INTRODUZIONE Le persone con un alto profilo comportamentale GIALLO influenzano il loro ambiente essendo socievoli, persuasivi e convincenti al punto da influenzare e ispirare gli altri.

Dettagli

Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015

Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015 Gli aspetti innovativi del Draft International Standard (DIS) ISO 9001:2015 I requisiti per la gestione del rischio presenti nel DIS della nuova ISO 9001:2015 Alessandra Peverini Perugia 9/09/2014 ISO

Dettagli

LE VENDITE COMPLESSE

LE VENDITE COMPLESSE LE VENDITE COMPLESSE 1 LE VENDITE COMPLESSE - PRINCIPI GENERALI Le vendite complesse differiscono da quelle semplici per molti importanti aspetti. Per avere successo è essenziale comprendere la psicologia

Dettagli

CRM E GESTIONE DEL CLIENTE

CRM E GESTIONE DEL CLIENTE CRM E GESTIONE DEL CLIENTE La concorrenza è così forte che la sola fonte di vantaggio competitivo risiede nella creazione di un valore superiore per i clienti, attraverso un investimento elevato di risorse

Dettagli

I METODI DEL MIGLIORAMENTO

I METODI DEL MIGLIORAMENTO I METODI DEL MIGLIORAMENTO 1 Le macro-tipologie di intervento di miglioramento: Su base giornaliera: è un intervento che può essere applicato quando i processi rispondono agli obiettivi aziendali, ma possono

Dettagli

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi

Un team agile allo sprint. 28 Febbraio 2013 Emiliano Soldi Un team agile allo sprint 28 Febbraio 2013 Emiliano Soldi una questione di leggerezza COMPLESSITÀ VARIABILITÀ SPRECHI SOVRA-ALLOCAZIONI COLLI DI BOTTIGLIA DEBITO BUSINESS/TECNICO RIDURRE TEMPI ATTESA RIDURRE

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 6

Corso di Amministrazione di Sistema Parte I ITIL 6 Corso di Amministrazione di Sistema Parte I ITIL 6 Francesco Clabot 1 Responsabile erogazione servizi tecnici francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici IT

Dettagli

extreme Programming in un curriculum universitario

extreme Programming in un curriculum universitario extreme Programming in un curriculum universitario Lars Bendix Department of Computer Science Lund Institute of Technology Sweden Università di Bologna, 18 giugno, 2002 Extreme Programming On-site customer

Dettagli

Action Learning: una metodologia didattica basata sull esperienza di Roberto Orazi 1 Università degli Studi di Perugia, roberto.orazi@unipg.

Action Learning: una metodologia didattica basata sull esperienza di Roberto Orazi 1 Università degli Studi di Perugia, roberto.orazi@unipg. 1 ISSN: 2038-3282 Pubblicato il: 09 Aprile 2014 Tutti i diritti riservati. Tutti gli articoli possono essere riprodotti con l'unica condizione di mettere in evidenza che il testo riprodotto è tratto da

Dettagli

Customer satisfaction

Customer satisfaction [moduli operativi di formazione] Customer satisfaction Soddisfare Migliorare Continuare a soddisfare CUSTOMER SATISFACTION Tutte le aziende dipendono dai propri clienti ed è indispensabile agire per capire

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Retrospective, Stand-Up Meeting e Daily Journal Raccogliere feedback dal team

Retrospective, Stand-Up Meeting e Daily Journal Raccogliere feedback dal team Retrospective, Stand-Up Meeting e Daily Journal Raccogliere feedback dal team Pietro Di Bello & Jacopo Franzoi { p.dibello, j.franzoi } @sourcesense.com Chi siamo Pietro Di Bello, sviluppatore dal 1999,

Dettagli

Progettazione per requisiti

Progettazione per requisiti Progettazione per requisiti White paper La riproduzione totale o parziale di questo documento è permessa solo se esplicitamente autorizzata da Lecit Consulting Copyright 2003 Lecit Consulting Sommario

Dettagli

ISO Revisions Whitepaper

ISO Revisions Whitepaper ISO Revisions ISO Revisions ISO Revisions Whitepaper Processi e procedure Verso il cambiamento Processo vs procedura Cosa vuol dire? Il concetto di gestione per processi è stato introdotto nella versione

Dettagli

INDICE. 1.Perché fare Qualità. 2. Qualità e non-qualità. 3. Le potenzialità del Sistema di gestione. 4. La ISO 9001:2015

INDICE. 1.Perché fare Qualità. 2. Qualità e non-qualità. 3. Le potenzialità del Sistema di gestione. 4. La ISO 9001:2015 LE NOVITA INDICE 1.Perché fare Qualità 2. Qualità e non-qualità 3. Le potenzialità del Sistema di gestione 4. La ISO 9001:2015 1. PERCHE FARE QUALITA Obiettivo di ogni azienda è aumentare la produttività,

Dettagli

Leadership Judgement Indicator

Leadership Judgement Indicator Leadership Judgement Indicator Michael Lock, Robert Wheeler, Nick Burnard e Colin Cooper Adattamento italiano di Palmira Faraci RAPPORTO INTERPRETATIVO Nominativo: Codice test: Data della prova: 09/01/2012

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Cap. 7: L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE

Cap. 7: L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE : L IMPRENDITORE MANAGER E IL MANAGER - IMPRENDITORE Definizioni Per lo sviluppo di un impresa sono necessarie sia le abilità dell imprenditore che quelle dei manager * Le abilità imprenditoriali sono

Dettagli

Comincio da tre! I MIEI AMICI LA MIA FAMIGLIA LE MIE ESPERIENZE IL MIO PASSATO COSA VOLEVO FARE DA GRANDE LE MIE RELAZIONI

Comincio da tre! I MIEI AMICI LA MIA FAMIGLIA LE MIE ESPERIENZE IL MIO PASSATO COSA VOLEVO FARE DA GRANDE LE MIE RELAZIONI I MIEI AMICI LA MIA FAMIGLIA IL MIO PASSATO LE MIE ESPERIENZE COSA VOLEVO FARE DA GRANDE COME SONO IO? I MIEI DIFETTI LE MIE RELAZIONI LE MIE PASSIONI I SOGNI NEL CASSETTO IL MIO CANE IL MIO GATTO Comincio

Dettagli

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business

La guida CRM per eliminare le incertezze: prendete il controllo del vostro business 2 La guida CRM per eliminare le incertezze: prendete il controllo del vostro business (2 - migliorate la vostra credibilità: i 5 passi per dimostrare l efficacia del Marketing) Pagina 1 di 9 SOMMARIO PREMESSA...

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 5

Corso di Amministrazione di Sistema Parte I ITIL 5 Corso di Amministrazione di Sistema Parte I ITIL 5 Francesco Clabot 1 Responsabile erogazione servizi tecnici francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici IT

Dettagli

www.learningschool.it

www.learningschool.it Bozza Programma di Intervento Formazione e Coaching Ica Foods S.p.A. Informazioni: L azienda ha bisogno di un programma di formazione e coaching per i responsabili dei centri di distribuzione dislocati

Dettagli

La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza. Flavio Tonetto - 4 maggio 2015

La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza. Flavio Tonetto - 4 maggio 2015 La leva della LEAN TECHNOLOGY per aumentare competitività, produttività ed efficienza Flavio Tonetto - 4 maggio 2015 METODO SINERGIA: PASSIONE, COMPETENZA, CONCRETEZZA Gli obiettivi del convegno In questo

Dettagli

Corso di Ingegneria del Software Paolo Bottoni

Corso di Ingegneria del Software Paolo Bottoni Corso di Ingegneria del Software Paolo Bottoni Lezione 13: Gestione del progetto: Rischi e garanzia di qualità Obiettivi Discutere rischio e processo di gestione rischio Discutere approccio alla qualità

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

Evolutive experience design

Evolutive experience design Evolutive experience design Luca Mascaro evolving experience sketchin.ch πάντα ῥεῖ ὡς ποταμός (Tutto scorre come un fiume) - Eraclito Il filosofo greco ammoniva che Non si può discendere due volte nel

Dettagli

Ref: 2013-1-ES1-LEO05-66260

Ref: 2013-1-ES1-LEO05-66260 Ref: 2013-1-ES1-LEO05-66260 Buone pratiche nell uso di ambienti di apprendimento collaborativo quali strumenti per favorire la creatività ed identificazione di modelli di successo nel settore metalmeccanico

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali LAVORO DI GRUPPO Caratteristiche dei gruppi di lavoro transnazionali Esistono molti manuali e teorie sulla costituzione di gruppi e sull efficacia del lavoro di gruppo. Un coordinatore dovrebbe tenere

Dettagli

Interfaccia Utente. Prototipi. Sviluppo SW - Usabilità. Sviluppo SW a cascata. Il ciclo di vita a stella (Hix & Hartson)

Interfaccia Utente. Prototipi. Sviluppo SW - Usabilità. Sviluppo SW a cascata. Il ciclo di vita a stella (Hix & Hartson) Interfaccia Utente An interface is a bridge between the world of the product or system and the world of the user. It is the means by which the users interact with the product to achieve their goals. It

Dettagli

Leveling delle attività

Leveling delle attività Leveling delle attività Metodi per risolvere i conflitti di allocazione delle attività Allocare in modo non-uniforme Ritardare un attività Prima le attività con slack più alto Nel caso di attività con

Dettagli

Corso di Ingegneria del Software. Modelli di produzione del software

Corso di Ingegneria del Software. Modelli di produzione del software Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali

Dettagli

Le sfide future per il Facility Management: l open facility management come nuova soluzione

Le sfide future per il Facility Management: l open facility management come nuova soluzione CHE COS È IL FACILITY MANAGEMENT Il Facility Management è una disciplina in continua evoluzione ed infatti in un contesto altamente dinamico, tipico della società odierna, si trova a dover interpretare

Dettagli

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System)

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) Giuseppe Santucci Qualità nella Produzione del Software 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) 02SQAS.1 Peculiarità del SW XXX warrants that the media (!) on which

Dettagli

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE

LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE LINEE GUIDA PER L APPLICAZIONE DELLA NORMA UNI EN ISO 9001:2008 IN ORGANIZZAZIONI CHE EROGANO SERVIZI E OPERANO PER PROGETTI, PRATICHE O COMMESSE ottobre 2010 SCOPO E CAMPO DI APPLICAZIONE Scopo delle

Dettagli

WP7 IMPLEMENTAZIONE A REGIME SISTEMA DI MONITORAGGIO QUALITATIVO- QUANTITATIVO DEI SERVIZI EROGATI. Deliverable di Progetto # (cod.

WP7 IMPLEMENTAZIONE A REGIME SISTEMA DI MONITORAGGIO QUALITATIVO- QUANTITATIVO DEI SERVIZI EROGATI. Deliverable di Progetto # (cod. WP7 IMPLEMENTAZIONE A REGIME SISTEMA DI MONITORAGGIO QUALITATIVO- QUANTITATIVO DEI SERVIZI EROGATI Deliverable di Progetto # (cod. A7P2) Versione 1.0 del 26.03.10 1 Indice 1. Premessa 3 2. Qualità e miglioramento

Dettagli

Service Design Programme

Service Design Programme Service Design Programme SERVICE DESIGN - cosa è Il Service Design è l attività di pianificazione e organizzazione di un servizio, con lo scopo di migliorarne l esperienza in termini di qualità ed interazione

Dettagli

Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna. SKF Car Business Unit

Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna. SKF Car Business Unit Una necessità per aumentare Velocità Qualità Motivazione Flessibilità di un organizzazione moderna 1 Un approccio difficile perchè Il Team conta più del singolo Utilizza risorse condivise E trasversale

Dettagli

Questionario stili di comunicazione/negoziazione questionario Thomas Kilmann

Questionario stili di comunicazione/negoziazione questionario Thomas Kilmann Questionario stili di comunicazione/negoziazione questionario Thomas Kilmann Obiettivo del questionario è rendere consapevole una persona della propria tendenza ad assumere in una conversazione uno o più

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 42 Sommario 1 Generalità

Dettagli

SULLA LEADERSHIP (3 parte) (liberamente tratto dalla letteratura manageriale anglosassone)

SULLA LEADERSHIP (3 parte) (liberamente tratto dalla letteratura manageriale anglosassone) SULLA LEADERSHIP (3 parte) (liberamente tratto dalla letteratura manageriale anglosassone) Dopo una prima descrizione dei sei stili di leadership, si espongono di seguito ulteriori evidenze emerse dalla

Dettagli

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE I PROCESSI AZIENDALI E PROGETTI UDA 3 I PRINCIPI DEL PROJECT MANAGEMENT

Dettagli

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita.

IL CRM NELL ERA DEL CLIENTE. modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita. IL CRM NELL ERA DEL CLIENTE modi in cui un CRM moderno può aiutarti a deliziare i tuoi clienti e contribuire alla tua crescita ebook 1 SOMMARIO Introduzione Allineare meglio le vendite e il marketing Creare

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA ROMA 20-22 OTTOBRE 2014 RESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE

LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE LA TECHNOLOGY TRANSFER PRESENTA ARIE VAN BENNEKUM AGILE PROJECT MANAGEMENT CON CERTIFICAZIONE ROMA 16-17 NOVEMBRE 2015 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli