Scaling Scrum all'interno di un gruppo di 100s di programmatori

3

La maggior parte dei team Scrum punta a 7-15 persone ******, anche se non è chiaro come aumentare lo Scrum tra 100 di persone, o come l'efficacia di una data squadra possa essere paragonata a un'altra squadra all'interno del gruppo; significato oltre a rompere il gruppo in team Scrum di 7-15 persone, non è chiaro come gli sforzi tra i team siano gestiti, confrontati, ecc.

Eventuali suggerimenti relativi a uno di questi argomenti o argomenti correlati aggiuntivi che potrebbero essere più importanti da prendere in considerazione nella pianificazione di un gruppo SCRUM su larga scala?

****** Nel riesaminare le ricerche relative alle dimensioni suggerite dei team di sviluppo software, che sembra essere la base per le dimensioni suggerite dal team Scrum, Ho trovato quello che sembra essere un errore nella ricerca che sembra stranamente mostrare che le squadre più grandi (15+ ppl), non le squadre più piccole (7 ppl) sono migliori.

UPDATE, "Re: Scrum non scala": ha fatto enormi progressi nel ricercare personalmente l'argomento, ma ho pensato che avrei risposto alla convinzione generale di alcuni che Scrum non scala citando una citazione da Avere successo con Agile di Mike Cohn :

Scrum Does Scale: You have to admire the intellectual honesty of the earliest agile authors. They were all very careful to say that agile methodolgies like Scrum were for small projects. This conservatism wasn’t because agile or Scrum turned out to be unsuited for large projects but because they hadn’t used these processes on large projects and so were reluctant to advise their readers to do so. But, in the years since the Agile Manifesto and the books that came shortly before and after it, we have learned that the principles and practices of agile development can be scaled up and applied on large projects, albeit it with a considerable amount of overhead. Fortunately, if large organizations use the techniques described regarding the role of the product owner, working with a shared product backlog, being mindful of dependencies, coordinating work among teams, and cultivating communities of practice, they can successfully scale a Scrum project.

SOURCE: (ran across the book thanks to Ladislav Mrnka answer)

    
posta blunders 28.03.2012 - 13:25
fonte

4 risposte

8

Non è possibile avere una mischia efficace con un gruppo così grande. Anche con venti-qualcosa inizi a lottare. Devi dividere queste 100 persone in gruppi di attività molto più piccoli, che ogni gruppo ha la sua mischia. Quindi puoi avere una mischia di dirigenti / rappresentanti di team. Questo è noto come la mischia delle mischie.

    
risposta data 28.03.2012 - 13:31
fonte
6

Scrum è pensato per piccoli gruppi, perché gli autori di scrum hanno scoperto che i piccoli gruppi auto-organizzati tendevano a essere molto efficaci nella loro esperienza. Questo ha senso se si considera il principio di lean che i passaggi mancano e le squadre più grandi tendono a richiedere hand-off.

La visione generale su come gestire gruppi più grandi consiste nel creare una "mischia di mischie", nel qual caso ciascuna squadra affronta il proprio sottoprogetto, e quindi un membro di ciascuna squadra rappresenta il sottoprogetto in una squadra di rappresentanti simili provenienti da altri sottoprogetti. Questo si ridimensiona come una piramide:

           MT (Master Team for full project)
          /|\
         / | \
        /  |  \
      T1   T2  T3 (Teams of Sub-projects)
     /|\
    / | \
   /  |  \
 ST1 ST2 ST3 (Teams of sub-sub-projects)

Il coordinamento di questo genere di cose è complicato, ma è stato fatto. La nozione di efficacia può essere vista attraverso la visibilità inerente a scrum-burn down e simili.

In realtà, se il tuo progetto è così grande che hai bisogno di centinaia di sviluppatori, le probabilità sono contro di te. Devi decomporlo in progetti realizzabili che possano essere capiti da chi li sta lavorando.

    
risposta data 28.03.2012 - 14:12
fonte
3

Se hai un singolo progetto con centinaia di persone e vuoi passare direttamente all'agile e specialmente a Scrum, probabilmente stai eseguendo un suicidio del progetto.

Lo sviluppo agile e Scrum sono abilità come tutte le altre. Se vuoi usarlo devi iniziare con un piccolo progetto. Una volta che hai padroneggiato un piccolo progetto, puoi iniziare il ridimensionamento con piccoli passaggi. Il modo migliore per dire che agile non funziona è convertire un grande progetto dall'approccio basato su piano all'approccio agile senza alcuna esperienza precedente con il ridimensionamento agile.

Scalare agile significa incorporare metodi guidati da piani a livello superiore. Non puoi scalare Scrum all'infinito. Più lo ridimensionhi e più sarà necessario il meccanismo di pianificazione. C'è qualcosa chiamato Scrum of Scrum ma è esattamente qualcosa che puoi fare solo se impari puro Scrum con una piccola squadra. Scrum of Scrum ha anche i suoi limiti - immagino qualcosa come 5-6 squadre / fino a 40 persone.

Modifica:

L'ultima ipotesi proviene da molte fonti, tra cui corsi di formazione CSM e CSPO, libri come Avere successo con Agile e Agilità e disciplina di bilanciamento e la mia esperienza personale quando partecipano sia al piccolo team Scrum (fino a 5 persone) che al team più grande con più di 15 persone divise in tre squadre che lavorano sullo stesso progetto. Più grande è il progetto, più l'agilità a livello superiore sarà sostituita da alcune vecchie tecniche di pianificazione.

Anche l'allenatore del mio addestramento CSM ha affermato che il ridimensionamento di Scrum è una delle maggiori sfide che lo Scrum stesso deve affrontare.

    
risposta data 28.03.2012 - 14:09
fonte
1

Quasi tutte le metodologie Agile sono progettate per piccoli team, parlano sempre di comunicazione come aspetto primario del metodo, e più una squadra diventa più difficile diventa comunicazione efficace.

Alistair Cockburn (uno dei padri fondatori di Agile) ha una metodologia chiamata Crystal che ha aspetti diversi a seconda delle dimensioni del team. Queste linee guida differiscono leggermente, ma continuano ad attenersi ai principi Agile.

Un'alternativa è AUP , che è 'parte Agile' e più adatta anche per grandi gruppi.

    
risposta data 29.03.2012 - 00:07
fonte

Leggi altre domande sui tag