Prima di iniziare a scrivere codice, è molto importante che dedichiate del tempo a conoscere e accogliere nella vostra quotidianità dei tool che vi possano aiutare nella comunicazione.
Anche se il team è piccolo, in questo momento pensa solo ad organizzare la comunicazione. Non bisogna sottovalutare i problemi derivanti da incomprensioni o specifiche poco chiare.
Per "comunicazione", intendo:
- La definizione dei requisiti business. Capire cosa vuole il committente è il primo scoglio perché lui parla il linguaggio del business della sua azienda, mentre gli sviluppatori parlano un linguaggio tecnico. Impegnatevi nel costruire un linguaggio fatto di termini condivisi, a cui entrambe le parti danno lo stesso significato. Meglio ripetere le cose mille volte anziché avere la falsa sicurezza di aver capito tutto subito. Vi eviterà un sacco di problemi più avanti, nello sviluppo.
- La documentazione. Idealmente, un software dovrebbe materializzarsi dalla visione di una sola persona all'interno del team, e la documentazione sarà il frutto del suo lavoro. Dedicare una persona a questo scopo vi garantisce che 1. il software venga disegnato con una certa omogeneità e coerenza dall'inizio alla fine; 2. i fraintendimenti saranno ridotti al minimo perché gli sviluppatori che andranno ad implementare quel disegno si atterranno tutti ad una specifica comune che sarà dettagliata perché curata a tempo pieno; 3. E' un'opportunità per parallelizzare il lavoro. Non pensare che più sviluppatori completeranno il lavoro più velocemente, anzi, se riesci ad assegnare a ciascuno un compito specifico eviterai che la gente si pesti i piedi a vicenda.
- Scambio di opinioni. Portando avanti il progetto andrete a conoscere le esigenze di business in maniera sempre più approfondita. Può darsi che si scoprano dei difetti di progettazione, o che nascano spunti per un miglioramento. Concentrate tutti gli scambi d'opinione e i problemi in riunioni mattutine di 15 minuti a cui tutti dovranno partecipare. Tutti quanti così vengono messi a conoscenza di ogni eventualità. Chi si occupa di scrivere la documentazione dovrà poi adeguarla a ciò che si era accettato verbalmente.
- Coinvolgete il committente e mostrategli il lavoro svolto con una certa frequenza. Ogni 15 giorni, stabilite quale pezzetto di applicazione andrete a sviluppare e concentratevi solo su quello affinchè sia pronto al termine delle due settimane. Non deviate su altri problemi mentre siete nello "sprint". Mostrate al committente il prodotto delle due settimane di lavoro, così riuscirete a stroncare eventuali incomprensioni sul nascere.
Tutto questo sembra una perdita di tempo ma ti assicuro che darà valore al vostro software, oltre a farvi lavorare molto più sereni e con pochi intoppi.
A proposito dei tool (free) di cui parlavo all'inizio, puoi dare un'occhiata a questi:
Mercurial: un sistema molto semplice di versioning distribuito del codice sorgente. Il vantaggio di usarlo ce l'hai se riesci (e dovresti farlo) ad assegnare ciascuno sviluppatore allo sviluppo di una specifica porzione del software. L'aggiunta (committing) delle modifiche è molto veloce perché avviene in locale, cioè non devi predisporre un server solo per conservare il codice sorgente. In più hai un backup naturale perché il codice che ciascuno scrive ce l'hai sulle macchine di tutti gli sviluppatori, trattandosi di un meccanismo peer-to-peer.
http://mercurial.selenic.com/YouTrack: un "issue tracker", ovvero consente a chiunque nel team di aprire "tickets" quando si incontrano dei bug e di tenere traccia della loro risoluzione.
http://www.jetbrains.com/youtrack/YouTrack può anche essere integrato dentro TeamCity, un tool per la continuous integration. Ovvero... la pratica metodica (e automatica) di mettere alla prova il software quotidinamente, man mano che piccole funzionalità vengono aggiunte al repository.
http://www.jetbrains.com/teamcity/Dotatevi anche una lavagna su cui appiccicherete tanti post-it per tenere traccia delle funzionalità man mano che passano da "da fare" a "in corso" a "fatte".
http://ju-n.net/files/2010/01/scrum-board.jpgIn fin dei conti, quello che ti consiglio è la metodologia di sviluppo agile.
http://it.wikipedia.org/wiki/Metodologia_agileSforzatevi di metterla in pratica, alla fine vi renderete conto di quanto paghi questo piccolo investimento iniziale in termini di impegno.
In più ti consiglio questo libro, che ha i suoi anni ma è sempre molto attuale. Dà consigli molto pratici. Su wikipedia c'è un "riassunto".
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
