Va bene avere persone con ruoli multipli in un team Scrum?

8

Sto valutando alcune metodologie in stile Agile per una possibile introduzione alla mia squadra. Con Scrum, è consentito che la stessa persona esegua più ruoli? Abbiamo un piccolo team di quattro sviluppatori e un web designer; non abbiamo un ruolo guida (svolgo questo ruolo), tester del controllo qualità o analisti aziendali e tutti i nostri compiti di sviluppo provengono dal CIO. I test automatici sono considerati una perdita totale di tempo e tutto si concentra sulla velocità e non sulla qualità.

Ciò che accadrà è che il CIO avrà un compito di sviluppo (sia esso una caratteristica o un bug) e lo darà a uno sviluppatore (non all'intera squadra, a un individuo, spesso in privato o fuori dal nulla) chi si aspetta quindi che venga completato. Il CIO non raccoglie requisiti oltre l'idea iniziale (e questo ci ha già morso perché implementeremo qualcosa solo per scoprire che nessuno degli utenti finali può utilizzare la funzione, perché non sono stati consultati o nemmeno informati prima che lo sviluppassimo, e in preda al panico ci verrà detto di annullare la modifica) ma richiede di dire / approvare tutto ciò che facciamo.

Per prima cosa, uno stile Scrum è qualcosa da considerare per introdurre alcuni standard e pratiche? Dalla lettura, Scrum sembra fare affidamento su un po 'più di fiducia e comunicazione e si concentra più sulla gestione dei progetti che sullo sviluppo, che è qualcosa di cui siamo completamente privi in quanto al momento non abbiamo alcuna parvenza di gestione dei progetti.

In secondo luogo, se può funzionare è irragionevole per qualcuno, diciamoci, agire sia come ScrumMaster che come sviluppatore? O per uno sviluppatore di essere anche il proprietario del prodotto (anche se è probabile che questo sarà il CIO, che non è uno sviluppatore)? Mi rendo conto che lo Scrum Master e il Product Owner dovrebbero essere persone diverse, ma allo stesso tempo non penso che abbiamo qualcuno che ha le qualità di un Product Owner (è probabile che si trasformi in "Ho bisogno di tutte queste storie, io non importa come, ma fallo fare "tipo di affare e / o qualsiasi blocco sarebbe unfrozen su un capriccio).

Mi sembra che potrei aver bisogno di scegliere e scegliere pezzi di Scrum / XP / Lean per compensare come sono fatte le cose al momento, poiché è altamente improbabile che la mentalità possa essere cambiata; ad esempio Pair Programming non volerebbe mai (visto come un rifiuto, si ottiene la metà delle attività svolte se hai bisogno di due persone per tutto), TDD sarebbe una vendita dura, ma i cicli brevi sarebbero ben accetti.

    
posta Wayne Molina 06.06.2012 - 17:36
fonte

4 risposte

11

Scrum, Kanban o qualsiasi altra metodologia Agile è principalmente una metodologia focalizzata sullo sviluppo di software progetti . In altre parole, è una pratica di gestione del progetto per sua natura.

Per quanto tu voglia disperatamente che tu e il tuo team stiate svolgendo un lavoro di progetto, troverete che Agile semplicemente non lavorerà nella vostra organizzazione perché non state davvero facendo un lavoro di "progetto" o dedicandovi come una squadra per un "impegno del progetto".

È possibile organizzare un mini progetto attorno a una funzione complessa, ma in realtà non si ha alcuna connessione con gli analisti di business o gli utenti finali, quindi come si può verificare che si stia consegnando su User Stories quando non si ha modo di sapere veramente cosa l'utente vuole?

Il tuo unico interlocutore è il tuo capo e sostanzialmente garantisce che il tuo team non esista per servire gli altri stakeholder del progetto, tu esisti come una squadra per servire lui e le sue esigenze indipendentemente da come questo influisce sugli altri stakeholder.

Oltre a tutto ciò, sta dando compiti individuali agli individui e probabilmente ridefinisce le priorità immediatamente quando decide che dovrebbero andare. Non puoi funzionare in una metodologia di progetto Agile se le singole risorse di progetto stanno per essere ridefinite in un preavviso di un attimo, o se lo sprint verrà messo in attesa.

Non dovrebbe funzionare così

Uno sprint è un impegno del intero team per fornire un sottoinsieme di storie utente entro una data specifica. Una volta avviato, uno sprint dovrebbe essere completato fino al completamento prima di qualsiasi riprioritization o modifiche devono verificarsi. Come deve essere gestito un progetto quando viene eseguito in un ambiente ad-hoc così caotico?

Non lavori in un ambiente che sia favorevole alle metodologie di gestione dei progetti Agile. Non si lavora nemmeno in un ambiente favorevole alle metodologie Waterfall. Lavori in una monarchia e sei semplicemente il re che fa le sue offerte e spara fuoco.

Questo non è il punto di forza di un team di sviluppo del software.

Quindi in un modo molto oscuro sto rispondendo alla tua domanda dicendo che, nella tua situazione, non importa se le persone giocano ruoli multipli. Hai problemi molto più grandi nelle tue mani. Stai chiedendo come rimuovere le macchie d'acqua dal tappeto su una casa senza tetto.

    
risposta data 06.06.2012 - 19:01
fonte
6

Come ho notato qui , se lo Scrum Master o il Product Owner hanno attività utilizzabili, sono anche membri del team.

Detto questo, avrai problemi seri con Agile a meno che tu non abbia un reale buy-in da parte del tuo CIO e dei tuoi clienti. Il tuo CIO è disposto a rispettare il fatto che non può aggiungere un oggetto di lavoro a metà sprint, ma dovrà aspettare fino al prossimo? È disposto a dare la priorità agli articoli da sviluppare? Da quello che hai scritto, sembra che possieda ciò che fai, e quindi dovrebbe essere il Product Owner. Se non è disposto a farlo, non avrai più successo di quello che fai attualmente.

    
risposta data 06.06.2012 - 18:06
fonte
1

Scrum potrebbe essere una buona soluzione per il problema del CIO che assegna il lavoro a uno sviluppatore ad hoc, ma solo se il CIO acquisterà il processo. Sospetto che al tuo CIO non piacerà l'incarico diretto. Ma se riesci a convincere il CIO ad acquistare l'idea che lui scrive storie di utenti e poi dare loro la priorità, potrebbe trovare un modo molto efficace per gestirlo. Ma inizierà con te convincendo il tuo CIO ad aderire al processo.

    
risposta data 06.06.2012 - 22:05
fonte
1

Scrum è qualcosa da considerare, certo. Tuttavia, c'è qualcosa da dire per coinvolgere tutti coloro che sono coinvolti nella stessa pagina e accettare alcune modifiche alla struttura insieme ad ottenere almeno alcuni sprint per risolvere vari problemi iniziali nell'uso di questa metodologia.

Il Product Owner dovrebbe essere al di fuori del team di sviluppo poiché altrimenti si presenterebbe un conflitto di interessi negativo qui presentato. Lo Scrum Master può essere uno sviluppatore, anche se in questo caso non c'è niente di male.

    
risposta data 06.06.2012 - 22:14
fonte

Leggi altre domande sui tag