Svantaggi delle storie utente verticali

Non conosco svantaggi a lungo termine. A breve termine, e per una squadra nuova a questo tipo di sviluppo, il principale svantaggio è che ci vuole un po 'di tempo per abituarsi e un po' di apprendimento.

Il modo più efficace per lavorare in verticale è avere sviluppatori full-stack: in questo modo una storia può essere tipicamente eseguita da una persona (o più di una, ma senza attività di pipeline ). Chiaramente ciò richiede che gli sviluppatori lavorino verticalmente nello stack (da html a database nel caso di un'applicazione web).

Se la tua squadra non è abituata a lavorare su storie verticali, allora è molto probabile che facciano il contrario: ogni persona avrà conoscenza solo di un livello / livello dell'applicazione. Quando si introducono storie verticali, è possibile aspettarsi che il team le divida in attività corrispondenti ai livelli e quindi distribuisca le attività a persone diverse. Questo sarà molto inefficiente.

L'approccio migliore che posso dare in merito è quello di tollerare inizialmente questo pipeling, chiarendo al contempo che l'obiettivo a lungo termine è completamente diverso. Fai in modo che i membri del team condividano il programma in modo tale da creare fiducia e, infine, consentire alle persone di essere completamente indipendenti.

Non sono d'accordo con l'altra risposta che questo approccio porta il debito tecnico. Può, ma così può qualsiasi altro approccio.

Ho pensato molto a questa domanda esatta.

Penso che sia importante distinguere tra affettare le responsabilità individuali e affettare le responsabilità del team. Concentrerò questa risposta principalmente sull'analisi dei team.

Per alcuni background: ho lavorato a progetti con sviluppatori full-stack, sviluppatori single-tier, team verticali (full-stack), team orizzontali (a livello singolo) e team diagonali. Per squadra diagonale intendo contenere tutti i livelli necessari per una storia ma non necessariamente tutti i livelli del sistema, e possibilmente contenere più sviluppatori focalizzati sullo stesso livello (i); in altre parole verticale nello spirito, ma forse in qualche modo orizzontale nell'aspetto o nei dettagli di implementazione.

Recentemente ho lavorato in un gruppo che è passato da squadre orizzontali a squadre diagonali (quasi verticali). È stato particolarmente istruttivo vedere lo stesso gruppo di persone allineato in due modi diversi. Rende abbastanza evidenti alcuni vantaggi e svantaggi.

Arrotolerò la mia opinione finora con il seguente confronto riassuntivo:

Squadre orizzontali

I vantaggi:

• Favorisce una buona separazione delle preoccupazioni e dei livelli liberamente accoppiati
• Gestione della distribuzione del carico di lavoro molto più semplice
• Facile da gestire per tecnici specializzati
• Promuove la collaborazione intra-livello, le migliori pratiche, l'orgoglio e una cultura di eccellenza
• Si allinea con i modelli di comunicazione naturali / emergenti

Svantaggi:

• Può portare all'isolamento dei tier e quindi ostacolare la comunicazione inter-tier
• Abilita la cultura "bolla" di livello se non attenuata
• Difficile approfittare della leadership generalista
• ostacola i generalisti

Squadre verticali / diagonali

I vantaggi:

• Tutte le parti di una storia di un utente in una squadra ("sportello unico")
• Assiste in modo specifico la distribuzione di storie di livello n in un singolo sprint (anche se ne hai davvero bisogno?)
• Promuove la collaborazione inter-tier e la crescita delle competenze generaliste
• Supporta i generalisti

Svantaggi:

• Gestione della distribuzione del carico di lavoro molto più difficile
• Permette una scarsa separazione delle preoccupazioni e livelli strettamente accoppiati
• ostacola la specializzazione riducendo la comunicazione intra-tier; è difficile vedere come una cultura di eccellenza possa nascere da questa struttura senza aggiungere attenuanti comportamenti orizzontali / specialistici

Non credo che l'appartenenza al team abbia una soluzione valida per tutti. Sembra piuttosto semplice, tuttavia, che la squadra verticale si alline meglio per le organizzazioni che richiedono generalizzazione. Se i tuoi ingegneri sono generalisti e amano lavorare con lo stack completo, è un buon motivo per considerare i team verticali. Il team orizzontale si allinea meglio per le organizzazioni che richiedono specialisti. Se i tuoi ingegneri sono specialisti, è un buon motivo per considerare i team orizzontali.

Come altri hanno già menzionato, strutture / comportamenti secondari che tagliano l'altra direzione possono aiutare a mitigare gli inconvenienti di entrambi i sistemi. Un fattore mitigante interessante è la durata dello sprint. Brevi sprint rendono alcuni degli svantaggi dei team orizzontali più tollerabili. Se puoi costruire il backend questa settimana e il frontend della prossima settimana, potrebbe essere abbastanza veloce?

Applicare alcuni di questi principi proposti a un problema del mondo reale ... Dirò che le sezioni orizzontali hanno funzionato abbastanza bene per un vero team di sviluppo SaaS su cui ho lavorato che stava risolvendo problemi tecnici molto impegnativi in ogni livello (dove la specializzazione era a mio avviso incredibilmente importante), dove la frequenza di consegna (e l'affidabilità a granularità / frequenza elevate) era fondamentale per il successo aziendale. Si prega di notare che questa conclusione è per un team del mondo reale molto particolare, non una dichiarazione generale di superiorità dell'affinamento orizzontale.

Un avvertimento: sono probabilmente prevenuto nel credere alle affermazioni di abilità generaliste di qualsiasi individuo nel moderno mondo dello sviluppo software senza prove significative, sebbene abbia conosciuto alcuni rari generalisti eccezionali. Ritengo che la generalità sia un ordine (verticale?) Alto, in particolare perché ogni livello cresce in complessità e con la proliferazione di linguaggi / piattaforme / framework / implementazioni alternative, ciascuno dei quali soddisfa esigenze diverse. In particolare, in questi giorni, un tuttofare può facilmente diventare un maestro di nessuno. Inoltre, aneddoticamente, trovo che molte persone vogliano specializzarsi un bel po ', anche con alcune eccezioni.

Il grande inconveniente che ho riscontrato è che rende difficile per un team creare l'applicazione seguendo un approccio architettonico unificato.

Nelle prime fasi del progetto ognuno scriverà i propri livelli in isolamento. Le storie (e gli strati coinvolti) funzioneranno, ma quando si guarda indietro al prodotto consegnato alla fine dello sprint sarà facile vedere le lievi differenze tra le idee architettoniche di ogni sviluppatore.

Questo genere di cose è inevitabile, ma non un blocco. Ho provato a combattere questo in due modi:

1. Avere lunghe discussioni sul design con il team prima di implementare ogni storia
   • Questo si stanca rapidamente. È spesso troppo presto per consentire a chiunque di prendere una decisione informata e poi si finisce semplicemente a discutere su cose che dovranno assolutamente cambiare comunque.
2. Continua e sviluppa un relativo isolamento, tenendo presente che stai accumulando debito tecnico .
   • La chiave qui è quella di registrare il debito tecnico (architettonico) come un problema. Questo è qualcosa che dovrà essere restituito.
   • Dopo alcuni sprint sarà più facile decidere su un'architettura coerente e unificata. Questo è il momento in cui dovresti richiedere uno sprint indurito per rimborsare parte del tuo debito tecnico (rifattore del codice esistente). In alternativa, puoi ripagarlo durante le successive iterazioni del progetto.

L'unico altro problema a cui posso pensare a parte questo è che di solito c'è un gran numero di codice per l'inserimento all'inizio di un progetto. La scrittura di storie di fette verticali significa che la velocità della squadra nelle prime storie sarà artificiosamente bassa a causa di questo piatto di prerequisiti ... ma fintanto che tutti sono consapevoli che ciò dovrebbe influire solo sul primo paio di sprint, allora tutto va bene.

Non conosco nessuno svantaggio, tuttavia le storie verticali possono essere implementate male.

Quando ho iniziato la mia carriera, mi sono unito a una squadra che desiderava fare XP, ma non ne aveva esperienza. Abbiamo commesso una serie di errori durante l'utilizzo di storie utente verticali.

Uno dei problemi che abbiamo riscontrato durante il lavoro orizzontale era che le funzionalità non si integrano bene tra i livelli. Le API spesso non corrispondevano alle specifiche, alle funzionalità mancate e a numerosi altri problemi. Spesso, poiché lo sviluppatore del programma era passato a qualcos'altro, dovresti o doverli aspettare o farlo tu stesso da solo.

Passare a fare Vertical Stories ha risolto questi problemi e ridotto / eliminato lo spreco di rielaborazione da integrare.

Ci sono un certo numero di pratiche XP che supportano questo modo di lavorare. Chiunque deve essere in grado di lavorare su qualsiasi area e tutti dovrebbero correggere i bug che trovano ( proprietà del codice collettivo ).

Quando stai apportando la modifica alle storie verticali, può essere complicato lavorare in aree che non ti sono familiari. Programmazione coppie può aiutarti, se non sei sicuro di prendere qualcuno nel team che è in coppia con loro. Ho trovato che la programmazione di coppie è il modo più veloce per essere aggiornato con una nuova base di codice.

Senza proprietari forti su livelli abbiamo scoperto che emergevano alcune duplicazioni. Anche se questo non era un grosso problema, dovevamo assicurarci di aver praticato Refactor senza scrupoli (con test appropriati per supportare ).

Anche se accenno a una serie di problemi, non penso che sia stata la causa delle storie dell'utente verticale. In effetti, ha reso i problemi più evidenti. Dopo aver effettuato l'opzione, i problemi non sono più stati offuscati tra i team o i livelli dell'applicazione.