In che modo uno Scrum Master "gestisce" un Product Manager fuori controllo? [chiuso]

Question

Sono nuovo su Scrum e mentre capisco il concetto di squadra dietro gli Sprint, immagino che ci sia ancora bisogno di un tutore per il team che minimizza l'interferenza da parte dei proprietari di prodotti che non hanno familiarità con lo sviluppo del software. Quali sono i tuoi successi e quali storie dell'orrore hai vissuto?

Aggiornamento:

Sto cercando l'equilibrio tra la codifica per implementare i processi di business e la creazione dell'architettura appropriata per un cliente. Se il proprietario del prodotto proviene dall'unità di business, devono esserci indicazioni su quale periodo di tempo dovrebbe essere dedicato al modello di dati, ecc.

Definizione:

Da " fuori controllo " proprietario del prodotto intendo in genere qualcuno della business unit che imposta in modo aggressivo i tempi senza avere una reale capacità tecnica di creare tale stima. In genere questa persona dirà: "Ho bisogno di quegli schermi prima del prossimo incontro con il Comitato Operativo la prossima settimana, quindi dai la priorità a quei prodotti di lavoro prima. Affronteremo il database dopo aver parlato con Operations. & Quot;

Grandi risposte a tutti. Grazie per il buon contributo.

Answer 1

" ci deve essere una guida su quale quantità di tempo dovrebbe essere speso per il modello di dati, ecc. "

destro. Questa è la priorità. Definisci il lavoro, dai la priorità. Lavori in base alle priorità.

Cosa può sfuggire al controllo?

1. Ridefinendo il lavoro prima che qualcosa venga fatto?

2. Ridefinire le priorità prima che il lavoro venga completato?

La soluzione è la stessa. Suddividi il lavoro in pezzi più piccoli in modo che qualcosa venga fatto prima che ci sia l'opportunità di fare un cambiamento.

Se hai sprint brevi (di 2 settimane), non è possibile essere fuori controllo. Se scegli sprint di 4 settimane leggermente più pratici, allora hai una piccola possibilità di metterti nei guai.

Answer 2

Le responsabilità sono definite in modo molto chiaro in Scrum: il Product Owner definisce gli articoli arretrati e ne dà la priorità, gli sviluppatori si impegnano su quanto possono fare in uno Sprint.

Quindi, un Product Owner semplicemente non ha alcuna autorità per stabilire le stime. Certo, può ancora dire che ha bisogno di qualcosa in un determinato momento - ciò accade semplicemente. Ma sono ancora gli sviluppatori a dire se può essere fatto. E se ciò non è possibile, devono lavorare insieme su come modificare l'ambito o qualsiasi altra cosa possa essere fatta per soddisfare al meglio le esigenze dell'OP.

Ora, come esattamente l'SM dovrebbe agire in una situazione in cui ciò non funziona senza problemi dipende molto dalla situazione specifica. Preferirei vederlo facilitare una buona relazione e cultura della comunicazione tra l'OP e la squadra piuttosto che averlo proteggere la squadra dall'OP, tuttavia.

Answer 3

Il proprietario del prodotto dovrebbe essere quello che ti protegge dalle esigenze ambigue o variabili dei clienti.

Il proprietario del prodotto non deve fornire le stime.

Answer 4

Non credo sia una questione di "fuori controllo".

  

" Ho bisogno di quelle schermate prima della prossima   incontro con il comitato operativo   la prossima settimana, quindi dai la priorità a quei lavori   prima i prodotti. Affronteremo il   database dopo aver parlato con Operations. "

Non c'è nulla di intrinsecamente sbagliato nell'affermazione da sola . Se la tua app è correttamente astratta, il tuo DB è comunque separato. Il problema principale con l'interfaccia utente in primo luogo è più psicologico: i non-sviluppatori supporranno che la maggior parte del lavoro viene eseguita se vedono schermate e si perdono quando le cose "rallentano". Tuttavia, ecco cosa penso che il tuo vero problema potrebbe essere:

La persona che hai contrassegnato come Product Owner non possiede il prodotto e quindi non si assume abbastanza responsabilità.

Il prodotto è il tutto , non solo i "requisiti funzionali" (prendere in prestito la terminologia). Il tuo SM deve sedersi ed essere irremovibile che l'OP non deve cercare di spingere a comprendere la portata del lavoro dietro le quinte che deve essere realizzato. Una volta che l'OP inizia a esaminare l'intero ambito, può effettivamente essere il tuo rappresentante per la più ampia comunità di parti interessate.

In definitiva, il tuo SM è il responsabile del processo di applicazione. Dovrebbero comportarsi come tali.

Answer 5

Ho usato Agile in due negozi diversi, entrambe le volte funziona bene. Non vedo come qualsiasi cosa fuori controllo possa rovinare il sistema. Prima dello sprint, pianifichi tutti i compiti che farai e indovinerai quanto tempo impiegheranno (sempre arrotondando per eccesso). Quindi puoi capire approssimativamente quanto lavoro puoi fare durante lo sprint.

La maggior parte dei negozi utilizza sprint di 4 settimane e 6,5 ore di tempo lavorabile al giorno. Quando è stato impostato uno sprint, non si introducono nuove attività e solo il lavoro non pianificato che si insinua in uno sprint sta risolvendo i bug nelle funzionalità che si stanno aggiungendo, ovviamente si suppone che siano inclusi nel tempo previsto.

Se vuoi una risposta più specifica, devi definire cosa intendi per "fuori controllo". proprietario del prodotto.

Answer 6

Ho due cose da dire.

