Slide relative alla sessione "Alm Pills" tenuta al Community Tour 2011 DotNetUmbria

1. Pillole di ALM Di: Ricci Gian Maria alkampfer@nablasoft.com http://www.codewrecks.com http://blogs.ugidotnet.org/rgm

2. Perché ALM Un progetto non è solo «codice», ma un insieme di attività che va dall’analisi dei requisiti fino al deployment per finire con la manutenzione

3. Code and fix Rappresenta la «non gestione» dell’ALM Funziona «forse» per team piccoli e per piccoli progetti Produce codice di bassa qualità, non manutenibile

4. Gestite il vostro processo Non esiste una regola aurea per gestire il vostro processo Esistono in circolazione molti processi e forse nessuno è adatto al vostro modo di lavorare La fase fondamentale è quindi quella di assessment in cui si cerca di capire «dove siete» per comprendere meglio «dove volete andare» Es. http://www.microsoft.com/assess/almassessment/ Per capire bene cosa serve al vostro team dovete essere consapevoli di cosa esiste per capire in che direzione andare

5. I modelli classici

6. Waterfall Funziona per progetti life-critical Le specifiche debbono essere conosciute nelle fasi iniziali Estremamente rigido

7. Waterfall per i «salmoni» Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone 

8. Waterfall Sashimi Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente

9. Verso processi evolutivi - Spiral

10. La crisi dei modelli classici I modelli classici sono troppo rigidi La loro formulazione è stata fatta per progetti di dimensioni grandi, negli anni 80 un progetto software per una banca richiedeva anni prima di completarsi Al giorno d’oggi i progetti sono di dimensione molto variabile e spesso più corti Specifiche non immutabili, ma variabili nel tempo

11. I modelli agili

12. Agile Manifesto Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

13. SCRUM Probabilmente è il processo agile più conosciuto Si basa su iterazioni piccole per dare al cliente nuove funzionalità molto spesso Release frequenti Feedback frequenti Si parte da un backlog che contiene «le cose da fare» e per ogni Sprint (iterazione) si sceglie cosa fare dal backlog

14. Scrum

