In che modo SCRUM gestisce un ambiente in cui i membri del team sono condivisi?

Bene, le domande si sono dette. Nel mio posto di lavoro accadono questi casi, ma anche molti libri Agile promuovono di lavorare nello stesso posto di lavoro e di essere concentrati nel progetto attuale per diventare più veloci nel ritmo del lavoro.

Forse non sono così informato sull'argomento, forse non è così rigoroso, ma è per questo che volevo sapere cosa propone Agile in casi come quelli.

Chiunque?

Nella metodologia Scrum influisce semplicemente sulla stima.

Assegneresti il ​​fattore di concentrazione per quella persona in base all'assegnazione del tempo a ciascun progetto.

Quindi, se sto lavorando sul progetto A e sul progetto B allo stesso modo, il progetto A calcolerebbe le risorse in questo modo:

Progetto A - Fattore di messa a fuoco del team del 70%
Sam - 10 giorni, allocazione del 100% (7 dopo il fattore di messa a fuoco)
Joe - 10 giorni, allocazione del 100% (7 dopo il fattore di messa a fuoco)
Me - 10 giorni, allocazione del 50% (3,5 dopo il fattore di messa a fuoco )
Totale: 25 giorni * 70% fattore di messa a fuoco = 17,5 velocità proiettata

È inoltre possibile calcolare il fattore di concentrazione separatamente per i membri del team a tempo pieno e per i membri del team a tempo parziale anziché una volta per l'intero team, a causa della ridotta efficienza derivante dalla suddivisione dei progetti. In questo caso, utilizzeresti il fattore di messa a fuoco del mio progetto del 50% e lo moltiplicheresti per un'allocazione personale del 50% per il 25% o velocità proiettata di 2,5 giorni .

Quanto bene funzionerà in pratica, sarà un fattore di quanto sai in anticipo quanto tempo una risorsa condivisa impiegherà per ogni progetto e quanto Scrum sta lavorando per te in altri modi.

Nella mia esperienza in Scrum, la velocità può essere prevista solo se il progetto e il team rimangono gli stessi e dedicati. Se una di queste cose cambia, non puoi davvero usare i calcoli di velocità degli sprint precedenti per fare la tua stima. Puoi provare, ma sarai fuori molto più di quanto faresti normalmente.

In generale, dovresti assolutamente provare a mantenere la squadra uguale e dedicata a LEAST durante uno sprint, più se puoi.

A mio avviso, ciò avrà un impatto molto grave su tutti i progetti. Non si tratta solo di stimare o pianificare. Sì, puoi dire che se i membri del team sono assegnati a tre progetti e hanno una dotazione del 33% per ogni progetto, sai tutto ciò di cui hai bisogno e hai finito, ma non è vero.

Il cambio di contesto è molto costoso. Anche mantenere il pieno impegno per più progetti paralleli è impossibile, quindi quelle percentuali del 33% del tempo degli sviluppatori sono molto lontane dal 33% quando lo sviluppatore è assegnato a un solo progetto.

Un altro posto in cui questo fallisce totalmente è la comunicazione. Cosa succede se un membro del team che sta attualmente lavorando al progetto A deve comunicare qualcosa con un membro del team che ha lavorato ieri al progetto A ma attualmente sta lavorando al progetto B? Questo è un impedimento per entrambi perché il primo ha bisogno di informazioni ma il secondo è concentrato su un progetto completamente diverso e qualsiasi domanda per il progetto A lo disturba. Scrum master dal progetto A vuole che il suo sviluppatore ottenga le informazioni il più velocemente possibile e Scrum master dal progetto B non vuole che il suo membro del team sia disturbato da qualcosa di non correlato al progetto B. Se vuoi evitare questo, devi pianificare tutto gli sviluppatori del team lavorano allo stesso progetto entro gli stessi giorni, il che è una grande complicazione per l'intero processo di pianificazione e qualcosa che dovrebbe essere completamente evitato.

