Disilluso di agile; come ti prepari per la vita dopo la release 1.1? [chiuso]

Penso che ciò che stai vivendo sia molto simile a molti altri team che sono passati per la prima volta ad Agile. Nella mia ultima azienda quando ci è stato detto di essere agili, è successa la stessa cosa. Questo articolo su Metodologia Agile Cult Cargo potrebbe risuonare con alcune delle cose che probabilmente hai sperimentato nella tua versione 1.1 era. Il punto è che non puoi semplicemente seguire regole / linee guida scritte senza fare un passo indietro e considerare ciò che è veramente importante per la tua squadra e la tua situazione specifica.

La chiave è che la metodologia Agile non ha mai detto che non è possibile avere documentazione. Sembra proprio così perché ha eliminato il 90% (se non di più) della documentazione rispetto a cascata. E questa è una buona cosa, ma alcune squadre, prendono "no documentazione" un po 'troppo alla lettera e vanno oltre, eliminando il 99,9% della documentazione. Quindi diventano agili come causa del prodotto non documentato.

Ho appena fatto una ricerca su google per trovare questo articolo sulla documentazione agile / lean e ho trovato un'altra domanda con la mia risposta di un anno fa che tocca questo stesso argomento. La conclusione di tutto ciò che ho scritto è che ritengo che i documenti di progettazione siano importanti, ma per la memoria organizzativa e solo se mantenuti ad un livello sufficientemente elevato. Sono quasi completamente inutili se scritti prima del codice.

Lo stesso vale per la visione e la direzione a lungo termine. Una metodologia agile ha suggerito che un grande progetto iniziale è sbagliato. E quello che intendevano è che non tentare di "abbozzare" tutti i dadi e le viti della tua applicazione usando le parole e poi provare a codificare tutto quanto sopra. Questo non funziona. Ma molti team, compreso il mio, lo hanno preso un po 'troppo alla lettera e quando hanno iniziato nuovi progetti sarebbero passati direttamente alla codifica senza definire l'architettura generale o avere un'idea generale approssimativa di come dovrebbe essere il prodotto finale. La linea di fondo è che in Agile dovresti avere la documentazione appena sufficiente in modo che ti aiuti ad andare avanti e ti renda più efficiente (es. Elaborare una visione in modo che il team possa lavorare verso un obiettivo comune e non devi tornare indietro e riprendere il lavoro) ma non creare documentazione solo per la stessa cosa di produrre volume su volume di specifiche di progettazione che a) nessuno leggerà mai eb) diventerà completamente obsoleto ancor prima che il software venga spedito.

Al suo nucleo, Agile è incredibilmente semplice. Si tratta di brevi iterazioni, eliminazione degli sprechi e miglioramento continuo. Dovresti rivedere costantemente ciò che fa perdere tempo e renderti meno efficiente e risolverlo. Se il team vede che hanno appena trascorso 2 settimane a produrre documenti e quei documenti non sono necessari a nessuno, è uno spreco. Tuttavia, se il team vede che vengono rallentati dalle chiamate dei clienti e dalla loro stessa incapacità di comprendere il codice che è stato scritto, allora la mancanza di documentazione è spreco.

Quello che stavi facendo non era agile, lascia andare oltre i tuoi punti:

• luce sulla documentazione - Agile non parla di "nessuna documentazione". Si tratta di creare codice che non necessita di documentazione e solo di creare la documentazione necessaria.
• non progettarlo finché non ne hai bisogno - In agile, questo non significa nulla. Solo perché stai progettando in seguito, non significa che non stai progettando affatto.
• continua a correre per il prossimo sprint - Agile non si tratta di correre al prossimo sprint. Il punto principale dell'agile è creare un ritmo di sviluppo stabile e sostenibile. Quindi, indipendentemente da quanto grande o complesso sia il software, il team può aggiungere nuove funzionalità e migliorare la qualità alla stessa velocità dell'anno precedente.
• lascia poca documentazione - Ancora una volta, agile significa che il team deve decidere quale documentazione ha bisogno per il proprio lavoro. Il problema principale con altre metodologie è che è qualcun altro che decide quali documenti sono necessari, quindi molto spesso i documenti danno più problemi di quanti ne risolvano.
• piccola visione - Che è sbagliato. Gli sviluppatori stessi non hanno davvero bisogno di una visione a lungo termine. Ma almeno il proprietario del prodotto dovrebbe guardare l'anno o due in futuro e immaginare quale tipo di software vogliono. Non c'è bisogno di sovraccaricare gli sviluppatori con così tanti what-if.
• record scadenti sul perché le decisioni di progettazione sono state prese - In agile, questi record esistono nel codice, nella memoria dello sviluppatore e nel team di documenti creati, perché la decisione è stata così complessa che il team ha deciso di registrarlo.

Quindi, per rispondere alla tua domanda: non puoi disilluderti con agile, quando non hai mai agito.

La disillusione viene dall'avere delle illusioni :-)

La mia interpretazione (con occhiali Scrum) su questi problemi è che sono

1. Principalmente causato da una "definizione" di "scarsa". Se uno sprint successivo ha bisogno di ripulire dopo lo sprint corrente, quindi a me che dice che lo sprint non ha finito è lavoro.

2. Contribuito a rompere una squadra di successo. Questo è uno dei metodi classici per riempire un prodotto.

Per me, una caratteristica chiave dell'agile è mantenere un ritmo sostenibile. Questo deriva dal conoscere la velocità della squadra, cosa possono ottenere in ogni sprint. Grandi cambiamenti nella squadra significano grandi cambiamenti nell'affidabilità della velocità del passato come predittore del futuro. Quel passo sostenibile include la manutenzione, e implica anche che non ci sia un improvviso taglio.

Le squadre, naturalmente, evolveranno, man mano che le persone vanno e vengono e cambiano i requisiti delle abilità. Ma sciogliere l'intera squadra mi fa rabbrividire.