Mi piacciono le piccole iterazioni. Mi piacciono i test unitari. Mi piace la revisione del codice. Quello che non mi piace è l'avvio con poca o nessuna documentazione. Sono solo in questo? Ho semplicemente un fraintendimento del processo?
Ogni pensiero sarebbe apprezzato.
Ricorda, Agile non significa nessuna documentazione, Agile significa che capisci che il "client" non sa tutto ciò che desidera in modo che non possano darti un documento con requisiti enormi che delinea tutto . Agile sostiene che parli costantemente con il cliente e dica "È questo ciò che vuoi?" oppure "Come funzionerà X quando si verifica Y?" così insieme crei i requisiti.
Detto questo, non c'è niente di sbagliato in te se non ti piace una particolare metodologia. La maggior parte delle persone sembra scegliere e scegliere vari aspetti di diverse metodologie in ogni caso.
La metodologia Agile afferma che fai solo ciò di cui hai bisogno in quel momento. Se vuoi / hai bisogno di più documentazione di quella data, allora questo è un problema con il processo, e non sei tu. Ci sono momenti in cui è necessaria molta documentazione per continuare il progetto. Non è contrario ad Agile averne bisogno. Non puoi giustificare il rallentamento dei requisiti sotto le spoglie di Agile. Questo è in realtà un grosso problema che ho visto. Un sacco di gente si arrabbia e la butta via nel processo. La vera domanda deve essere posta, "Gli sviluppatori hanno ciò di cui hanno bisogno?" Se la risposta è no, allora c'è bisogno di più lavoro.
Ora questo può essere portato all'estremo e qualcuno può dire: "Beh, non posso lavorarci sopra a meno che l'intero programma non sia documentato". A volte questo è vero, ma la squadra ha bisogno di dare un'occhiata e vedere se è veramente necessario.
Non vedo perché ti farebbe diventare un cattivo programmatore solo perché non ti piace una particolare metodologia. Potrebbe rendere difficile l'integrazione con i negozi che lo implementano; detto questo, ho qualche dubbio sul modo efficace in cui viene applicato ovunque.
Ciò che ti rende un programmatore cattivo è un codice errato - facile lo so - ma puoi piacere / essere brillante con tutte le metodologie che ti piacciono, ed essere ancora un cattivo programmatore perché il tuo codice non è adeguato.
L'idea di base di Agile è che, a meno che tu non abbia un dono della precognizione, non puoi prevedere un futuro lontano. Quindi non puoi documentare ciò che non puoi prevedere.
Questo non significa che non hai affatto documentazione. Esegui la progettazione tecnica del documento per i attuali requisiti (e naturalmente fai i requisiti del documento stessi) e documenta l'implementazione corrente . Non è previsto che documenti come il sistema si occuperà di altri 10 sprint, perché vivi in un mondo dinamico, i requisiti potrebbero cambiare.
Penso che tu stia fraintendendo il processo. Che documentazione vuoi? Prima di iniziare hai bisogno di una sorta di obiettivo. Comincio con i casi d'uso che raccolgo dalle conversazioni con il mio cliente. Non passo i giorni a fare diagrammi di fantasia. Parliamo, e poi scrivo una pagina Wiki, e andiamo oltre. Quindi scrivo alcuni test. Quindi scrivo del codice.
Esiste una combinazione infinita di dimensioni, domini, lingue, personalità, budget e requisiti del team. Non esiste una metodologia che sia la migliore per ogni situazione. Allo stesso modo molte persone hanno preferenze e stili personali.
Anche se non ti piace, vale la pena provare nuove idee e analizzare i risultati in modo critico. Ci sono molte cose che non mi piacciono, ma dopo aver provato per un po 'ad imparare ad amare. Like Olives.
L'altra cosa è che le mode cambiano regolarmente. Sono cresciuto con Waterfall, ho lavorato in una squadra che ha cercato di fare tutto in Rational Unified Process che era la "cosa migliore" al momento. Presto Agile sarà sostituito con qualcosa di più nuovo e migliore e nessuno menzionerà di nuovo la parola Agile.
Quindi non hai bisogno di una metodologia come Agile. (Personalmente non mi piace) Non ti rende un cattivo programmatore.
Leggi altre domande sui tag agile methodology documentation