Probabilmente hai una sorta di manager R & amp; D (che non è necessariamente uno scrum master) e che non è un proprietario del prodotto).

Questo ragazzo può e dovrebbe (credo) " proteggere " sviluppatori. Eravamo in situazione quando avevamo un ragazzo del genere, e ha funzionato abbastanza bene. Ad esempio, ci ha aiutato a ottenere cose non funzionali nel backlog.

Ora non abbiamo questo ragazzo. Il nostro manager è scrum master. E fa anche un ottimo lavoro proteggendoci. Anche se ... il problema qui è che il generico scrum master non ha alcun potere ufficiale, quindi non può dire "non li premerai così tanto", ma ovviamente può e dovrebbe parlare se vede che il branco ha bisogno di aiuto.

Anche il team stesso e il proprietario del prodotto si evolvono nel tempo, in modo che inizino a prendersi più cura l'uno dell'altro. Il proprietario del prodotto capisce quando il team non si impegna di più o dice "abbiamo bisogno di un po 'di tempo per cose non funzionali ora".

Ma poi - ancora una volta - è bello ovviamente se c'è un manager R & D separato la cui principale responsabilità è prendersi cura degli sviluppatori ... allora sarà più equilibrato penso ..

Abbiamo anche un dipartimento di supporto che prende in prestito gli sviluppatori per le attività di supporto. A volte è difficile concordare cosa sta succedendo o non sarà fatto per questo o quel cliente (perché il supporto vuole tutto). Per questo caso R & amp; D manager - un'ottima idea anche ..

Idealmente, mi piace che l'idea diventi completamente snella in modo che gli sviluppatori non abbiano bisogno di un manager o di uno scudo ... ma non so se e come funziona ... :)

Answer 7

Sono d'accordo con S. Lott. Gli sprint corti sono migliori. Brevi storie utente possono aiutare a. Cerchiamo di limitare le storie degli utenti a 2-4 giorni al massimo.

1. Assicurati che tutto il tuo utente le storie sono ben definite e questo il proprietario in accordo con loro.

2. Una volta iniziato uno sprint, insistere     a cui non è possibile aggiungere nuove attività     lo sprint corrente, ma possono essere     massima priorità nel prossimo sprint.     Gli sprint più brevi lo fanno molto     più facile.

3. Inoltre, per rimuovere il file     imposizione di termini artificiali,     non dovresti davvero consegnare oggetti     dallo sprint corrente fino al     inizio del prossimo sprint quando     possibile.

La parte più difficile dello sviluppo agile è la disciplina. Una volta che hai un team disciplinato e uno scrum master, gli utenti si abituano e le cose si muovono molto più agevolmente. Non sono sicuro se utilizzi qualche software per la gestione dei progetti, ma dai un'occhiata a Rally. Negli ultimi anni hanno apportato alcuni importanti miglioramenti.

Answer 8

L'ambito di iterazione (Sprint in Scrum) non deve essere modificato durante l'iterazione. Ecco perché è prevista una sola iterazione alla volta. Come ha sottolineato S. Lott, più breve è l'iterazione, prima il Product Owner sarà in grado di pianificare nuove cose.

Il ruolo di Scrum Master è quello di isolare il Team da tale pressione e deve dire al Product Owner che le nuove richieste devono attendere la prossima iterazione.

Ora il ruolo di Product Owner è quello di massimizzare il valore del lavoro svolto dal Team, quindi se esiste un nuovo elemento con priorità assoluta, che non può attendere la fine dell'iterazione corrente, è ancora possibile sostituire gli articoli con stima simile e che non sono stati avviati . Questa dovrebbe essere l'eccezione, non la regola.

Answer 9

Rispetta le regole di ingaggio chiaramente definite, quindi tu (SM) puoi piuttosto passare il tempo a guidare la tua squadra.

Answer 10

Un team agile è composto da sviluppatori, analista aziendale, tester, DBA, master Scrum e proprietario del prodotto. Tutti lavorano come un team basato sulle funzionalità .

La metodologia agile è qui per aiutare le aziende ad accelerare lo sviluppo più rapido del prodotto. Il proprietario del prodotto può definire la priorità e modificarne la priorità. In realtà, è un team Scrum che lo stima tra cui (PMI, sviluppatore, designer, tester…. Tutti). Ogni membro del team offre una prospettiva diversa sul prodotto e sul lavoro richiesto per fornire una user story e uno sprint comprende e la storia di piccoli utenti. Se il team di Scrum ritiene che non possa essere fatto entro lo sprint, deve essere diviso nella piccola porzione della storia dell'utente e stimare in base alla traccia dello stack coinvolta per svilupparla.

vale a dire. Se il Product Owner (PO) desidera che la specifica user story debba terminare per prima, ma se tale story include le molteplici modifiche (ad esempio Frontend e backend incluso il database) e non può essere completata in uno sprint, il team Scrum può seguire le regole chiave di seguito:

Elementi chiave :

• Dividi nella storia dell'utente secondario in base alla traccia stack
• Stimare ogni user story relativa a questo
• Scrum master dovrebbe informare il Product Owner sulla linea temporale  per terminare questa user story in base alla velocità attuale del team
• Il proprietario del prodotto deve essere abbastanza maturo per comprendere la sequenza temporale in quanto tale  non può essere completato nello sprint.

• Se Still PO ha il problema di priorità, può consultare il  Scrum Master / Coach.

  A colpo d'occhio, Agile è di più per aiutare le imprese, ma è necessario occuparsene non sovraccaricherà la mischia. Poiché è un processo regolare per sviluppo iterativo.