Gli sviluppatori di backend eliminati dalle storie degli utenti

10

Ho pianificato di affiancare lo sviluppo del backend alle storie degli utenti in verticale. Ma un tizio del nostro team ha iniziato a lamentarsi del fatto che ciò rende il loro lavoro invisibile.

La mia risposta è stata questa

durante le riunioni di pianificazione e revisione dello sprint discutiamo di attività di back-end di fronte alle parti interessate in modo da renderlo visibile e
il mantenimento di un'alta qualità durante il progetto comporterà un ritmo di partenza più lento rispetto ad altri team, ma avremo una velocità stabile durante il progetto. E la velocità è altamente visibile agli stakeholder.

Insiste ancora con storie come: "Come sviluppatore ho bisogno di avere un livello di dominio in modo da poter incapsulare la logica aziendale".

Come posso risolvere il problema prima che inquini il team?

La radice del problema è che la nostra gestione considera sistematicamente il lavoro di backend come invisibile e chiama minatori di sviluppatori, o altri termini peggiorativi.

— Szili
fonte

7

Non ho storie di backend, non hanno senso .. Tuttavia, non mi piacerebbe avere quel tipo di manager .. Pensavo che gli sviluppatori di backend fossero le rockstar qualche tempo fa

— margabit

2

Realizzare storie di back-end separate implica che il lavoro di back-end può essere prioritario separatamente dal front-end. Ciò comporta il rischio che le priorità vengano assegnate in modo tale che il lavoro di back-end venga relegato in fondo al backlog fino a quando non viene nuovamente incorporato nelle storie del front-end. Per il problema con la mancanza di apprezzamento da parte della direzione, ti consiglio di chiedere a riguardo su Workplace.SE.

— Bart van Ingen Schenau,

La mia soluzione fantasy prevede schiaffi occasionali di tutte le parti. schiaffo Smettere di piagnucolare. schiaffo Smettere di ignorare il ruolo fondamentale che i dati e la logica aziendale contribuiscono al successo dell'azienda che paga l'affitto. schiaffo Smetti di mangiare i pranzi degli altri. Non è il frigorifero di tua madre.

— Erik Reppen,

1

suddividere gli argomenti in verticale, quindi suddividere le storie risultanti in attività orizzontali.

— jwenting

4

Ci sono alcune cose che non vanno nella situazione descritta, il problema evidente è la mancanza di rispetto nei confronti degli sviluppatori back-end. Poiché questa domanda è taggata in modo agile, ho intenzione di respingere altre risposte suggerendo che questo è solo un problema sociale. Ci sono molti cattivi odori e possibili anti-schemi nella tua storia, nessuno dei quali ha a che fare con una gestione ignorante o anche come tagliare le storie.

Il fatto che un gruppo di persone nella squadra si senta offeso per non aver ottenuto gloria dal lavoro ha completato molti possibili problemi.

Non dovrebbero esserci persone che fanno solo sviluppo back-end. Un approccio Agile comune è quello di avere team interfunzionali composti da specialisti generalisti che esercitano la proprietà del codice condiviso. Gli individui non dovrebbero concentrarsi esclusivamente sullo sviluppo di back-end o front-end, anche se sicuramente saranno più esperti o esperti in alcune cose rispetto ad altri.
L'architettura non guadagna valore. Dal punto di vista di un 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 conta è se hai creato valore per gli utenti. La "storia" proposta dallo sviluppatore back-end è un requisito senza senso: è un riepilogo delle decisioni di progettazione che, dal punto di vista di un utente / cliente, non fanno nulla per raggiungere la funzionalità desiderata. In altre parole, una determinata user story potrebbe essere raggiunta da un numero qualsiasi di diversi progetti di architettura. È possibile che una user story possa essere completata senza alcuna modifica al back-end. Questo non lo rende una storia non valida.
Pensare sistematicamente è ancora fondamentale. Mentre l'architettura potrebbe non guadagnare 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. L'intero sistema è importante anche se solo le funzionalità front-end sono le cose che otterranno tutta la gloria.

La mia raccomandazione è di considerare l'architettura come un cittadino di prima classe, ma farlo nel modo giusto. Eseguire un seminario sugli attributi di qualità con le parti interessate . Coinvolgere le principali parti interessate nelle revisioni dell'architettura o almeno riassumere le decisioni di progettazione essenziali in importanti traguardi. Disegna l'architettura su carta grande 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ò accada in modo efficace. Continuare a creare user story incentrate sull'utente. Ma identifica anche scenari di attributi di qualità chiave che mostrano perché il sistema è progettato così com'è e guida il processo decisionale relativo alla progettazione "back-end". Elevare il design dell'architettura in modo che non sia più invisibile.

— Michael
fonte

1

