Quali sono alcuni concetti chiave per team di sviluppo efficaci? [chiuso]

Question

Dove lavoro di recente abbiamo messo insieme quello che chiamiamo il Comitato per gli standard di sviluppo che ha il compito di migliorare le nostre procedure, processi, metodologie, strumenti, standard e qualunque cosa pensiamo possa aiutarci a diventare un team più efficace.

Abbiamo un foglio di calcolo che abbiamo classificato e che inizieremo ad affrontare dall'alto verso il basso. Abbiamo cose come un migliore controllo del codice sorgente (attualmente su SourceSafe), implementare un tracker bug (come Mantis of FogBugz), revisione del codice peer, passare a .Net 3.5, possibilmente passare a qualche forma di Agile, fare squadra più reale sviluppo piuttosto che singolo sviluppatore per tipo di progetto, e alcune altre cose ...

Quali pensi siano alcune cose chiave che possono creare o distruggere un team di sviluppo? Cosa dovremmo aggiungere a questo elenco?

Alcune informazioni aggiuntive: abbiamo circa 12 persone nel nostro team di Windows e circa cinquanta in sviluppo se includi tutte le piattaforme. Vogliamo migliorare il più possibile per tutti, ma il nostro obiettivo principale è il team di Windows. Tutti noi siamo qui da almeno un paio d'anni, quindi molti di noi si conoscono e lavorano abbastanza bene insieme.

Answer 1

Il numero di persone nella tua squadra è davvero molto importante qui. Ci sono cose di base che ogni squadra dovrebbe implementare (controllo del codice sorgente, tracciamento dei bug, ecc.), Ma ci sono cose che sono di base diverse per dimensione della squadra. Le revisioni del codice in un team molto piccolo, ad esempio, possono essere più informali.

Passare ad Agile è una buona idea, a meno che il tuo particolare ambiente di sviluppo non la renda una cattiva idea. Inoltre, non sarai in grado di farlo senza il supporto delle persone che utilizzano il tuo software.

Valuta di fare qualcosa per garantire che la comunicazione tra il team sia più semplice e con meno blocchi stradali: tutti i tuoi membri si conoscono abbastanza bene? Puoi lavorare l'uno con l'altro? Comprendi le reciproche idiosincrasie? Imparare a lavorare in gruppo è molto più importante di qualsiasi miglioramento di processo casuale che puoi apportare.

Answer 2

Richiedi commenti quando esegui il check-in del codice (è fantastico se riesci a legare i commit al tuo bug tracker)

Forse l'analisi del codice statico, come quella incorporata in Visual Studio

Integrazione continua come CruiseControl

Answer 3

I team di sviluppo hanno davvero bisogno di persone buone per cominciare, che lavorino bene insieme, ma questo non è davvero un elemento da aggiungere all'elenco. Tuttavia, influisce sulla mia prima raccomandazione, siate pragmatici. Se non stai incoraggiando i tuoi sviluppatori a pensare a come funzionano e possono spingere se stessi a migliorare, è davvero difficile stabilire un ambiente di sviluppo che lo farà per loro.

Mentore e formazione: se non puoi fare XP, almeno collega i tuoi Juniors con gli anziani ogni volta che puoi. Non solo condividerai le tue conoscenze, ma condividerai anche il contesto attorno ai tuoi progetti.

Answer 4

Una sorta di integrazione continua e rilasci regolari, testati, funzionanti " fare meraviglie per la qualità.

Answer 5

  

come miglior controllo del codice sorgente (attualmente su SourceSafe)

Se si tratta di Visual SourceSafe, è necessario modificarlo immediatamente. Prova cvs, svn o anche qualcosa pagato come Perforce.

Esiste qualcosa chiamato Rational Unified Process che affronta il tuo problema (e molto altro) .