Come ottenere un buon design quando si usano metodi agili?

On the other hand, developing some complex feature in small increments, with daily commits and continuously rethinking the code when it gets unstructured is not allowing me to produce really good design.

Quindi non farlo.

Non tutto si adatta alla bella scatola agile. Spesso un prodotto ha alcune cose complesse che non possono essere estese a singoli individui e non possono essere completate in modo sano all'interno di uno sprint. Forzarli in quella scatola causerà solo problemi. Ma questi dovrebbero essere pochi e lontani tra loro. Se trovi che molti dei tuoi componenti sono così, il proprietario del tuo prodotto deve lavorare per rompere le cose meglio (con il tuo team). Sto facendo bene come quello che hai fatto: prendi la storia, disegnala, poi martella il tutto al più presto con l'aspettativa che ci vorranno alcune settimane.

Nel caso più generale, ci sono 3 cose che ho visto fare per ottenere un buon design in Agile:

• Realmente progetta : molti luoghi che ho visto iniziano il loro sprint e iniziano a codificare il codice. Otterrai un cattivo design in questo modo. Agile non modifica il processo di sviluppo di plan - code - test - release, lo accorcia semplicemente a pezzi più granulari. All'inizio dello sprint, siediti quando necessario e progetta la tua soluzione.

• Avere un architetto / lead - Una volta che il tuo progetto è abbastanza grande, ti ritroverai con diversi team di Scrum che lavorano su diversi pezzi dell'applicazione. È molto utile avere qualcuno (o più persone a seconda delle dimensioni dell'applicazione) il cui compito principale è sapere cosa stanno facendo tutti i team dal punto di vista del design. Possono rispondere alle domande e guidare le squadre verso un design più armonioso e sovrastante. Avere un team di mischia che ha un vantaggio che conosce la maggior parte di ciò che fanno gli altri team, ho anche visto ed è stato molto efficace.

• Sii un pragmatico - Ho parlato di questo sopra. Agile è uno strumento e come qualsiasi strumento; non si applica a tutti i problemi. Se non ha senso applicare a qualche componente, non applicarlo lì. Il tuo obiettivo è spedire un buon software; non dimenticarlo.

È molto possibile implementare in piccoli incrementi e finire con un codice gestibile ben strutturato. In teoria, è molto semplice: se si assicura che il codice sia ben strutturato dopo ogni modifica, sarà sempre ben strutturato. Il tuo codice sta diventando scarsamente strutturato perché continui ad aggiungere codice quando dovresti eseguire il refactoring.

Indipendentemente dal tempo che dedichi alla progettazione, alla fine i requisiti cambieranno in qualche modo inaspettato e dovrai scrivere codice che non si adatta al design originale. Quindi dovrai apportare un cambiamento incrementale. Se hai una buona serie di test unitari e sei abile nel refactoring, allora sarai in grado di mantenere il codice ben strutturato nel soddisfare i nuovi requisiti.

"Ben progettato" è soggettivo

Che cosa significa "ben progettato" per te? al proprietario del prodotto? al cliente?

"ben progettato " è un obiettivo del proprietario del prodotto? un obiettivo del cliente? o solo tu?

È ciò che tu consideri "non ben progettato" che soddisfa ancora le aspettative dei Proprietari di prodotto e rende felice il cliente? Allora è "ben progettato" .

Good Enough and YAGNI

Niente nella maggior parte delle metodologie Agile parla di "ben progettato", perché qualsiasi sistema che il Product Owner accetta come completo e che i clienti ritengono che soddisfi le loro esigenze è "ben progettato" .

È previsto che gli sviluppatori siano professionisti e pragmaticamente utilizzino le best practice, i design e gli idiomi appropriati per implementare le caratteristiche e le storie.

Se non stai prendendo in considerazione il tempo per fare le cose correttamente che è un problema con gli sviluppatori, se il Product Owner richiede le cose in meno tempo che queste possono essere fatte, è la loro prerogativa a farlo e la tua responsabilità di educare riguardo le conseguenze sotto forma di debito tecnico storie.

MISCHIA

_{La Metodologia Agile che può essere scritta, non è la Metodologia Agile. "- Jarrod Roberson}

SCRUM dovrebbe essere un framework di strumenti per gestire il ciclo di vita totale di un prodotto software. Non dovrebbe essere un insieme rigido di cose, solo un buon punto di partenza e, auspicabilmente, migliorare.

La maggior parte dei negozi in cui ho lavorato ha definito Sprint ZERO, Sprint per i membri senior del team per delineare un'architettura o un tema generale del prodotto.

Le storie che sono più grandi di dire 20 di solito vengono suddivise fino a quando non sono in realtà alcune storie da 3 a 5 punti. Una di queste storie è, "Come squadra dobbiamo incontrarci per discutere di come progetteremo questa funzione, in modo da avere il minor debito tecnico possibile, dato il tempo a disposizione."

In generale

In generale un sistema "ben progettato" è abbastanza buono e segue YAGNI.

Agile, e SCRUM in particolare come implementazione di Agile riguardano più come per produrre un prodotto nel modo più trasparente possibile per il proprietario / sponsor del prodotto.

Non si tratta di qualcosa di tecnico di design / architettura saggio. È più una filosofia su come affrontare la fornitura di software che soddisfi le esigenze e le aspettative dei clienti. Se non c'è ciò che chiami parti "ben progettate" , non è un fallimento di per sé, poiché non è una parte fondamentale della filosofia.

Lavoriamo con scrum da diversi mesi e voglio condividere la mia esperienza sul problema.

Alcuni mesi fa mi è stato dato un grande pezzo da implementare. Avevo tutte le specifiche pronte, quindi ho dovuto implementare di conseguenza le nuove funzionalità. Il compito era di prendere circa 5-6 settimane (come ho stimato). Ho trascorso la prima settimana lavorando solo sul design. Il compito era un po 'complicato: c'era un oggetto principale che, come ho concluso dalle specifiche, aveva 15 diversi stati, e l'interfaccia utente doveva avere comportamenti diversi per ogni stato.

Ho progettato l'intero flusso di lavoro e successivamente la struttura e le classi del DB.

Non vedo nessun altro approccio nel mio caso. Se mi fossi immerso nella codifica in una volta, avrei avuto un grosso pasticcio alla fine _ quasi impossibile da mantenere ed estremamente difficile apportare ulteriori modifiche. Ma i cambiamenti sono arrivati nelle prossime 2 settimane, quindi ho dovuto rielaborare il codice. Questo è stato facile ora, con il progetto iniziale pensato. Questo ci ha permesso di risparmiare tempo, denaro e nervi.

Dopo questa esperienza sono assolutamente sicuro che valga la pena di fare un progetto accettabile all'inizio, piuttosto che sperare che con un miracolo lo avrai alla fine.

La vista posteriore è 20-20. Se tu avessi le informazioni a tua disposizione all'inizio del progetto per capire tutto e poi scrivere il codice tra qualche settimana, ti suggerisco di farlo.

Non attribuisci abbastanza credito a tutti gli approfondimenti che hai acquisito, agli approcci che sono stati provati e falliti / che sono stati modificati e alla maggiore capacità del cliente / utente di fornire sufficiente credito ai requisiti.

Perché qualcuno con una storia di progetti di caduta dell'acqua di successo, passare a una metodologia agile?

Hai sempre bisogno di un'immagine più ampia di ciò che dovrebbe essere l'obiettivo finale, e quali caratteristiche devono essere implementate e quando, prima di iniziare un progetto. Lavorare su storie come compiti atomici è un problema. Devi tenere a mente le esigenze future il più possibile.