3.939 messaggi dal 28 gennaio 2003
Questa la situazione. Un server con windows 2003/windows 2008 e più computer collegati in rete, ognuno con visual studio 2010.
Dobbiamo lavorare ad un progetto web (intranet) a più mani.
Volevo un suggerimento sulla modalità corretta per gestire questo tipo di lavoro.

Ciao
a parte l'ovvia pianificazione dell'architettura e distribuzione delle "aree di competenza"....avete un repository dei sorgenti (TFS o SourceSave) ?

Davide Guida
Technical Architect @ Razorfish Healthware
http://davideguida.altervista.org
3.939 messaggi dal 28 gennaio 2003
Io uso sempre visual source safe, ma ho lavorato sempre da solo
145 messaggi dal 25 giugno 2010
Ciao Pietro,
questa "discussione" interessa moltissimo anche a me, domanda visual source safe è un pacchetto che si acquista a parte? oppure è gratuito o è integrato in qualche suite?
uso visual studio 2008
grazie mille
stefano
11.886 messaggi dal 09 febbraio 2002
Contributi
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.jpg

In fin dei conti, quello che ti consiglio è la metodologia di sviluppo agile.
http://it.wikipedia.org/wiki/Metodologia_agile
Sforzatevi 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

Enjoy learning and just keep making
11.886 messaggi dal 09 febbraio 2002
Contributi
intendolabolla ha scritto:
visual source safe è un pacchetto che si acquista a parte?


Lascia perdere Visual Source Safe. Io non ne ho esperienza diretta, ma so che è considerato uno tra i peggiori. Qualcuno una volta disse una cosa tipo: "Source Safe non è consigliato per team di 1 sviluppatori o più".
Esistono molte alternative gratuite & valide, ma se non vuoi scendere a compromessi, dai un'occhiata a Team Foundation Server di Microsoft, come mizrael aveva consigliato. E' una soluzione omnicomprensiva che si integra con Visual Studio; preparati a spendere cifra, però.
http://en.wikipedia.org/wiki/Team_Foundation_Server

Enjoy learning and just keep making
89 messaggi dal 13 marzo 2010
Personalmente mi sono trovato molto bene con SVN, esiste anche un plugin per VS
3.939 messaggi dal 28 gennaio 2003
Ringrazio tutti delle risposte. Ciao.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.