Gestione agile del progetto, sviluppo agile: integrazione precoce

1

Credo che agile funzioni se tutto è agile .

Nell'area di sviluppo del software, a mio parere, se il codice dei membri del team è integrato in anticipo, il codice sarà più sincronizzato e questo ha molti vantaggi:

  • L'integrazione precoce aiuta i membri del team ad evitare fusioni dolorose.
  • Incoraggia le abitudini di codifica migliori, perché tutti fanno in modo che non rompano il codice dei colleghi ogni giorno.
  • Sia gli sviluppatori che gli architetti ( revisori di codice ) possono rilevare decisioni di progettazione errate o solo errate indicazioni di sviluppo in tempo reale, impedendo il lavoro inutile.

In realtà sto parlando di ottenere l'ultima versione del codice di base e il controllo del proprio codice al controllo del codice sorgente ogni giorno.

Quando avvii il tuo giorno di codifica (ad esempio, arrivi al tuo lavoro), la prima azione consiste nell'aggiornare il tuo codice base con l'ultima versione dal controllo del codice sorgente. D'altra parte, quando sei a circa un'ora dall'uscita dal lavoro e vai a casa, l'ultima azione consiste nel controllare il codice al controllo del codice sorgente e assicurarti che la tua giornata di lavoro non interrompa il processo di creazione del progetto.

Invece di aggiornare e verificare il codice una volta terminato un intero compito, credo che l'approccio migliore sia la risoluzione di piccoli e flessibili traguardi personali e il controllo del codice una volta terminato uno di questi.

Credo davvero che questo approccio di codifica si adatti meglio al concetto di gestione del progetto

.

Conosci qualche documento, post di blog, wiki, articolo o qualsiasi cosa tu possa suggerirmi che potrebbe essere sincronizzato con la mia opinione? . E, trovi qualche problema a lavorare con questo approccio? .

Grazie in anticipo.

    
posta Matías Fidemraizer 23.11.2012 - 21:21
fonte

2 risposte

2

And, do you find any problem working with this approach?

Mi concentrerò su questo particolare punto.

Ho problemi con questo approccio, in gran parte perché è un po 'ortogonale a ciò che le persone dovrebbero fare. Certo, dovremmo promuovere più frequenti 'ottenere le ultime e le commit, ma allineare quelli con la giornata lavorativa è in cattivo allineamento con quello che stiamo effettivamente cercando di risolvere e in che modo lo sviluppo di solito funziona.

I programmatori dovrebbero essere aggiornati prima di iniziare un'attività e prima che eseguano il commit del codice per un'attività. Questi sono i due punti naturali per unire gli sviluppatori. Se gli sviluppatori non stanno facendo questo, allora è abbastanza semplice correggerlo. "Ehi, dovresti avere le ultime notizie per evitare di rompere la costruzione e unire dolore". Sviluppatori come ridurre il dolore per lo sviluppo.

Se che in qualche modo porta all'integrazione meno frequentemente del quotidiano, allora hai problemi peggiori rispetto all'integrazione non frequente. Hai compiti molto grandi. Questi saranno intrinsecamente più inclini agli errori e porteranno a un maggior numero di problemi generali; indipendentemente dalla frequenza di integrazione. Dovresti cercare di ridurre le dimensioni delle attività comuni in blocchi più gestibili. Ciò ridurrà molto di più il tuo dolore legato all'integrazione (e altri problemi di sviluppo come errore di stima, problemi di coordinazione, accuratezza nel tracciamento del tempo / problema, ecc.) Che dettare che le persone si uniscono anche se non si trovano in una posizione favorevole. p>     

risposta data 23.11.2012 - 21:39
fonte
0

Bene, vedo il tuo elenco Pro come un elenco piuttosto debole di "vantaggi"

Early integration helps team members to avoid painful merges

Le fusioni dolorose sono entrambi tipi: o non esistono ancora o sono già stati qui. Conflitto (fatto di questa azione ) produce disordine, non la quantità di azioni prima di esso

Encourages better coding habits, because everyone makes sure that they don't break co-workers' code everyday

Se la fusione del codice di un collega in la mia base di codice funzionante distrugge la build, non è colpa mia, mi dispiace! Questo vale anche per la direzione opposta della fusione

Both developers and architects (code reviewers) may detect bad design decisions or just wrong development directions in real-time, preventing useless work.

Se ho visto questo stile di lavoro nella mia squadra (controlla solo il codice unito), PM e TL verranno immediatamente eliminati con il segno nero

I'm talking about getting the latest version of code base and checking-in your own code to the source control in a daily basis

"Dipende" (c):

  • Se nessuno tocca i "miei" file, io (posso) non preoccuparmi di modifiche al codice non correlate
  • Se chiudo molte piccole informazioni relative ad altre attività, preferirò unire le modifiche il più rapidamente possibile
risposta data 23.11.2012 - 23:19
fonte

Leggi altre domande sui tag