In tutti i progetti, indipendentemente dallo strumento e dalla dimensione dello stesso, un fattore fondamentale è l'organizzazione e la gestione del processo di realizzazione ed il mantenimento successivo. In questa sessione ci focalizzeremo su come approcciare la gestione di un progetto basato su Drupal, partendo dalla fase di analisi e definizione delle specifiche iniziali, per poi passare alla gestione delle attività e la loro consequenzialità nella fase di sviluppo. Verranno illustrati alcuni degli strumenti che possono essere utilizzati e come questi possono aiutare nel raggiungere l'obiettivo nei tempi e modalità previste.

1. Organizza il lavoro Marco Vito Moscaritolo [email_address]

2. Mettiamo SUBITO in chiaro le cose... ...non parleremo di Agile vs Waterfall ...non parleremo di come gestire i costi del progetto ...tutti, TUTTI, TUTTI potrebbero sbagliare (ed io non son da meno) ...non parleremo di come gestire un progetto qualsiasi ...ok, quindi? parleremo di? Come gestire un progetto in DRUPAL

3. Ok, partiamo dall'inizio... Drupal è un CMS (con i superpoteri, ma sempre come CMS nasce) Ecco, magari questo non glie lo lascerei fare...

4. Facciamoci aiutare, ecco a voi... Il cliente (d'ora in poi Mr. X) Il “PM” Lo sviluppatore

5. Il cliente Ho un idea, vorrei… ...poi anche... ...inoltre... ...e non si può fare a meno di... ...e mi serve per settimana prossima. OMG! Ma almeno ha le idee chiare? Il “PM”

6. Raccogliamo le informazioni Impariamo la terminologia dei clienti, non sono i clienti a dover imparare la nostra #ddroma11 Capiamo lo scopo del progetto (aiutiamo Mr. X a capire cosa vuole) Organizziamo le informazioni SCRIVENDOLE (su web, mail, carta, … ovunque ma scriviamo!)

7. Il progetto riguarda... ..e servirebbe avere.... In Drupal questo è un nodo... ...questo una tassonomia... ...quest'altro sono invece utenti... su quest'ultimo punto, invece, ho qualche dubbio.. Il PM Lo sviluppatore

8. Identifichiamo le strutture dati Ragioniamo indipendentemente dall'uso, ma su cosa le informazioni sono/rappresentano (diamo importanza all'architettra dell'informazione del prodotto) Identifichiamo le strutture dati Drupal che le rappresentano (usiamo ciò che c'è a disposizione, quando possibile) Confrontarsi (una scelta sbagliata a questa fase può diventare un grande problema)

9. Mr. X vorrebbe... Con Drupal si più fare usando il modulo... Poi anche... Questa cosa, invece, va sviluppata ad-hoc... Il PM Lo sviluppatore

10. Ragioniamo sui processi... Identificare le funzionalità di uso del sistema (azioni, procedure, automatismi.. e molto altro! :) ) Pensiamo ai moduli per implementarli in Drupal (dai classici rules + views + context.. fino ai moduli un po' più “sperimentali” come plupload+mupload ancora in sandbox) Testare e sperimentare (in caso di incertezze, dubbi.. o anche solo per valutare alternative, provare!) Confrontarsi (anche qui l'importanza non è da meno)

11. “ Pappardella teorica” finita, ma nella realtà ? Come operiamo ? Cosa usiamo ?

12. Le tre leggi della termodinamica lavoro in Drupal Suddividiamo Automatizziamo Implementiamo

13. So cosa fare, in che ordine e come procedere! Lo sviluppatore

14. Suddividiamo Separare le funzionalità, rendendole “isolate” (disaccoppiamento di elementi) Definire le dipendenze (A dipende da B, C dipende da A e B, …) Definire l'importanza e l'ordine di realizzazione (solo io sento puzza di gantt?)

15. “ Clicco” e sono pronto a creare nuove funzionalità “ Clicco” e posso andarmene a casa tranquillo “ Clicco” e rilascio! Lo sviluppatore

16. Automatizziamo Rendiamo le procedure ripetitive automatiche (non vogliamo fare “lavori da scimmia”) Usiamo gli strumenti a disposizione, non reinventiamo la ruota (jenkins [ http://jenkins-ci.org/ ], phing [ http://phing.info/ ], drush [ http://drupal.org/project/drush ], drush_make [ http://drupal.org/project/drush_make ], features [ http://drupal.org/project/features ], giusto per citarne qualcuno) Si da per scontato l'uso di sistemi di versioning (CVS, git, svn, bazaar, mercury, poco importa quale.. basta usarli!) Testiamo il codice, le integrazioni e le interazioni (qui si apre un mondo che esula da questa sessione)

17. /** * Implementation of hook_node_save(). */ function miomodulo_node_save(...) Lo sviluppatore

18. Implementiamo Usiamo quello che c'è già pronto (non reinventiamo la ruota ogni volta…) Possiamo ESTENDERE molti dei moduli già presenti (non ha senso sviluppare da 0 tutto perché manca una funzionalità, contribuiamo al progetto originario o creiamo moduli estensione) Ricordiamo che se scriviamo codice poi dobbiamo MANTENERLO (no, non usate come scusa i contratti di manutenzione...)

19. Il cliente Il progetto è andato benissimo.. ..vorrei aggiungere anche... Il PM

20. Manteniamo I progetti vanno poi mantenuti (operazioni automatiche ci aiutano anche dopo mesi che non mettiamo mano ad un progetto, loro non “si dimenticano”) Documentiamo (progetto fantastico, ma tra 2 mesi ci chiedono l'aggiunta dell'#inventatiqualcosa .. ed ora come lo faccio?) Aggiornamenti del core, dei moduli... (Disabilitando il sistema di notifica degli update non si risolvono i problemi ;) )

21. Tool di gestione “progetto” Redmine [ http://www.redmine.org ]

22. Definire le tipologie di attività (nuova feature, test, bug, ...) Definire il workflow delle attività (nuova, in lavorazione, in approvazione, chiusa) Definire (internamente ed esternamente) il significato di priorità

23. Sistemi di automatizzazione Jenkins con phing

24. “ Se nn conosci il #web, non gestire il progetto. Sarà un disastro a catena.” Pillole da twitter: Lasciatemi spiegare...

25. Marco Vito Moscaritolo http://agavee.com http://mavimo.org @mavimo [email_address]