In che modo si dà la priorità agli sprint iniziali per massimizzare la possibilità di rilevare precocemente errori di architettura?

how can I best allocate work in initial sprints to catch the (probably inevitable) architectural issues in the solution as early as possible?

Non confondendo la qualità della pianificazione con la quantità di pianificazione.

L'intero punto di agilità è che la pianificazione è inadeguata. Gli uomini d'affari non sanno veramente di cosa hanno bisogno finché non riescono a far provare i clienti. I tecnici non sanno veramente cosa funzionerà finché non saranno in grado di eseguirlo e misurarlo.

Quindi la migliore allocazione di lavoro è ottenere qualcosa lavorando al più presto. Certo, dovresti passare un po 'di tempo in una stanza a discutere di quali affari pensano di aver bisogno. E dovresti passare un po 'di tempo con una lavagna discutendo i meriti relativi delle potenziali architetture. Questo ti porterà un giorno. Forse.

Quindi fai la tua ipotesi e crea un prototipo. Guarda cosa funziona. Guarda cosa fa schifo. Mostra l'attività e guarda cosa hai comunicato in modo errato. Quindi esegui l'iterazione. Sembra che i tuoi predecessori non abbiano iterato. Non si sono fermati e hanno valutato come andavano le cose e, naturalmente, la rotta è stata corretta. Hanno appena aggrappato il pasticcio esistente rendendolo peggio.

Il primo errore che viene spesso commesso è che le persone non guardano oltre le storie nello sprint attuale.

Sebbene sia corretto che quelle storie non siano ora nel campo di applicazione e potrebbero essere modificate o rimosse in un attimo, ignorandole completamente quando si prendono decisioni di progettazione di alto livello è una buona via per il caos.
Quando prendi decisioni di design di alto livello, devi anche guardare alle storie che sono ancora presenti nel product backlog per vedere come la tua decisione influisce su quelle storie e per rivedere la tua decisione se risulta che rende difficili quelle storie future. < br> Le storie più alte nel backlog dovrebbero avere una priorità più alta in questa valutazione, poiché è più probabile che vengano implementate.

Quando sento questo argomento contro Agile contro cascata, sembra che immaginino la storia come,

"We create these great specifications that the clients love because all of our projects are always on time and budget, but if only we could be lazy and accomplish the same thing without having to write requirements."

Questo non è il modo in cui ho capito cosa stava succedendo. Anch'io non cado nella trappola di pensare alle cose come tutto o niente. Non c'è nulla di sbagliato nell'avanzare i requisiti, ma ciò non significa che TUTTI i requisiti debbano essere scritti prima di ogni programmazione. Questa è la differenza più grande.

Anche se pensi davvero di poter scrivere completamente tutte le specifiche per un progetto complesso, non farlo se ci vorrà un lungo periodo di tempo. Se parli con un cliente per settimane, passa attraverso un lungo processo di negoziazione del contratto, costruisci l'intera applicazione e restituisci mesi dopo con un progetto finito, non sorprenderti quando il cliente ti dice che non è quello che si aspettavano e più probabilmente non funziona come pensavi.

Ho lavorato come capo del supporto tecnico e dopo mesi di non aver visto i nostri programmatori durante la creazione di un'altra versione della nostra applicazione completamente da zero (molto migliore architettura questa volta - sì giusto) non ho potuto farlo installare su il mio PC Ha rotto ogni passo del cammino. Ero così incazzato, li ho fatti stare tutta la notte e continuo a sistemare la cosa fino a quando non ho potuto vedere l'app.

Hanno passato così tanto tempo a scrivere le specifiche, non hanno avuto il tempo per la fase di pseudo-codice molto bally-hooed del progetto. OK, forse impiegare molto tempo per scrivere le specifiche può essere una buona cosa.

Credo che il concetto di "Sprint 0", che in genere potrebbe essere uno sprint iniziale più lungo, lo copra, vero? Ecco un articolo ( Cos'è Sprint Zero? ) che secondo me descrive cosa dovrebbe essere fatto in Sprint 0, incluso un progetto iniziale sufficiente per facilitare la progettazione emergente negli sprint successivi.

L'articolo descrive alcune fra le errate percezioni e le "pratiche scorrette" di uno "sprint iniziale" per aiutare i nuovi progetti di sviluppo a decollare. Sia l'articolo che i commenti sottostanti sono utili da leggere. Riesco a capire la sfida di decidere quali dovrebbero essere le storie degli utenti iniziali quando si inizia lo sviluppo di un'app o di un prodotto di grandi dimensioni o complessi. Dato che molti (la maggior parte?) Squadre provengono da uno sfondo a cascata, eliminando BDUF e un sacco di pianificazione in anticipo può essere spaventoso!

Ho trovato utili i 3 punti dell'articolo di una definizione operativa di uno Sprint 0: uno, che dovrebbe essere usato per creare lo "scheletro di base e l'impianto idraulico" per il progetto per facilitare la pianificazione futura dello sprint; due, facendo un progetto minimo in anticipo per consentire la progettazione emergente possibile man mano che il progetto procede; e tre, assicurando che anche questo sprint offra valore in termini di alcune storie completate, alcune delle quali includono lo scheletro / framework del prodotto.

Spero che questo aiuti!

Ho lavorato a un progetto sin dalle sue fasi iniziali e quello che ho imparato è che adottare una mentalità agile e "fallire velocemente" può davvero aiutare i progetti a progredire.

Prima di tutto devi assicurarti di poter far funzionare le cose avendo un POC adeguato e iniziando a costruire il tuo software, ma allo stesso tempo non dovresti spendere un sacco di tempo e risorse per progettare la migliore architettura. il codice può anche essere mantenuto semplice e fondamentalmente solo praticabile e quindi è sempre possibile effettuare il refactoring dei PBI in iterazioni successive in cui lo si rende più complicato.

Accanto a ciò è bene scoprire quelle cose critiche nel tuo progetto e cercare di fallire la tua architettura il più velocemente possibile! in modo da poterlo convalidare velocemente e in anticipo invece che nelle fasi avanzate. perché se invece hai componenti diversi nel tuo arco e quando sono fattibili (non è necessario abbastanza complesso) è una buona idea iniziare l'integrazione di quei componenti e vedere se possono lavorare insieme o manca qualcosa

Governare e picchi è il modo in cui abbiamo affrontato questo genere di cose, non sempre con successo potrei aggiungere, tutto dipende da come (anche se) le storie sono scritte. Abbiamo anche un architetto dedicato, e un po 'di tempo da loro.

Quindi, nel governare le persone che hanno familiarità con l'arretrato e l'architettura proposta dovrebbero guardare a come una "nuova" storia influisce su ciò che è stato fatto o sarà fatto. Pensala come una sorta di meta-dipendenza.

L'altra cosa che facevamo quando c'era incertezza sul fatto che ci fosse un impatto o il modo migliore per migliorarlo era una Spike Story. Fondamentalmente si trattava di una dimostrazione cronologica di una concept story come in tutti i casi non banali e quindi più problematici, molti dei problemi non emergono fino a quando uno sviluppatore non ci ha provato.

tricks, tips or techniques to ensure that we correctly identify the parts of the project that need the most rigidity,

Indovina e spera che tu sia fortunato. L'esperienza aiuterà.

prototype and iterate them first, and catch problems there as early as possible?

Consegna qualcosa il prima possibile. Prima fallisce, meno doloroso sarà buttarlo fuori. Non pianificare. Fai e impara.