La progettazione leggera potrebbe essere una trappola di metodologie agili che causano una costante rielaborazione o è un fraintendimento della metodologia?

Una parte di questo è prevista e buona, parte di questa non è, e non possiamo davvero dirti quale è quale.

L'obiettivo principale di Agile è fornire ciò che è importante ora , in base a ciò che conosci oggi . Prenditi un po 'di tempo, implementa questo importante bit e spediscilo in modo che tu possa avere un feedback su di esso piuttosto che dopo. Alcuni di quei feedback saranno essere "ugh, questo in realtà fa schifo in pratica!". Questo è il buon tipo di rilavorazione che agile promuove. Dal momento che l'hai preso prima, puoi sistemarlo prima.

L'altro aspetto è che ciò che è importante per gli uomini d'affari è raramente importante per gli sviluppatori. Come sviluppatori, hai bisogno di qualcuno che difenda cose tecnicamente importanti come infrastrutture, formazione e debito tecnico. Questo può aiutare ad eliminare alcune delle "lacune" mancate dagli ambienti più agili. Ma alla fine, la disciplina per fare un buon lavoro piuttosto che semplicemente dare una soluzione a una soluzione ricadrà sullo sviluppatore, agile o no.

Sebbene l'agile si basi su un prodotto minimo vitale e offra solo ciò di cui hai bisogno, si basa anche sul prendere le decisioni migliori che puoi con le informazioni che hai attualmente.

Questo significa non solo considerare la storia dell'utente su cui stai lavorando, ma quello che sai sta arrivando, o probabilmente arriverà. Il momento giusto per il design è quando ne hai bisogno, considerando la possibilità di dedicare del tempo al design quando pensi che qualcosa che stai facendo possa causare problemi in futuro.

Per me agile non incoraggia la procrastinazione o il ritardo delle decisioni di progettazione, ti permette di rimuovere l'enorme sovraccarico di progettazione del sistema all'inizio (che non è mai giusto comunque) e di integrarlo nel progetto come e quando è necessario .

Ci sarà sempre un certo grado di rielaborazione nel software e ci saranno sempre cose inaspettate che saltano fuori, ma se come dici tu i requisiti sono ben definiti e veramente improbabili da cambiare, puoi considerarli relativamente nel design all'inizio e può ancora trascorrere una quantità ragionevole di tempo nel lavoro di progettazione all'inizio del progetto. Questo può essere considerato anche come parte dello "sprint zero" - fondamentalmente pianificando un framework per il progetto.

Nella configurazione agile con cui lavoro, è quello che vuole la squadra. La definizione di team qui non include i manager e gli uomini d'affari. Concordo che ciò potrebbe non essere possibile se lavori in un luogo in cui gli uomini d'affari hanno un altro da dire su questioni tecniche.

Nel nostro caso, se il team ritiene che alcune funzionalità necessitino di una discussione sul design, creiamo dei documenti di progettazione e dei diagrammi a blocchi di buona qualità. Ma a volte questo è eccessivo per alcune funzionalità e ha più senso farla finita con la stessa rapidità possibile.

Potrebbe essere d'aiuto avere una persona esperta esperta con flussi di lavoro agili per guidare dimostrazioni e retrospettive in cui anche la rispettiva persona d'affari può partecipare e capire cosa vuol dire lavorare in modo agile.

Ogni squadra è diversa quindi spetta al tuo team capire quale è meglio per te, e mi sento agile ti consente di farlo più facilmente di altri modelli aprendo opportunità di comunicazione con demo, retrospettive che stimolano discussioni e miglioramenti.

Agile non si tratta di non progettare, è agile sulla sua progettazione tutto il tempo!

Nella progettazione a cascata è vincolata a una fase, quindi alla programmazione, quindi alla verifica ... in agile si progetta / si programma / si verifica tutto il tempo. Se il tuo problema è che stai prendendo decisioni di progettazione scadenti che compromettono la futura estensibilità o manutenibilità dell'applicazione, impara da questi errori e prova a prendere decisioni migliori la prossima volta.

ma in agile hai un sacco di tempo per progettare, infatti, sempre per il design.

Tutte le discipline ingegneristiche mature includono una fase di stile di progettazione / ingegneria dei sistemi (o più fasi iterative).

Il problema con il software è che lo spazio di progettazione non è limitato come la maggior parte dei problemi di progettazione, quindi c'è un sacco di incertezza / molti modi per eseguire un'attività di ingegneria, ecco perché è stato sviluppato Agile.

Agile va bene per alcune cose, come i clienti che vogliono siti web, ma non hanno una buona idea esattamente di quale sito web vogliono.

Lo sviluppo basato sui test (TDD) e Agile, tuttavia, sono scarsi (o implementati male) in altre cose, specialmente quelle che richiedono un'ingegneria reale come:

• Modellazione matematica
• Algoritmi
• Sistemi vincolati o specifici per attività
• Sistemi critici per la missione

ecc. Qualsiasi soluzione ingegneristica richiede qualche iterazione, incluse le discipline al di fuori del software, ma non possiamo assolutamente ignorare completamente il design. La progettazione è necessaria per ottenere soluzioni efficienti, robuste e scalabili.

Agile è stato utile per gli spazi problema in cui i vincoli non sono definiti o non sono nemmeno conosciuti , ma anche in queste situazioni la progettazione deve ancora essere inclusa nel processo iterativo. Recentemente ho riscontrato quello che considero uno swing troppo grande per minimizzare tutto il design, e questo è particolarmente diffuso tra gli evangelisti Agile nella mia esperienza.