Va bene avere persone con più ruoli in un team Scrum?

Sto valutando alcune metodologie di tipo Agile per una possibile introduzione al mio team. Con Scrum, è consentito che la stessa persona reciti più ruoli? Abbiamo un piccolo team di quattro sviluppatori e un web designer; non abbiamo davvero un vantaggio (ricopro questo ruolo), tester di qualità o analisti aziendali e tutte le nostre attività di sviluppo provengono dal CIO. I test automatizzati sono visti come una totale perdita di tempo e tutto si concentra sulla velocità e non sulla qualità.

Quello che accadrà è che il CIO presenterà un compito di sviluppo (che sia una funzione o un bug) e lo consegnerà a uno sviluppatore (non a tutto il team, a un individuo, spesso in privato o di punto in bianco) che è quindi dovrebbe averlo completato. Il CIO non raccoglie requisiti oltre l'idea iniziale (e questo ci ha morso prima poiché implementeremo qualcosa solo per scoprire che nessuno degli utenti finali può utilizzare la funzione, perché non sono stati consultati o addirittura informati su di essa prima di svilupparlo, e in preda al panico ci verrà detto di ripristinare il cambiamento), ma è necessario 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 del progetto che sullo sviluppo, che è qualcosa di cui siamo completamente privi, poiché al momento non abbiamo alcuna parvenza di gestione del progetto.

In secondo luogo, se può funzionare, è irragionevole per qualcuno, diciamo me stesso, agire sia come ScrumMaster che come sviluppatore? O affinché uno sviluppatore sia anche il Product Owner (anche se è probabile che questo sarà il CIO, che non è uno sviluppatore)? Mi rendo conto che Scrum Master e Product Owner dovrebbero essere persone diverse ma allo stesso tempo non penso che abbiamo qualcuno che abbia le qualità di Product Owner (è probabile che si trasformerebbe in un "Ho bisogno di tutte queste storie, io non importa come, ma fai "tipo di accordo e / o qualsiasi blocco sarebbe sbloccato per un capriccio).

Mi sembra che potrei aver bisogno di scegliere pezzi di Scrum / XP / Lean per compensare il modo in cui le cose vengono fatte attualmente, poiché è altamente improbabile che la mentalità possa essere cambiata; per esempio, la programmazione a coppie non volerebbe mai (visto come uno spreco, si ottiene la metà dei compiti se si hanno bisogno di due persone per tutto), TDD sarebbe una vendita difficile, ma i cicli brevi sarebbero i benvenuti.

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

Per quanto tu desideri disperatamente che tu e il tuo team svolgiate un lavoro di progetto, scoprirete che Agile semplicemente non lavorerà nella vostra organizzazione a causa del fatto che non state davvero facendo "progetti" di lavoro o dedicandovi come squadra a un "impegno di progetto".

Puoi organizzare un mini progetto attorno a una funzionalità complessa, ma in realtà non hai alcun collegamento con gli analisti aziendali o gli utenti finali, quindi come puoi verificare che stai fornendo storie utente quando non hai modo di sapere veramente di cosa si tratta l'utente vuole?

Il tuo unico stakeholder è il tuo capo, e fondamentalmente assicura che il tuo team non esista per servire gli altri stakeholder del progetto, tu esisti come un team per servire lui e le sue esigenze, indipendentemente da come ciò influisca sugli altri stakeholder.

Oltre a tutto ciò, sta assegnando compiti individuali agli individui e probabilmente ridistribuendo immediatamente le cose mentre decide che dovrebbero andare. Non è possibile funzionare in una metodologia di progetto Agile se le singole risorse del progetto verranno ridefinite in un momento o se lo sprint verrà sospeso.

Non dovrebbe funzionare così

Uno sprint è un impegno da parte di tutto il team a fornire un sottoinsieme di user story entro una data specifica. Una volta avviato, uno sprint dovrebbe essere completato fino al completamento prima che si verifichino eventuali riprogrammazioni o modifiche. Come dovrebbe essere gestito un progetto se eseguito in un ambiente così caotico ad hoc?

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

Non si tratta di un team di progetto di sviluppo software.

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

Come ho notato qui , se lo Scrum Master o il Product Owner hanno compiti attuabili, sono anche membri del Team.

Detto questo, avrai problemi seri con Agile a meno che tu non abbia un vero riscontro sia dal tuo CIO che dai tuoi clienti. Il tuo CIO è disposto a rispettare il fatto che non può aggiungere un oggetto di lavoro a metà scatto, ma dovrà attendere fino al prossimo? È disposto a dare la priorità agli articoli da sviluppare? Da quello che hai scritto, sembra che possiede quello che fai, e quindi dovrebbe essere il Product Owner. Se non è disposto, non ci riuscirai più di quanto tu non faccia attualmente.

Scrum potrebbe essere una buona soluzione per il tuo problema del CIO che assegna il lavoro a uno sviluppatore ad hoc, ma solo se il CIO accetterà il processo. Ho il sospetto che al tuo CIO non piacerà essere assegnato a un incarico diretto. Ma se riesci a convincere il CIO a convincersi dell'idea che lui scriva storie utente e poi le priorità, potrebbe trovarlo un modo molto efficace per gestirlo. Ma inizierà con te a convincere il tuo CIO ad attenersi al processo.

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 e 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 in quanto altrimenti vi sarebbe un cattivo conflitto di interessi qui presentato. Lo Scrum Master può essere uno sviluppatore, poiché in questo caso non c'è un conflitto così grave.