Come gestisci il design in Scrum?

Come gestisci il design in Scrum? Hai ancora documenti di design ben scritti per ogni iterazione della mischia? Ti basta fare delle note di progettazione con diagrammi UML? O hai solo un codice ben commentato?

Ogni iterazione può comportare una modifica del design, quindi volevo solo sapere come le persone lo catturano, così i nuovi sviluppatori hanno un lavoro facile per comprendere il dominio e salire a bordo il più rapidamente possibile.

solo perché è mischia non significa che tutto cambi ad ogni scatto!

Scrum significa fare ciò che è necessario (ma non di più) . Devi ancora fare il disegno e devi ancora documentare. È solo che l'importo non è fisso né come farlo.

Parte della pianificazione di ogni sprint è decidere cosa deve essere fatto. Se è necessario progettare qualcosa nel backlog perché influisce su altre cose, è necessario aggiungere un'attività specifica per i processi di progettazione e farlo prima dell'attività di implementazione.

Ho molto da dire su questo argomento. Ho visto molti casi in cui aziende / team / persone affermano di utilizzare un approccio Agile al software, ma in realtà vogliono raccogliere i frutti che i metodi Agile promettono senza aderire ai principi.

Affinché l'iterazione rapida funzioni, è necessario eseguire uno sviluppo guidato dai test (ho smesso di dire che devi fare riluttante TDD). In TDD, i tuoi test esprimono il design e l'intento del codice (quando dicono "il codice è la documentazione" quello che dovrebbero dire è "i test sono la documentazione"). Scrivendo unit test che esprimono la tua comprensione della funzionalità a portata di mano stai dichiarando esplicitamente ciò che ritieni debba fare il codice. Quindi scrivi il codice che lo fa. Quindi refactoring quel codice in modo che aderisca ai buoni principi architettonici "Red-Green-Refactor".

L'esecuzione dei test unitari con ogni check-in (o anche prima di ogni check-in) verifica che il nuovo codice che hai scritto non interrompa la funzionalità prevista in qualche altra area dell'applicazione. Ciò fornisce una rete di sicurezza che consente di modificare il codice con l'abbandono senza problemi. Man mano che aumenta la comprensione dei requisiti a portata di mano, è possibile modificare il test per riflettere quella nuova conoscenza. Il vero design risiede nei test unitari. Tutto il resto (incluso il codice che non è coperto) è una bugia.

Ecco alcune letture consigliate

• Codice pulito
• Principi, schemi e pratiche di sviluppo software agili
• Il programmatore pragmatico

Questi sono buoni posti per iniziare a cercare di imparare come affrontare veramente lo sviluppo agile.

Scrum è una metodologia di gestione del progetto, non una metodologia di sviluppo del software. Scrum viene in genere utilizzato in combinazione con una metodologia Agile. Qui sta la tua risposta.

Non c'è tanto design frontale quanto i requisiti cambiano spesso. Quindi progettare a livello di classe è generalmente una perdita di tempo. Tuttavia, può essere utile abbozzare decisioni architettoniche di livello superiore.

Il problema con la realizzazione di documenti di progettazione pesanti è che sono obsoleti non appena vengono creati. Quindi ciò che ha funzionato meglio è di solito una documentazione di alto livello che difficilmente cambierà completamente in breve tempo.

Scrum è un modello iterativo e incrementale basato su valori agili . Ciò significa che non hai una fase di progettazione separata. L'idea è che dovresti occuparti costantemente del design, così come ti occupi costantemente dell'analisi, dell'implementazione, del testing e dell'integrazione nel corso del progetto.

Hai bisogno di un po 'di pianificazione affinché questo funzioni. Partecipa alla riunione di pianificazione dello sprint , in cui il team stima le attività per lo sprint a venire. Molte persone non si rendono conto che questo non è solo un incontro di stima, ma anche uno sforzo di progettazione. Ad esempio, un'attività potrebbe essere "Aggiungi codice per nuovo modello di auto". Non puoi ancora stimarlo, devi sapere un po 'di più. Quindi il team discute del design e propone una soluzione ampia ("Auto di sottoclasse?") E lo aggiunge come promemoria all'attività. Raramente hai bisogno di più formalità di quella. Ora hai un'idea di come risolvere il problema. Non hai ancora tutti i dettagli e va bene, conosci abbastanza il design da poter fare una stima comoda. Senza dover creare alcun diagramma (a questo punto).

Per la vera documentazione fisica , consiglio di creare un diagramma di panoramica dei sistemi su una parete che tutti possano vedere. La panoramica deve solo includere le classi e i moduli più importanti e raramente dovrebbe essere aggiornata. Inoltre, la creazione di alcuni diagrammi di stato per le classi più importanti nel sistema è molto utile. Cospargere con alcuni diagrammi di sequenza selezionati di casi d'uso tipici per consentire alle persone di vedere rapidamente come sono collegati gli oggetti. Presumo che tu possa generare diagrammi di gerarchia di classi dal tuo codice, in modo tale problema sia facilmente risolto.

Si noti che tutti i diagrammi vengono creati dopo l'implementazione effettiva. Ciò è coerente con il "software funzionante sulla documentazione completa" e la progettazione just-in-time.

E sì, il codice leggibile è sicuramente documentazione.

L'architettura generale del progetto e il design di alto livello verrebbero realizzati al di fuori dei team di scrum quando i proprietari del progetto stanno creando le storie.

Deve esserci abbastanza di un disegno complessivo scritto in qualsiasi forma per aiutare a vedere la relazione tra le storie e le aspettative del cliente.

Parte della progettazione necessaria per ogni storia sarebbe stata fatta durante la pianificazione e la negoziazione con il proprietario del prodotto durante la pianificazione.

La maggior parte dello sforzo progettuale per una storia verrebbe fatto nello sprint.

Se la storia non è abbastanza definita per essere stimata, allora una finestra temporale potrebbe essere messa da parte nello sprint corrente per fare abbastanza lavoro di progettazione da poter creare una storia appropriata per uno sprint successivo.

La mia comprensione è che si esegue una progettazione di livello superiore con i requisiti iniziali che si raccolgono all'inizio del progetto. Documentate bene questo disegno.

Quindi, quando si implementa effettivamente il requisito, si modifica la progettazione di livello inferiore come è necessario, ma si evita di modificare la progettazione di livello superiore.

Bene, è così che mi è stato spiegato cinque minuti fa comunque ...

Oggi esiste una divisione all'interno della comunità Eclipse tra strumenti UML tradizionali focalizzati su MDD in cui il modello guida il codice / sviluppo e Omondo che ritiene che le iterazioni dovrebbero guidare il processo di sviluppo e certamente non solo il modello.

Sono d'accordo con loro perché MDD è una schifezza mentre UML è davvero un modo eccellente perché standardizzare per comunicare con altri membri del team.