Upload
gian-maria-ricci
View
500
Download
0
Embed Size (px)
DESCRIPTION
Slide relative alla sessione "Alm Pills" tenuta al Community Tour 2011 DotNetUmbria
Citation preview
Pillole di ALM
Di: Ricci Gian [email protected]://www.codewrecks.comhttp://blogs.ugidotnet.org/rgm
Do your systems talk business? | 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 Analisi
requisiti
Design
Sviluppo
Testing
Deploy
Do your systems talk business? | 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
Do your systems talk business? | 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
Do your systems talk business? | 5
I modelli classici
Do your systems talk business? | 6
WaterfallRequisi
ti
Design
Sviluppo
Test
Deploy
Funziona per progetti life-critical
Le specifiche debbono essere conosciute nelle fasi iniziali
Estremamente rigido
Do your systems talk business? | 7
Waterfall per i «salmoni»Requisi
ti
Design
Sviluppo
Test
Deploy
Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone
Do your systems talk business? | 8
Waterfall SashimiRequisi
ti
Design
Sviluppo
Test
Deploy
Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente
Do your systems talk business? | 9
Verso processi evolutivi - Spiral
Do your systems talk business? | 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
Do your systems talk business? | 11
I modelli agili
Do your systems talk business? | 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.
Do your systems talk business? | 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
Do your systems talk business? | 14
Scrum
Do your systems talk business? | 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 Make frequent small releases The project is divided into iterations Iteration planning starts each iteration Fonte (http://www.extremeprogramming.org/rules.html)
Do your systems talk business? | 16
Extreme programming
Do your systems talk business? | 17
Requisiti
Do your systems talk business? | 18
L’importanza dei requisiti
I believe the hard part of building software to be the specification, design, and testing of conceptual constructr, not the labor of representing it and testing the fidelity of the representation.
The hardest single part of building a software system is deciding precisely what to build
The mythical man month.
Do your systems talk business? | 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
Do your systems talk business? | 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)
Do your systems talk business? | 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.
Do your systems talk business? | 22
Gli aspetti più importanti
Prendere dai processi agili il concetto di Backlog (Scrum), o Planning Game (XP)
Raccogliere i requisiti in un tool visibile 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
Do your systems talk business? | 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
Do your systems talk business? | 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.
DEMO
Una survey di alcuni tools di gestione requisiti
Do your systems talk business? | 26
Prototipi di UI
The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability
The mythical man month.
Do your systems talk business? | 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
Do your systems talk business? | 28
Vantaggi Il cliente vedendo questo potrebbe dire,
dove sono le funzionalità di ricerca?
Do your systems talk business? | 29
Vantaggi Si può immediatamente (pochi secondi)
modificare lo sketch
Do your systems talk business? | 30
Vantaggi Alcune funzionalità avanzate posso essere
elicitate discutendo semplicemente sulla UI
Do your systems talk business? | 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
Do your systems talk business? | 32
VCS
Do your systems talk business? | 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
Do your systems talk business? | 34
Scegliere il Source control giusto
SCS
Distributed
HG GIT
Centralized
TFS SVN CVS
Do your systems talk business? | 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”
Do your systems talk business? | 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
Do your systems talk business? | 37
VCS – Come organizzo il tutto
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
− Branches− Tags− Trunk
− Src− Common− MyStuff
− Core− Tests− UI
− WPF− Silverligth
− Libs− Nhibernate− Castle
− Net35− Silverlight− Net40
− Nunit− Tools
− Sandcastle− Simian− Msbuild
Do your systems talk business? | 38
VCS – update / commit
Il flusso di lavoro dello sviluppatore quando si appresta a scrivere una modifica al codice è1. Update all’ultima versione
2. Scrittura del nuovo codice, esecuzione dei test (preferibilmente automatizzati) e verifica correttezza
3. Update per eventuali altri cambiamenti inseriti nel tempo intercorso
4. In caso di cambiamenti, rieseguire i test per verificare la compatibilità del codice scritto
5. Tornare al punto tre
6. Quando nessun update esiste nel punto 3 inviare le proprie modifiche al server
Gli sviluppatori debbono essere istruiti
Do your systems talk business? | 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.
Do your systems talk business? | 40
Branching and Merging
Do your systems talk business? | 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 deploy e 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
Do your systems talk business? | 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 VCSC1 C2
C120
C2000
C30
C245
C2123
Do your systems talk business? | 43
Forward e Reverse integration Le modifiche fluiscono tra le branch in due
modi Reverse integration: dalla branch vengono portate al
ramo sorgente Forward integration: 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)
BRANCH
RI
FI
Do your systems talk business? | 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
Rel1
Hotfix
BugMain
Do your systems talk business? | 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 ™
Rel1
Main
Feat1
Feat2
Do your systems talk business? | 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 forward integration e Reverse integration in milestone stabili (se ci sono
Main
Mods
Esempio di Branch con SVN
Do your systems talk business? | 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
Do your systems talk business? | 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
Mercurial
Un piccolo excursus su un DVCS
Do your systems talk business? | 52
Integrazione continua
Do your systems talk business? | 53
Se vi ricorda qualcosa siete nei guai
Microsoft Confidential53
We are 2 weeks from release date
and we have nothing to test. Is it
everything ok?
We need only to put everything together
and create the setup. It is all Green.
Do your systems talk business? | 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.
Do your systems talk business? | 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.
Do your systems talk business? | 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)
Do your systems talk business? | 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)
Do your systems talk business? | 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 ….
Demo
Continuous Integration in TFS e Team City
Do your systems talk business? | 60
Testing
Do your systems talk business? | 61
Gli unit test non sono tutto Le pratiche di unit testing 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»
Do your systems talk business? | 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 – Cem Kaner et Al.)
Do your systems talk business? | 63
A cosa serve il testA 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 – Cem Kaner et al)
Do your systems talk business? | 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)
Do your systems talk business? | 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 testing Es. Microsoft Test Manager
MTM Quick Tour
Do your systems talk business? | 67
Altri consigli
Do your systems talk business? | 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
Do your systems talk business? | 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
Do your systems talk business? | 70
Pair programming Una forma di Code Review è il Pair
Programming, 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
Do your systems talk business? | 71
Rilascio Il software non è completato quando
funziona nelle macchine degli sviluppatori Il rilascio è una operazione non sempre risk-
free
Do your systems talk business? | 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.
Do your systems talk business? | 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 (registry key, 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
Do your systems talk business? | 74
Le stime software Esiste un libro veramente bello
sull’argomento, pieno di consigli utili
Do your systems talk business? | 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
Do your systems talk business? | 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
Do your systems talk business? | 77