Scrum team vs. team organizzati tradizionalmente [chiuso]

Question

A quelli di voi che hanno iniziato a usare la mischia nei propri team di sviluppo: avete mantenuto i team tradizionali o ne avete creati di nuovi? Nella nostra organizzazione siamo divisi in database, sviluppo di prodotti e sviluppatori frontend (semplificati!).

Sono interessato a sapere se altri hanno effettivamente riorganizzato l'intera struttura del team a causa della mischia o se hai formato team di progetto dedicati (?) combinando ad es. una persona per ogni "vecchio" squadra.

Answer 1

In realtà non riesco nemmeno a immaginare come potrebbe funzionare la mischia se mantieni i tuoi silos di ruolo. Nella mischia costruiamo sezioni verticali attraverso il prodotto in modo che ogni funzione fornita durante uno sprint richieda tutte le abilità che hai citato (oltre al QA che non hai fatto). Come creeresti una collaborazione continua e convincere le persone allo sprint se non fossero tutti nella stessa squadra? Sembra il modo più probabile per finire in "Scrumfall" per me. Non sono affatto un esperto, ma mi sembra che il modo sicuro di fallire in mischia sia di pensarlo come una soluzione di gestione del progetto anziché un intero cambiamento organizzativo. È culturale al centro.

Per rispondere alla tua domanda su " generalisti " ;. La risposta semplice è che avendo determinate persone in grado di lavorare solo su determinate cose si creano grandi strozzature grasse quando si arriva a Fatto. Con le specialità sei sempre costretto ad ogni passo avendo risorse limitate per lavorare su qualcosa. Nello sprint 1 potresti avere molto lavoro da fare in db dove c'è più di quello che un dba può fare. Ma poi nello sprint 5, dove non c'è alcun cambiamento nel modello di dati, il tuo dba resterà seduto annoiato. Diventa quasi impossibile nella pianificazione dello sprint impegnarsi in un tempo ragionevole se devi dividere e assegnare a livello di compito per ruolo invece di afferrare il prossimo set di caratteristiche prioritarie che si adattano alla velocità della tua squadra. Il modello generalista porterà inevitabilmente valore commerciale nel lungo periodo. Potresti non vederlo subito finché non raggiungi l'impollinazione incrociata.

Vorrei avvertire che se si è già in gruppi di silos per ruolo, allora bisogna stare molto attenti nella riorganizzazione agile. Molte persone non sono pronte e non vogliono essere pronte a perdere i loro titoli speciali e diventare semplicemente membri del team. Penso che dovresti aspettarti quasi sempre un certo volume di fatturato.

Answer 2

Si preferisce che nello sviluppo mischia / agile che la maggior parte degli individui nel team siano "generalisti", il che significa che chiunque può ragionevolmente ricoprire qualsiasi ruolo in modo che chiunque possa tirare fuori gli elementi nel backlog come il futuro e nessuno sta aspettando in giro altri.

ora questo potrebbe non essere il caso nella tua situazione odierna, ma fare cose come la programmazione tra pari e riunioni stand-up per vedere dove le persone stanno subendo impedimenti e per migliorare l'impollinazione incrociata delle conoscenze aiuterà a raggiungere questo obiettivo.

Answer 3

Nella mia azienda creiamo un team temporaneo per tutte le funzioni. I nostri team esistenti sono ancora lì, ma è davvero importante avere team interfunzionali per la mischia.

Answer 4

Generalmente proviamo a confondere un po 'per ottenere alcune conoscenze tra team, ma per la maggior parte lavoriamo sulle nostre specialità. Ma man mano che il progetto avanza, possiamo più facilmente dare una mano su diversi team

Answer 5

Quando ho lavorato per il mio precedente datore di lavoro, la società ha riprogrammato l'intera organizzazione degli sviluppatori e la gestione del prodotto. Hanno messo ingegneri, qa e analisti in ogni squadra. La divisione era principalmente verticale / funzionale con alcune eccezioni. Quelle eccezioni furono un errore: l'architettura verticale non si adattava, perché era davvero orizzontale. Pensavo che i team interfunzionali funzionassero bene. Nel tuo caso, i dipartimenti db e front-end devono fondersi con il resto, se possibile, e possono essere creati nuovi verticali specifici per il tuo prodotto

Answer 6

Abbiamo diviso il nostro team in Sviluppo di nuovi prodotti e Manutenzione di prodotti esistenti, con la possibilità per qualsiasi sviluppatore di passare da uno all'altro tra gli sprint.

Answer 7

Penso che abbiamo mantenuto la squadra tradizionale, almeno per ora. Ci sono un paio di altri team nel ramo delle applicazioni del dipartimento Sistemi informatici in cui lavoro, sebbene siano stati inseriti poco prima di entrare in Scrum.

C'è un grande progetto su cui sta lavorando la maggior parte di noi che sta usando Scrum e il team sembra evolversi bene. Abbiamo alcuni nuovi strumenti e processi che sembrano averci aiutato molto e ci hanno dato un senso di "bellezza". che speriamo di passare alle altre squadre.

Per le modifiche a un database, ognuno di noi sviluppatori può apportare la modifica nell'ambiente di sviluppo e quindi passare lo script a un DBA da eseguire quando è pronto per la produzione. Per le modifiche alla rete, ci sono persone che gestiscono l'infrastruttura e che inizialmente configurano un server in termini di O / S, rete, memoria, dischi rigidi, ecc.