Bene, le domande si dicevano. Nel mio posto di lavoro si verificano questi casi, ma anche molti libri Agile promuovono il lavoro nello stesso posto di lavoro e sono concentrati nel progetto attuale per diventare più veloci nel ritmo del lavoro.
Forse non sono così informato sull'argomento, forse non è così severo ma, ecco perché volevo sapere cosa propone Agile in casi come questi.
Chiunque?
Nella metodologia Scrum influisce semplicemente sulla stima.
Assegneresti il fattore di fuoco per quella persona in base all'assegnazione del tempo a ciascun progetto.
Quindi, se sto lavorando su Progetto A e Progetto B allo stesso modo, il Progetto A calcolerebbe le risorse in questo modo:
Project A — Team focus factor of 70%
Sam - 10 days, 100% allocation (7 after focus factor)
Joe - 10 days, 100% allocation (7 after focus factor)
Me - 10 days, 50% allocation (3.5 after focus factor)
Total: 25 days * 70% focus factor = 17.5 projected velocity
Potresti anche calcolare il fattore di concentrazione separatamente per i membri del team a tempo pieno e per i membri del team part-time piuttosto che una volta per l'intero team, a causa della ridotta efficienza dei progetti di suddivisione. In questo caso, utilizzeresti il mio fattore di attivazione del progetto del 50% e moltiplicalo per una allocazione personale del 50% per il 25% o per 2,5 giorni proiettata velocità .
Quanto bene ciò funzioni nella pratica, sarà un fattore di quanto saprai in anticipo quanto tempo una risorsa condivisa sta spendendo in ciascun progetto e quanto bene Scrum sta lavorando per te in altri modi.
Nella mia esperienza in Scrum, la velocità può essere prevista solo se il progetto & il team rimane lo stesso e dedicato. Se una di queste cose cambia, non è possibile utilizzare i calcoli di velocità degli sprint precedenti per eseguire la stima. Puoi provare, ma sarai fuori da molto più di quanto faresti normalmente.
In generale, dovresti assolutamente cercare di mantenere la stessa squadra e amp; dedicato a meno di uno sprint, più se puoi.
A mio parere ciò influenzerà molto 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 il 33% di allocazione per ogni progetto, sai tutto ciò di cui hai bisogno e hai finito, ma non è vero.
Il cambio di contesto è molto costoso. Inoltre, mantenere il pieno impegno per più progetti paralleli è impossibile, quindi quelle percentuali del 33% del tempo di sviluppo sono lontane dal 33% quando lo sviluppatore è assegnato a un solo progetto.
Un altro posto dove questo totalmente fallisce è la comunicazione. Cosa succede se un membro del team che lavora attualmente al progetto A deve comunicare qualcosa con un membro del team che ha lavorato al progetto A ieri 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 del progetto A vuole che il suo sviluppatore ottenga informazioni il più rapidamente possibile e Scrum master del progetto B non vuole che il suo membro del team sia disturbato da qualcosa che non è correlato al progetto B. Se vuoi evitare questo devi pianificare tutto gli sviluppatori del team di lavorare sullo stesso progetto negli stessi giorni - questa è una grande complicazione dell'intero processo di pianificazione e qualcosa che dovrebbe essere completamente evitato.
Devi anche pianificare tutte le riunioni per non entrare in collisione. Devi anche capire che l'incontro è in realtà un rifiuto e, a causa di ciò, dovrebbe essere il numero minimo di riunioni il più breve possibile per mantenere il controllo sul processo. Ma se hai un membro del team che lavora su tre progetti, deve partecipare a tutti gli incontri per questi tre progetti = > tre volte più riunioni in cui lo sviluppatore non produce alcun valore commerciale.
Poiché la conclusione agile riguarda anche la riduzione degli sprechi (sì è dall'approccio Lean) e la condivisione dei membri del team tra i team è uno dei peggiori fallimenti in termini di introduzione di rifiuti e riduzione della produttività. Immagino che il valore di business consegnato per l'allocazione del 33% a un singolo progetto sarà pari al valore aziendale fornito dal 10-16% dell'allocazione a tempo pieno. Ciò significa che lo sviluppatore non parteciperà solo a 1/3 del progetto, ma durante quel periodo la sua produttività sarà compresa tra 1/3 e 1/2.
SCRUM si basa sul fatto di avere un team impegnato senza membri condivisi, quindi potresti anche chiedere:
Given we have been told we must make true == false, how do we do x
Se non è SCRUM, non chiamarlo SCRUM!
La domanda chiave riguarda l'impegno del membro del team per il progetto. Idealmente, un membro del team dovrebbe essere totalmente impegnato per il successo del progetto. Ciò non significa che il suo tempo sia totalmente dedicato al progetto, ma che sia disponibile a fare qualsiasi compito richiesto per il progetto quando sta lavorando al progetto.
Spesso con un personale che è solo part-time su un progetto, sono coinvolti solo per un ambito di impegno limitato. Ad esempio, potresti avere una persona che fa solo l'ottimizzazione del database.
In tal caso, spesso è meglio trattare quella persona come una "risorsa" anziché come membro di una squadra. Il team decide quanta parte di quella risorsa vorranno in un determinato Sprint e gli darà un insieme molto specifico di compiti da completare per lo Sprint. A volte è meglio che il Team abbia un particolare membro del team responsabile di quella risorsa, e faranno gli aggiornamenti di stato e il reporting di impedimento per quella risorsa nello Scrum quotidiano.
Credo che uno degli aspetti centrali di Scrum sia quello di mantenere il team focalizzato su una cosa sola 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 prendere in considerazione di provare uno di:
spero che questo aiuti!
Leggi altre domande sui tag project-management agile team scrum