Sono sorpreso che tutti pensino che sia una cosa così buona. Gli autori di Peopleware (che, IMO, è ancora uno dei pochi preziosi libri sulla gestione di progetti software che vale davvero la pena di leggere) sono fortemente in disaccordo. Quasi l'intera parte IV del libro è dedicata proprio a questo problema.
Il team del software è un'unità funzionale incredibilmente importante. Le squadre devono gelarsi per diventare veramente produttive. Ci vuole tempo ( molto tempo) per i membri del team per guadagnarsi il rispetto reciproco, per imparare le reciproche abitudini e stranezze e punti di forza e di debolezza.
Certamente, per esperienza personale, posso dire che dopo un anno di lavoro con alcune persone, ho imparato a ridere di alcune cose che mi legavano, le mie stime come capo squadra sono molto migliori, e non è troppo difficile distribuire il lavoro in modo da rendere tutti felici. All'inizio non era così.
Ora potresti dire: "Oh, ma non stiamo facendo a pezzi l'intera squadra, spostando solo poche persone". Ma considera (a) quanto ciecamente improduttivi saranno i loro sostituti all'inizio, e (b) quante volte troverai te stesso o altre squadre che dicono, senza nemmeno pensare, "Mi è davvero piaciuta X" o "Questo avrebbe è stato più facile con Y ancora in circolazione " , offensivo sottilmente e inconsciamente i nuovi membri e creando scismi all'interno della squadra esistente, seminando persino malcontento tra i" vecchi "membri.
Le persone non lo fanno apposta , ovviamente, ma succede quasi ogni volta. Le persone lo fanno senza pensare. E se si sforzano di non farlo, finiscono per concentrarsi ancora di più sulla questione e sono frustrati dal silenzio forzato. Squadre e persino sotto-team svilupperanno sinergie che si perdono quando si fa il giro della struttura. Gli autori di Peopleware lo definiscono una forma di "teamicidio".
Detto questo, anche se i membri del team di rotazione sono una pratica orribile, i team di rotazione stessi vanno benissimo. Sebbene le società di software ben gestite debbano avere un concetto di proprietà del prodotto, non è altrettanto dirompente per un team spostare l'intero team in un progetto diverso, purché il team riesca effettivamente a finire il vecchio progetto o almeno portarlo a un livello di cui sono contenti.
Avendo restrizioni di squadra invece di restrizioni di sviluppatore , ottieni tutti gli stessi benefici che ti aspetteresti di ottenere con gli sviluppatori a rotazione (documentazione, "impollinazione incrociata", ecc.) Senza effetti collaterali negativi su ogni squadra come unità. A coloro che non capiscono veramente la gestione, può sembrare meno produttivo, ma state certi che la produttività persa dividendo il team riduce completamente la produttività persa spostando quel team in un altro progetto.
PS Nella tua nota a piè di pagina menzioni che il capo tecnico potrebbe essere l' unica persona a non essere ruotata. Questo è praticamente garantito per incasinare entrambe le squadre. Il responsabile della tecnologia è un leader, non un manager, deve guadagnarsi il rispetto della squadra e non è semplicemente concesso l'autorità da livelli più alti di gestione. Mettere un intero team sotto la direzione di un nuovo lead con cui non hanno mai lavorato e con cui è molto probabile che abbiano idee diverse su cose come architettura, usabilità, organizzazione del codice, stima ... beh, sarà stressante da morire per il vantaggio cercando 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 hannoper fare questo, cioè se il lead si chiude o viene promosso, ma farlo per scelta sembra folle.