Gli sviluppatori rotanti di un progetto sono un'idea buona o cattiva?

Sono sorpreso che tutti pensino che questa sia una buona cosa. Gli autori di Peopleware (che, IMO, è ancora uno dei pochi preziosi software libri di project management in realtà vale la pena di leggere) non sono assolutamente d'accordo. Quasi l'intera parte IV del libro è dedicata proprio a questo problema.

Il team del software è un'unità funzionale incredibilmente importante. I team hanno bisogno di essere jell per diventare veramente produttivi. Ci vuole tempo (un lotto di tempo) per i membri del team per guadagnarsi il rispetto gli uni degli altri, per imparare le reciproche abitudini e peculiarità, punti di forza e punti deboli.

Certamente, per esperienza personale, posso dire che dopo un anno di lavoro con certe persone, ho imparato a ridere di certe cose che prima mi infastidivano, le mie stime come team leader sono molto migliori, e non è troppo difficile da distribuire il lavoro in modo da rendere tutti felici. All'inizio non era così.

Ora potresti dire "Oh, ma non stiamo rompendo l'intera squadra, spostando solo poche persone". Considerate (a) quanto i loro sostituzioni saranno ciecamente improduttivi all'inizio, e (b) quante volte vi troverete o altre squadre che dicono, senza nemmeno pensare, " Mi piaceva molto X " o " Sarebbe stato più facile con Y ancora in giro ", sottilmente e inconsciamente offendendo i nuovi membri e creando scismi all'interno della squadra esistente, seminando persino scontento tra i" vecchi "membri.

Le persone non fanno questo di proposito , ovviamente, ma succede quasi sempre. Le persone lo fanno senza pensare. E se si costringono a non farlo, finiscono per concentrarsi ulteriormente sulla questione, e sono frustrati dal silenzio forzato. Squadre e persino sottogruppi svilupperanno sinergie che si perderanno quando si scopre con la struttura. Gli autori Peopleware lo chiamano una forma di "teamicidio".

Detto questo, anche se la rotazione dei membri del team è una pratica orribile, la rotazione dei team stessi è perfetta. Sebbene le società di software ben gestite debbano avere un concetto di proprietà del prodotto, non è altrettanto fastidioso per un team spostare l'intero team in un progetto diverso, a condizione che il team finisca effettivamente per completare il vecchio progetto o almeno lo porti a un livello di cui sono felici.

Avendo std di team invece di stipendi developer , ottieni tutti gli stessi benefici che ti aspetteresti di ottenere con gli sviluppatori rotanti (documentazione, "impollinazione incrociata", ecc. .) senza nessuno dei brutti effetti collaterali su ogni squadra come unità. A chi non capisce veramente la gestione, può sembrare meno produttivo, ma è certo che la produttività persa dividendo la squadra è assolutamente nana della produttività persa spostando quella squadra in un progetto diverso.

P.S. Nella tua nota in calce dici che il lead tecnologico potrebbe essere la solo persona non da ruotare. Questo è praticamente garantito per rovinare i team entrambi . Il leader tecnologico è un leader, non un manager, deve guadagnarsi il rispetto della squadra e non è semplicemente autorizzato dall'autorità da parte di livelli superiori di gestione. Mettere un intero team sotto la direzione di un nuovo lead con il quale non hanno mai lavorato e che ha molte probabilità di avere idee diverse su architettura, usabilità, organizzazione del codice, stima ... beh, sarà stressante come l'inferno per il protagonista cerca di costruire credibilità e molto improduttivo per i membri del team che iniziano a perdere coesione in assenza del loro vecchio vantaggio. A volte le aziende hanno per farlo, cioè se il lead si licenzia o viene promosso, ma farlo con choice suona pazzo.

Non vedo molto di un rovescio qui io stesso. La rotazione ti dà:

