Semplicemente Agile
•2 likes•2,626 views
Report
Share
Download to read offline
AGILE Project Management. Dall’idea alle persone, un percorso per comprendere la transizione dal modello predittivo a quello adattivo.
Recommended
More Related Content
What's hot
What's hot(20)
Similar to Semplicemente Agile
Similar to Semplicemente Agile(20)
Semplicemente Agile
- 1. 1 Semplicemente AGILE SUPSI – 29 Aprile 2014 Stefano Gallotti
- 2. 2 La Storia L’idea Gli strumenti Il Progetto Le persone Qualche suggerimento AGENDA
- 3. La Storia 3
- 4. 4 Quecreek Mine Disaster Un ottimo esempio di collaborazione https://en.wikipedia.org/wiki/Quecreek_Mine_rescue
- 5. 5 Modello evolutivo di una organizzazione
- 6. «Abbiamo successo perché lavoriamo Insieme» Collaborazione 6
- 7. «Abbiamo successo creando e mantenendo il controllo» Controllo 7
- 8. «Abbiamo successo perché siamo i migliori» Competenza 8
- 9. «Abbiamo successo perché facciamo crescere le persone che alimentano la nostra vision» Incubazione - Cultura 9
- 11. Partiamo da 3 semplici verità E’ impossibile raccogliere tutti i requisiti all’inizio del progetto. Qualsiasi requisito andrai a raccogliere è sicuro che cambierà. Ci saranno sempre più cose da fare che soldi e tempo. 11
- 12. Analizziamo il modello waterfall Vediamo i 6 punti che lo caratterizzano 1. Descrizione vaga e grossolana dei requisiti 2. Valutazione e stima di effort e risorse necessarie 3. Offerta economica (out of the box - tutto compreso e senza possibili modifiche) 4. Analisi Funzionale (dove capisci cosa è andato male al punto 2) 5. Analisi Architetturale (dove i dubbi del punto 4 diventano realtà) 6. Sviluppo e Test (dove il disastro assume proporzioni irreparabili) 12
- 14. Principali cause del fallimento 14
- 15. 15
- 16. Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti: 16 Gli individui e le interazioni più che i processi e gli strumenti Il software funzionante più che la documentazione esaustiva La collaborazione con il cliente più che la negoziazione dei contratti Rispondere al cambiamento più che seguire un piano Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
- 17. I principi sottostanti al Manifesto Agile 17 La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua. Il software funzionante è il principale metro di misura di progresso. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente. I processi agili promuovono uno sviluppo sostenibile. Sponsor, Sviluppatori e Utenti in grado di mantenere indefinitamente un ritmo costante. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale. Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
- 18. Agile timeline 18 Waterfall Predittivo: Fasi, document-centric, functional handoffs, fare bene la prima volta Spiral, RAD, RUP Iterativo: process framework, fasi, tool driven, complessi artifact Scrum, XP Adattivo: Iterativo, self-organizing team, value driven, transparente 20001970 19901980
- 19. Facciamo un passo indietro... ANALISI DESIGN SVILUPPO TEST RILASCIO 19
- 20. Come si può migliorare... ANALISI DESIGN SVILUPPO TEST RILASCIO 20
- 21. Gli Strumenti 21
- 22. Approach SCRUM Scrum è una delle tecniche agili più utilizzate. Sottolinea la comunicazione la collaborazione, software funzionante, e la flessibilità necessaria per adattarsi alle realtà aziendali emergenti. Tutti attributi che soffrono nel paradigma waterfall. 22 3 Ruoli • Product Owner • Team Member • Scrum Master 4 Cerimonie • Sprint Planning • Daily Meeting • Sprint review • Retrospective 3 Artifacts • Product backlog • Sprint backlog • Burn down chart
- 23. I N V E S T ndipendent E’ più semplice se sono indipendenti ed è possibile eseguirle in qualsiasi ordine egotiable Non è un contratto esplicito, piuttosto i dettagli devono essere co-creati durante la definizione. aluable Deve essere utile non solo per qualcuno ma per il cliente stimable L’esatta stima non è necessaria fin dall’inizio ma sufficiente per classificare e definire l’implementazione mall Sufficientemente piccoli da permettere una stima accurata stable Ogni requisito deve essere testabile per essere considerato “Fatto” Invest in Requirement 23
- 24. Gestire il Product Backlog Per avere un buon product backlog è necessario essere in grado di: • Gestire la priorità degli elementi • Scambiare requisiti con lo stesso effort • Cambiare l'ordine dei requisiti fissi • Migliorare la “definizione di fatto” in ogni iterazione. Ora si è pronti per definire e pianificare gli sprints • Partendo con la definizione della Timebox (Fixed Time) • Definendo le funzionalità rilasciate (Fixed Scope) In questa fase si ha la completa visibilità del progetto e si è in grado di stimarne i costi totali. 24
- 25. AGILE Architecture Dal punto di vista architetturale, durante l'iterazione 0 l'obiettivo è identificare una direzione potenziale per la soluzione nonché eventuali rischi tecnici che potenzialmente saranno da affrontare. In questa fase non c’è bisogno di specifiche architetturali dettagliate. Definire l’architettura completa all'inizio di un progetto di sviluppo è infatti un rischio. Bisogna poter rispondere a domande critiche circa l’ambito, costi, tempi, e la strategia tecnica del progetto. 25
- 26. 26 Envision Architetturale iniziale Condivisione Architettura con Stakeholder Aggiornamento deliverable architetturali Collaborazione con team di sviluppo Models Vision Models Vision Feedback L’architettura si aggiorna ed evolve con il tempo Scott W.Amber Architecture Evolution
- 27. Data Architecture 27 • Classificando i data elements (data classification) • Considerando gli accessi ai dati (data security) • Identificando i Master Data (entity types, data elements, associations…) • Definendo e gestendo i metadati pertinenti ai Master Data includendo: • Primary Source(s) • Come i sistemi accedono ai MD • Lifecycles dei MD • Owners e/o data stewards • Adottando tools (repository and modeling) per gestire Master Data e metadati Come un approccio agile alla Data Architecture permette di ottenere un buon modello di MDM?
- 28. 28 Il Progetto
- 29. Fixed Price, Fixed Scope 29 Manager: Voglio ordinare qualcosa, passare ad un'altra attività senza interruzioni e che si consegni il tutto per tempo. I progetti Fixed-price sono stati promossi con il pretesto di varie ottimizzazioni: Cliente: Voglio conoscere il costo del progetto. Fornitore: Voglio definire il costo totale della commessa. Venditore: Voglio definire la commessa per ottenere la commissione completa. La principale domanda diventa quindi:
- 30. Incomprensioni su FPFS 30 Quando viene utilizzato un metodo agile i requisiti generali di rilascio del progetto non sono noti o stimati prima della prima iterazione. Con i metodi agili i requisiti sono sempre soggetti al cambiamento. Ci sono spesso due malintesi sul connubio FPFS ed i metodi agili: Anzi, in Scrum, già dall prima iterazione, è chiara la pianificazione dei rilasci (“product backlog”), in cui tutti i requisiti identificabili sono chiariti e stimati. Non è vero. Piuttosto, tutti i metodi agili offrono l'opportunità e il meccanismo per supportare l'apprendimento ed il cambiamento, ma non lo richiedono. Scrum può essere utilizzato con un backlog di fixed features da rilasciare. Non è vero.
- 31. 31 FIXED ESTIMATED VALUE DRIVEN PLAN DRIVEN Features Cost Time Features Time Cost Project Approach
- 32. Le Persone 32
- 33. Agile team 33 TUTTI TUTTI INSIEME FIN DALL'INIZIO
- 34. Five dysfunction of a team 34 Assenza di fiducia Paura del conflitto Mancanza di impegno Evitare la responsabilità Disattenzione al risultato Patrik Lencioni
- 35. 35 La barca che vince ha lo stesso vento delle altre… …ma ha un equipaggio migliore!
- 37. Software Development Delivery Methods Agile best practice: • Analisys & Design • User Stories • Impact Mapping • Test-Driven Design • Behavior-Driven Development • Development • Scrum • Test & Delivery • Scrum • Continous Delivery 37
- 40. Agile software development is one tool in a vast toolbox. But a fool with a tool is still a fool. 40
Editor's Notes
- Slide 4. Quecreek Mine Disaster 9 minatori a Queckreek nel 2002 in Pennsylvania - 77 ore intrappolati a 73 metri sottoterra La mappa usata per scavare non era aggiornata e questo ha portato a perforare la vecchia miniera abbandonata ed allagata. I soccorsi sono intervenuti repentinamente provando dapprima a estrarre l’acqua e poi pompando aria per i minatori. La super trivella usata per scavare la via di fuga si è fermata dopo 42 metri, quando hanno provato ad estrarla un componente rotto è rimasto nel tunnel impedendo ulteriori scavi. Era necessario un attrezzo speciale per rimuovere la punta rotta ed il tempo necessario a costruirlo è di norma 3 giorni. 95 operai hanno lavorato insieme ed in sole 3 ore hanno prodotto l’attrezzo. È stato quindi possibile procedere alla perforazione e quindi salvare i minatori.
- Modello di William Schneider Personale<->Impersonale Realtà ^-v Possibilità
- Cascata perpetua - Escher
- 12 ulteriori principi supportano i 4 valori fondamentali sottolineando: Sviluppo iterativo e la consegna le persone - sia per gli individui e le squadre collaborazione eccellenza tecnica
- Negli ultimi 20 anni le classiche metodologie di project management sono state riconosciute come inadatte a portare una percentuale sufficiente di progetti verso il completo successo. il modello lineare: suggerisce un approccio sequenziale allo sviluppo del software al livello del sistema e procede attraverso l’analisi, la progettazione, la codifica, il collaudo e il supporto. Spiral: framework attraverso cui si possono inquadrare tanti altri modelli. Prevede di analizzare ciclicamente (allontanandomi dal centro e aumentando i costi) tutte le fasi dello sviluppo. Questo processo e rappresentato mediante una spirale in cui ogni voluta rappresenta un completamento del sistema rispetto alla voluta precedente. Il software e sviluppato in modo ciclico (iterativo ed incrementale), producendo versioni via via piu complete del prodotto riducendo i rischi. RAD Rapid Application Development: punta a un ciclo di sviluppo molto breve. Adattamento “ad alta velocità” del modello sequenziale lineare, nel quale l’obiettivo di uno sviluppo rapido è raggiunto grazie all’uso di componenti. Si applica se i requisiti sono chiari e precisi. RUP Rational Unified Process: metamodello object-oriented, espresso in UML (Unified Modeling Language) . Prevede cicli di sviluppo, a loro volta scomposti in fasi fase iniziale elaborazione costruzione transizione Chi (ruoli) - Cosa (artefatti) - Quando (workflow) - Come (attività)
- Sulla base del feedback iniziale, è possibile aggiustare il tiro presto piuttosto che tardi. Soprattutto in progetti FPFS, volete sapere quanto male le cose stanno andando il più velocemente possibile I metodi agili migliorano questo tipo di feedback.
- Concentrarsi sulle persone, non la tecnologia o le tecniche Keep it simple Lavorare in modo iterativo e incrementale Rimboccarsi le maniche Guardate l'immagine intera Fai architettura attraente per i vostri clienti
- il ruolo del'architetto non è più lo stesso, evolve naturalmente in membro del gruppo che con una visione di insieme più ampia può dare indicazioni precise al team autogestito su come indirizzare gli sviluppi e come insieme collaborare alla definizione ed evoluzione della architettura. una collaborazione costante con team permette di, data la target architecture definita da business e management, capire nelle fasi evolutive deli progetti il punto boa e definire la distanza per poter indirizzare verso l’obiettivo.
- 1) Assenza di fiducia. Se i membri del team non si fidano l'un l'altro allora non possono essere completamente onesti tra loro . 2) La paura del conflitto. Senza fiducia la gente non avrà i dibattiti sani che sono necessari per arrivare ad una migliore pensiero attraverso decisioni. 3) Mancanza di impegno. Se la squadra non sono allineati dietro una decisione che poi i singoli membri che non erano d'accordo con la decisione finale alla fine sarà meno impegnati a tale decisione. 4) Evitare di responsabilità. Se non sono impegnati nel corso di azione, allora sono meno propensi a sentirsi responsabili (o tenere altre persone responsabili). 5) Disattenzione ai risultati. Di conseguenza, sono meno propensi a preoccuparsi dei risultati del gruppo (e invece concentrarsi sul raggiungimento dei propri obiettivi).
- User Story come (tipo di utente), voglio (obiettivo), così da (razionale) 3C Card-Conversation-Confirmation Impact Mapping Mind map che risponde a queste domanda: perchè-chi-come-cosa Perchè lo facciamo Chi aiuta e chi ostacola Come aiuti o Come ostacoli Cosa (Ambito) cosa possiamo fare per raggiungere l’obiettivo Behavior Driven user story: Specifiche del progetto agile - test driven: rappresenta il design BDD armonizza i due elementi Esempio Bonifico: 1 riferimento 2 contesti 3 specifiche trasferisco tra 2 conti addebito chi lo esegue accredito chi lo riceve trasferisco una somma superiore alla disponibilità non effettuo il bonifico