行き詰まったときにさまざまな機能を操作するために飛び回るのは、プロジェクトの失敗の原因ですか？

個人プロジェクト（または仕事）で、問題に巻き込まれたり、問題の解決策を見つけ出すのを待っている場合、コードの別のセクションにジャンプしても、アプリケーションの正当な理由になると思いませんかバグが発生したり、さらに悪化したりすることはありませんか？

gitを使用せず、各機能を特定のブランチにコーディングしていると仮定すると、作業中の3つの異なる機能があり、それぞれに未解決の問題があるため、物事が手に負えなくなる可能性があります。

そのため、仕事に取り掛かると、これらのぶら下がりの問題や中途半端なコードが残っているため、ストレスがたまってしまいます。

この問題を回避する最良の方法は何ですか？（お持ちの場合）

gitのようなものを使用し、機能ごとにブランチを作成することが、この悪い習慣を回避する最も安全な方法だと思います。

他の提案はありますか？

これは問題ではありません。困惑する問題から一時的に離れることは、そのような問題を突破するための最良の方法の1つです（後で考えたとき、または次に新しい視点/心で座るとき）。

ソース管理の分岐を適切に利用し、コードの半分のソリューションを心配する必要がないことを常に確認してください。休憩を決してとらない人もいますが、それは単なる個人的な選択です。ただし、他の人と共有するために休憩を本当に押してはいけません。

smp7dで述べたように、ジャンプすることで、目の前にある問題から抜け出すことができます。ただし、作業していたコードがまだ不完全であることを忘れないことが重要です。中断した場所を必ず確認してください。

smp7dで述べたように、ソース管理と分岐は、新しい機能コードを分割し、メインコードベースとの違いを確認するための優れた方法です。

私が持っている提案の1つは、特定のメソッドに取り組んでいる場合 、そのメソッドの周りに適切な名前のユニットテストがあることを確認することです。そうすれば、次の日/週/月/年にそのコードで作業するとき、メソッドが現在テストに合格していなくても、メソッドが何をすべきかを明確に伝えることができるはずです。

それって問題ですか？実装しようとしている機能の10％で発生したときではありません。最初に何か別のことをすると、心がはっきりすることがあります。

明らかに、実装しようとする機能の90％にこだわるのは問題です。そして、他の人からの助けが必要か、上司からのわずかなキックが必要なものを完成させるために必要です（もちろん、後者は実際の技術的な問題が原因で立ち往生した場合は、生産性が低下します）。

この場合の最適なオプションは、作業中の機能を小さなサブ機能または「機能スライス」に分割して、1つずつ実装、テスト、デバッグできるようにすることです。私にとっては、これらの機能スライス、未解決の問題、リストに記載する部分を記述し、優先度（A、B、Cで十分）を与え、優先度の最も高いものに最初に取り組むことが役立ちます。

私の経験では、「飛び跳ねる」、またはより明確に「ランダムに飛び回る」というのは、目標が十分に述べられていない、より緊急の問題の症状です。

モニターの側面にポストイットノートを書くか、選択した課題トラッカーに添付された正式な仕様に書かれているかについて、非常に明確なアイデアがあれば、ほとんど常に次の作業を正確に知っています。これらの次の作業のいずれかに常に取り組んでいれば、プロジェクトで成功する可能性が高くなります。

一方、次に重要なことについてのあなたの考えがかすんでいる場合、プロジェクトが解決しようとしている問題に実際に対処する作業を実際に見つけるのははるかに難しく、より具体的には、そして、この特定の変更が完全であり、特定の問題を解決することを決定するとき、乾燥します。

「UIを使いやすくする」などの目標がある場合、次の修正がどうあるべきか、または「UIの修正」を終えて他の何かに進むことができると言うことはほとんど不可能です。一方、「これらのドロップダウンをオートコンプリートで検索フィールドに結合する」、「「foo」を「Fooly Brand Baring」に自動補完する必要がある」などの目標がある場合、修正したときは完全に明らかですその問題。

停止するタイミングが本当に明確になるまでコードを記述しないでください。明確なアイデアがない場合は、一般的な機能のために別のブランチを開始するのではなく、そのうちの1つを取得してください。

このような優れた作業仕様がある場合（個人プロジェクトでも）、「ジャンプ」は完全に安全で便利です。

問題から逃れることは解決に役立つかもしれませんが、コンテキストの切り替えにはコストがかかることに留意してください。本当に立ち往生している場合、またはミッションクリティカルなタスクが発生した場合（たとえば、顧客がダウンした場合）にのみ、そうするようにしてください。

タスク間を絶えず切り替えていると、いくつかの半分完成した機能と多くの時間の無駄に終わる可能性があります。これが、かんばんのような慣行により、進行中の作業制限を設定するよう奨励される理由です。これにより、一度に実行できるタスクはせいぜい数個に集中できるため、スループットが向上します。

並行して実装される機能の数を制限すると役立つ場合があります。他の1つの機能が終了するまでその制限を超える場合は、追加の機能の実装を拒否します。このアプローチはかんばんと呼ばれます