• Cross impollinazione delle conoscenze istituzionali - tutti conosceranno il progetto legacy e il nuovo, almeno in teoria.
• Cross training: diversi progetti richiedono spesso cose diverse. Cresci molto più come uno sviluppatore che lavora in progetti brutti e legacy che in progetti greenfield puliti e puliti.
• Progetti fondamentalmente migliori - non è come avere una nuova squadra in arrivo per farti finire la documentazione e ripulire i brutti processi con cui sei disposto a convivere ma che non ammetti pubblicamente.
• Codice migliore: più teste sono migliori nella maggior parte dei casi.
• Miglioramenti morali del morale: la varietà è il sale della vita. E chi vuole rimanere bloccato nella fissazione di bug di progetto legacy / taping in modo permanente. Inoltre tieni presente che il tuo "nuovo" progetto diventerà legacy ad un certo punto, vuoi rimanere bloccato lì per sempre?

Probabilmente l'unico svantaggio è il calo di produttività che si ottiene dai punti di cambio, ma che dovrebbe fare solo male al primo giro. Successivamente entrambe le parti avranno un tempo di seduta in entrambi i posti e le parti brutte del trasferimento saranno probabilmente meglio comprese e forse risolte.

È interessante notare che nella mia esperienza abbiamo spesso avviato i nostri progetti con questo intento. In futuro abbiamo spesso omesso di agire in base a questo intento a causa dei vincoli sul nuovo progetto e della convinzione che il cross training sia troppo costoso.

Mi auguro sempre che ci siamo riusciti anche se, a lungo termine, credo che sia vantaggioso per tutte le parti: team, società, clienti e Software. I 2/3 mesi sembrano durare abbastanza a lungo che non vi è un rischio limitato di gravi conseguenze negative, non vi è alcun cambio di contesto in corso per gli sviluppatori coinvolti, tranne nel momento del passaggio all'ora in cui possono dedicarsi al progetto alternativo. / p>

Un paio di possibili vantaggi non menzionati:

• Migliore gestione dei progetti. Se i project manager di entrambi i progetti sono a bordo, è il loro miglior interesse lavorare sodo in modo che i periodi di transizione non siano dolorosi per entrambi i progetti. Questo è il turno (a seconda della configurazione) potrebbe rendere più stretta la collaborazione tra i PM e i team di sviluppo.
• Migliore documentazione (proattiva). Se sai che stai entrando e uscendo da un progetto, non è solo nell'interesse del progetto, il miglior interesse delle aziende, le migliori pratiche in generale, ma ora in ogni sviluppatore è proprio il miglior interesse a rendere la vita facile mentre rimbalzano intorno.
• La questione morale è un grosso problema, se i tuoi sviluppatori non ne hanno abbastanza di essere bloccati su un progetto precedente, allora potrebbero non essere gli sviluppatori che desideri! Se li hanno, cambiandoli e facendo in modo che altri sviluppatori lavorino li faranno sentire l'amore per la tua azienda - potrebbero solo riordinare i pezzetti di codice che pensavano che nessuno avrebbe mai visto. I sistemi legacy sono spesso visti come progetti di seconda classe che spesso vanno a loro detrimento, forse in questo modo aiutate a cambiare quella percezione a

La rotazione è una buona cosa per l'azienda e può essere una buona cosa anche per gli sviluppatori.

Ci sono molte buone ragioni e Wyatt ne ha menzionate molte nella sua risposta.

Detto questo, nella tua situazione, potresti trovarlo quando lo introduci, gli sviluppatori che stanno spostando il nuovo progetto sul progetto precedente potrebbero non essere felici, quindi c'è bisogno di comunicare molto chiaramente perché questo sta accadendo e quanto è lungo, e il piano va avanti.

Potrebbe essere utile pensare di non scambiare le squadre all'ingrosso per iniziare e ruotare 1 o 2 sviluppatori per iniziare, anche se questo potrebbe sembrare come individuare persone per una retrocessione (che alcune persone potrebbero vedere).

