Agile software lifecycle

3,600 views

Published on

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,600
On SlideShare
0
From Embeds
0
Number of Embeds
54
Actions
Shares
0
Downloads
72
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • 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.
  • Che cos’è, perché lo facciamo. A volte poco.
  • Agile software lifecycle

    1. 1. Agile software lifecycle Francesco (cphp) Trucchia http://joind.in/talk/view/1426
    2. 2. o meglio... a real software quality lifecycle experience
    3. 3. Chi sono <ul><li>Francesco Trucchia... per gli amici ciccio, per il web cphp!! </li></ul><ul><li>  </li></ul><ul><ul><li>Sviluppatore PHP dal 1999  </li></ul></ul><ul><ul><li>Sviluppatore XP dal 2006 </li></ul></ul><ul><ul><li>Fondatore dell'XPug Romagna </li></ul></ul><ul><ul><li>CTO, co-founder e coach @ ideato srl </li></ul></ul><ul><ul><li>Autore di libri </li></ul></ul>
    4. 4. Agenda <ul><li>Parte I </li></ul><ul><li>  </li></ul><ul><ul><li>Nozioni elementari di qualità, agile e XP </li></ul></ul><ul><ul><li>Processi di produzione software in una piccola azienda </li></ul></ul><ul><li>  </li></ul><ul><li>Parte II </li></ul><ul><ul><li>Approfondimenti sulle pratiche e gli strumenti a supporto dei processi di produzione software in una piccola azienda </li></ul></ul>
    5. 5. Contestualizziamo un po'... <ul><li>Le esperienza trattate in questo workshop vengono da esperienze reali nella mia azienda: </li></ul><ul><ul><li>fondata nel 2008 </li></ul></ul><ul><ul><li>7 dipendenti </li></ul></ul><ul><ul><li>sviluppo di applicazione PHP </li></ul></ul>
    6. 6. La mission condivisa <ul><li>&quot;Produrre, per i nostri clienti, software di qualità nel minor tempo possibile&quot; </li></ul>
    7. 7. Ma prima alcune nozioni....
    8. 8. Che cos'è il software lifecycle? <ul><li>” Un processo di sviluppo software è un flusso strutturato e imposto per lo sviluppo di un prodotto software. Alcuni sinonimi possono essere software life cycle e processo software. Ci sono modelli differenti che cercano di descrivere questo processo.&quot; - Wikipedia </li></ul>
    9. 9. Alcuni modelli di sviluppo software <ul><ul><li>Waterfall </li></ul></ul><ul><ul><li>Iterative and incremental </li></ul></ul><ul><ul><li>Agile </li></ul></ul>
    10. 10. Che cosa significa qualità? <ul><li>&quot; Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something. Quality is a perceptual, conditional and somewhat subjective attribute and may be understood differently by different people.&quot; - Wikipedia </li></ul>
    11. 11. Che ne pensa il team? <ul><ul><li>Codice semplice da capire e da modificare </li></ul></ul><ul><ul><li>Facilità nel fixare i bug </li></ul></ul><ul><ul><li>Requisiti chiari, mutevoli e semplici da stimare </li></ul></ul><ul><ul><li>Utilizzo di standard aperti </li></ul></ul><ul><ul><li>Utilizzo di pattern </li></ul></ul><ul><ul><li>Codice ad oggetti </li></ul></ul><ul><ul><li>Lavorare in team autogestiti </li></ul></ul><ul><ul><li>Comunicazione chiara </li></ul></ul><ul><ul><li>Feedback rapidi </li></ul></ul><ul><ul><li>Partecipare a corsi di formazioni </li></ul></ul><ul><ul><li>Apprendere </li></ul></ul><ul><ul><li>Vedere il fallimento il prima possibile così da poter cambiare/correggere strada in tempo </li></ul></ul>
    12. 12. E per voi che cosa significa produrre software di qualità?
    13. 13. Manifesto agile === ricerca della qualità <ul><li>Stiamo ricercando modi migliori di sviluppare software facendolo e aiutando gli altri a farlo. </li></ul><ul><li>Grazie a questa attività siamo arrivati a considerare importanti:  </li></ul><ul><li>  </li></ul><ul><li>Gli individui e le interazioni più dei processi e degli strumenti </li></ul><ul><li>Il software funzionante più che la documentazione esaustiva </li></ul><ul><li>La collaborazione col cliente più che la negoziazione del contratto </li></ul><ul><li>Rispondere al cambiamento più che seguire i piani </li></ul><ul><li>  </li></ul><ul><li>Ovvero, fermo restando il valore delle entità a destra, consideriamo più importanti le entità a sinistra. </li></ul>
    14. 14. Noi cerchiamo la qualità con XP <ul><li>&quot;L'Extreme Programming (espressione inglese per programmazione estrema, spesso abbreviato in XP) è una metodologia agile e un approccio all'ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries.&quot; - Wikipedia </li></ul>
    15. 15. XP si basa su 5 valori assoluti <ul><ul><li>Comunicazione </li></ul></ul><ul><ul><li>Semplicità </li></ul></ul><ul><ul><li>Feedback </li></ul></ul><ul><ul><li>Rispetto </li></ul></ul><ul><ul><li>Coraggio </li></ul></ul>
    16. 16. XP si basa su pratiche chiare <ul><li>Primary </li></ul><ul><li>  </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Team completo </li></ul></ul><ul><ul><li>Workspace informativo </li></ul></ul><ul><ul><li>Lavoro energizzante </li></ul></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>Storie </li></ul></ul><ul><ul><li>Cicli settimanali </li></ul></ul><ul><ul><li>Cicli mensili </li></ul></ul><ul><ul><li>Ten minute build </li></ul></ul><ul><ul><li>Continous Integration </li></ul></ul><ul><ul><li>Test-First Programming </li></ul></ul><ul><ul><li>Design incrementale </li></ul></ul><ul><li>Corollari </li></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Deploy incrementale </li></ul></ul><ul><ul><li>Continuità del team </li></ul></ul><ul><ul><li>Shrinking Teams </li></ul></ul><ul><ul><li>Analisi alla radice delle causes </li></ul></ul><ul><ul><li>Codice condiviso </li></ul></ul><ul><ul><li>Code and Tests </li></ul></ul><ul><ul><li>Single Code Base </li></ul></ul><ul><ul><li>Deploy quotidiano </li></ul></ul><ul><ul><li>Scope del contratto negoziabile </li></ul></ul><ul><ul><li>Pay-Per-Use </li></ul></ul>
    17. 17. I principi XP <ul><ul><li>Flusso </li></ul></ul><ul><ul><li>Opportunità </li></ul></ul><ul><ul><li>Ridondanza </li></ul></ul><ul><ul><li>Fallimento </li></ul></ul><ul><ul><li>Qualità </li></ul></ul><ul><ul><li>Piccoli step </li></ul></ul><ul><ul><li>Responsabilità accettata </li></ul></ul><ul><ul><li>Umanità </li></ul></ul><ul><ul><li>Economia </li></ul></ul><ul><ul><li>Mutuo Beneficio </li></ul></ul><ul><ul><li>Self-Similarity </li></ul></ul><ul><ul><li>Improvement </li></ul></ul><ul><ul><li>Diversità </li></ul></ul><ul><ul><li>Reflection </li></ul></ul>
    18. 18. Noi condividiamo i valori XP e attraverso i suoi principi ne applichiamo le pratiche alla ricerca della massima qualità
    19. 20. Vi ricorda qualcosa?
    20. 21. Pre-Produzione
    21. 22. Attività <ul><ul><li>Analisi dei Requisiti </li></ul></ul><ul><ul><li>Pianificazione </li></ul></ul>
    22. 23. Analisi Requisiti I <ul><li>L'analisi dei requisiti è l'attività attraverso la quale si definiscono le funzionalità utente con il software. </li></ul><ul><li>Dall'analisi dei requisiti si producono delle storie funzionali (User stories) che serviranno a pianificare la release. </li></ul>
    23. 24. Analisi dei Requisiti II <ul><li>Ruoli </li></ul><ul><ul><li>Account </li></ul></ul><ul><ul><li>Figure primarie del team (UX, dev, design) </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><li>  </li></ul><ul><li>Pratiche </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Storie </li></ul></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Time boxing </li></ul></ul>
    24. 25. Pianificazione I <ul><li>La pianificazione è l'attività attraverso la quale si definisce la più piccola release di valore da realizzare, delineando tempi e budget a scope variabile. </li></ul><ul><li>Durante la pianificazione si stimano le user stories utilizzando il buffer d'incertezza (regola dell'80/20) e lo scope variabile (must to have, nice to have). </li></ul><ul><li>In XP questo tipo di pianificazione è chiamata &quot;Release Planning&quot;. </li></ul>
    25. 26. Pianificazione II <ul><li>Ruoli </li></ul><ul><ul><li>Account </li></ul></ul><ul><ul><li>Figure primarie del team </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><li>  </li></ul><ul><li>Pratiche </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Planning game </li></ul></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Time boxing </li></ul></ul><ul><ul><li>Storie </li></ul></ul>
    26. 27. Produzione
    27. 28. Attività <ul><ul><li>Pianificazione </li></ul></ul><ul><ul><li>Sviluppo iterativo </li></ul></ul><ul><ul><li>Demo </li></ul></ul>
    28. 29. Produzione - Pianificazione I <ul><li>Ad ogni iterazione si pianifica quali storie implementare. Le storie vengono suddivide in task, i task stimati e si riempie il buffer dell'iterazione. </li></ul><ul><li>In XP questo tipo di pianificazione è chiamta &quot;Iteration Planning&quot;. </li></ul>
    29. 30. Produzione - Pianificazione II <ul><li>Ruoli </li></ul><ul><ul><li>Tutto il team di sviluppo </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><ul><li>Account </li></ul></ul><ul><li>Pratiche </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Team completo </li></ul></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Time boxing  </li></ul></ul><ul><ul><li>Storie </li></ul></ul><ul><ul><li>Informative workspace </li></ul></ul><ul><ul><li>Weekly cycle </li></ul></ul><ul><li>  </li></ul>
    30. 31. Produzione - Sviluppo Iterativo I <ul><li>Ad ogni iterazione si testano e implementano i task relativi alle storie. Ogni coppia di sviluppatori è responsabile della storia che ha scelto di implementare. Le storie vengono implementate in base all'ordinamento dato dal cliente. </li></ul><ul><li>Alla fine di ogni iterazione si memorizza la velocity. </li></ul><ul><li>Se durante l'iterazione nascono nuove storie, queste vengono messe in backlog e poi pianificate nel successivo iteration planning. </li></ul>
    31. 32. Produzione - Sviluppo Iterativo II <ul><li>Ruoli </li></ul><ul><ul><li>Tutto il team </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><li>  </li></ul><ul><li>Pratiche </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Team completo </li></ul></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Time boxing  </li></ul></ul><ul><ul><li>Storie </li></ul></ul><ul><ul><li>Informative workspace </li></ul></ul><ul><ul><li>Weekly cycle </li></ul></ul><ul><ul><li>Single code base </li></ul></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Sviluppo Test First </li></ul></ul><ul><ul><li>Continuità del team </li></ul></ul><ul><ul><li>Analisi della causa alla radice </li></ul></ul><ul><ul><li>Deploy quotidiano </li></ul></ul><ul><ul><li>Negoziare lo scope </li></ul></ul><ul><ul><li>Continous Integration </li></ul></ul><ul><ul><li>Codice condiviso </li></ul></ul><ul><ul><li>Stand-up meeting  </li></ul></ul>
    32. 33. Produzione - Demo I <ul><li>La fase di Demo è il momento nel quale il team si riunisce con il cliente per presentare la demo dell'ultima iterazione eseguita. Ogni singola storia viene mostrata al cliente e il cliente ne approva la bontà o fa emergere bug e nuove storie. </li></ul>
    33. 34. Produzione - Demo II <ul><li>Ruoli </li></ul><ul><ul><li>Tutto il team </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><li>Pratiche </li></ul><ul><ul><li>Sedersi insieme </li></ul></ul><ul><ul><li>Team completo </li></ul></ul><ul><ul><li>Coinvolgimento del cliente </li></ul></ul><ul><ul><li>Time boxing  </li></ul></ul><ul><ul><li>Storie </li></ul></ul><ul><ul><li>Weekly cycle </li></ul></ul><ul><li>  </li></ul>
    34. 35. Post-Produzione
    35. 36. Attività <ul><ul><li>Consegna release </li></ul></ul><ul><ul><li>Bug-fixing </li></ul></ul>
    36. 37. Consegna Release I <ul><li>La fase della consegna della release è il momento nel quale si fa il deploy del codice nella macchina di produzione. </li></ul><ul><li>Alla fine del deploy in produzione il team festeggia l'obiettivo raggiunto. </li></ul><ul><li>Alla fine del deploy viene individuato il release manager. </li></ul>
    37. 38. Consegna Release II <ul><li>Ruoli </li></ul><ul><ul><li>Tutto il team </li></ul></ul><ul><ul><li>Product owner </li></ul></ul><ul><ul><li>Release manager </li></ul></ul><ul><li>Pratiche </li></ul><ul><ul><li>Pair programming </li></ul></ul><ul><ul><li>Continous Integration </li></ul></ul><ul><ul><li>Deploy quotidiano  </li></ul></ul>
    38. 39. Mantenimento I <ul><li>La fase di mantenimento è la fase nella quale una release è stata messa in produzione e il codice va mantenuto in caso di bug-fixing o micro modifiche. </li></ul>
    39. 40. Mantenimento II <ul><li>Ruoli </li></ul><ul><ul><li>Release manager </li></ul></ul><ul><ul><li>Cliente </li></ul></ul><ul><li>Pratiche </li></ul><ul><ul><li>Analisi della causa alla radice </li></ul></ul><ul><ul><li>Deploy quotidiano </li></ul></ul><ul><ul><li>Continous Integration </li></ul></ul><ul><ul><li>Kanban </li></ul></ul>
    40. 41. Non è oro tutto ciò che luccica!! Alcuni problemi reali che abbiamo incontrato
    41. 42. Pianificazione cross progetti
    42. 43. Customer Care
    43. 44. Feedback
    44. 45. Agile dentro Waterfall Quando si lavora da terzisti
    45. 46. Team remoto
    46. 47. Codice legacy
    47. 48. L’illusione del multi tasking
    48. 49. Interruzioni continue
    49. 50. E voi? Quali problemi abbassano la qualità di produzione del vostro software?
    50. 51. Crampi allo stomaco… non è colpa dei clienti è solo la fame!!! Ci vediamo alle 14.15
    51. 53. Abbiamo provato a trovare alcun soluzioni ai nostri problemi
    52. 54. <ul><li>Problemi </li></ul><ul><li>Souzioni </li></ul><ul><li>Il facilitatore </li></ul><ul><li>Il Pronto soccorso </li></ul><ul><li>Il facilitatore </li></ul><ul><li>Strumenti di collaborazione </li></ul><ul><li>Spike di studio e testing </li></ul><ul><li>Il facilitatore </li></ul><ul><li>La tecnica del pomodoro </li></ul>
    53. 55. Che cosa fa il facilitatore? <ul><ul><li>Pianifica i progetti internamente </li></ul></ul><ul><ul><li>Crea il team </li></ul></ul><ul><ul><li>Supporta l'account </li></ul></ul><ul><ul><li>Supporta il team </li></ul></ul><ul><ul><li>Supporta il cliente </li></ul></ul><ul><ul><li>Pianifica e decide le attività del pronto soccorso </li></ul></ul>
    54. 56. Pronto soccorso? Siamo forse un ospedale?
    55. 57. La metafora del pronto soccorso <ul><li>&quot;Il pronto soccorso è un'unità operativa dell'ospedale dedicata ai casi di emergenza e con spazi dedicati alla breve osservazione (medicina d'urgenza). Qui vengono prestate le prime cure in tutti i casi di urgenza ed emergenza (traumi, infarti, ...) e si accede quindi in modalità di ricovero urgente .&quot; - Wikipedia </li></ul>
    56. 58. Supporto e pronto soccorso I <ul><li>Secondo noi rispondere in maniera rapida alle richieste o emergenze del cliente è sinonimo di qualità. </li></ul><ul><li>Gli sviluppatori fanno quotidianamente turni al pronto soccorso, offrendo la loro disponibilità ad attività di emergenza aziendali. </li></ul><ul><li>Il facilitatore è il Product Owner del progetto Pronto Soccorso ed è lui che decide e pianifica le priorità di intervento. </li></ul>
    57. 59. Supporto e pronto soccorso II <ul><li>Ruoli </li></ul><ul><ul><li>Sviluppatore </li></ul></ul><ul><ul><li>Facilitatore </li></ul></ul><ul><ul><li>Cliente </li></ul></ul><ul><li>  </li></ul><ul><li>Pratiche </li></ul><ul><ul><li>Stand-up meeting </li></ul></ul><ul><ul><li>Test first </li></ul></ul><ul><ul><li>Analisi della causa alla radice </li></ul></ul><ul><ul><li>Deploy quotidiano </li></ul></ul><ul><ul><li>Customer care di secondo livello </li></ul></ul><ul><ul><li>Stime e pianificazioni di emergenza </li></ul></ul>
    58. 60. Approfondiamo un po’ di pratiche con immagini e colori…
    59. 61. Sedersi insieme
    60. 62. User story
    61. 63. Coinvolgimento del cliente
    62. 64. Time boxing
    63. 65. Planning game
    64. 66. Spazio di lavoro informativo
    65. 67. Weekly cycle
    66. 68. Single code base
    67. 69. Test First
    68. 70. Continuità del team
    69. 71. Continous integration
    70. 72. Stand-up meeting
    71. 73. Pair Programming
    72. 74. Ora proviamo insieme a trovare una soluzine ai problemi emersi nella prima parte del workshop
    73. 75. Altre domande?
    74. 76. Ringrazimanti <ul><li>Ideato - http://www.ideato.it </li></ul><ul><li>Al mio team - www.theideatos.com </li></ul><ul><li>Jacopo Romei (il mio mentore) - www.sviluppoagile.it </li></ul>
    75. 77. Contatti <ul><li>Francesco (cphp) Trucchia </li></ul><ul><li>E-Mail: ft@ideato.it </li></ul><ul><li>Skype: trucchia </li></ul><ul><li>Twittter: cphp </li></ul><ul><li>Website: www.ideato.it </li></ul><ul><li>Blog: www.cphp.it </li></ul><ul><li>http://joind.in/talk/view/1426 </li></ul>
    76. 78. Recruitment @ ideato <ul><li>Stiamo cercando uno sviluppatori php </li></ul><ul><li>[email_address] </li></ul><ul><li>http://www.ideato.it/Azienda/Lavora-con-noi </li></ul><ul><li>Fermatemi e chiedetemi informazioni </li></ul>
    77. 79. Riferimenti <ul><li>Extreme Programming Explained (Second edition). K. Back, C. Andres. Addison Wesley 2005. </li></ul><ul><li>Agile Estimating and Planning . M. Cohn. Prentice Hall 2005. </li></ul><ul><li>User Stories Applied: For Agile Software Development . M. Cohn. Addison-Wesley Professional 2004. </li></ul><ul><li>The Pragmatic Programmer: From Journeyman to Master . A. Hunt, D. Thomas. Addison-Wesley Professional 1999 </li></ul>
    78. 80. Pro PHP Refactoring <ul><li>What you’ll learn </li></ul><ul><li>What refactoring is and why you need to refactor code </li></ul><ul><li>What test-driven design is and why you need to test your code </li></ul><ul><li>How to write unit and functional tests with PHPUnit and Selenium RC </li></ul><ul><li>How to detect “bad smells” in PHP code, and refactor them using test-driven design </li></ul><ul><li>How to refactor a large procedural application affected by many bad smells </li></ul><ul><li>Who is this book for? </li></ul><ul><li>This book is for PHP developers, businesses, and developers relying on legacy PHP apps. </li></ul>Francesco Trucchia Jacopo Romei Apress June 2010

    ×