Gli sviluppatori back-end messi giù dalle storie degli utenti

Ci sono alcune cose che non vanno nella situazione descritta, il problema ovvio è la mancanza di rispetto data agli sviluppatori di back-end. Poiché questa domanda è etichettata come agile, ho intenzione di respingere altre risposte suggerendo che questo è solo un problema sociale. Ci sono molti cattivi odori e possibili anti-pattern nella tua storia, nessuno dei quali ha a che fare con la gestione degli ignoranti o persino come si suddividono le storie.

Il fatto che un gruppo di individui nel team si senta offeso per non ottenere gloria dal lavoro completato sa di diversi possibili problemi.

• Non dovrebbero esserci persone che fanno solo lo sviluppo back-end. Un approccio Agile comune è quello di avere team interfunzionali composti da specialisti generalisti che praticano la proprietà condivisa del codice. Gli individui non dovrebbero concentrarsi esclusivamente sullo sviluppo back-end o front-end, anche se sicuramente saranno più esperti o migliori in alcune cose rispetto ad altri.
• L'architettura non guadagna valore. Dal punto di vista dell'utente - l'unica prospettiva che conta davvero - non importa se hai livelli o lingue di dominio o anche se la soluzione è programmata. L'unica cosa che importa è se hai creato valore per gli utenti. La "storia" proposta dallo sviluppatore back-end è un requisito priva di senso: è un riassunto delle decisioni di progettazione che, dal punto di vista di un utente / cliente, non fanno nulla per ottenere la funzionalità desiderata. In altre parole, qualsiasi storia utente può essere raggiunta da un numero qualsiasi di architetture differenti. È possibile che una storia utente possa essere completata senza alcuna modifica al back-end. Questo non lo rende una storia non valida.
• Il pensiero sistemico è ancora fondamentale. Sebbene l'architettura non ottenga un valore, è ancora fondamentale per il successo. Lo sviluppatore back-end ha alcune preoccupazioni valide. Dovresti pensare a come costruirai il sistema. Dovresti scrivere quelle decisioni giù. L'intero sistema è importante anche se solo le funzionalità di front-end sono le cose che otterranno tutto il gloria.

La mia raccomandazione è di trattare l'architettura come un cittadino di prima classe , ma farlo nel modo giusto. Esegui un workshop sugli attributi di qualità con le parti interessate . Coinvolgere gli stakeholder chiave in recensioni di architettura , o almeno riassumere le decisioni di progettazione essenziali a livello di importanza pietre miliari. Disegna l'architettura su una grande carta e rendila visibile in modo che l'intera squadra possa vederla.

Richiede che tutti si sviluppino ovunque nel sistema (front-end e back-end), accoppiando il programma se è necessario in modo che ciò possa avvenire in modo efficace. Continua a creare storie utente incentrate sull'utente. Ma identifica anche gli scenari degli attributi di qualità chiave che mostrano perché il sistema è stato progettato così com'è e guida il processo decisionale sul design "back-end". Elevare il design dell'architettura in modo che non sia più invisibile.

Questo sembra essere un problema sociale, quindi avrà bisogno di una soluzione sociale.

Se (come ti ho capito) gli sviluppatori di backend si sentono ignorati e trascurati e ritengono che il loro lavoro non sia sufficientemente valutato, quindi c'è ben poco che il processo di sviluppo possa fare per cambiare questo aspetto.

Se ho capito bene, sembra che gli sviluppatori sentano che dovrebbero almeno avere le loro "user" user story, in modo che possano indicarle e dire "Questo è quello che abbiamo fatto, solo noi backend ragazzi / ragazze". Tuttavia, avere storie tagliate "orizzontalmente" come questa è una cattiva idea, e sono d'accordo con te per suddividerle verticalmente.

La soluzione migliore è probabilmente parlare tranquillamente con lo / gli sviluppatore / i in questione (individualmente o come gruppo) e affrontare il problema sottostante, che sembra essere di rispetto. A un certo punto, probabilmente sarà necessario passare alla gestione.

The root of the issue is that our management systematically consider backend work as invisible and call backed devs miners, or other pejorative terms.

In effetti questo è il problema. È ovvio che non lo risolvi con le storie!

In generale, una delle caratteristiche dello sviluppo agile è la trasparenza. Ciò significa anche che rende i tuoi problemi organizzativi più manifest .

La soluzione agile standard a questo problema è adottare un approccio più "verticale" o "full stack" allo sviluppo, dove i tuoi sviluppatori backend prendono storie da cima a fondo invece di lavorare semplicemente nella loro zona di comfort del back-end gli sviluppatori di livello e frontend si allungano anche verso il back-end (*).

In altre parole: fai in modo che tutti producano valore per i tuoi utenti finali.

^{(*) Nota: non tutte le storie devono avere un componente front-end o un componente back-end. Gli elementi dell'interfaccia utente possono essere rimescolati senza ulteriore lavoro di back-end e le prestazioni sono una funzione .}

I tuoi problemi sono:

• Hai livelli di gestione nella tua azienda in cui non servono a nulla. Scrum, agile, non mi interessa. La gestione e lo sviluppo dovrebbero essere isolati con le preoccupazioni aziendali gestite da un product manager che ha un indizio! @ # $ Sulla tecnologia. Forse ha funzionato per Steve Jobs, ma non sono mai stato in una situazione in cui i manager non esperti di tecnologia che si avvicinano allo sviluppo erano una cosa salutare o alla fine sono serviti a produrre il prodotto di migliore qualità che una squadra avrebbe potuto fare.

• Hai degli sviluppatori che sono più preoccupati per le apparenze di quanto non stiano risolvendo i problemi. Questo è un problema culturale molto serio (sembra probabile dato l'intero fenomeno "minatore") e / o avete un problema di qualità di sviluppo, che non mi scioccherebbe vista la mancanza di fiducia.

Ottieni le persone che non hanno bisogno di essere lì fuori dalla pianificazione e dalla posizione in piedi. Chiunque abbia nozioni sul back-end sia meno importante del front-end è qualcuno che non ha bisogno di esserci e sta di fatto ostacolando il processo essendo lì.

Storie di fossati. Si sono serio. Se provocano questo tipo di problemi, gettali fuori dalla camera di equilibrio. Al mio attuale incarico ci limitiamo a rispettare i criteri "completati" per un dato compito, che in genere rimane più focalizzato sull'app rispetto all'utente che potrebbe offendere coloro che pensano agile (che è in continua evoluzione da 20 anni), ha vinto " funziona se non lo segui alla lettera, ma in realtà se siamo professionisti, non abbiamo bisogno di nulla che ci stia causando problemi. Accartocciati, gettali sulla tua spalla.

E potresti voler ricordare a Dev che le persone di cui hanno davvero bisogno di preoccuparsi sono i loro pari immediati, non le persone che sono troppo incapaci di partecipare allo sprint planning.