Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (6)
Ähnlich wie Agile software lifecycle
Ähnlich wie Agile software lifecycle (20)
Mehr von Francesco Trucchia
Mehr von Francesco Trucchia (10)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
Agile software lifecycle
- 1. Agile software lifecycle Francesco (cphp) Trucchia http://joind.in/talk/view/1426
- 2. o meglio... a real software quality lifecycle experience
- 7. Ma prima alcune nozioni....
- 12. E per voi che cosa significa produrre software di qualità?
- 18. Noi condividiamo i valori XP e attraverso i suoi principi ne applichiamo le pratiche alla ricerca della massima qualità
- 21. Pre-Produzione
- 27. Produzione
- 35. Post-Produzione
- 41. Non è oro tutto ciò che luccica!! Alcuni problemi reali che abbiamo incontrato
- 43. Customer Care
- 44. Feedback
- 45. Agile dentro Waterfall Quando si lavora da terzisti
- 46. Team remoto
- 47. Codice legacy
- 48. L’illusione del multi tasking
- 50. E voi? Quali problemi abbassano la qualità di produzione del vostro software?
- 51. Crampi allo stomaco… non è colpa dei clienti è solo la fame!!! Ci vediamo alle 14.15
- 53. Abbiamo provato a trovare alcun soluzioni ai nostri problemi
- 56. Pronto soccorso? Siamo forse un ospedale?
- 60. Approfondiamo un po’ di pratiche con immagini e colori…
- 61. Sedersi insieme
- 62. User story
- 64. Time boxing
- 65. Planning game
- 66. Spazio di lavoro informativo
- 67. Weekly cycle
- 68. Single code base
- 69. Test First
- 72. Stand-up meeting
- 73. Pair Programming
- 74. Ora proviamo insieme a trovare una soluzine ai problemi emersi nella prima parte del workshop
- 75. Altre domande?
Hinweis der Redaktion
- 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.