Dove e quando si progetta, le attività di architettura si svolgono in Scrum

Il design dovrebbe essere pianificato, sia come numero aggiuntivo di storie per storia che come storia separata. E dovresti avere ancora designer nella tua squadra che possiedono e controllano il design.

Il guaio è che il design rappresenta "nessun valore aziendale" e che le storie di puro utente vengono tipicamente scaricate su "il team", che è questo blob di sviluppatori che si concentra su software utilizzabile piuttosto che software gestibile. Quindi, con l'introduzione della mischia, il design consapevole spesso cessa di esistere. Per i prodotti più grandi e di lunga durata, questo è un disastro che aspetta di accadere, naturalmente. Sarà comunque silenzioso, i tempi di sviluppo e il numero di bug che si presentano torneranno gradualmente. E nessuno lo considererà preoccupante, faremo solo più test e ci sentiremo bene. Non è un caso che i test siano diventati una cosa importante ultimamente, anche in progetti software run-off-the-mill.

Fortunatamente, oggi abbiamo anche un nome di fantasia per questo: "debito tecnico". È un nome eccezionale perché non sembra un problema per nessuno, ma per il team di sviluppo. Implica che sia colpa loro, i tecnici dovrebbero pagare per questo, non per il business. È il loro problema.

E in tutta onestà, lo è davvero. Il team di sviluppo deve assicurarsi che lo facciano. Sono auto-organizzanti e devono essere abbastanza forti da riservare le risorse per fare ciò che è necessario. Si impegnano in una pianificazione che si fanno da soli. Ci sarà la pressione per andare avanti con le caratteristiche, ma rimane la loro responsabilità di pensare le cose attraverso e di avere persone che sono responsabili e responsabili per questo. Scrum rende più difficile mantenere queste basi.

Where does design work belong?

Prima del primo sprint, o del primo sprint, e possibilmente in ogni sprint successivo. Alcune squadre avranno un periodo di tempo prima del primo sprint in cui vengono prese alcune di queste decisioni. Se le decisioni non vengono prese prima del primo sprint, allora devi fare almeno parte del lavoro di progettazione e architettura nel primo sprint. Mentre il progetto progredisce attraverso gli sprint, ci saranno opportunità per ulteriori attività di progettazione e architettura. L'estensione dipende dall'ambito e dalla complessità del prodotto in costruzione.

Penso che sia perfettamente valido durante qualsiasi sessione di pianificazione sprint di dire qualcosa del tipo "non abbiamo abbastanza informazioni su come stiamo andando a progettare questo, quindi la nostra prima storia (o attività) deve essere di venire con architettura ".

L'intero punto di discussione è di avere team che hanno il potere di prendere decisioni su come costruire un prodotto. Se parte del processo di costruzione del prodotto implica la decisione sull'architettura, si tratta di un'attività perfettamente adatta a qualsiasi sprint.

Robert C. Martin ha parlato di quello che puoi trovare su youtube:

La terra Scrum dimenticata

Qui egli affronta questo problema comune che nell'architettura e nel design di Scrum non viene mai menzionato, quindi spetta al team identificare quali architetture e desiogn dovrebbero significare all'interno del progetto.

La mia opinione personale è che dovresti avere un'istanza nel team responsabile dell'architettura e del design. Il contratto dovrebbe essere: l'architetto decide come questi soggetti sono indirizzati. Dall'altro lato non dovrebbe essere in grado di sfuggire alle domande risultanti che sono uscite dalle sue decisioni.

Nel mio attuale progetto ci troviamo di fronte a diversi problemi, che possono essere principalmente suddivisi in base alla diversificazione del concetto e al codice disarmo, accanto a implementazioni che ignorano completamente l'architettura invece di estenderla in un modo utile.

Il punto è: se non riesci a trovare un consensi sulla migliore architettura ai requisiti specificati all'interno del team, non puoi aspettarti che il team stia facendo un buon lavoro. Questo vale anche per problemi di qualità del codice. Un modo democratico di risolvere questo problema può essere un modo se la comprensione differisce solo in alcuni punti. Ma se hai discussioni essenziali che non portano a una soluzione, è meglio mettere qualcuno in grado di decidere.

there isn't enough time for the team to decide on technology choices, which responsibilities belong different components deployment and release considerations etc

La maggior parte di questo è trattata in uno "Sprint 0" o è solo inerente al team. Si prevede che i server e gli ambienti di generazione siano installati prima dell'avvio del progetto.

Come se fossi un team di sviluppatori web c #, hai saputo che avresti scritto un sito Web asp.net supportato da MSSQL

Scrum si concentra sull'ottenere risultati rapidamente. Quindi quale framework javascript o database è il migliore non è importante. Non perdere tempo a pensarci.

Scegli la cosa che è più veloce da implementare. singolo. tempo.

Se il prodotto è un successo, tra qualche anno potresti forse avere un altro progetto per trasformare una delle tecnologie in una versione più economica.

Il lavoro di progettazione prima della pianificazione della riunione è non preferibile in quanto il team non avrà input sufficienti perché la trama non è stata analizzata. La riunione di pianificazione può essere utilizzata per interrompere le funzioni e stima . In seguito il team dovrebbe avere il tempo per analizzare e rivalutare la storia dopo la quale dovrebbe essere programmata una riunione per il lavoro di progettazione.