Come allocare preoccupazioni trasversali nella pianificazione dello sviluppo software agile?

Question

Come allocare preoccupazioni trasversali nella pianificazione dello sviluppo software agile?

#1 da (3 voti)
#2 da (1 voti)
#3 da (1 voti)

5

Il mio datore di lavoro si è spostato dai tradizionali progetti a cascata a una versione modificata di agile. Il lavoro è suddiviso in storie, che sono stimate e sequenziate in iterazioni di due settimane. Ogni iterazione include punti per la creazione, il test e l'accettazione di funzionalità.

Le storie sono incentrate su caratteristiche aziendali verificabili. Non c'è modo di pianificare e tenere conto di problemi trasversali come la progettazione, l'architettura, l'infrastruttura o (ironicamente) la gestione dei progetti.

I team agili dovrebbero includere esplicitamente storie o compiti per queste preoccupazioni trasversali? In che modo il tuo team gestisce le attività che non vanno mai via? Sono "off book"?

agile planning

posta duffymo 15.08.2014 - 14:42

fonte

3 risposte

Leggi altre domande sui tag agile planning

Accesso basato sul ruolo alle risorse per un servizio RESTful REST-full design: approccio raccomandato per il recupero delle entità correlate

score 3 · Answer 1

Ho visto due approcci di base:

Aggiungi attività ricorrenti e in timebox a ogni sprint per questi tipi di problemi. Ciò aumenta la visibilità delle attività e consente di verificare se è stato eseguito un passaggio o un'attività specifica. Il rovescio della medaglia è la clonazione in alto o la ricreazione di queste attività dallo sprint allo sprint.
Basta impostare un timebox collettivo per queste attività per ogni sprint, riducendo di conseguenza il tempo disponibile per l'implementazione di storie nello sprint. È più semplice da gestire, ma rende più difficile gestire le singole attività incluse nella confezione.

score 1 · Answer 2

Sì, crea storie per design, architettura, infrastruttura e gestione dei progetti.

Potresti voler creare una scheda aggiuntiva per loro, almeno inizialmente.

In definitiva coinvolgono persone che lavorano, così come si sviluppano dovrebbero essere in grado di assegnare loro delle persone o spostarle nella bacheca di un team.

Una cosa che facciamo per storie più intangibili a volte è la creazione di spikjes con limiti di tempo, ad es. "2 giorni" per svolgere tali compiti.

score 1 · Answer 3

TL: DR; Storie per l'architettura dei sistemi, design emergente attraverso il refactoring e la deduplicazione del codice.

Questo è ciò che facciamo nel mio lavoro:

L'architettura e l'infrastruttura dei sistemi viene considerata una storia (o più storie), nel nostro linguaggio sarebbe una scheda di ricerca. La ricerca fatta quando risponde a una domanda e di solito porta a storie o schede più ben definite.
La progettazione del codice viene gestita in modo diverso. Pratichiamo la progettazione emergente attraverso il costante refactoring e la deduplicazione del codice che è sempre una parte di ogni attività di programmazione che facciamo.

An A parte:

Come ben saprai, il design di refactoring può essere molto difficile, specialmente con una base di codice stabilita. Uno dei maggiori fattori attenuanti per noi che rende ancora possibile la progettazione iterativa è lo sviluppo basato su test di accettazione. Creiamo una suite di test che definisce e verifica il comportamento del nostro sistema. Ciò ci ha permesso di strappare completamente interi sottosistemi, reimplementarli ed essere certi che tutto funzioni. Di solito, proviamo a farlo in modo iterativo e nel fornire valore al cliente. Tuttavia, ci sono delle eccezioni alla regola e quando si presentano (raramente) abbiamo trascorso alcuni giorni esclusivamente a rielaborare parte del design. MA, va bene perché sono eventi rari e il nostro processo consente eccezioni.