Qual è il modo più efficiente per uno sviluppatore di passare da un'attività all'altra?

Question

Sto cercando una descrizione del tipo di flusso di lavoro della serie di passaggi che esegui per passare da un'attività di sviluppo software a un'altra. Se un passaggio riguarda uno strumento, specifica quale strumento e come viene utilizzato. L'obiettivo del flusso di lavoro è ottenere la transizione più semplice possibile dall'attività n. 1 all'attività n. 2 e viceversa.

consideri questo scenario ...

• Stai l'implementazione di una nuova storia utente e, mentre hai fatto progressi finora oggi, non è ancora finito e che non hanno ancora attuato le vostre prove.
• Il tuo vantaggio arriva con un bug ad alta priorità che sta bloccando il tuo team di test. È necessario interrompere ciò che si sta facendo e ottenere il bug corretto. Il bug è in una build di tre giorni fa, che è la build più recente acquisita dal team di test.

È possibile correggere il bug in una nuova versione delle fonti, ma deve essere una versione stabile e non può includere la funzione incompleta si sta attualmente lavorando.

Answer 1

Direi che i passaggi che è necessario prendere nello scenario che descrivi dipendono al 100% per l'ambiente di sviluppo e gli strumenti è stato impostato.

Utilizzando Perforce per il codice sorgente controllo di versione, abbiamo messo a punto un sistema di ramificazione in cui le uscite sono separati dal lavoro di sviluppo e tutti i rami di sviluppo derivano da un unico ramo "accettazione". Ogni ramo viene utilizzato per un singolo problema o per un insieme di problemi strettamente correlati. Non è possibile elaborare altri problemi in un ramo finché le modifiche non sono state integrate nel ramo di accettazione.

Sì, vuol dire che abbiamo molti rami. Sì, eseguiamo molte sincronizzazioni (accettazione fino a un ramo di lavoro) e integrazione (il ramo di lavoro è accettato). Ma il suo valore è incalcolabile quando si passa facilmente da un'attività all'altra, tornando a un test costruito, individuando due problemi che si mordono, ecc.

Dopo lo sviluppo ha fatto il suo dovere (inclusi i propri test) , un problema è testato dal team di controllo qualità. Primo in isolamento nel proprio ramo. Dopo questo è integrato nel ramo accettazione e viene eseguito un test di regressione per trovare eventuali problemi con problemi indipendenti che si mordono a vicenda. Quando tutti i problemi relativi a un rilascio sono stati così integrati nell'accettazione, il team di controllo qualità esegue una regressione completa e un nuovo test di funzionalità.

Quindi, il ramo di accettazione è sempre lo stato "ultimo" di sviluppo per l'app.

in questo insieme lo scenario che descrivi avrebbe giocato come:

• Lascia il mio compito attuale così com'è, forse il check-nei cambiamenti in sospeso in modo da non perderli quando il mio computer si blocca. Se ciò comporta la rottura di una build giornaliera di quel ramo, non effettuerei il check-in, a meno che non sia facile correggere gli errori di compilazione. (Si noti che abbiamo molte app nella nostra suite di applicazioni e mentre le mie modifiche possono essere compilate nell'app a cui sto lavorando, potrebbero comunque interrompere la compilazione di altre app nella nostra suite) La nostra regola è: ogni invio potrebbe interrompere la funzionalità, ma non deve rompere il processo di costruzione.

• Trova un ramo "vuoto", un ramo che non è attualmente utilizzato per alcun lavoro di sviluppo o, se tutti i rami sono stati creati, ne crea uno nuovo.

• Forza sincronizzazione del ramo di accettazione e del ramo di lavoro selezionato in modo che la mia macchina abbia lo stato più recente per entrambe le filiali.

• Sincronizzare (forzato se necessario) lo stato più recente del ramo di accettazione sul ramo di lavoro, quindi il ramo di lavoro selezionato è lo stesso del ramo di accettazione.

• Aprire la suite di applicazioni di quel ramo nell'IDE, eseguire il debug e risolvere. Invia al ramo di lavoro.

• Chiedi a QA di dare un'occhiata al ramo di lavoro. Se sono soddisfatti, integrare le modifiche fino all'accettazione in modo che possano continuare il test.

• Ripristinare l'IDE per lavorare sulla suite di applicazioni nel ramo su cui stavo lavorando in precedenza.

• Risciacquare e ripetere.

Answer 2

Il cambio di attività è una cosa del cervello. Non penso che ci sia uno strumento per farlo per te. Se c'è, sono anche interessato.

Ogni persona ha il suo modo di preparare, alcuni non preparare a tutti e sono in un'altra cosa come un gioco da ragazzi, alcuni prendono più tempo ecc Dipende l'uomo/donna.

Certo, puoi provare a creare alcuni traguardi mentali (prendere appunti, posizionare un promemoria, ecc.) Per tornare ad esso quando si ritorna all'attività, ma questo di nuovo dipende da altri fattori (quanto è stato il turno di attività, quanto è silenzioso l'ufficio, la familiarità con l'attività, moon phases ecc.).

Il modo più efficace per uno sviluppatore per passare tra i compiti credo sia soggettivo. Nel frattempo, hai letto il Human Task Switches Considered Harmful da Joel Spolsky?

Answer 3

Alt + Tab è come lo facciamo.

Answer 4

Considerando lo scenario,
, è possibile controllare la versione stabile delle origini in un'altra copia di lavoro, correggere il bug, eseguire il commit.
Quando torni al lavoro incompleto, fai un aggiornamento e continua a lavorare.

Answer 5

Quando si lavora su qualcosa che di solito hanno un paio di idee, alcune cose hai intenzione di fare, alcune cose che non è chiaro e deve essere risolto in seguito. Tende a perdersi quando si passa ad altre attività.

ho trovato utile scrivere giù da qualche parte - scattare un'istantanea del cervello. Più tardi è più facile ripristinarlo e tornare più velocemente al tuo compito originale.

Answer 6

Prendo nota di ogni file su cui sto lavorando all'interno di un oggetto Task/Todo con un promemoria in ca. la quantità di tempo che sarò lontano da esso. Quindi salvi e chiudo ciascuno di questi file per evitare che mi distraggano/elimina la confusione/creo spazio per la nuova attività sul mio desktop. Ho il ricordo di una pulce, quindi ho bisogno di tutto l'aiuto che posso ottenere.