Storie di sistema per un'architettura agile

Question

Mentre cercavamo di applicare principi agili al nostro processo di sviluppo, in particolare i principi di Scrum e le storie utente simili a XP, abbiamo affrontato un problema relativo all'architettura.

Forse siamo ancora troppo legati allo sviluppo incentrato sull'architettura, tuttavia stiamo cercando di mantenere un forte sviluppo basato su componenti, mescolato con i principi di modellazione agili. Il nostro obiettivo è quello di avere un piccolo design davanti, incline alle evoluzioni durante lo sviluppo.

Quello che sto cercando è qualcosa che potrebbe farmi inserire nelle mie storie arretrate sulla mia architettura e le componenti al suo interno: storie di sviluppo, non solo storie di utilizzo. La storia del sistema potrebbe essere un diverso tipo di storia utente, che indica qualcosa che non è strettamente correlato al valore aziendale, ma che è invece legato all'architettura e ai problemi di qualità di un sistema.

Edit: ho trovato this research dell'Università di Aalborg di "storie sviluppatore".

Hai esperienza, idea o opposizione?

Grazie in anticipo! (questa è la mia prima domanda!: D)

Answer 1

IMO un arretrato dovrebbe non includere sviluppatore storie. Non c'è modo che nessun Product Owner possa sensibilmente dare la priorità a questi aspetti insieme alle funzionalità aziendali. E cosa succede se il Product Owner ritiene che uno di essi non sia importante e quindi lo estrae dal backlog? Se il team insiste nel mantenere la trama, si è in una situazione in cui la proprietà del backlog diventa poco chiara.

Tuttavia, sicuramente penso che il team abbia bisogno di costruire l'architettura nelle prime fasi del progetto. Un problema nel mio progetto era che ci siamo concentrati troppo sulla funzionalità nei primi sprint.

Pensiamo al "debito architettonico" (simile al debito tecnico) come il tempo che deve essere speso per costruire infrastrutture e architettura. A differenza del debito tecnico (che inizia a zero e si accumula mentre il team produce funzionalità senza un adeguato refactoring), un team inizia con il debito architettonico e deve lavorare per ridurlo. Il tempo impiegato per ridurre il debito architettonico significa che dedicare meno tempo alla produzione di funzionalità, ad es.una velocità ridotta della squadra e una riduzione dello sprint. In questo modo il debito architettonico è simile al debito tecnico. Se emergessero requisiti che non si adattavano all'architettura attuale, il livello del debito architettonico aumenterebbe.

Tenere presente che la squadra deve decidere (ed essere in grado di giustificare il proprietario del prodotto) come trascorrere il proprio tempo. E così possono dividere il loro sforzo tra funzionalità, debito tecnico e debito architettonico come meglio credono.

I lavori di architettura dovrebbero comunque essere guidati dalla funzionalità. In altre parole, il team dovrebbe creare un'infrastruttura per supportare e abilitare una particolare user story. Non solo perché pensano che sarà utile in futuro. The YAGNI principle si applica a questo tipo di approccio.

Answer 2

La mia risposta è here.

C'è un equilibrio molto impegnativo tra il lavoro di architettura e il lavoro più specifico. Tecnicamente, entrambi sono approcci validi e funzionano, ma più a lungo si fa ritardare una certa quantità di prodotto utilizzabile (risultati sprint), maggiore è il rischio che si assume che non si stia creando il prodotto giusto (requisiti utente, requisiti di prestazione, ecc.). Non appena possibile, raggiungi un punto in cui puoi eseguire test a livello di sistema per dimostrare che il tuo prodotto funziona e puoi dimostrare il valore e la direzione del prodotto con i tuoi stakeholder.

Answer 3

E 'semplice come mettere un Assicurarsi che il componente di adesione può essere testato scollegato dalla tutti gli altri componenti story 'utente', il tuo arretrato DOVREBBE avere system/sviluppo-storie, fino a quando è stato rimesso in sincronia con il desiderio del proprietario del prodotto di tale implementazione.

Questo è il modo in cui di solito mettere i requisiti non funzionali in un portafoglio ordini, come "Il modello di dominio deve essere eseguito su un datacenter diverso sotto il bilanciamento del carico", ecc

Answer 4

Una lente che trovo utile per affrontare le storie degli sviluppatori è pensare a chi è "l'utente" di una determinata storia. Solo perché non stai scrivendo una funzionalità che verrà vista da persone esterne alla tua azienda non significa che non ci sia un utente per quel lavoro. Potresti scrivere un codice per una squadra in fondo al corridoio. In alcuni casi, l'utente è te stesso. Questo è spesso il caso delle storie degli sviluppatori. Pensa "Come sviluppatore, ho un'architettura scalabile in modo che possa facilmente aggiungere nuove funzionalità." Chiamando l'utente particolare, fornisce al proprietario del prodotto alcune informazioni su chi vedrà il valore della storia. E sottolineando il "perché" è anche utile per veicolare i benefici che la storia spera di ottenere. Come altri hanno menzionato, la gestione del backlog si riduce a una negoziazione tra il proprietario del prodotto e il team. E come sempre, devi capire cosa funziona meglio per il tuo team, indipendentemente dal dogma del processo. Ogni squadra ha una situazione diversa e le idee che funzionano bene per una squadra non sempre si traducono in un'altra.

Answer 5

Nel nostro team lo chiamiamo "IT-card", ovvero le carte del modulo: "Come sviluppatore, non voglio rifattorizzare il componente xyz per ridurre i costi di manutenzione e aumentare la flessibilità."

I membri del team sono liberi di scegliere qualsiasi IT-card che ritengono importante invece di fare scoppiare una "carta delle caratteristiche" dal backlog prioritario.

Trovo che questo approccio funzioni ragionevolmente bene per mantenere il debito tecnico a un livello accettabile e consentire un ritmo sano di innovazione.

L'ho trovato un po 'carente come mezzo per riprogettare il sistema. È difficile giustificare lunghe partenze dal flusso della produzione di feature.

Mentre sto scrivendo questo, penso che si possa avvicinare l'architettura leggendo le storie. Identifica gli obiettivi architettonici con le epopee in cui dividi in un tema su cui concentrarti.