Migliorare in modo iterativo l'architettura e la qualità del software in un processo agile?

Penso che per lo più tu stia mescolando i livelli errati di astrazione e quindi, ti stai bloccando.

Prima di tutto, ci possono essere dei requisiti per cambiare l'architettura, ma normalmente non fanno buone storie. Supponiamo ad esempio che sia necessario migliorare le prestazioni del x%. Questa non è una storia di un utente e potrebbe non essere affatto realizzabile. Ci sono sistemi che non possono essere migliorati, ci sono sistemi che possono essere migliorati solo a costi molto alti, ecc.

I primi due bit mancanti che mi vengono in mente sono:

• Qual è il valore commerciale del miglioramento delle prestazioni di x%?
• Quali sono i limiti corretti in cui operiamo?

Non possiamo semplicemente acquistare un server x% più veloce, ad esempio?

Non ci sono storie "architettoniche" in sviluppo agile perché l'architettura non ha un valore reale per l'utente.

L'architettura è uno strumento, ha un valore pratico ed è utile per lo sviluppo agile, ma non ha nulla a che fare con storie architettoniche . L'architettura è un'attività, come il design, il refactoring, il debugging, ecc. Nessuna di queste attività potrebbe mai fare una buona storia, ma tutte queste attività fanno generalmente parte dello sviluppo di una storia.

Un altro punto da tenere a mente, le qualità architettoniche diventano parte della "definizione di fatto". Se hai il requisito che ogni pagina web debba essere consegnata in meno di 500 ms, fare in modo che questa parte del DoD assicuri che questo si applichi a ogni storia, e diventa un criterio per il test di accettazione.

Inoltre, cambiare in modo significativo il livello di prestazioni impostato come "definizione di fatto", è generalmente una mossa rischiosa. A meno che non abbiate semplicemente commesso un errore e impostato il valore sbagliato, la modifica del profilo delle prestazioni di un'applicazione è difficile a molti livelli - ed è particolarmente difficile da stimare.

In alternativa puoi limitare l'impatto specificando in quali casi vuoi questa modifica e perché . Ciò consente al team di essere impostato per il successo, con risultati che possono essere raggiungibili. Nessuno può essere certo di poter modificare le prestazioni di un'applicazione complessa a livello generale, tuttavia stimare una singola pagina o funzionalità è più fattibile.

Riguardo alle storie di hardening: l'unico approccio che ho visto lavorare (e quello che usiamo allo Stack Exchange) è avere una persona in errore ogni iterazione. Questo assicura che ci sia sempre qualcuno sul pezzo quando sorgono problemi, è di natura giusta, e ignora completamente i problemi di pianificazione che si presentano quando trattano i bug come storie ("c'è un nuovo bug nel mezzo di un'iterazione, lo aggiustiamo o lo chiudiamo le storie? ").

L'architettura agile è una sparatoria. Cerco di implementarlo in una metodologia just-in-time, ma alla fine, è in diretta opposizione alle metodologie agili. Ciò non significa che sia cattivo. È molto importante, non è qualcosa che si adatta al processo agile.

L'architettura e il design all'avanguardia sono davvero una copertura contro i rischi di uno sviluppo agile. Devi bilanciare la tua mitigazione del rischio con il tuo time to market. In questo caso, sembra che tu sia sceso un po 'dalla parte sbagliata dell'equazione rischio / rendimento. La prossima volta potresti fare troppa architettura e perdere un sacco di tempo. Sfortunatamente, ci vuole solo esperienza e saggezza per capire quanto sia "troppo" l'architettura per un processo agile.

È una domanda comune - e che molti dei nostri clienti chiedono quando discutiamo di agile.

La parola chiave nella tua domanda è "senno di poi". Per ogni volta in cui ho incontrato un momento "se solo lo avessimo saputo", ho incontrato molti momenti di "You Is not Gonna Need It" (YAGNI). Cercare di risolvere tutti i problemi / requisiti attuali e futuri in una singola versione ti farà impazzire, renderà il software complesso, tardivo e costoso, e generalmente ti rallenterà.

Nel complesso, la rielaborazione necessaria per migliorare le prestazioni di una funzionalità esistente e ben realizzata è molto meno dispendiosa rispetto all'investimento in soluzioni "architettoniche" a problemi ipotetici.

Spiegando questo ai miei clienti e ai miei team, generalmente dico che il lavoro del team è di ottimizzare il throughput e la qualità; il compito del cliente è assicurarsi che lavoriamo sempre alle attività più preziose. L'intero punto di agilità è che i cambiamenti "preziosi" nel tempo e che il team risponde rapidamente. Finché lo realizzi, la rilavorazione non è un grosso problema, anche se sembra inefficiente.