Unified Team Dev Environment

Question

Unified Team Dev Environment

#1 da (1 voti)

0

Dove lavoro abbiamo un numero di team che si stanno convertendo in un ambiente di sviluppo del team. Fondamentalmente un paio di membri del team stanno mettendo insieme un'immagine che viene poi installata sul computer di tutti. Include un sistema operativo, un IDE (con controllo del codice sorgente gestito da esso), un paio di sistemi server necessari per il test e un'immagine del server di test. Apparentemente l'immagine viene compilata sulla base dell'input di tutti, quindi tutti sono, di nuovo, apparentemente, felici con l'ambiente in questione.

I leader del team affermano che questo sarà più efficiente perché ogni volta che qualcuno ha un problema, tutti gli altri membri del team possono aiutarlo a risolverlo (al contrario, ad esempio, degli altri 2 che stanno ancora utilizzando vim ). allo stesso tempo, sembra che questo approccio avrebbe un effetto negativo sulle persone che non eccellono nel lavorare nel paradigma delle maggioranze.

Quindi la mia domanda è questa: il trade off vale la pena? I guadagni del "supporto del team" che probabilmente supereranno l '"efficienza individuale" vengono persi? Tangenzialmente, c'è un punto a metà? Forse se tutti avessero lo stesso sistema operativo e la stessa immagine del server ma avessero IDE diversi, potrebbe essere meglio?

teamwork development-process

posta Jay Carr 24.04.2014 - 14:56

fonte

1 risposta

Leggi altre domande sui tag teamwork development-process

Cosa succede all'interno della panoramica dell'architettura di una specifica di progetto? Modelli multipli o un singolo modello con più tipi di dati personalizzati?

score 1 · Accepted Answer

Dove lavoro usiamo la stessa politica - una immagine principale , che è installata su tutti i computer di sviluppo (nel nostro caso windows, visual studio con plugin come R #, ghost doc, editor, regex strumenti e così via).

Non penso che nessuno dei membri del nostro team abbia mai avuto qualche inconveniente che abbia trascurato la politica dell'immagine, al contrario:

abbiamo la stessa struttura di directory per i nostri mapping di progetto, quindi i riferimenti locali nei codici sorgente sono sempre gli stessi
abbiamo le stesse impostazioni per le applicazioni
abbiamo gli stessi mapping dei tasti, quindi cambiare i luoghi di lavoro (se necessario o, ad esempio, per fare la programmazione della coppia) non influirà sulla nostra produttività
cambiare l'hardware non sarà un cambiamento irrisorio per qualsiasi membro dev
se qualcuno ha bisogno di aiuto, ad esempio l'estensione di un'espressione regolare, la regex per email sarà sufficiente, tutti hanno lo stesso strumento per testare
gli stessi aggiornamenti (del prodotto) si applicano su ogni macchina / macchina sono sincronizzati
questo significa anche lo stesso comportamento su tutte le macchine (che bello se fosse vero: -)

Dall'altro lato, possiamo sempre regolare / estendere alcune impostazioni risp. aggiungi nuovo software localmente

ad esempio ho aggiunto le mie proprie # keymappings
ero da tanto tempo (circa 1 anno o giù di lì) l'unico utilizzando / con LINQPad

IMO abbiamo un grande vantaggio da questa politica e non vedo come this approach would have a negative effect on people who don't excel at working in the majorities paradigm .

Al momento abbiamo due tirocinanti che sono iniziati circa 6 mesi fa. Dal momento che per loro tutto è nuovo, imparare gli stessi strumenti e le scorciatoie che usiamo non è una cattiva abitudine. Un giorno (dopo aver saputo come tutto funziona e può essere impostato) possono sempre decidere di definire le proprie impostazioni e / o provare nuovi e diversi strumenti.

Il individual efficiency loss può essere IMO trascurato - la stessa policy immagine può essere confrontata IMO con le linee guida per la codifica - il team è più efficiente, quando tutti hanno lo stesso stile e anche tutti si adattano un po ' . Dopotutto è anche un processo di apprendimento continuo.