Sviluppo di applicazioni scalabili usando i metodi Agile

Fast paced development that doesn't take into account all requirements (since they are added one by one) may lead to unsuitable design in the infrastructure level of the application.

Questo non è vero. Il design segue i requisiti. Se la tua squadra si impegna a fornire funzionalità, si impegna anche ai suoi criteri di accettazione (definizione di fatto). I criteri di accettazione per la storia possono contenere richieste di scalabilità e prestazioni e, se tali criteri sono menzionati, è necessario fornire un test automatizzato per convalidare la propria approvazione per dimostrare che la storia è completa e assicurarsi che i criteri di accettazione non vengano interrotti in futuro dalla regressione.

Il proprietario del tuo prodotto può persino dichiarare tali criteri di accettazione come globali in modo che possano far parte di ogni storia utente e il team sarà in grado di tenerne conto durante la stima delle storie (requisiti).

Se si chiede l'applicazione "tuning" per le prestazioni globali di quanto non sia simile a qualsiasi altra. L'ottimizzazione prematura è fonte di malvagità, quindi finché non hai una solida base di codice con funzionalità implementate, non c'è nulla da ottimizzare e refactoring per le prestazioni.

Se non vuoi che l'applicazione sia in grado di scalare "tempi grandi", hai bisogno di soldi e hardware - o ancora meglio devi fare applicazioni su cloud e pagare per HW che utilizzerai davvero.

Se hai a che fare con i requisiti uno alla volta senza conoscere altri requisiti, stai agendo in modo sbagliato.

Un progetto agile ha ancora un componente di progettazione anteriore - è molto meno di quello che hai in un progetto a cascata e non è necessario definire tutti i dettagli - solo cose di alto livello come la scelta della piattaforma e la progettazione generale del sistema che non puoi gestire a livello di singola funzionalità.

Poiché i problemi di ridimensionamento di solito non sono legati alle singole funzionalità (quelle che sono facili da risolvere), la soluzione è in quel progetto iniziale, non diverso da qualsiasi altro tipo di progetto.

Se ritieni che sia necessario cambiare la modalità di parte del framework attraverso un progetto, hai fatto quel primo passo sbagliato e dovrai tornare a tutte le funzionalità sviluppate in precedenza. Molto probabilmente sarà più veloce dello sviluppo originale in quanto hai del codice che puoi riutilizzare, ma il processo è lo stesso di una riscrittura completa.

Nella maggior parte dei casi, il cliente dovrebbe avere un'idea della scala dell'applicazione. Ad esempio se stai costruendo un'app CRUD interna o il "prossimo facebook". Il contesto del cliente on-demand è il punto di Agile, non hai un team di sviluppatori che scappa con specifiche obsolete sperando di colpire un bersaglio mobile.

In questo modo il cliente è in qualche modo responsabile della priorità delle storie, quindi se le prestazioni sono mission-critical, non cadrà fino alla fine del progetto. C'è anche l'effetto collaterale che l'intero team è consapevole del fatto che esiste una storia nel backlog che richiede determinati criteri di rendimento e che provocherà naturalmente una conversazione se la storia X in questa iterazione potrebbe in seguito rimandare la stima per quella storia di performance.

Ora, la scoperta di un requisito di prestazione potrebbe davvero andare male con qualsiasi metodologia. Agile potrebbe non essere più efficiente nel gestire questo problema. Un team di Cascate potrebbe facilmente dire che non era nei requisiti, quindi non è un nostro problema. Una squadra agile probabilmente cercherebbe almeno di cambiare rotta. Entrambi hanno un'alta possibilità di non riuscire a fornire ciò che il cliente desiderava davvero.