Gli studi di casi sono un modo efficace per convincere i membri del team focalizzati sull'efficienza a voler scambiare un po 'di efficienza per la qualità? [chiuso]

Setting aside such issues, are case-studies (of other teams' effective uses of Scrum) an effective way of swaying reluctant team members? (particularly on the issue of efficiency) Or, is there something better than case-studies?

Gli studi di casi sono davvero un cattivo sostituto dell'esperienza generale e anche se le persone li leggono, probabilmente non farà alcuna differenza.

Il tuo problema è uno degli obiettivi successivi. Un team di Scrum è in grado di pensare solo in termini di recupero di articoli nel backlog su cui si deve lavorare. Sono anche lungimiranti in modalità "Sprint Zero", dove stanno pianificando il progetto in generale, il design di alto livello e gli sviluppi ambientali. È così.

Tutto il resto dovrebbe essere un obiettivo a breve termine per il team di scrum, completando il prossimo sprint all'accettazione del proprietario del prodotto.

Se i membri del tuo team stanno pensando a rielaborazioni successive, allora hanno ragione di sollevarlo come preoccupazione durante Sprint Planning, ma la decisione di portarlo nello sprint si basa esclusivamente sul Product Owner. La rilavorazione è solo una preoccupazione quando il Product Owner lo considera un problema, ma deve essere consapevole delle implicazioni tecniche di ciò a cui sta affidando il team.

Quindi come convincere la squadra?

Hai bisogno di coinvolgere tutti nel team con lo stesso obiettivo in mente. Segnala potenziali problemi tecnici e rischi e aumenta quando non hai abbastanza informazioni, ma alla fine, quando ti impegni in una storia, i tuoi sentimenti dovrebbero essere lasciati alla porta e dovresti farlo indipendentemente dagli impatti a valle. Il team deve solo essere chiaro su quanto impegno sarà speso per fare questo e se è realistico in termini di tempo di sprint assegnato.

Se gli sviluppatori sono preoccupati di dover scrivere un mucchio di codice che verrà buttato via in seguito, non saranno allineati.

L'obiettivo sta rapidamente fornendo valore per il business ORA, non impedendo future rilavorazioni. Non si tratta di loro e delle loro preoccupazioni riguardo al refactoring e al carico di lavoro futuro, inducendoli ad abbandonare questi obiettivi sottolineando l'importanza del Prodotto minimo vitale e offrendo rapidamente valore per il business.

C'è qualcosa di meglio. Si chiama 'autorità'. Il proprietario del prodotto decide cosa va prima e cosa va dopo.

Tuttavia, ci si aspetta che gli sviluppatori comunichino al proprietario del prodotto che alcune cose potrebbero essere più efficienti in un modo o nell'altro.

Detto questo, l'autorità è ancora il proprietario del prodotto e, in base agli input degli sviluppatori, il proprietario del prodotto deve decidere se attenersi al suo piano o modificare un po 'il piano.

Lo sviluppatore professionista è colui che informa il proprietario del prodotto delle possibili ottimizzazioni , ma non colui che rifiuta di fare qualcosa perché "crede così".