Grazie per una risposta attuabile! Vorrei chiarire un po 'di comprensione causata dalla mia formulazione sbagliata. Non è solo un "sviluppatore di backend" in realtà lavora su tutto lo stack anche nel firmware. Il suo punto dolente è l'architettura di backend che non ottiene il giusto riconoscimento. E mentre l'architettura non guadagna valore da sola, un'architettura sciatta può rompere i sistemi o almeno può renderli molto costosi da mantenere. Il mio piano era di facilitare ulteriori interventi sull'architettura durante le riunioni di revisione e pianificazione e anche un seminario di qualità sembra un ottimo strumento!

— Szili,

FWIW, non è sempre pratico avere uno sviluppatore che lavora l'intero stack. Un requisito nella mia attuale azienda potrebbe comportare lo sviluppo di CICS su un mainframe IBM, MQ, Java in Mule ESB, Datapower e infine una ricca interfaccia utente Web con jquery e altri modelli. Un'altra user story potrebbe coinvolgere CORBA a parlare VMS COBOL e un altro backend è scritto in Gupta.

— Alan Shutko,

@AlanShutko - esattamente. "Il front-end di una persona è il back-end di un'altra persona", giusto? Questo è uno dei motivi per cui non mi piace il gergo come "back-end" e "front-end" soprattutto quando parlo di più componenti in un sistema. Il tuo punto è estremamente importante! Anche "full stack" è un termine relativo che può significare cose diverse in diverse parti di un sistema!

— Michael,

11

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

Se (come ho capito tu) gli sviluppatori di backend si sentono ignorati e svalutati e sentono che il loro lavoro non è valutato abbastanza, allora c'è poco che il processo di sviluppo può fare per cambiarlo.

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

La soluzione migliore è probabilmente quella di parlare in silenzio con lo / gli sviluppatore / i in questione (individualmente o come gruppo) e affrontare il problema di fondo, che sembra essere di rispetto. Ad un certo punto, questo probabilmente dovrà passare alla gestione.

— sleske
fonte

Grazie per le risposte. Il problema è davvero sociale. Oggi abbiamo discusso dell'argomento di ieri e lo sviluppatore in questione mi ha detto che si trattava più di anni di sistematica mancanza di rispetto del suo lavoro di back-end che della sua visione del nostro progetto attuale e della sua comprensione del processo di mischia. Abbiamo deciso di andare avanti con storie a fette verticali.

— Szili,

1

@Szili: Il back-end ha funzionato così male da non meritare alcun rispetto, o è appena spuntato dal fatto che non viene riconosciuto?

— Blrfl,

Il suo lavoro di backend è eccellente. Il problema è il corretto riconoscimento e persino il bullismo da parte della direzione.

— Szili,

4

La radice del problema è che la nostra gestione considera sistematicamente il lavoro di backend come invisibile e chiama minatori di sviluppatori, o altri termini peggiorativi.

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

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

La soluzione agile standard a questo problema è quella di adottare un approccio più "verticale" o "full-stack" allo sviluppo, in cui gli sviluppatori backend prendono le storie dall'alto verso il basso invece di lavorare semplicemente nella loro zona di comfort del livello back-end, e Anche gli sviluppatori frontend si estendono verso il backend (*).

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 back-end. Gli elementi dell'interfaccia utente possono essere rimescolati senza ulteriore lavoro di back-end e le prestazioni sono una caratteristica .}

— Sklivvz
fonte

3

Sembra che tu abbia una comprensione zero dello sviluppo del backend. Scopri quanto poco valore offre un bravo ragazzo di backend quando i ragazzi del front-end eseguono tutta la modellazione dei dati e l'implementazione della logica nel front-end, quindi attendi sei mesi. La maggior parte della buona ingegneria non è buona per produrre valore immediato, si tratta di produrre dividendi a lungo termine. Il tuo approccio applicato alla costruzione di ponti avrebbe fatto in modo che ogni ponte rimanesse in piedi solo per una settimana e non avrebbe un progetto o un architetto perché quelli non hanno un valore immediato.

— Jimmy Hoffa,

1

No @JimmyHoffa Conosco abbastanza bene lo sviluppo del back-end. La mia risposta è praticamente agile da manuale. Come potresti notare, non sostengo di avere solo persone front-end. Se non ti piace l'agile, non usarlo, ma sto semplicemente descrivendo come funziona una metodologia, quindi non dare per scontato cose su di me o altro.

— Sklivvz,

2

La parte in cui va fuori strada è dove stai dicendo che i ragazzi del back-end non stanno producendo valore e dovrebbero semplicemente fare un lavoro front-end, se non è questo il tuo intento in questa risposta, dovresti davvero riformularlo per essere più chiaro cosa intendi qui.

— Jimmy Hoffa,

1

