Lavorare in un progetto informatico non è sempre semplice soprattutto quando si ha a che fare con più persone, aziende o collaboratori, dove ognuno dovrà gestire la sua parte nel modo giusto per far funzionare la tua.
La mia esperienza passata in una multi-nazionale americana mi ha insegnato che per lavori di questo tipo è necessario seguire un processo ben strutturato tale da consentire di ottenere un lavoro finale ben fatto e di qualità, da poter vendere al giusto prezzo e quindi valorizzarsi. Purtroppo non sempre queste nozioni vengono messe in pratica nelle realtà informatiche italiane e onestamente non ne comprendo i motivi.
Ecco quindi la mia lista delle 10 cose da fare assolutamente quando si gestisce e si lavora in un progetto di medie-grandi dimensioni.
1. Analisi
Rivolto a: TUTTI
Il processo di analisi è uno step obbligatorio per poter garantire il successo del progetto! Più tempo si dedicherà all'analisi e meno se ne dedicherà alla risoluzione di errori futuri, di sviluppo o di mancata implementazione.
Ogni componente del team può dare il suo contributo in questa fase che inizierà con un bel e confuso brainstorming dove verranno evidenziati tutti i dubbi che vengono in mente. Il risultato sarà un buon documento con le specifiche da sviluppare che sarà la base del contratto con il cliente.
Una buona analisi di base e già il 40% del lavoro è fatto. Potrebbe capitare, ed è capitato, che dopo aver discusso giorni su come bisogna procedere ci si rende conto che quel progetto non è realizzabile oppure è "troppo grande" per noi perchè richiede risorse e conoscenze diverse dalle nostre. Meglio scoprirlo prima che dopo!
2. Ma cosa deve fare?
Rivolto a: PROJECT LEADER
Dall'analisi dei requisiti devono essere stilati gli use cases ossia la descrizione di cosa può fare l'utente e quale reazione deve avere il sistema di conseguenza.
Si possono disegnare oppure descrivere testualmente, l'importante è indicare sempre da dove l'utente parte (Start), cosa fa il sistema (Action) su un determinato evento (User event) e cosa viene mostrato (Return) all'utente dopo l'evento.
Ad esempio vediamo un semplice invio del form su una pagina web:
Use case: L'utente compila il form dei contatti per richiedere informazioni.
Start: Form dei contatti (contact.html)
User event: Click sul tasto submit
Action: Invio della mail all'amministratore del sito
Return: Pagina di ringraziamento (mail-ok.html)
Sembra semplice e banale, soprattutto per l'invio del form dei contatti, ma se ci aggiungiamo i campi obbligatori e criteri di sicurezza sulla password in un form di registrazione vediamo che i casi d'uso aumentano.
3. Design
Rivolto a: TECHNICAL LEADER
Dopo, e solo dopo, aver le idee chiare su quello che si deve fare bisogna passare alla fase di design utilizzando magari sistemi astratti come l'UML (Unified Modeling Language) che andranno a definire il design di tutti gli use cases.
Cosa andare a progettare in UML dipende dal tipo di progetto e dal linguaggio di programmazione, l'UML è un metodo applicato a diverse situazioni: design dei componenti, delle classi nella programmazione ad oggetti, per le interazioni o per il meta-modeling... scegliete quello che più può aiutarvi nel vostro sviluppo.
4. Abbi fede!
Rivolto a: PROJECT LEADER
Bisogna avere fiducia degli sviluppatori e nel loro lavoro! Analizzate il miglior sistema di sviluppo da utilizzare con il supporto di chi ci deve mettere le mani; non bisogna scegliere il primo cms che compare nei motori di ricerca, l'esperienza degli sviluppatori aiuta a capire, dopo una breve analisi da parte loro, i limiti che ci sono e i rischi da assumersi - Umbraco docet.
"Se mi obblighi ad usare un sistema non adatto, non pretendere che poi tutto funzioni!". (Uno sviluppatore)
5. "Deve essere pronto per... ieri!"
Rivolto a: PROJECT LEADER
Dopo, e solo dopo, aver messo insieme tutte le informazioni degli step precedenti bisogna calcolare le stime, cioè il tempo necessario per sviluppare il progetto dal quale verrà poi calcolato il preventivo. Ovviamente con l'aiuto degli sviluppatori che sanno meglio dire quanto tempo impiegano per fare il lavoro, non fare stime al posto loro!
Se il cliente ha già in mente una data di scadenza del progetto verificare da subito quante persone saranno coinvolte nel progetto (staff/days): se ad esempio un nuovo sviluppatore viene coinvolto dopo un mese, qualcuno del team sarà costretto a spiegargli tutto, dall'analisi al design allo sviluppo perdendo ulteriormente tempo. Meglio pensarci prima!
6. Team sempre aggiornato
Rivolto a: TUTTI
Se ci sono diversi attori coinvolti (designers, db administrator, developers, seo, collaboratori esterni...) è necessario riunirsi almeno settimanalmente (anche a distanza) per stabilire i traguardi da raggiungere entro la prossima settimana e verificare quelli raggiunti nella settimana passata. Importante stabilire le priorità di sviluppo per evitare che un team non lavora perchè manca del codice che dipende da un altro team!
Tutti gli aspetti tecnici devono essere affrontati senza la presenza dei manager che si annoieranno ascoltando argomenti che non fanno parte del loro lessico.
7. Fareste un giro in bici... senza ruote?
Rivolto a: PROJECT LEADER
Il cliente deve da subito fornire tutti i requisiti e i dati necessari per poter svolgere il lavoro! Non iniziare prima a sviluppare senza avere tutte le idee chiare, ti farebbe perdere solo tempo.
Molti manager, molto gestionali e poco tecnici, pensano che il codice sia "flessibile" in base a quello che vuole il cliente... mi spiace ma Babbo Natale non esiste! Dall'analisi si passa al design, dal design allo sviluppo e se cambia un requisito bisogna rifare l'analisi, il design e lo sviluppo e potrebbe coinvolgere diversi use cases... capite perchè è meglio soffermarsi il più possibile sull'analisi?
Tutto ciò che arriverà dopo sarà un implementazione di una nuova feature da fatturare a parte e gestire come un nuovo progetto, date una data di scadenza al vostro cliente per la consegna di tutto ciò che vi serve!
8. Pronti a tutto!
Rivolto a: IT ADMINISTRATOR - TECHNICAL LEADER
Preparare sempre un ambiente di sviluppo in locale, uno di test in remoto e uno di produzione. In questo modo gli sviluppatori potranno lavorare su un ambiente senza modificare il lavoro già in produzione o in test. Questi ultimi devono essere due ambienti identici.
Tutto il codice deve essere posto sotto repository (come Tortoise SVN e Github) in modo da renderlo accessibile a tutti e gestire le revisioni nelle varie fasi. Sono sistemi utili anche nel caso sfortunato che tutti i dati vengano accidentalmente perduti, tipo un hard disk che prende fuoco... (è successo!)
9. Ma sei proprio sicuro del tuo codice?
Rivolto a: DEVELOPERS
Per progetti complessi fate una review del codice con un altro sviluppatore: in questo modo capirete insieme se l'algoritmo è stato sviluppato nel modo corretto o c'è qualcosa che vi è sfuggito.
E' anche un modo per confrontarsi ed imparare molto dalle esperienze di altri e dai propri errori.
10. Test, test, test
Rivolto a: TUTTI
Prima di andare online: TEST, TEST, TEST... Tutti devono contribuire per verificare che funzioni a dovere.
Lo sviluppatore deve testare sempre il codice, per ogni procedura sviluppata. Bisogna però tenere a mente che il test svolto dallo sviluppatore raramente terrà conto dei casi limiti che potrebbero generare errori: chi sviluppa ragiona ovviamente sulla logica del codice che sta programmando (partendo dal design dell'UML). Sarà quindi compito di una risorsa esterna, meglio se estranea al progetto, capire se tutto funziona bene.
Dagli use cases si potranno scrivere anche i test da eseguire, ad ogni requisito ci dovrà essere almeno un test case corrispondente.
Per i progetti web considerate anche l'usabilità e i test vi faranno capire il comportamento dell'utente che si trova di fronte il vostro sito. Vi consiglio questo articolo sull'argomento.
Cosa ne pensi?
Questa è la lista di come - secondo me - dovrebbe essere gestito un progetto di sviluppo informatico. Mi piacerebbe conoscere la tua opinione a riguardo. Pensi che ho dimenticato qualcosa?
Libri consigliati per la gestione di un progetto informatico
6f97a0ac-516e-4bec-bde1-afe7969f641b|0|.0