Ultimamente abbiamo sentito molto spesso il concetto di "affettamento verticale". Penso che abbiamo fatto un lavoro migliore nel creare storie più piccole e ben definite. Quando stavo cercando informazioni sull'affinamento verticale, nessuno ha definito quanto fossero grandi i loro sistemi. Ad esempio, ne ho visto uno in cui Adobe ha stipulato un contratto con il software di capra di montagna per trovare una soluzione per ottenere le feature in verticale, anche su più team.
Per maggiori informazioni su di me, il mio background era con un'azienda più grande in cui i team erano responsabili di alcuni sistemi di back-end e dovevamo lavorare su almeno due sprint per fare le cose come "feature" - c'era il lavoro di back-end per l'altro sistema e il lavoro di integrazione per il nostro sistema. Il mio punto è che il quadro di riferimento per l'affettatura verticale in quella società era in qualche modo a livello di "progetto". Un progetto può essere un insieme completo di database, server back-end, servizi in background, accodamento / elaborazione dei messaggi, ecc., Ma era ben definito attorno a un progetto aziendale centrale.
La nostra app web orientata al cliente, ad esempio, aveva più DB propri, estratta da diversi archivi dati in cui altri progetti hanno riversato informazioni, avevano app batch che venivano eseguite ogni notte, leggere e scrivere da e verso diverse code di messaggi a inviare e-mail ai clienti, ecc. Anche con tutto ciò, tutte le "funzionalità deliverable" erano verticali all'interno del "progetto". Lo stack di solito è andato: client - > server web - > database o servizio web.
Alla nuova società, abbiamo una rete di progetti piuttosto intricata con pochi sviluppatori (avevo più sviluppatori del mio team nell'ultima azienda e principalmente ci siamo integrati solo con altri sistemi). 
Ultimamente,perunadeterminatafunzione,dobbiamoapportareleseguentimodifiche:
- IdatifunzionanoinunfamosoCRMbasatosucloud(esisteunteamseparatoperquesto)
- lavorosuldatabaseinloco,disolitosolo2o3deiDBvengonotoccatiperunadeterminatafunzione3.DueappdiserviziAPIdistinte:unaèinmodalitàdimanutenzionefinoaquandotutteleapppossonoessereaggiornateallanuovaAPI.Entrambisiintegranocon1.e2.sopra.
- PiùclientchesiconnettonoallavecchiaAPI
- PiùclientchesiconnettonoallanuovaAPI(alcunisicolleganoadentrambi)
- LavecchiaAPIchiamalanuovaAPIperalcunecose,quindiintegriamolalogicaprincipaleinun'unicaposizione,inattesacheiclientvenganoaggiornati.
- Abbiamodiversiprocessieseguiticomeappdiserviziooappbatchsuiserverdelleapp.
*notacheogniwebclienthaancheilproprioserverback-end,nonmostratoneldiagramma.
Ilmioframeofreferenceperattaccarequestoecrearestoriediutentièsimileallamiaesperienzanellasocietàprecedente,principalmenteacausadeiseguentifattori:
- Dimensionidellasquadra(2-3)
- DimensioniUserStory(8punti)
- lunghezzasprint
- variandoletecnologielatoclient
- Sentocheunauserstorydovrebbeessereingradodiessereaffrontatadaunasingolapersonapertracciarepiùfacilmenteilcompletamento.Inalcunicasi,illavoropotrebbeesserediviso,maaquelpuntosarebbeprobabilmentealivelloorizzontale("Si può fare il database mentre funziona la logica di back-end, e io farò l'interfaccia utente?") .
Penso che la cosa più grande di cui siamo preoccupati sia l'8 punti. La gestione è flessibile su questo, ma non molto. È difficile quando i punti della storia sono 2-3 ore. Quello che ho proposto è che abbiamo un quadro di riferimento di "progetto". Credo che ottenere la funzionalità implementata nella nuova API, ad esempio, sia un buon risultato in 8-13 punti. Questo può includere il livello del database, ecc., Quindi è ancora una fetta verticale all'interno dell'ecosistema, ma stiamo tagliando orizzontalmente i sistemi.
Dopodiché, ogni app client può essere la sua storia, poiché ognuno di essi ha il proprio codice client e server, oltre all'integrazione API.
Noi (sviluppatori) di solito proviamo a utilizzare una funzione [TFS] per i principali sistemi di back-end (logica aziendale) e una funzione [TFS] per le app client (integratori dei sistemi back-end). Monitoriamo le "funzionalità" su larga scala richieste dall'azienda come Iniziative o Epiche quando toccano un'ampia gamma di applicazioni e per quelle che potremmo avere una funzione per app cliente. Potremmo affrontare 2-3 funzionalità in uno sprint come questo, ed è più facile per noi monitorare gli sviluppatori e cercare di avere una storia per realizzare questo, che si estende su più implementazioni di servizi e app web.
Ci sono dei pro o dei contro in entrambi gli approcci e hai altre esperienze con l'affettamento verticale su un'ampia catena di applicazioni / servizi?