Come gestisco il codice di unione che non è stato unito in ~ 3 anni in modo agile? [chiuso]

Naviga le tue risposte
5

Il nostro team ha recentemente adottato pratiche agili e la maggior parte del team è nuovo in termini di agilità.

Nel nostro prodotto, utilizziamo un codice sviluppato da un altro team e solo loro mantengono quel codice. Negli ultimi 4-5 anni, gli sviluppatori precedenti hanno unito il codice che intendevano utilizzare e non tutto ciò. Nel tempo, anche il codice nel nostro ramo è stato personalizzato. Ora per 3 anni, queste basi di codice non sono state unite. Ci aspettiamo un sacco di cambiamenti e il processo di risoluzione dei conflitti manuale per eseguire un'unione, poiché tutti noi siamo nuovi in questo codice e anche il codice è fuori sincrono da molto tempo.

Come dovremmo affrontare questo tipo di compito / storia in modo agile? Ci sono delle linee guida per affrontare un compito così poco chiaro in cui l'incertezza è molto alta e non sappiamo quanti conflitti / bug emergeranno?

EDIT: 1 per favore portami con me se la domanda non è chiara, fammi sapere nei commenti e cercherò di chiarire il più possibile. Quindi lasciami provare ancora una volta.

In quanto team di AGILE, ciò che io (e il team) abbiamo imparato finora è che, prima che inizi lo sprint di 2 settimane, discutiamo i requisiti con PM, comprendiamo il lavoro da fare, finalizziamo l'approccio per qualsiasi progetto di DB se e poi due inizia la settimana di sprint. nel mezzo un giorno facciamo anche un'altra sessione PBR in cui è possibile sollevare nuove preoccupazioni per lo sprint attuale o semplicemente continuiamo a comprendere nuove storie per il prossimo sprint. Nell'ultimo giorno di Sprint facciamo Sprint Demo, e il prossimo Day Sprint Retrospective.

Recentemente ho scoperto la parola Spike. molti team di AGILE usano lo Spike come un periodo di 2-3 giorni tra gli sprint o alla fine dello sprint per finire il compito secondario restante e non hanno bisogno di portare le storie intere al prossimo sprint. O a volte all'inizio dello sprint per finalizzare il design / approccio o per scovare la prova del concetto di qualcosa.

Quando I (team) ha visto questo task di unione dei merge, siamo come se non fosse in grado di suddividere questa storia in un compito confinato poiché il 90% delle cose è sconosciuto. non abbiamo automatizzato il test sul codice, non abbiamo unito questo codice prima e ancora questa è un'unione Baseless sul lato SQL. che cosa mai stimiamo ci sono molte possibilità che una buona quantità di attività possa rimanere incompleta. ora in retrospettiva questo diventerà un male per la squadra. e tale compito può anche disturbare la velocità della squadra.

Quindi la mia domanda è: in che modo altre persone includono questo compito nella squadra AGILE? Questo è veramente eseguito come SPRINT? o questo dovrebbe essere uno sforzo una tantum da parte del team e non ha effettuato l'accesso alla scheda AGILE? In un certo senso sto cercando una guida su come AGILE permette di eseguire tale compito. Se non lo Sprint c'è qualcos'altro?

    
posta Anup Shah 10.03.2014 - 15:41
fonte

4 risposte

9

Non c'è nulla di "agile" in un'unione di 3 anni.

La tua squadra dovrà mettere da parte "agile" per un po ', probabilmente molto più di un singolo sprint. Prima di unire e testare in modo estensivo, dovrai congelare la base di codice corrente, così saprai che il codice di partenza è perfettamente funzionante. Quindi dovrai eseguire l'unione completa, senza introdurre modifiche non correlate per la sua durata. Poi dovrai testare almeno altrettanto bene come quando hai iniziato, perché non importa quanto ci provi, introdurrà bug. Una volta che hai fatto, puoi tornare ad essere agile, ma tutta quella roba nel mezzo è una classica soluzione a cascata per un classico problema a cascata.