Concordare con Aaronaught è molto strano vedere quante persone non vedono solo i lati negativi .. Pochi pensieri sbagliati, che puoi puntare molto velocemente: il codice non ha il proprietario e quando tutti sono responsabili di tutto ciò non è buono per la qualità. Gli sviluppatori non sono risorse (anche loro sono chiamati così spesso dai manager), sono persone e per la squadra è molto importante conoscersi, la rotazione fa un po 'di caos lì. Se lavori per qualche progetto più a lungo diventerai un esperto (non solo nel dominio, ma in quel progetto), saprai da dove viene la maggior parte dei problemi, chi ti darà le risposte migliori o forse qualche conoscenza di dominio più specifica, ecc. Se sei nuovo, dovrai imparare tutto questo, quindi rallenterà i progressi. Ma ovviamente è anche utile conoscere altre pratiche della tua organizzazione, come gli altri team costruiscono e organizzano. È particolarmente utile se i progetti sono correlati in qualche modo, ad esempio un progetto viene inserito in un altro (non necessario direttamente), in modo da ottenere una migliore comprensione del quadro generale. E naturalmente la diffusione della competenza è buona (se avrai tempo per ottenere queste conoscenze).

TL; DR Crea una squadra e poi è un team che supporta 2 progetti.

Per echo @Aaronaught penso che i team di mixaggio possano essere problematici in quanto potrebbe richiedere del tempo per acclimatarsi a nuove pratiche, processi, ecc. Se giri troppe persone in fretta, il team perderà la sua identità. Questo porta a più domande, confusione e tempo trascorso a cercare di recuperare quell'identità.

D'altra parte, se c'è uno sforzo concertato per unire le 2 squadre in una squadra e avere 1 team di supporto 2 progetti, penso che funzioni alla grande finché la squadra non è troppo grande. Ho fatto parte di numerosi team che supportano più progetti. Più vicini sono i 2 progetti tecnologici, più facile sarà la transizione. Nella mia esperienza, il costo più elevato nella transizione da un progetto a un altro avviene incrociando lingue, client / server (in particolare GUI), industria (medica, web, giochi) o altre linee simili. Il trucco è far sì che persone diverse lavorino al progetto abbastanza frequentemente per ottenere i benefici, ma non così spesso che i costi di transizione superano i benefici.

Quindi i benefici per ottenere più persone in un progetto sono abbastanza noti, così come i costi.

La rotazione dei programmatori è una buona cosa dal punto di vista dell'azienda e dal punto di vista dello sviluppatore.

Dalla prospettiva dell'azienda

1. La gestione conoscerà, la forza e la debolezza di un particolare sviluppatore, se possono gestire il multitasking o meno e adattarsi alle modifiche.
2. Se alcuni sviluppatori lasciano la società per qualche motivo, la società dispone già di un backup pronto per il futuro.
3. Migliorerà le prestazioni del progetto, dato che molte persone lavoreranno su di esso, la stessa cosa verrà testata da un numero sempre maggiore di sviluppatori. (Testare lo spreco di risorse ridotto al minimo)
4. Tutti i membri del team lavorano in team e aumenteranno le prestazioni del progetto e in futuro la gestione verrà a sapere, che tipo di squadra deve essere fatto durante l'implementazione di moduli o attività difficili.

Da potenziale sviluppatore

1. Renderà lo sviluppatore più positivo mentre aumenta la sua fiducia.
2. Gli sviluppatori ottengono idee migliori e migliori dagli altri membri del team e possono usare queste tecniche per lo sviluppo futuro.
3. Da idee e suggerimenti migliori di altri membri del team aumenta la produttività degli sviluppatori.

Solo una cosa principale, è necessario tenere presente che

La rotazione dei programmatori non dovrebbe accadere molto frequentemente. dopo il 60% - 70% di sviluppo fatto, allora solo lo spostamento sarà vantaggioso.