@JimmyHoffa Ma non stanno producendo alcun valore per l'utente finale. Se fosse un team di soli sviluppatori back-end, gli utenti sarebbero gli sviluppatori front-end. In tal caso il tuo ragionamento avrebbe senso, ma non sembra essere il caso.

— Sklivvz,

1

Se nel tuo mondo il valore è prodotto solo dalla creazione di un prodotto interagibile dall'utente e gli sviluppatori back-end non sono necessari a ciò, allora nel tuo mondo apparentemente architetti e project manager, analisti aziendali, risorse umane e tutti gli altri sono irrilevanti. Nel mio mondo il valore è prodotto dalla qualità della progettazione e dell'implementazione di un sistema in modo tale che lo sviluppo di funzionalità future non implichi il vagare attraverso la ragnatela di un database di accesso perché è stato valutato solo il prodotto interattivo per l'utente ... L'implementazione della qualità è un valore . Forse non immediatamente, ma a lungo termine.

— Jimmy Hoffa,

1

I tuoi problemi sono:

Hai livelli di gestione nella tua attività in cui non servono a nulla. Scrum, agile, non mi interessa. La gestione e lo sviluppo dovrebbero essere isolati con le preoccupazioni commerciali gestite da un product manager che ha un indizio! @ # $ Sulla tecnologia. Forse ha funzionato per Steve Jobs, ma non mi sono mai trovato in una situazione in cui i manager non esperti di tecnologia essendo vicini agli sviluppatori era una cosa salutare o alla fine servivano a produrre il miglior prodotto di qualità che un team avrebbe potuto realizzare.
Hai degli sviluppatori che sono più preoccupati delle apparenze di quanto non stiano risolvendo problemi. Questo è o un problema di cultura molto grave (sembra probabilmente dato tutto questo fenomeno "minatore") e / o hai un problema di qualità di sviluppo, che inoltre non mi scioccerebbe data la mancanza di fiducia.

Prendi le persone che non hanno bisogno di essere lì fuori dalla pianificazione e standup. Chiunque abbia idee sul fatto che il back-end sia meno importante del front-end è qualcuno che non ha bisogno di essere lì e di fatto ostacola il processo essendo lì.

Storie di fossati. Si sono serio. Se stanno causando questo tipo di problemi, buttali fuori dalla camera di equilibrio. Nel mio lavoro attuale ci limitiamo a rispettare i criteri "completati" per un determinato compito, che in genere rimane più focalizzato sull'app rispetto all'utente che può offendere coloro che pensano agile (che è cambiato costantemente da 20 anni) ha vinto ' non funziona se non lo segui alla lettera, ma davvero se siamo professionisti, non abbiamo bisogno di nulla che ci causi problemi. Accartocciateli, gettateli sopra la spalla.

E potresti voler ricordare a quel dev che le persone di cui hanno davvero bisogno di preoccuparsi sono i loro colleghi immediati, non le persone che sono troppo all'oscuro per essere nella pianificazione dello sprint.

— Erik Reppen
fonte

Buon Consiglio. Tieni presente che non c'è nulla nel manifesto agile delle "storie degli utenti" e sono solo una pratica popolare nata con processi specifici. Puoi essere agile con le storie degli utenti come puoi senza ...

— Michael,

Questo è vero. Non sono sicuro che il manifesto agile sarebbe considerato abbastanza per "farlo nel modo giusto" da molti standard dell'intero settore della formazione che è stato costruito attorno ad esso, ma come sempre le idee e quali hanno senso per te e la tua squadra dovrebbe avere la precedenza sugli affetti, IMO. Inoltre riceverai tante risposte da quel fronte su come "fare agile" correttamente come chiederesti agli studenti universitari quali sono le regole di datazione. Non c'è sostituto per il pensiero critico.

— Erik Reppen,

Non abbandonerei le storie degli utenti. In realtà sto lavorando duramente per presentarli poiché abbiamo una tradizione di ignorare gli utenti finali. L'analogia di Steve Jobs è molto appropriata in quanto il nostro CEO è un brillante ragazzo tecnico che ha avviato un'azienda multimilionaria. L'unica cosa che ha fallito è la costruzione di un livello manageriale, quindi è rimasto molto pratico con il lavoro svolto. Ciò ha lasciato il posto all'emergere della cultura stellare che si traduce in preoccuparsi delle apparenze. Riassumendo: abbiamo un problema culturale. Ma considerato come dato ho bisogno degli strumenti come quelli nella risposta per rendere necessari i piccoli passi.

— Szili,

Ad ogni modo, consiglierei uno sviluppatore dell'interfaccia utente anal-ritentivo esperto se hai problemi di UX. Non c'è sostituto a parte alcuni fantastici generalisti di cui pochi vorrebbero mai pagare una squadra completa.

— Erik Reppen,