Oh, e assicurati di contrassegnare il repository immediatamente prima e dopo l'unione - per un anno o più, incolperesti ogni strano bug su " che $ # @ @ @ $ # ^% big merge" abbiamo fatto "e vorrai riesaminare le modifiche per convincerti di sbagliare.

    
risposta data 10.03.2014 - 22:31
fonte
8

I sono d'accordo con MetaFight , questo è difficile.

Solo per eliminare un punto di vista contrarian, devi davvero unire il codice?

Hai due grandi blocchi di codice che condividono un antenato comune. Si sono separati l'uno dall'altro almeno 3 anni fa. I blocchi sono stati gestiti da due gruppi indipendenti che apparentemente non si parlano tra loro.

Quale valore ottiene l'azienda da questo sforzo di fusione? Sai che sarà costoso, difficile e richiederà molto tempo. Potrebbe essere più economico mantenere a tempo indeterminato 2 basi di codice piuttosto che spendere gli anni di sviluppo per unirle. (La manutenzione del codice fase di produzione è molto più economica rispetto allo sforzo della fase di sviluppo)

    
risposta data 10.03.2014 - 16:58
fonte
7

Questo è difficile.

Dovendo unire due rami di codice con cui non hai familiarità, è difficile cominciare. Aggiungi 3 anni di sviluppo divergente e hai fatto qualcosa per lasciare il mio lavoro finito;)

Ma cerchiamo di essere costruttivi.

Non esiste una soluzione facile per i conflitti di fusione. Dovrai risolverli manualmente.

E, sfortunatamente, a ogni conflitto di unione viene un ulteriore rischio di regressione.

Se sei fortunato, il tuo codice e il codice da unire avranno già una copertura di test automatizzata molto buona. Questo è importante perché nessuno nel team sa qual è il comportamento previsto delle interiora dell'applicazione. I tuoi test lo sapranno per te.

L'idea è che, dopo aver unito entrambe le filiali, i test automatici evidenzieranno eventuali regressioni risultanti dall'unione.

D'altra parte, potresti essere sfortunato e scoprire che c'è una copertura di prova molto piccola o nulla. In questo caso dovrai iniziare a scrivere test automatici. Puoi scrivere questi test di integrazione e unità contro il tuo codice, e si spera che l'altro team accetti di fare lo stesso con il loro. Altrimenti, dovrai farlo da solo.

A seconda delle dimensioni dell'applicazione, il raggiungimento della copertura funzionale del 100% potrebbe non essere possibile in un ragionevole lasso di tempo. L'unica cosa che posso suggerire qui è concentrarsi sulle funzionalità più importanti e dedicare un po 'di tempo ai test di regressione manuale per coprire il resto.

    
risposta data 10.03.2014 - 16:45
fonte
6

Mi sembra che potrebbe essere un grosso errore trattarlo come un grande esempio di unione, qualcosa che coinvolgerà una serie insolitamente lunga di sedute di fronte a uno strumento di unione e premendo 'accept / rifiuta le modifiche ".

Invece, vorrei:

  • Dedica una quantità appropriata di tempo, forse una settimana, leggendo entrambi gli insiemi di codice.
  • Decidi quale ha l'architettura e i test migliori; rendilo (chiamalo sistema A) alla linea di base
  • Assicurarsi che ci sia un discreto set di test automatici per il sistema A; probabilmente per lo più in stile di integrazione vicino ai test end-to-end.
  • estrae un elenco del set richiesto di funzionalità dal sistema B
  • metti quelle funzionalità sul sistema Un backlog
  • man mano che queste funzionalità sono implementate, considera l'estrazione del sistema B per utili bit di codice. Ma in realtà stai reimplementando le funzionalità, con almeno la normale quantità di test; forse un po 'di più.
  • come sottosistemi di A diventano feature-complete i requisiti di wrt B, scambiati in produzione su entrambi i sistemi, scartando quella parte di B.
  • ripeti fino a quando rimane solo una parte di B: fai in modo che il sottosistema 'do-B' di A.
risposta data 11.03.2014 - 00:46
fonte

Leggi altre domande sui tag

Come posso raccogliere i dati del cliente su Google App Engine senza utilizzare troppo le istanze di Datastore / Backend? Statico e non statico? (con funzioni non OOP)