Qual è il ruolo di un Project Manager in Scrum?

4

Qual è il ruolo di un Project Manager in Scrum?

Ho sentito che non è consigliabile che il PM sia un SCRUM Master che posso considerare sensato dato che il PM supervisiona il progetto mentre il Master SCRUM è più interessato alla gestione dei pacchetti di lavoro.

A mio parere, sembrerebbe che avere un PM come SCRUM Master vada contro managina per eccezione, uno dei principi di PRINCE2.

Il PM dovrebbe essere più interessato a:

  • stabilendo lo scopo del progetto, assicurando il caso aziendale il progetto rimane valido

  • pianificazione del numero di iterazioni

  • mantenimento del piano generale del progetto comprese le date di rilascio del software

  • acquisire risorse esterne necessarie al team di Scrum, ad es. utenti per Test di accettazione degli utenti

  • gestione dei rischi e dei problemi che vengono intensificati dal team di Scrum

  • comunicare con l'esecutivo includendo la segnalazione dei progressi

Qualcuno dei PM (o master SCRUM) con esperienza nella gestione di progetti agili usando SCRUM può fornire la propria esperienza / opinione sul fatto che i due ruoli potrebbero / dovrebbero essere combinati?

    
posta Ollie 15.03.2012 - 15:31
fonte

3 risposte

11

In Scrum, il ruolo tradizionale del PM è davvero suddiviso nei ruoli del Product Owner e dello Scrum Master, con una certa responsabilità che ricade anche su tutti gli Scrum team.

Il Product Owner è responsabile della definizione dell'ambito del progetto, della priorità del lavoro mantenendo il backlog del prodotto, decidendo se lo sforzo dovrebbe continuare nelle iterazioni future e del coinvolgimento nelle strategie di gestione e mitigazione del rischio come rappresentante dell'utente e del cliente. In altre parole, il Product Owner si occupa di cose che accadono fuori dal team, per quanto riguarda l'utente e il cliente, e fornisce un singolo punto focale per queste informazioni.

Lo Scrum Master è più orientato al processo e al team. Questa persona gestisce le risorse, spesso prende decisioni sulle strategie di gestione del rischio e di mitigazione e affronta il processo e garantisce che le persone che hanno bisogno di informazioni ma non nel team di Scrum abbiano accesso ad essa e visibilità sul lavoro svolto e su qualsiasi successi e insuccessi della squadra.

Alcuni lavori sono delegati al team nel suo insieme. Ad esempio, non esiste un singolo individuo che fornisce l'organizzazione e le istruzioni: il team nel suo complesso lavora con il backlog del prodotto e i dati precedenti per determinare quanto lavoro intraprendere in uno sprint. Inoltre, la gestione del rischio è un'altra attività che ricade sull'intero team, con lo Scrum Master che facilita il processo.

Infine, alcuni concetti non si adattano bene a Scrum.

Non esiste un'idea anticipata del numero totale di iterazioni necessarie. L'idea è di impostare un timebox su iterazioni (spesso 2-4 settimane) e avere un deliverable potenzialmente spedibile che aggiunge valore. Il progetto termina quando il backlog è vuoto o le esigenze del cliente cambiano in modo tale che il finanziamento di un'altra iterazione costerebbe più del valore aggiunto dal lavoro che può essere fatto. Certo, non è un'idea cieca: sai guardando il backlog e lavorando con il Product Owner quando il progetto si avvicina a uno stato di terminazione.

Inoltre, il software potenzialmente rilasciabile viene prodotto non meno frequentemente rispetto al completamento di ogni sprint. L'idea è che al termine di ogni iterazione esista un prodotto con valore aggiunto. Questo prodotto è stato progettato, implementato, testato internamente e sottoposto a test di accettazione. Tutta la documentazione e le guide associate al prodotto sono anche aggiornate. In altre parole, se il cliente lo desidera, può ottenerlo. Tuttavia, potrebbero non voler passare allo sforzo di distribuire un prodotto alla fine di ogni sprint, ma è un'opzione. Poiché sei reattivo al cambiamento, dovresti essere in grado di indicare un prodotto effettivamente spedito nella tua riunione di pianificazione dello sprint.

Non è consigliabile combinare il ruolo di Product Owner e Scrum Master perché si occupano di cose diverse. Il Product Owner funziona dal punto di vista dell'utente finale e del cliente - offre il massimo valore nel minor tempo possibile e richiede un prodotto di alta qualità. Lo Scrum Master è centrato sul team e fornisce un controbilanciamento per garantire che il team non sia oberato di lavoro, abbia le risorse di cui ha bisogno per fare il lavoro migliore e che siano generalmente persone felici e produttive. Personalmente, penso che qualcuno che è abbastanza abile possa interpretare entrambi i ruoli. Tuttavia, ci vuole un manager esperto e leader per farlo. C'è una grande quantità di informazioni su questo in una domanda di scambio di stack di gestione progetti relativa alla combinazione dei ruoli di Scrum Master e del proprietario del prodotto .

    
risposta data 15.03.2012 - 16:11
fonte
2

Sono totalmente d'accordo con la risposta di @Thomas Owens ma sto aggiungendo la mia esperienza.

Nel tipico progetto Scrum non ci sono PM. Il ruolo del PM è suddiviso in tutti i partecipanti al progetto: PO, Scrum Master e team. Quando ridimensionate un progetto Scrum o quando provate ad applicare Scrum in ambiente aziendale, la persona aggiuntiva come un PM può essere utile.

Lo scaling agile è in genere un compito difficile e in genere richiede alcune aggiunte pianificate per rendere il ridimensionamento corretto. PM può essere in cima all'intero progetto e coordinarlo con l'aiuto di Scrum Masters e Product Owner dei team.

Non abbiamo nemmeno bisogno di lavorare sul ridimensionamento - è sufficiente se devi integrare il tuo lavoro con un altro team che non usa la metodologia agile. In tal caso è necessaria molta coordinazione aggiuntiva. Di solito, non è possibile affidare il compito di coordinare team non agili su Scrum Master o Product Owner, ma è possibile utilizzare il PM tradizionale coordinando entrambi i team e collaborando con Scrum Master e Product Owner.

L'intera storia separata è l'ambiente aziendale / aziendale e la burocrazia. Se la società stessa non si muove verso una mentalità agile, avrai semplicemente bisogno di PM e molto probabilmente sarà "adattatore" tra il tuo mondo agile e la burocrazia aziendale.

    
risposta data 16.03.2012 - 13:07
fonte
1

La mia prospettiva su questo come sviluppatore è che un Project Manager può essere una buona cosa avere in Scrum, se sei nel tipo di organizzazione che ha Project Manager. Il ruolo di questa persona in Scrum è quello di aiutare il resto del business a comprendere Scrum e agire come qualcuno a cui lo Scrum Master e il Product Owner possono rivolgersi se stanno incontrando problemi nella riconciliazione di Scrum con il tipico processo di sviluppo del software nell'organizzazione. Come tale, ha bisogno di avere una profonda comprensione sia di Scrum che del processo tipico dell'organizzazione in modo che possa agire da cuscinetto tra i due.

Poiché l'azienda nel suo complesso abbraccia maggiormente Scrum, penso che il ruolo diventi sempre meno importante perché si verificano meno problemi, al punto che i Project Manager dovrebbero probabilmente concentrarsi sul passaggio a un Product Owner, Scrum Master, o ruolo di Coach Agile.

    
risposta data 16.03.2012 - 15:04
fonte

Leggi altre domande sui tag