Svantaggi delle storie utente verticali

L' approccio agile consiste nel strutturare il lavoro in user story verticali e fornire un pezzo di applicazione focalizzato ma perfettamente funzionante da un capo all'altro . Poiché questo è il nuovo approccio alla costruzione di software, ho letto molta letteratura sul perché sia ​​meglio delle storie orizzontali, ma non trovo molto degli svantaggi di questo approccio.

Ho già bevuto l'agile dispositivo di raffreddamento e sono anche d'accordo sul fatto che tagliare la torta verticalmente abbia molti vantaggi rispetto all'affettare orizzontale. Ecco un breve elenco di svantaggi che potrei trovare:

• Uno sviluppatore potrebbe inizialmente essere più lento nell'implementazione di una funzionalità perché deve comprendere tutte le tecnologie necessarie per sviluppare la storia (UI + livello di servizio + accesso ai dati + rete, ecc ...)
• La progettazione complessiva dell'architettura (cassa portante della colonna portante dell'applicazione) non si adatta davvero a questo mantra (tuttavia alcuni potrebbero sostenere che è parte di una storia utente sviluppare / modificare l'architettura complessiva)

Quali sono alcuni altri svantaggi del taglio verticale delle storie degli utenti?

Nota: il motivo per cui sto ponendo questa domanda ora è perché cercherò di convincere una squadra a iniziare a scrivere storie in "modo verticale" e voglio essere in grado di far emergere i possibili compromessi in anticipo, così hanno vinto considera l'approccio un fallimento quando si trovano di fronte agli svantaggi.

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

Il modo più efficiente di 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 su tutto lo stack (da HTML a database nel caso di un'applicazione Web).

Se il tuo team non è abituato a lavorare su storie verticali, è molto probabile che facciano il contrario: ogni persona avrà conoscenza di un solo livello / livello dell'applicazione. Quando introduci storie verticali, puoi aspettarti 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 al riguardo è tollerare inizialmente questa pipeline, chiarendo che l'obiettivo a lungo termine è completamente diverso. Avere membri del team attraverso i livelli abbina il programma in modo da creare fiducia e infine consentire alle persone di essere completamente indipendenti.

Non sono d'accordo con l'altra risposta che questo approccio comporta un debito tecnico. Può, ma anche qualsiasi altro approccio.

Ho pensato molto a questa domanda esatta.

Penso che sia importante distinguere tra suddivisione in base alle responsabilità individuali e suddivisione in base alle responsabilità del team. Concentrerò questa risposta principalmente sull'affettare le squadre.

Per alcuni retroscena: ho lavorato a progetti con sviluppatori full-stack, sviluppatori single-tier, team verticali (full-stack), team orizzontali (single-tier) 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 anche contenere più sviluppatori che si concentrano sugli stessi livelli; in altre parole verticale nello spirito ma forse in qualche modo orizzontale nell'aspetto o nei dettagli di attuazione.

Di recente 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 chiari alcuni vantaggi e svantaggi.

Fin qui completerò la mia opinione con il seguente confronto di sintesi:

Squadre orizzontali

vantaggi:

• Favorisce una buona separazione delle preoccupazioni e livelli vagamente 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 modelli di comunicazione naturali / emergenti

svantaggi:

• Può portare all'isolamento dei livelli e quindi ostacolare la comunicazione tra livelli
• Abilita la cultura di livello "bolla" se non modificata
• Difficile trarre vantaggio dalla leadership generalista
• Ostacola i generalisti

Squadre verticali / diagonali

vantaggi:

• Tutte le parti di una user story in un team ("sportello unico")
• Aiuta in particolare a fornire 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
• Consente una scarsa separazione delle preoccupazioni e livelli strettamente accoppiati
• Ostacola la specializzazione limitando la comunicazione intra-tier; è difficile vedere come una cultura dell'eccellenza possa nascere da questa struttura senza aggiungere comportamenti mitigatori orizzontali / specialistici

Non credo che l'appartenenza al team abbia una soluzione unica per tutti. Sembra abbastanza semplice, tuttavia, che il team verticale si allinei meglio per le organizzazioni che richiedono generalizzazione. Se i tuoi ingegneri sono generalisti e ti piace lavorare a tutto campo, questa è una buona ragione per considerare i team verticali. Il team orizzontale si allinea meglio per le organizzazioni che richiedono specialisti. Se i tuoi ingegneri sono specialisti, questa è una buona ragione per prendere in considerazione team orizzontali.

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

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

Un avvertimento: probabilmente sono di parte contro il credere alle affermazioni delle capacità generaliste di qualsiasi individuo nel moderno mondo dello sviluppo del software senza prove significative, anche se ho conosciuto alcuni rari generalisti eccezionali. Sento che la generalità è davvero un ordine elevato (verticale?), In particolare man mano che ogni livello cresce in complessità e con la proliferazione di linguaggi / piattaforme / quadri / distribuzioni alternative, ognuno dei quali soddisfa esigenze diverse. In questi giorni, in particolare, un tuttofare può facilmente diventare un maestro di nessuno. Inoltre, aneddoticamente, trovo che la maggior parte delle persone voglia specializzarsi un po ', sempre con alcune eccezioni.

Il grande svantaggio 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 strati in modo isolato. Le storie (e gli strati coinvolti) funzioneranno, ma guardando indietro al prodotto consegnato alla fine dello sprint sarà facile vedere le lievi differenze tra le idee architettoniche di ciascuno sviluppatore.

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

1. Discuti a lungo con il team prima di implementare ogni storia
   • Questo si stanca rapidamente. Spesso è troppo presto per chiunque di prendere una decisione informata e poi finisci per litigare su cose che dovranno sicuramente cambiare comunque.
2. Vai avanti e sviluppa in relativo isolamento, tenendo presente che stai accumulando debito tecnico .
   • La chiave qui è di registrare il debito tecnico (architettonico) come un problema. Questo è qualcosa che dovrà essere rimborsato.
   • Dopo alcuni sprint sarà più semplice decidere un'architettura coerente e unificata. Questo è quando si dovrebbe richiedere uno sprint di indurimento per rimborsare parte del proprio debito tecnico (rifattorizzare il codice esistente). In alternativa, puoi ripagarlo frammentariamente nelle successive iterazioni del progetto.

L'unico altro problema che mi viene in mente a parte quello è che di solito c'è molto codice da aggiungere all'inizio di un progetto. Scrivere storie a sezioni verticali significa che la velocità della squadra sulle prime storie sarà artificialmente bassa a causa di questo prerequisito plateplate ... ma fintanto che tutti saranno consapevoli che ciò dovrebbe influenzare solo la prima coppia di sprint, allora tutto andrà bene.

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

Quando ho iniziato la mia carriera, mi sono unito a un team che voleva fare XP ma non ne avevano esperienza. Abbiamo commesso numerosi errori durante l'utilizzo di user story verticali.

Uno dei problemi che abbiamo riscontrato durante il lavoro orizzontale era che le funzionalità non si integravano bene tra i livelli. Le API spesso non corrispondevano alle specifiche, alle funzionalità mancanti e a numerosi altri problemi. Spesso perché lo sviluppatore del passato era passato a qualcos'altro, avresti dovuto aspettarli o farlo da solo.

Passare alle storie verticali ha risolto questi problemi e ridotto / eliminato gli sprechi di rilavorazione per l'integrazione.

Esistono diverse 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 modificando le storie verticali, può essere difficile lavorare in aree che non conosci. La programmazione in coppia può essere d'aiuto, se non sei sicuro di prendere qualcuno nel team che è accoppiato con loro. Ho trovato che la programmazione in coppia è il modo più veloce per aggiornarmi con una nuova base di codice.

Senza forti proprietari su livelli abbiamo scoperto che stavano emergendo delle duplicazioni. Anche se questo non era un grosso problema, dovevamo assicurarci di praticare senza pietà Refactor (con test appropriati per supportare).

Anche se menziono una serie di problemi, non credo che la causa siano state le storie di utenti verticali. In effetti, ha reso i problemi più evidenti. Dopo aver effettuato il passaggio, i problemi non venivano più offuscati tra i team o i livelli dell'applicazione.