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

Questo non è un problema. Temporaneamente allontanarsi da un problema di perplessità è uno dei modi migliori per avere una svolta su 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. Non dovresti mai spingere davvero le pause per condividerle con gli altri.

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

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

Un suggerimento che ho è che se stai lavorando su un metodo particolare, assicurati che ci sia un test di unità con nome attorno a quel metodo. In questo modo quando lavori su quel codice il giorno successivo / settimana / mese / anno, dovresti essere in grado di dire chiaramente quale sia il metodo che si suppone fare, anche se attualmente non supera il test .

È un problema? Non quando ti viene in mente per il 10% delle funzionalità che stai tentando di implementare. A volte ti chiarisci la mente quando fai qualcosa di diverso.

Ovviamente è un problema quando si rimane bloccati per il 90% delle funzionalità che si tenta di implementare - quindi si ha bisogno dell'aiuto degli altri o di un leggero kick-ass dal tuo capo per finire quello che hai iniziato (ovviamente, quest'ultimo sarà controproducente se rimarrai bloccato a causa di problemi tecnici reali).

L'opzione migliore per questo caso spesso sta tentando di dividere la funzione su cui stai lavorando in sotto-funzioni più piccole o "feature-slice", che possono essere implementate, testate e debuggate una per una. Per me, aiuta a scrivere quelle sezioni di funzionalità, i problemi aperti, le parti da fare in una lista, dare loro priorità (A, B, C è sufficiente) e lavorare prima alle cose con la massima priorità.

È stata la mia esperienza che "saltellare" o, più chiaramente, "Saltare a caso" è un sintomo di un problema più urgente, uno degli obiettivi mal dichiarati.

Se hai un'idea molto chiara, in forma scritta, di post-it sul lato del tuo monitor o di specifiche formali allegate al tuo tracker di scelta, allora sai quasi sempre su cosa lavorare su successivo . Se lavori sempre su una di quelle prossime, avrai buone possibilità di riuscire con il progetto.

Se, d'altra parte, la tua idea di quale sia la prossima cosa più importante è confusa, è molto più difficile trovare effettivamente una cosa su cui lavorare che risolva il problema che il tuo progetto intende risolvere, o più specificamente, è molto meno incisivo quando decidi 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 "aggiustare l'interfaccia utente" e puoi passare a qualcosa altro. Se, d'altra parte, hai un obiettivo come "combinare questi elenchi a discesa in un campo di ricerca con completamento automatico" e "'foo' dovrebbe completarsi automaticamente a 'Fooly Brand Baring'", è assolutamente ovvio a quando hai risolto quel problema.

Non scrivere alcun codice finché non hai una chiara idea di quando smettere , e se non hai idee chiare, lavora per ottenere uno di quelli invece di iniziare un altro ramo per alcune funzioni generali.

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

Mentre ti allontani 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 verifica un'attività mission-critical (ad esempio, un cliente è inattivo).

Se passi continuamente avanti e indietro tra una missione e l'altra, potresti finire con diverse funzioni a metà e molto tempo perso. Questo è il motivo per cui pratiche come kan-ban ti incoraggiano a impostare un limite di work in progress. In questo modo puoi concentrarti a completare, al massimo, solo alcune attività alla volta, aumentando così il throughput.

A volte può essere utile limitare il numero di funzionalità implementate in parallelo. Rifiutarsi di iniziare a implementare una funzionalità extra se tale limite verrà superato fino al completamento di un'altra funzionalità. Questo approccio è chiamato Kanban