15. Extreme programming Basato su cinque principi: Simplicity, feedback, respect, communication and courage I principi base sono comunque quelli di Scrum User Stories are written Release planning creates the release schedule Makefrequent small releases The projectisdividedintoiterations Iteration planning startseachiteration Fonte (http://www.extremeprogramming.org/rules.html)

16. Extreme programming

17. Requisiti

18. L’importanza dei requisiti I believe the hard part of building software to be the specification, design, and testing of conceptualconstructr, not the labor of representingit and testing the fidelity of the representation. The hardest single part of building a software systemisdecidingpreciselywhat to build The mythical man month.

19. Gestire i requisiti I requisiti sono la parte più importante del progetto, più di qualsiasi altra pratica o procedura Una corretta gestione dei requisiti è quindi fondamentale e spesso sottovalutata Il rischio maggiore in un progetto è spesso quello di realizzare qualcosa che non serve all’utente

20. Non ripetiamo gli errori di altri The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements (Standish Group) (http://www.projectsmart.co.uk/docs/chaos-report.pdf)

21. Perché è difficile gestire i requisiti Mancanza di analisti con adeguata formazione Gestione fatta da figure che dovrebbero fare altro (Sviluppatori, product manager, commerciali) I software sono complessi, è difficile capire cosa serve al cliente/utente I requisiti sono in costante cambiamento e non possono essere nella maggioranza dei casi determinati in maniera esaustiva prima di iniziare lo sviluppo. Uso errato dei requisiti Es. blindare le eventuali modifiche richieste dal cliente.

22. Gli aspetti più importanti Prendere dai processi agili il concetto di Backlog (Scrum), o Planning Game (XP) Raccogliere i requisiti in un toolvisibile all’intera catena di sviluppo Fare prioritizzare i requisiti dallo Stakeholder Sviluppo iterativo prendere un certo numero di requisiti Implementarli in uno slot di tempo prefissato Deployare il tutto all’utente Prendere feedback, modificare il backlog e procedere alla nuova iterazione

23. Tools Esistono tool commerciali o open source per la gestione dei requisiti Adottare un tool rispetto ad un altro è principalmente questione di Integrazione con i propri sistemi di sviluppo Budget Supporto del proprio processo (o del processo desiderato) Possibilità di customizzazione (Campi aggiuntivi, workflow, etc) Il budget è volutamente scritto piccolo, perché è importante avere un tool che supporti correttamente questa fase di progetto

24. Mini glossario agile per requisiti Backlog A list of user stories, bugs and features that need to be done. Product Backlog A list of Stakeholder requirements for entire product. Release Backlog A list of user stories, features and bugs that should be implemented in defined release. Iteration Backlog A list of user stories, features and bugs that should be implemented in defined iteration.

25. DEMO Una survey di alcuni tools di gestione requisiti

26. Prototipi di UI The purpose of the prototypeis to makereal the conceptualstructurespecified, so that the client can test it for consistency and usability The mythical man month.

27. Vantaggi Grazie ad un prototipo il si riesce meglio a elicitare i requisiti degli stakeholder/utenti Un prototipo non deve necessariamente essere funzionante (spesso è meglio che non lo sia) Esistono molti tool per creare sketch di interfacce (Balsamiq / Sketchflow / …) Una figura vale più di mille parole, lo stakeholder trova più semplice capire una UI rispetto a tonnellate di carta

28. Vantaggi Il cliente vedendo questo potrebbe dire, dove sono le funzionalità di ricerca?

29. Vantaggi Si può immediatamente (pochi secondi) modificare lo sketch

30. Vantaggi Alcune funzionalità avanzate posso essere elicitate discutendo semplicemente sulla UI

31. Derivazione dei requisiti dai mockup Come utente voglio poter gestire Ordini Fornitori e Clienti con funzionalità di ricerca ed editing Come utente vorrei poter avere funzioni di Undo/Redo sulle mie modifiche, cosi come la possibilità di annullare le modifiche effettuate Come utente vorrei poter modificare più di un elemento e decidere di propagare le modifiche a sistema in massa

32. VCS

33. Il source control Dopo avere raccolto i requisiti è ora necessario scrivere codice Anche in team di un singolo sviluppatore è necessario adottare un VCS (Version Control System) Vediamo quindi perchè utilizzarlo e quali pratiche adottare per avere il massimo dal proprio VCS

34. Scegliere il Source control giusto

35. Centralizzato o distribuito? Le soluzioni DVCS offrono tutte le funzionalità del centralizzato + le funzionalità distribuite Pro Lavoro offline o in generale disconnesso dal server centrale Facilità di branch (branch for developer) Merge più semplice Contro Necessità di un training maggiore, si rischia di perdere il controllo delle branch I tool sono ancora un po’ “acerbi”

36. VCS – cosa ci metto dentro? Oltre ai Sorgenti (ovvio)  Tutte le librerie utilizzate dai sorgenti (Nhibernate, castle, ..) Istruzioni sul come è strutturato il progetto (descrizione delle soluzioni, dei progetti, etc) Istruzioni per il nuovo sviluppatore (come compilare, strumenti utilizzati etc) Tutto ciò che è necessario per compilare il progetto Strumenti di build specifici Installer di qualsiasi addin sia necessario al proprio strumento di sviluppo (Addin di visual studio, eclipse, etc) Script di build

37. VCS – Come organizzo il tutto Branches Tags Trunk Src Common MyStuff Core Tests UI WPF Silverligth Libs Nhibernate Castle Net35 Silverlight Net40 Nunit Tools Sandcastle Simian Msbuild Non esiste una strutturazione di default la più comune suggerisce che Al livello zero esista una trunk (main, tip) ed una Branch, con un Tags opzionale A livello 1 esista una src, libs e tools Nei sorgenti si suddividano i progetti in aree logiche del proprio software Se si usano progetti con runtime differenti (Silverlight, .NET) anche le libs andrebbero suddivise

38. VCS – update / commit Il flusso di lavoro dello sviluppatore quando si appresta a scrivere una modifica al codice è Update all’ultima versione Scrittura del nuovo codice, esecuzione dei test (preferibilmente automatizzati) e verifica correttezza Update per eventuali altri cambiamenti inseriti nel tempo intercorso In caso di cambiamenti, rieseguire i test per verificare la compatibilità del codice scritto Tornare al punto tre Quando nessun update esiste nel punto 3 inviare le proprie modifiche al server Gli sviluppatori debbono essere istruiti

39. VCS – update/commit errori comuni Troppi pochi commit (ogni qualche giorno ) Rischio di merge più elevato Rischio di perdere dati (ad un collega hanno rubato il portatile ed ha perso 10 gg di sviluppo) Inadatto a progetti agili Mancato update prima del commit Si inviano le proprie modifiche, ma il codice nel frattempo è cambiato e quindi la soluzione diventa instabile Si rischia che il codice non sia più compilabile Assenza di test prima dell’invio Rischio di rendere il codice incompilabile o comunque instabile Soluzione a rischio di stabilità, possibile blocco del team di sviluppo.

40. Branching and Merging

41. VCS – Branch / merge Sindrome del «siamo vicini alla release non scriviamo nuovo codice, ma fixiamo solo bug» Blocchiamo l’introduzione di nuove feature fino alla release Impantaniamo tutto il team nel solo bugfixing. Il cliente segnala un bug bloccante, sono passati 5 mesi dal deploye il progetto è in mezzo a modifiche sostanziali Limitiamo la possibilità di correggere bug nel software rilasciato al cliente Ci limitiamo a poter fornire al cliente solo le major release Uno o più sviluppatori debbono modificare una funzionalità core Durante questo sviluppo tutto il team lavora su codice instabile

42. VCS – Branch / merge Questo deriva dall’avere una sola «linea di codice» Il branching risolve questo problema in maniera egregia ed è supportato da tutti i VCS (in maniera avanzata nei DVCS) Una branch è una copia dei sorgenti fatta in uno specifico momento, che viene manutenuta nel VCS C1 C2 C120 C2000 C245 C2123 C30

43. Forward e Reverse integration Le modifiche fluiscono tra le branch in due modi Reverse integration: dalla branch vengono portate al ramo sorgente Forwardintegration: dal ramo sorgente vengono portate nella branch Baseless merge: fatta tra due branch non contigue Si possono portare tutte le modifiche, un range, oppure singoli check-in (cherry-picking) RI FI BRANCH

44. Quando usare Branch Rilasciamo software al cliente in produzione e vogliamo mantenere La possibilità di continuare a sviluppare anche durante la fase di stabilizzazione della release La possibilità di fare hotfix durante lo sviluppo delle nuove versioni Bug Hotfix Main Rel1

45. Quando usare Branch Abbiamo team che lavorano a funzionalità differenti Vogliamo garantire che ogni team lavori in isolamento Vogliamo la possibilità di rilascio differenziato delle funzionalità Abbiamo merge più impegnative Le feature sono indipendenti, chi fa la merge per primo è fortunato, per gli altri….Siamo nella Merge ™  Feat2 Feat1 Main Rel1

46. Quando usare Branch Uno o più sviluppatori debbono modificare una parte «core» del sistema Si vuole evitare che tutto il team lavori con codice instabile Si vuole garantire che le modifiche al «core» del sistema siano autonome Il segreto è fare frequenti forwardintegration e Reverse integration in milestone stabili (se ci sono Mods Main

47. Esempio di Branch con SVN

48. DVCS La differenza sostanziale è che un DVCS non ha un «repository» centralizzato Ogni sviluppatore «clona» da un repository e poi sviluppa sul proprio repository locale Si lavora quindi con una Branch Per Developer Il sistema permette la sincronia tra i repository / branch Le merge sono più gestibili perché il sistema è inerentemente pensato per lavorare sempre in branch/merge

49. Che DVCS usare? Attualmente i due più «famosi» sono HG (mercurial) e GIT Personalmente trovo HG più usabile e con una interfaccia più «umana» HG supporta l’installazione in server windows senza troppi problemi http://stackoverflow.com/questions/818571/how-to-setup-mercurial-and-hgwebdir-on-iis http://mercurial.selenic.com/wiki/WindowsInstall HG supporta molte modalità di condivisione dei repository http://mercurial.selenic.com/wiki/PublishingRepositories

50. HG esposto linea di comando C:entralRepo> hg init C:entralRepo> hg serve Nel file .hggrc [web]push_ssl=Falseallow_push=* Source http://hginit.com/02.html

51. Mercurial Un piccolo excursus su un DVCS

52. Integrazione continua

53. Se vi ricorda qualcosa siete nei guai We need only to put everything together and create the setup. It is all Green. We are 2 weeks from release date and we have nothing to test. Is it everything ok? Microsoft Confidential 53

54. Integrazione Uno dei problemi più ricorrenti nei team è l’Integration Hell Questo problema si verifica quando si integrano tardi nel ciclo di vita le varie parti che compongono il software.

55. Le cause I software vengono spesso sviluppati a blocchi Mettere insieme i vari blocchi è come un puzzle, più attendete, più pezzi si accumulano, più è difficile finirlo.

56. Integrazione continua Continuous Integration is a software development practice where members of a team integrate their work frequently … Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible (Martin Fowler)

57. Integrazione continua CI is the embodiment of tactics that gives us, as software developers, the ability to make changes in our code, knowing that if we break software, we’ll receive immediate feedback...[It is] the centerpiece of software development, as it ensures the health of software through running a build with every change. (Paul Duval)

58. Come fare Esistono software gratuiti (CruiseControl.Net, Team City) o a pagamento (TFS, DrumBeat) Essenzialmente eseguono degli script al sopravvenire di alcuni trigger Lo scopo è quello di eseguire spesso Compilazione Esecuzione degli unit test Calcolo di metriche (Code Coverage, Code Analysis) Creazione package di setup Test di deploy dei package di setup Esecuzione di test automatizzati direttamente sulla UI ….

59. Demo Continuous Integration in TFS e Team City

60. Testing

61. Gli unit test non sono tutto Le pratiche di unittesting sono in grado di rilevare molti bug del software ma non tutti Alcune funzionalità sono difficili da testare in maniera automatica È necessario prevedere di avere risorse dedicate al testing, un tester infatti «ragiona in maniera differente da un developer»

62. A cosa serve il test The purpose of testing a program is to find problems in it The purpose of finding problem is to get them fixed (Testing Computer Software – CemKaner et Al.)

63. A cosa serve il test A mismatch between the program and its specification is an error in the program if and only if the specification exists and is correct A program that follows a terrible specification is terrible not perfect (Testing Computer Software – CemKaner et al)

64. A cosa serve il test A software error is present when the program does not do what its end user reasonably expects it to do (Software Reliability: Principles and Practices - Myers) The extent to which a program has bugs is measured by the extent to witch it fails to be useful. This is a fundamentally human measure. (Software system testing and quality assurance - Beizer)

65. Test manuali – come fare È consigliabile tenere una suite di test che possa in maniera inequivocabile stabilire che operazioni fare per «verificare» il software Evitare di utilizzare tools pensati per altre cose (Es. Excel) per creare le suite di test Esistono strumenti pensati per gestire il testingEs. Microsoft Test Manager

66. MTM Quick Tour

67. Altri consigli

68. Code review Il Code Review è una delle pratiche di ALM meno utilizzate (purtroppo è anche una delle più utili) La pratica di Code Review consiste nella revisione da parte del team di alcune parti di codice

69. Code review - consigli Il Code Review è anonimo e non ha lo scopo di punire o ridicolizzare un membro del team Gli strumenti di VCS aiutano questa pratica, Es. Shelveset di TFS o HG shelve http://msdn.microsoft.com/en-us/library/ms182019.aspx

70. Pairprogramming Una forma di Code Review è il PairProgramming, utilissimo per le parti critiche di codice Sebbene due sviluppatori usino un solo pc, la qualità del codice è migliore Si migliora la comunicazione e si favorisce uno standard per il codice

71. Rilascio Il software non è completato quando funziona nelle macchine degli sviluppatori Il rilascio è una operazione non sempre risk-free

72. Rilascio - consigli Cercate di automatizzare il tutto con uno script Con manipolazione XML modificare gli app.config per l’ambiente di produzione Grazie ai database project generare il database logico da usare per l’aggiornamento dei db di produzione Con msbuild automatizzare la creazione di package msi o clickonce Fate girare gli script in integrazione continua Avete la garanzia che il software sia sempre deployabile Potete tenere un ambiente di test sempre allineato per il team di test Es: NHProfiler di ayende.

73. Rilascio - consigli Realizzate comunque un documento di deploy con Istruzioni dettagliate sui tool necessari per la compilazione Istruzioni dettagliate su come generare i setup o i binari Descrizione dell’ambiente di staging/preproduzione e rilascio sequenza dettagliata di backup dell’installazione corrente Sequenza dettagliata di passi per installare i binari Informazioni dettagliate sui file di configurazione e su ogni possibile altra configurazione (registrykey, ini file, etc) Lista di verifiche da fare per assicurarsi che il deploy sia andato a buon fine Istruzioni dettagliate per il ripristino del backup in caso di problemi

74. Le stime software Esiste un libro veramente bello sull’argomento, pieno di consigli utili

75. Cicli corti (sprint) Invece di stimare tempi lunghi è preferibile creare iterazioni corte (2-4 settimane) Si può tenere traccia del progresso con grafici molto chiari come il burndown chart

76. Cicli corti Al termine di uno sprint le funzionalità debbono essere rese disponibili al cliente Si affrontano subito i problemi relativi al rilascio e alla messa in produzione Il software è subito usabile, la soddisfazione dello stakeholder è maggiore Al termine del tempo stimato, forse non si sono implementate tutte le feature, ma sicuramente si sono fatte le più importanti e sono testate e pronte all’uso