È inoltre necessario pianificare tutte le riunioni per non scontrarsi. È inoltre necessario comprendere che la riunione è in realtà uno spreco e per questo motivo dovrebbe esserci un numero minimo richiesto di riunioni il più breve possibile per mantenere il controllo del processo. Ma se hai un membro del team che lavora su tre progetti, deve partecipare a tutte le riunioni per quei tre progetti => tre volte più riunioni in cui lo sviluppatore non produce alcun valore aziendale.

Come conclusione agile si tratta anche di ridurre gli sprechi (sì, deriva dall'approccio Lean) e condividere i membri del team tra i team è uno dei peggiori fallimenti in termini di introduzione di rifiuti e riduzione della produttività. Immagino che il valore aziendale erogato per l'allocazione del 33% in un singolo progetto sarà uguale al valore aziendale erogato dal 10-16% dell'allocazione a tempo pieno. Ciò significa che lo sviluppatore parteciperà non solo 1/3 del progetto, ma durante quel periodo la sua produttività sarà compresa tra 1/3 e 1/2.

SCRUM si basa sull'avere un team impegnato senza membri condivisi, quindi potresti anche chiedere:

Dato che ci è stato detto che dobbiamo rendere true == false, come facciamo x

Se non è SCRUM, non chiamarlo SCRUM!

La domanda chiave riguarda l'impegno del membro del team nel progetto. Idealmente, un membro del team dovrebbe impegnarsi totalmente per il successo del progetto. Ciò non significa che il suo tempo sia totalmente dedicato al progetto, ma che sia disponibile a fare qualsiasi attività richiesta per il progetto quando sta lavorando al progetto.

Spesso con il personale che è solo part-time in un progetto, sono coinvolti solo per un ambito di impegno limitato. Ad esempio, potresti avere una persona che esegue solo l'ottimizzazione del database.

In tal caso, è spesso meglio trattare quella persona come una "risorsa" anziché come un membro del team. Il team decide quanta parte di quella risorsa vorrà in un determinato Sprint e gli fornisce una serie molto specifica di compiti da completare per lo Sprint. A volte è meglio se il Team ha un particolare membro del team responsabile di quella risorsa e eseguirà gli aggiornamenti dello stato e la segnalazione degli impedimenti per quella risorsa nella Scrum quotidiana.

Credo che uno degli aspetti chiave di Scrum sia quello di mantenere il team concentrato su una cosa alla volta (un progetto, una storia, un compito ...)

Hai chiesto "cosa propone Agile" nella situazione in cui non puoi allocare le risorse a un progetto ... Potresti considerare di provare uno di:

• Mantieni una grande scheda Kanban che si estende su più progetti. Poiché un progetto ha bisogno, viene aggiunto alla lavagna, poiché le persone hanno capacità, tirano fuori le storie chiave. Il problema è che tutti i progetti vengono gestiti insieme, il che riduce la prevedibilità complessiva per ogni singolo progetto. Detto questo, la storia individuale / gli elementi Kanban verranno tirati e sviluppati da una persona o una squadra focalizzata. (Potresti provare a creare squadre di 4-5 persone più piccole da estrarre dalla scheda Kanban
• Assegnare solo risorse impegnate. Mantenere un pool di risorse dedicate per un progetto. Questi sono protetti come una squadra e le interruzioni sono mantenute vicino allo zero. Mantenere anche un "team di risposta rapida" che non ha un arretrato e non ha un focus sul progetto / prodotto. Quando si verificano interruzioni, il team di risposta rapida si occupa delle interruzioni. Quando non hanno interruzioni, possono concentrarsi sul miglioramento del sistema di compilazione, sull'aggiunta al framework dei test di automazione, ecc. Inoltre, possono aiutare con revisioni del codice / revisioni del progetto e risoluzione dei problemi che possono insorgere. Gestisci lo sviluppo come se questa squadra non esistesse. Tutto quello che possono fare è ritirare la consegna. Ruota le persone attraverso questo team per "mantenerlo fresco" (alla gente sembra piacere / odiare far parte del team di risposta rapida ...)

spero che sia di aiuto!