WPF …sometime change is everything…

Questo post dovrebbe essere il primo di alcuni che riguardano l’argomento della mia tesi. Ovviamente non scriverò tanto e così approfonditamente come farò in “quella”, ma spero di dare buoni spunti segnalando dove e come io ho trovato informazioni per il mio lavoro.

Innanzitutto direi di introdurre che cosa sono ste benedette metodologie agili.
Le metodologie agili sono una nuova forma per lo sviluppo del software, voi direte “non è che puoi essere più specifico”, certo! Queste metodologie sono delle ricette tramite cui voi organizzate l’implementazione del software.
Si dicono agili perchè i valori a cui esse attribuiscono maggiore importanta sono:

• Individui e interazioni più che processi e strumenti
• Software funzionante più che documentazione dettagliata
• Collaborazione con il cliente più che negoziazione di un contratto
• Adeguarsi al cambiamento più che seguire un piano

In pratica sono state sviluppate perchè si è notato come le tecniche di sviluppo “classiche” basate su fasi ben distinte di Analisi, Progettazione, Implementazione e Verifica, non riuscivano sempre a sostenere il lavoro di gruppi che affrontavano problemi che avevano al loro interno degli elementi di dinamicità.
Spiego meglio: Se si fa un’analisi dei requisiti di un software, lo si progetta e quando si arriva a metà implementazione ci si accorge di: “oddio l’analista a sca22ato ad interpretare il requisito x”, “il cliente si presenta e vi dice che non gli va bene l’apetto x e lo vuole invece y”(x può essere il colore del bottone ‘login’ ma può anche essere un aspetto base della business logic del vostro progetto o di una sua parte consistente), etc.. Voi che fareste?? Ok, licenziare l’analista può andare bene, ma mica potete licenziare il cliente!!
Le metodologie agili vanno a piazzarsi proprio a questo punto. In esse si pensa al cambiamento come un fattore inevitabile, soprattutto in un ambiente come quello del software e in genere della tecnologie che fa passi da gigante nel giro di giorni e mesi, nenache di anni!
I fattori base di una metodologia agile sono :

• Le COMUNICAZIONI: L’importante è capirsi, comunicare in modo efficace e possibilmente faccia a faccia. Le comunicazioni non devono essere limitate tra i programmatori, ma estese a tutti gli interessati dal progetto: programmatori, project manager, cliente, designer, grafici, etc. etc. …
  Questpo permette non solo di capire cosa vuole il cliente ma anche di innalzare la conoscenza generale dell’intero gruppo di lavoro sul problema (o problemi) da affrontare, come verra affrontato e perchè. Tutto questo senza dover scrivere 12 capitoli di documentazione da 1000 pagine l’uno!
• Devi consegnare spesso al cliente e devi consegnare software funzionante: Le metodologie agili prevedono uno sviluppo del software che può essere descritto grossolanamente come una serie di fette di una torta che vengano attaccate una all’altra, per partire da un piatto vuoto ed arrivare ad una torta intera. Questo modo di fare è diverso dal concetto di sviluppo a partire da un nucleo centrale di funzionalità, su cui poi viene montato uno strato di “business logic” e poi le “interfacce utente”, che io chiamo (a mia inappellabile decisione ) “sviluppo a cipolla”.
  L’idea è quindi quella di ottenere, ogni poche iterazioni del processo di sviluppo della metodologia agile scelta, una porzione (fetta) del progetto (torta) che funzioni esattamente come ci era stato richiesto dal cliente (una fetta di torta deve essere buona quando il cliente la mangia) e che sia utilizzabbile da subito per test da parte del cliente ed eventualmente per l’uso nelle attività aziendali (una volta che il cliente mangia la fetta di torta e dice che fa schifo significa che qualcosa non va!).
  L’ultima cosa da notare è che qui si parla di software funzionante. Come fate a dire che un software funziona? Lo testate! Giusto. L’idea nuova è quella di scrivere i test per il codice prima del codice stesso. I test devono essere basati su quello che il cliente vuole, così chi sviluppa ha l’obiettivo di verificare quel test e di conseguenza sviluppare esattamente quello che vuole il cliente.
  NB: senza sprechi di tempo perchè implementi solo ciò che è richiesto!!
• PUNTO FONDAMENTALE: Adeguarsi al cambiamento e accettarlo come parte del proprio lavoro. Questo non significa lavorare nottate intere come schiavi perchè “qualcosa è cambiato”. Significa sfruttare le molte iterazioni brevi per approfondire di volta in volta la conoscenza di una piccola porzione di software, implementarla al meglio, integrarla con quelle già presenti e verificare che tutto funzioni. Se qualcosa non funziona: risolverlo subito!. Si ha l’obbligo di consegnare software funzionante, ricordate?
  Inoltre il cambiamento può riguardare non solo il codice ma anche il modo di svilupparlo. Se vediamo che il processo di sviluppo utilizzato non dà i risultati che volevamo o non è efficiente nel nostro ambiente di lavoro e per il nostro progetto, allora perchè non cambiarlo e migliorarlo analizzando cosa non va?

Per oggi basta così. Vi dico solo un’ultima cosa, ma non ditela a nessuno: Le metodologie agili non sono una manna! Vanno applicate dove servono e con criterio. Dovete studiare per applicarle e studiare tanto. Di seguito un pò di link per approfondire.

• Agile Manifesto: Principles
• Agile software development
• “The Agile Manifesto“: la speigazione di due dei fondatori

Posted under Metodologie Agili, planet-sprite