Come gestisci il design in Scrum? Hai ancora documenti di design ben scritti per ogni iterazione di mischia? Hai solo disegnato note con diagrammi UML? O hai solo un codice ben commentato?
Ogni iterazione può comportare la modifica del design, quindi volevo solo sapere in che modo le persone catturano questo aspetto, quindi i nuovi sviluppatori hanno un facile compito di comprendere il dominio e di salire a bordo il più rapidamente possibile.
solo perché è mischia non significa che ogni cosa cambia ogni sprint!
Scrum parla di facendo ciò che è necessario (ma non più) . Hai ancora bisogno di fare il design e hai ancora bisogno di documentare. È solo l'importo non è stato risolto né come farlo.
Parte della pianificazione di ogni sprint sta decidendo che cosa deve essere fatto. Se qualcosa nel backlog deve essere progettato 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 dicono di usare un approccio Agile al software, ma in realtà vogliono raccogliere i frutti che i metodi Agile promettono senza aderire ai principi.
Affinché la iterazione rapida funzioni, dovresti fare uno sviluppo basato sui test (non mi sono limitato a dire che devi fare il TDD con riluttanza). 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 funzione a portata di mano, stai esplicitamente affermando ciò che ritieni che il codice debba fare. Quindi scrivi il codice che lo fa. Quindi devi refactoring quel codice in modo che aderisca ai principi di architettura "Red-Green-Refactor".
Eseguendo i test dell'unità 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. Questo fornisce una rete di sicurezza che ti permette di cambiare il codice con abbandono spregevole. Man mano che la tua comprensione dei requisiti disponibili aumenta, puoi modificare il test per riflettere quella nuova conoscenza. Il vero design sta nei test di unità. Tutto il resto (incluso il codice che non è coperto) è una bugia.
Ecco alcune letture consigliate
Questi sono buoni posti per iniziare a cercare di imparare come affrontare veramente lo sviluppo agile.
Il design anteriore non è così frequente in quanto i requisiti cambiano frequentemente. Quindi progettare fino al livello di classe è di solito una perdita di tempo. Tuttavia, può valere la pena di delineare decisioni architetturali di livello superiore.
Il problema con i documenti di progettazione per lavori pesanti è che sono obsoleti quasi non appena vengono creati. Quindi, ciò che funziona meglio è solitamente una documentazione di alto livello che è improbabile che cambi completamente in un breve lasso di 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 costantemente avere a che fare con il design, così come hai costantemente a che fare con analisi, implementazione, test e integrazione durante il progetto.
Hai bisogno di un po 'di pianificazione per far funzionare tutto questo. Immettere la riunione di pianificazione sprint , in cui il team stima le attività per lo sprint in anticipo. La maggior parte delle persone non si rende conto che questo non è solo un incontro di stima, ma anche uno sforzo progettuale. Ad esempio, un'attività potrebbe essere "Aggiungi codice per il nuovo modello di auto". Non puoi ancora stimarlo, devi sapere un po 'di più. Quindi il team discute il design e presenta una soluzione ampia ("sottoclasse Car?") E la aggiunge come promemoria del compito. Raramente hai bisogno di più formalità di così. Ora hai un'idea di come risolvere il problema. Non hai ancora tutti i dettagli e va bene, sai abbastanza del design per essere in grado di fare una stima constrongvole. Senza dover creare alcun diagramma (a questo punto).
Per documentazione fisica effettiva , I consiglia creare una panoramica dei sistemi si sviluppa su un muro perché tutti possano vederli. La panoramica deve solo includere le classi e i moduli più importanti e deve essere raramente aggiornata. Inoltre, creare alcuni diagrammi di stato per le classi più importanti del sistema è molto utile. Cospargere con alcuni diagrammi di sequenza selezionati di casi d'uso tipici per rendere facile per le persone vedere rapidamente come sono connesse le cose. Presumo che tu possa generare diagrammi di gerarchia di classi dal tuo codice, in modo che il problema sia facilmente risolto.
Si noti che tutti i diagrammi vengono creati dopo l'effettiva implementazione. Questo è in linea con il "software di lavoro su una documentazione completa" e la progettazione just-in-time.
E sì, il codice leggibile è sicuramente una documentazione.
L'architettura generale del progetto e il design di alto livello verrebbero fatti al di fuori dei team di Scrum quando i proprietari del progetto stanno creando le storie.
Ci deve essere abbastanza di un design generale scritto in qualsiasi forma per aiutare a vedere la relazione tra le storie e le aspettative del cliente.
Alcuni progetti necessari per ciascuna storia verranno eseguiti nella pianificazione e nella negoziazione con il proprietario del prodotto durante la pianificazione.
La maggior parte degli sforzi di progettazione per una storia si farebbero nello sprint.
Se la storia non è definita abbastanza da stimare, allora uno spazio temporale potrebbe essere messo da parte nello sprint corrente per fare abbastanza lavoro di progettazione che una storia appropriata possa essere creata per uno sprint successivo.
La mia comprensione è che si esegue un progetto di livello superiore con i requisiti iniziali raccolti all'inizio del progetto. Documenta bene questo design.
Quindi, quando si implementa effettivamente il requisito, si modifica il design di livello inferiore come necessario, ma si evita di modificare il progetto di livello superiore.
Beh, è così che mi è stato spiegato cinque minuti fa comunque ...
Oggi c'è una divisione all'interno della comunità di Eclipse tra gli 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 fa schifo mentre UML è davvero un modo eccellente perché standardizza per comunicare con gli altri membri del team.
