Saltare in giro per lavorare su diverse funzionalità quando rimani bloccato, è una fonte di fallimenti del progetto?

Sui progetti personali (o sul lavoro), se si rimane bloccati su un problema o in attesa di trovare una soluzione al problema, se si passa a un'altra sezione del codice, non pensare che sarà una buona ragione per la tua applicazione sarà difettoso o peggio ancora non essere mai completato?

Supponendo che tu non stia usando git e codifichi ciascuna funzione in un ramo specifico, le cose possono sfuggire di mano poiché hai 3 diverse funzioni su cui stai lavorando e hai problemi irrisolti in ognuna.

Quindi, quando hai finito di lavorare, sei stressato perché hai questi problemi sospesi e il codice mezzo cotto persistono.

Qual è il modo migliore per evitare questo problema? (se ce l'hai)

Immagino che usare qualcosa come git e creare un ramo per funzione sia il modo più sicuro per evitare questa cattiva abitudine.

Altri suggerimenti?

Questo non è un problema. Allontanarsi temporaneamente da un problema imbarazzante è uno dei modi migliori per fare una svolta su un tale problema (o più tardi quando ci pensi o la prossima volta che ti siedi con una nuova prospettiva / mente).

Assicurati sempre di utilizzare correttamente la diramazione del controllo del codice sorgente e non dovrai preoccuparti delle mezze soluzioni nel codice. Alcune persone non commettono mai pause, ma questa è solo una scelta personale. Tuttavia, non dovresti mai fare delle pause per condividerli con gli altri.

Come menzionato smp7d , saltare in giro può darti una buona pausa mentale dal problema in questione. Tuttavia, è importante non dimenticare che il codice su cui stavi lavorando è ancora incompleto. Assicurati di sapere da dove eri rimasto.

Come menzionato smp7d, il controllo del codice sorgente e la ramificazione sono un ottimo modo per dividere il nuovo codice funzione e vedere come differisce dalla base di codice principale.

Un suggerimento che ho è che se stai lavorando su un metodo particolare, assicurati che ci sia un unit test ben definito attorno a quel metodo. In questo modo quando lavori su quel codice il giorno / settimana / mese / anno successivo, dovresti essere in grado di dire chiaramente cosa dovrebbe fare il metodo , anche se al momento non supera il test.

È un problema? Non quando ti viene in mente il 10% delle funzionalità che stai tentando di implementare. A volte la tua mente diventa più chiara quando fai prima qualcosa di diverso.

Ovviamente è un problema quando rimani bloccato per il 90% delle funzionalità che tenti di implementare - quindi hai bisogno dell'aiuto di altri o di un leggero calcio del tuo capo per finire ciò che hai generato (ovviamente, quest'ultimo lo farà essere controproducente se ti sei bloccato a causa di problemi tecnici reali).

La migliore opzione per questo caso è spesso quella di cercare di dividere la funzionalità su cui si sta lavorando in funzioni secondarie o "sezioni" più piccole, che possono essere implementate, testate e messe a punto una alla volta. Per me, aiuta a scrivere quelle sezioni di funzioni, problemi aperti, parti da scrivere in un elenco, dare loro priorità (A, B, C è sufficiente) e lavorare prima sulle cose con la massima priorità.

È stata la mia esperienza che "saltare in giro", o più chiaramente "saltare in modo casuale", è un sintomo di un problema più urgente, uno degli obiettivi male indicati.

Se hai un'idea molto chiara, per iscritto, se post-it sul lato del monitor o in specifiche formali allegate al tuo tracker di problemi scelto, allora quasi sempre sai esattamente su cosa lavorare dopo . Se lavori sempre su una di quelle cose successive, avrai buone possibilità di avere successo con il progetto.

Se, d'altra parte, la tua idea di qual è la prossima cosa più importante è confusa, è molto più difficile trovare effettivamente qualcosa su cui lavorare che risolva effettivamente il problema che il tuo progetto mira a risolvere, o più specificamente, è molto meno tagliato- e-asciutto quando si decide che questo particolare cambiamento è completo e risolve un problema particolare.

Se hai un obiettivo come "rendere l'interfaccia utente più facile da usare", beh, è ​​quasi impossibile dire quale dovrebbe essere la prossima correzione, o quando hai finito di "riparare l'interfaccia utente" e puoi passare a qualcos'altro. Se, d'altra parte, hai un obiettivo come "combinare questi menu a discesa in un campo di ricerca con il completamento automatico" e "" pippo "dovrebbe essere completato automaticamente in" Fooly Brand Baring "", è del tutto ovvio quando hai risolto quel problema.

Non scrivere alcun codice fino a quando non hai un'idea molto chiara di quando fermarti , e se non hai idee chiare, cerca di ottenerne uno invece di avviare un altro ramo per alcune funzionalità generali.

Se hai una buona specifica di lavoro (anche per progetti personali), allora "saltare in giro" è assolutamente perfetto, sicuro e utile.

Mentre allontanarti da un problema può aiutarti a risolverlo, tieni presente che c'è un costo per cambiare contesto. Dovresti provare a farlo solo quando sei veramente bloccato o quando si presenta un'attività mission-critical (ad es. Un cliente è inattivo).

Se si passa continuamente da un'attività all'altra, è possibile che si verifichino diverse funzioni semifinite e un sacco di tempo sprecato. Ecco perché pratiche come il kan-ban ti incoraggiano a fissare un limite di lavori in corso. In questo modo puoi concentrarti sul completamento, al massimo, solo di alcune attività alla volta, aumentando così la produttività.

A volte può essere utile limitare il numero di funzionalità implementate in parallelo. Rifiuta di avviare l'implementazione di una funzionalità aggiuntiva se tale limite viene superato fino al completamento di un'altra funzionalità. Questo approccio si chiama Kanban