Alm pills - Sessione community tour Dot Net Umbria 2011

Pillole di ALM

Di: Ricci Gian [email protected]://www.codewrecks.comhttp://blogs.ugidotnet.org/rgm

mailto:[email protected]

http://www.codewrecks.com/

http://www.codewrecks.com/

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


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


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

http://www.microsoft.com/assess/almassessment/

http://www.microsoft.com/assess/almassessment/


I modelli classici


WaterfallRequisi

ti

Design

Sviluppo

Test

Deploy

Funziona per progetti life-critical

Le specifiche debbono essere conosciute nelle fasi iniziali

Estremamente rigido


Waterfall per i «salmoni»Requisi

ti

Design

Sviluppo

Test

Deploy

Diminuisce la rigidità ammettendo la possibilità di «risalire» la cascata come un salmone


Waterfall SashimiRequisi

ti

Design

Sviluppo

Test

Deploy

Si sovrappongono le fasi, una fase successiva inizia prima del completamento della precedente


Verso processi evolutivi - Spiral


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


I modelli agili


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.


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


Scrum


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)

http://www.extremeprogramming.org/rules.html


Extreme programming


Requisiti


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.


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


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)

http://www.projectsmart.co.uk/docs/chaos-report.pdf

http://www.projectsmart.co.uk/docs/chaos-report.pdf


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.


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


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


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


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.


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


Vantaggi Il cliente vedendo questo potrebbe dire,

dove sono le funzionalità di ricerca?


Vantaggi Si può immediatamente (pochi secondi)

modificare lo sketch


Vantaggi Alcune funzionalità avanzate posso essere

elicitate discutendo semplicemente sulla UI


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


VCS


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


Scegliere il Source control giusto

SCS

Distributed

HG GIT

Centralized

TFS SVN CVS


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”


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


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


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


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.


Branching and Merging


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


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


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


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


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


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


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


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

http://stackoverflow.com/questions/818571/how-to-setup-mercurial-and-hgwebdir-on-iis





http://mercurial.selenic.com/wiki/PublishingRepositories

Mercurial

Un piccolo excursus su un DVCS


Integrazione continua


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.


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.


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.



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)



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)


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


Testing


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»


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.)


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)


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)


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


Altri consigli


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


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




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


Rilascio Il software non è completato quando

funziona nelle macchine degli sviluppatori Il rilascio è una operazione non sempre risk-

free


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.


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


Le stime software Esiste un libro veramente bello

sull’argomento, pieno di consigli utili

http://www.amazon.com/gp/reader/0735605351/ref=sib_dp_pt#reader-link


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


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


Date post:	26-May-2015
Category:	Technology
Upload:	gian-maria-ricci
View:	498 times
Download:	0 times

Alm pills - Sessione community tour Dot Net Umbria 2011

Technology