Come far funzionare Scrum per una squadra con ruoli definiti?

In realtà, il tuo attuale modo di lavorare non è così lontano da Scrum come potresti pensare.

In Scrum, ottieni anche una serie iniziale di requisiti, li implementa e ne dimostra i risultati e, in base alla dimostrazione, possono essere forniti nuovi requisiti o le parti interessate possono decidere che il prodotto è sufficientemente buono da non richiedere ulteriori sviluppi è necessario.
Nella tua situazione, al "cliente" di cui hai parlato potrebbe essere assegnato il ruolo di Product Owner in Scrum (sembrano già riempire quel ruolo impostando le priorità all'interno di un progetto e decidendo quando è pronto per essere distribuito). < br> Un grande cambiamento potrebbe essere la lunghezza di un'iterazione. In Scrum, un'iterazione dovrebbe durare da 1 a 4 settimane.

Per quanto riguarda la composizione della squadra e la fallacia di tutti i mestieri: Scrum non richiede a tutti di essere un tuttofare. Scrum richiede semplicemente che il team nel suo insieme abbia tutte le competenze richieste per portare il prodotto da un elenco di requisiti a qualcosa che è stato / può essere implementato.
Nella tua situazione, potrei facilmente vedere un team per progetto costituito da uno o più sviluppatori (che svolgono principalmente attività di implementazione e testing) e un membro dello "staff di implementazione" che si concentra principalmente sulla creazione di manuali e materiale di formazione per le funzionalità che gli sviluppatori ora stanno implementando.

Dopo che il client / proprietario del prodotto ha dato il via libera all'implementazione, il lavoro per il team di Scrum verrà principalmente svolto, in modo che gli sviluppatori possano passare a un altro progetto (e essere disponibili solo su richiesta per risolvere problemi di post-distribuzione) e lo staff di implementazione può passare all'esecuzione dell'addestramento e al supporto del roll-out.

Il fatto che ci sia una scadenza non è un problema reale, a patto che ci sia abbastanza flessibilità su quale funzionalità deve essere presente in quel rilascio.

Chiedi alternative, quindi ho intenzione di dire eXtreme Programming (XP). In particolare, penso che la programmazione della coppia potrebbe aiutarti qui.

Accoppiando persone con abilità diverse insieme, non importa su quale abilità: fare il caffè, testare, allenarsi ecc. puoi diffondere le abilità nel team.

Ma a dire il vero non sembra che SCRUM sia così lontano per te. Parte di SCRUM è flessibile e trova ciò che è meglio per la tua squadra. Parte di XP sta rispettando la tua squadra e adattandosi. Forse tra 100 anni potremmo avere una professione più sviluppata con regole dure e veloci (anche se ne dubito) ma per ora, fare ciò che funziona per te è tutto ciò che abbiamo. L'importante è avere loop di feedback. Se qualcosa non funziona, allora il team ha bisogno di discuterne e provare nuove cose finché non trovano qualcosa che funzioni.

Come far funzionare Scrum per una squadra con ruoli definiti?

Fallo e basta. Secondo la guida scrum ognuno è uno sviluppatore, ma di nuovo qui sul pianeta terra, diverse persone porteranno cose diverse al tavolo. I sono quasi stati linciati quando ho suggerito che alcune persone sono davvero testers mentre altri scrivono il software.

Alcune cose che potresti voler indirizzare:

Sprint

Sembra che tu abbia una fase di sviluppo iniziale seguita da una serie di ciò che è apparentemente sprint. Considerare la possibilità di rompere questo. Non solo il cliente vedrà qualcosa in anticipo, ma migliorerà le pietre miliari dello sviluppo man mano che si presentano.

Scadenze fisse

Ciò si verifica di volta in volta e in effetti è una spina persistente nel lato degli sviluppatori in cui attualmente lavoro. Scrum imposta le stime per lo sprint - niente di più. Sì, potresti colpire il bersaglio dopo una serie di sprint, ma una volta che il cliente ha notato le versioni precedenti, è probabile che lo scope si insinui significativamente. Questo non è un problema in sé, ma il cliente dovrebbe essere reso consapevole che ulteriori lavori si svolgeranno negli sprint successivi e supereranno i requisiti noti.

La tua situazione potrebbe essere una corrispondenza migliore per Kanban, dal momento che puoi iniziare da te e iterare da lì. Ciò significa che non avresti un'introduzione al Big Bang che è dirompente per i tuoi progetti attuali: inizia solo visualizzando le attività su una lavagna e adottando alcune delle pratiche come le retrospettive e le riunioni quotidiane.

Devi essere un po 'più attento rispetto a Scrum perché non è così prescrittivo: quindi ha la tendenza a tornare a qualsiasi cosa prima, invece di inculcare una corretta mentalità agile.

Scrum non funziona bene con progetti separati che si sovrappongono, poiché non hai un gruppo stabile di persone che lavorano su un progetto per lo sprint completo. Quindi concetti come la verbosità ecc. Probabilmente ti deprimono.

Ma prima raccogliendo la storia che offre il miglior rapporto costo / beneficio al cliente e implementandola, compresi i test completamente automatizzati, a una qualità che è abbastanza buona da essere implementata, prima di lavorare sulla prossima trama è un concetto utile. Allo stesso modo, richiede che tutto il codice scritto per una storia venga esaminato da un altro sviluppatore prima che la storia sia considerata "conclusa".

Suppongo che il personale addetto all'implementazione debba scrivere documenti di formazione e di riferimento, che possano essere scritti (prima bozza) per ogni articolo prima che il codice sia scritto, diventando quindi test di accettazione.

Mi aspetto che all'inizio di ogni progetto l'input dello staff di implementazione sarebbe di maggior aiuto per gli sviluppatori che sono impegnati al 100% nello sviluppo del progetto precedente. Pertanto, considera se lo staff di implementazione può lavorare per scrivere le storie e la documentazione utente per il prossimo progetto, mentre gli sviluppatori stanno scrivendo il codice per il progetto corrente.

"sviluppo guidato dal comportamento" con il personale addetto all'implementazione che scrive l'esempio utilizzato nei test potrebbe funzionare.

Quindi c'è un po 'di Scrum che ti aiuterà, ma cerca di sporgere da Scrum invece di usare Scrum.