Mi rende un cattivo programmatore se non mi piace la metodologia Agile? [chiuso]


10

Mi piacciono le piccole iterazioni. Mi piacciono i test unitari. Mi piace la revisione del codice. Quello che non mi piace è iniziare con poca o nessuna documentazione. Sono solo in questo? Ho semplicemente un malinteso sul processo?

Ogni pensiero sarebbe apprezzato.


2
Prima di tutto, non parlare della metodologia Agile. Il movimento Agile è davvero una filosofia di sviluppo, che incoraggia l'adozione di una varietà di pratiche e metodologie appropriate.
Eric Wilson,

1
"hai un fraintendimento del processo?" - sì
vartec,

2
"La metodologia Agile che deve essere seguita rigorosamente non è una vera metodologia Agile"

1
Ciao Dan, non sembra esserci un problema risolvibile nella tua domanda, e domande come "Penso / sento X, gli altri si sentono allo stesso modo?" non sono in argomento qui . Se hai un problema specifico con cui hai bisogno di aiuto, sentiti libero di chiedere.

Tutti iniziano con poca o nessuna documentazione. La domanda è: come dividere il tempo tra documentazione e codice: prima tutta la documentazione? O solo quanto ti serve per iniziare?
Carson63000,

Risposte:


18

Ricorda, Agile non significa nessuna documentazione, Agile significa che hai capito che il "cliente" non sa tutto quello che vogliono, quindi non possono darti un documento con requisiti enormi che delinei tutto. Agile sostiene che parli costantemente con il cliente e dici "È questo quello che vuoi?" o "Come funzionerà X quando Y accade?" così insieme crei i requisiti.

Detto questo, no, non c'è niente di sbagliato in te se non ti piace una particolare metodologia. La maggior parte delle persone sembra comunque scegliere e scegliere vari aspetti di diverse metodologie.


10
+1 Agile non significa nessuna documentazione . La gente sembra pensare che fosse Agile; non è. Apprezza il software funzionante su una documentazione completa; non nega il valore nella documentazione.
Aaron McIver

10

La metodologia agile afferma che fai solo ciò di cui hai bisogno in quel momento. Se desideri / hai bisogno di più documentazione di quella fornita, 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 impigrisce in anticipo e lo attacca al processo. La vera domanda deve essere posta: "Gli sviluppatori hanno ciò di cui hanno bisogno?" Se la risposta è no, è necessario un ulteriore lavoro.

Ora questo può essere portato all'estremo e qualcuno può dire: "Beh, non posso lavorarci su a meno che l'intero programma non sia documentato". A volte questo è vero, ma il team deve dare un'occhiata e vedere se questo è veramente necessario.


8

Non vedo perché ti renderebbe un cattivo programmatore solo perché non ti piace una particolare metodologia. Potrebbe essere difficile integrarti con i negozi che lo implementano; detto questo, ho dei dubbi su quanto efficacemente sia implementato ovunque.

Ciò che ti rende un cattivo programmatore è il cattivo codice - facile lo so - ma puoi apprezzare / essere brillante in tutte le metodologie che ti piacciono e rimanere un cattivo programmatore perché il tuo codice non è adeguato.


3

L'idea di base di Agile è che a meno che tu non abbia un dono di precognizione, non puoi prevedere un futuro lontano. Quindi non puoi documentare ciò che non puoi prevedere.

Ciò non significa che non hai alcuna documentazione. Documentate la progettazione tecnica per i requisiti attuali (e ovviamente documentate i requisiti stessi) e documentate l' implementazione corrente . Non ci si aspetta che documenti come sarà il sistema dopo altri 10 sprint, poiché vivi in ​​un mondo dinamico, i requisiti potrebbero cambiare.


2

Penso che tu stia fraintendendo il processo. Quale documentazione vuoi? Prima di iniziare hai bisogno di una sorta di obiettivo. Comincio con i casi d'uso raccolti dalle conversazioni con il mio cliente. Non passo giorni a realizzare diagrammi fantasiosi. Parliamo, quindi scrivo una pagina Wiki, e andiamo oltre. Quindi scrivo alcuni test. Quindi scrivo un po 'di codice.


2

Esiste un'infinita combinazione di dimensioni di team, domini, lingue, personalità, budget e requisiti. 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 criticamente i risultati. Ci sono molte cose che non mi piacciono, ma dopo aver provato per un po 'imparo ad amare. Come le olive.

L'altra cosa è che le mode cambiano regolarmente. Sono stato cresciuto con Waterfall, ho lavorato in un team che ha cercato di fare tutto in Rational Unified Process che era la "cosa migliore" al momento. Presto Agile verrà sostituito con qualcosa di più nuovo e migliore e nessuno menzionerà di nuovo la parola Agile.

Quindi non sentirti come se avessi bisogno di una metodologia come Agile. (Personalmente non mi piace) Non ti rende un cattivo programmatore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.