Come far funzionare Scrum per un team con ruoli definiti?

Alcune informazioni di base

Faccio parte di un team di sviluppo software interno. Consiste in

• 5 sviluppatori (con esperienze che vanno dai 2 ai 5 anni, sono uno di loro)
• 3 addetti all'implementazione (svolgono la distribuzione e la formazione del software)
• e 1 project manager.

Sviluppiamo numerosi progetti di piccole e medie dimensioni e le loro scadenze si sovrappongono di solito. Lo sviluppo procede così:

1. "Client" ci fornisce una serie di requisiti iniziali
2. Sviluppiamo il sistema secondo le specifiche
3. Presentare detto sistema al "client"
4. "Cliente" ci fornisce requisiti aggiuntivi basati su detta presentazione
5. Ripetere 2-4 fino a quando il "client" ha esaurito i nuovi requisiti o la data di destinazione della distribuzione è prossima
6. Configurare e distribuire il sistema

Questo, insieme al fatto che è il "cliente" che gestisce le scadenze per la maggior parte del tempo (che è una bandiera rossa, da quello che vedo qui in Programmers e PM.SE) e non seguiamo una guida metodologica di sviluppo definita alla codifica da cowboy, al codice pressoché non mantenibile e ai bug che riescono a superare la produzione, tra le altre cose. Ecco perché abbiamo deciso di adottare una metodologia basata su Agile come Scrum.

Perché Scrum?

È stata l'iniziativa del nostro manager, e tutti sembrano concordare, data la nostra situazione attuale.

Il problema con Scrum

Alcuni degli elementi di Scrum sono in conflitto con la nostra configurazione attuale che non possiamo affrontare facilmente, in particolare la natura "tuttofare" degli sviluppatori Agile. Il team di distribuzione non sa come programmare e gli sviluppatori hanno capacità di comunicazione e formazione inferiori alla media. E questa formazione non cambierà molto presto.

La domanda

Interesserebbe l'efficacia di Scrum come metodologia? Dovrebbero essere apportate altre modifiche per compensare? O sarebbe meglio abbandonare del tutto il pensiero e pensare a una metodologia diversa?

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, implementali e dimostra il risultato e, in base alla dimostrazione, puoi fornire nuovi requisiti o le parti interessate possono decidere che il prodotto è abbastanza buono da non richiedere ulteriori sviluppi.
Nella tua situazione, al "cliente" di cui hai parlato potrebbe essere assegnato il ruolo di Product Owner in Scrum (sembrano già occupare quel ruolo impostando le priorità all'interno di un progetto e decidendo quando è pronto per essere implementato).
Un grande cambiamento potrebbe essere la lunghezza di un'iterazione. In Scrum, un'iterazione dovrebbe durare da qualche parte tra 1 e 4 settimane.

Per quanto riguarda la composizione della squadra e l'errore di tutti i mestieri: Scrum non richiede a tutti di essere un tuttofare. Scrum richiede solo che il team nel suo insieme abbia tutte le competenze necessarie per ottenere il prodotto da un elenco di requisiti a qualcosa che è stato / può essere distribuito.
Nella tua situazione, ho potuto facilmente vedere un team per progetto composto da uno o più sviluppatori (che svolgono principalmente il lavoro di implementazione e test) 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 cliente / proprietario del prodotto ha dato il via libera per l'implementazione, il lavoro per il team di scrum sarà per lo più svolto, quindi gli sviluppatori possono andare a un altro progetto (ed essere disponibili solo su richiesta per risolvere i problemi post-implementazione) e l'implementazione il personale può passare all'esecuzione dell'addestramento e supportare il lancio.

Il fatto che ci siano scadenze non è un vero problema, purché ci sia sufficiente flessibilità in quale funzionalità deve essere presente in quella versione.

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

Abbinando persone con diverse abilità insieme, non importa quale abilità: preparare il caffè, testare, allenarsi ecc., È possibile diffondere le competenze in tutto il team.

Ma a dire il vero non sembra che SCRUM sia così lontano per te. Parte di SCRUM è essere flessibile e trovare ciò che è meglio per il tuo team. Parte di XP è il rispetto del tuo team e l'adattamento. Forse tra 100 anni potremmo avere una professione più pienamente sviluppata con regole rigide 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, il team deve discuterne e provare nuove cose fino a quando non trovano qualcosa che funzioni.

Come far funzionare Scrum per un team con ruoli definiti?

Fallo e basta. Secondo la guida della mischia ognuno è uno sviluppatore, ma qui sul pianeta terra persone diverse porteranno cose diverse sul tavolo. Mi sono quasi linciato quando ho suggerito che alcune persone sono davvero tester mentre altri scrivono il software.

Alcune cose che potresti voler affrontare:

sprint

Sembra che tu abbia una fase di sviluppo iniziale seguita da una serie di quelli che sono apparentemente sprint. Valuta di spezzarlo. Il cliente non solo vedrà qualcosa in anticipo, ma avrà anche una migliore sensazione delle pietre miliari dello sviluppo man mano che si verificano.

Scadenze fisse

Questo si ripresenta più volte e in effetti è una spina persistente nel lato degli sviluppatori in cui attualmente lavoro. Scrum stabilisce 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 osservato le prime versioni, è probabile che l'ambito si insinui significativamente. Questo non è un problema in sé, ma il cliente dovrebbe essere consapevole che ulteriori lavori avranno luogo negli sprint successivi e vanno oltre i requisiti noti.

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

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

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 deprimeranno.

Ma prima portare la storia che offre il miglior rapporto costi / benefici al cliente e implementarla, inclusi i test completamente automatizzati, su una qualità sufficientemente buona per essere implementata, prima di lavorare alla storia successiva è un concetto utile. Allo stesso modo è necessario che tutto il codice scritto per una storia sia rivisto da un altro sviluppatore prima che la storia sia considerata "fatta".

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

Mi aspetto che scoprirai che all'inizio di ogni progetto in cui l'input dello staff di implementazione sarebbe di grande aiuto per gli sviluppatori, sono impegnati al 100% nella realizzazione del progetto precedente. Pertanto, considera se lo staff di implementazione può lavorare alla stesura delle storie e della documentazione per l'utente per il prossimo progetto, mentre gli sviluppatori stanno scrivendo il codice per il progetto corrente.

"Sviluppo guidato dal comportamento" con lo staff di implementazione che scrive l'esempio utilizzato nei test può funzionare.

Quindi ci sono alcuni Scrum che ti aiuteranno, ma cerca di appoggiarti a Scrum invece di usare Scrum.