3か月前のプロジェクトで何をしていたのか、なぜそれを覚えているのですか？
3か月前のプロジェクトに取り組んでいたところ、突然別の緊急プロジェクトが現れ、注意を向けるように求められました。
明日から、古いプロジェクトに戻ります。自分が何をしていたのか正確には覚えていません。どこから始めればいいのかわかりません。
どのようにプロジェクトを文書化すれば、いつでも振り返って、離れたところから行くのに数分以上かかることはありません。ベストプラクティスはありますか？
私はあなたの現在の状況では役に立たないだろういくつかのアドバイスを提供したかっただけですが、あなたはそれを今すぐ実装して将来に役立つことができます。
もちろん、todoリストや問題ログなどの明らかな候補があります。最近追加された問題を見ると、プロジェクトから離れたときに何をしていたかについての手掛かりが得られるはずです。
私が取り組んできた以前のプロジェクトでは、品質管理プロセスの一環としてプロジェクトログを保持することが期待されていました。内容はあまり明確に指定されていませんでしたが、プロジェクトに関連する事柄を毎日記録し、将来の作業の継続や完了時のレビュー活動に役立つ可能性があるという考えでした。例えば：
プロジェクトの質に関する観察
このコードは、いくつかのリファクタリングを使用できます
これを機能させるために簡単な実装を行いましたが、[〜＃〜] abc [〜＃〜]の方が良いでしょう。
Todo items/issues課題追跡に正式に記録したくない
「このメソッドを
x < 0ですが、現時点では対象外です。設計上の決定-特に重要なもの。
標準の並べ替え機能はクイックソートを実行しますが、ここで必要な並べ替え条件の下で等しい項目の順序は保持されません。
明らかなアルゴリズムは[〜＃〜] abc [〜＃〜]ですが、
xが負の値になる可能性があるため、ここでは失敗し、一般化された形式が必要です（Wikipedia link）。発生した問題とその解決方法私の個人的な見解では、非常に重要な問題です。問題が発生した場合は、ログに記録してください。
コードをチェックアウトしましたが、エラーXYZ0123が発生しました。最初に、コンポーネントCをバージョン1.2以降にアップグレードする必要がありました。
後者の2つのポイントは非常に重要です。私はよく似た状況や問題に遭遇しました-時々完全に異なるプロジェクトで-そして考えました"うーん、私はこれに一日を費やしたことを覚えていますが、解決策は何でしたか？"
しばらくしてプロジェクトに戻ったときに、プロジェクトログ（自分のものか、最新の開発者のものか）を読み返すと、去ったときのフローに戻り、トラップに関するいくつかの警告が表示されます。そうでなければ再び陥る可能性があります。
やることリストは魔法です。一般に、プロジェクトごとにアクティブなTo Doリストを維持する必要があります。プログラミングが忙しいときでも、やらなければならないことがすぐにできない場合は、リストに表示されます。このリストは、電子的にプロジェクトフォルダーのスプレッドシートまたはテキストファイル、または紙のログブックなど、よく知られた場所に保管してください。
また、プロジェクトを一晩（または週末に）去るときはいつでも、ポストイットのメモを取り、そのメモに次に行うことを書き、それをモニターに貼り付けます。これにより、翌朝すぐに再開できる可能性が高くなります。
編集：
私は、to-doリスト（会場とプロジェクトによって分離された、特に優先順位が付けられたto-doリスト）が Getting Things Done ブックの重要な部分であることを指摘しておきます。
今何をする？
さて、明日から古いプロジェクトに戻りますが、自分が何をしていたのか、どこから始めればいいのか覚えていません。
私の推測では、あなたは次のセクションのいずれも行っていません。したがって、ToDoリストを検索しても機能しません。
- 期間をブロックします。これをカレンダーに入れて、プロジェクトの確認に時間をかけます。ドキュメント、コード、要件などを確認している可能性があります。
- 同意して速度に戻るにはしばらく時間がかかります。関係者全員がこれを理解していることを確認してください。 あなたがこれを理解していることを確認してください。
- 小さなタスクから始めます。小さなことを実行して、自信を再構築します。新しいアイテムのリストがある場合は、最初に小さいアイテムから作業してください。これは自信を再構築するだけでなく、プロジェクトに慣れるのにも役立ちます。
これを自分でもっと良くする方法は？
プロジェクトを文書化する方法を知りたいのですが、いつでも振り返って、離れたところから行くのに数分以上かかることはありません！
最初に、あなたの仕事を追跡するためのシステムが必要です。あなたは今そのようなシステムを持っていますか？現在のプロジェクト作業をどのように管理していますか？
私は 明日バスに当たる を得ることができました、そして私のチームは私のアクションアイテムの90％をはるかに超える良いアイデアを持っているでしょう。これは、自分を文書化するための一貫したシステムがあるためです。
- 即時作業（<1週間のアイテム）
- 「すてきな」todos
- マイルストーンとマクロ作業（詳細が意味をなさない場合）
- 要件/会議メモ
さらに、VCSを使用し、必要に応じてコードにコメントを付けます。
私は主な開発者なので、これは私と私のチームにとってうまくいきます。チームで何らかの問題追跡システムを使用できます。または、アジャイルで作業するときのバックログ。たくさんのオプションがあります。これに本当に興味がある場合は、 Getting Things Done またはその他の関連するタスク管理方法論を読んでください。
ポイントは何ですか？
システムの詳細は、それがまとまりのあるシステムよりも関連性が低く、それを使用します。そして、あなたはそれを使います。そしてそれを使用してください。これは重要。使用しないニースの完璧なシステムよりも重要です。 「私の仕事の大部分はここにありますが、いくつかは私の頭の中にあります」を行わないでください。さもないと、プロジェクトに戻るのが嫌になります。
また、コメントがコードの「何を」だけではなく「なぜ」を説明していることを確認してください。単に技術的な詳細を説明するコメントよりも、「これはIE8のバグを修正すること」を読み、コードが何をするかを思い出す方がはるかに簡単です。
私の意見では、コードプロジェクトを「再開」するには2つの部分があります。
- 中断した場所の特定
- あなたがしなければならない残されたものを思い出す
これは、バージョン管理を正しい方法で行っている場合、それが「他の脳」になることの1つだと思います。
どこでやめたのですか？コードを頻繁にコミットしている限り、最後のチェンジセットを確認してください。それはおそらくあなたの心の中で何かをジョギングするでしょう。そうでない場合は、最も古い、再生中のコミットから始めて、過去のいくつかを見てください。
あなたがしなければならないことに関しては、バックログはその目的（またはto-doリスト、または名前を付けたいものは何でも。基本的に将来のためのアイテム）を果たすべきです。
私はフルタイムのソフトウェア開発者ではありません。私は夜と週末にハッキングするプログラマーです。このため、仕事やその他のプログラミング以外のものがより優先されると、コードを一目で確認しなくても、数日から数週間かかることがあります。上記は非常に効果的であることが証明されています。
これは完全な回答を意図したものではありません。VCSやプロジェクト管理ソフトウェアの使用方法などの重要な事項について言及している非常に優れた回答はすでにいくつかありますが、他では見られなかったいくつかのポイントを追加する補遺があります。他の人にも役立つと思います。
1.書き留めるタスクが短すぎたり小さすぎたりしない
人々は通常、計画していること将来のTODOリストを作成しますが、プログラミングには集中力が必要なので、中断することができますいつでも、書き留めておくと役に立ちます今行っていることや、今していることほんの数秒で開始されます。 ahaの瞬間にあなたを襲ったソリューションを忘れることができなかったかもしれませんが、 同僚がキューブに立ち寄って表示するとき）あなたの彼の感染したつま先の写真 、そしてあなたは最終的にしかできません あなた自身の腕をかじり始めて彼を取り除く 、あなたは簡単なメモを書き留めておくとよいかもしれませんPost-It™のみの場合。
もちろん、他のより永続的なメディアの方が良いかもしれません（私は特に OmniFocus が好きです）が、ポイントは少なくともどこかに持っているです。 20分で終了し、Post-It™を捨てます。その情報が役に立つことを発見するかもしれませんが、タイムシートや請求書をクライアントに貼る、または上司/クライアントがあなたが取り組んでいることをあなたに尋ねて、あなたが思い出せないとき。これらのメモをすべてボックス、引き出し、またはフォルダにドロップすると、big割り込みが発生した場合（割り込みプロジェクト）、それらを一瞥して、取得した多くのことを思い出すことができます。プロジェクトに戻ったときにコードが見つかるところまでコードを書きます。
2.デスクでホワイトボードを使用して、全体像を捉えます
私は机の横に3 "x 4"のホワイトボードを持っているので、プロジェクトを開始するときに、プロジェクトで気付いたすべての問題の解決策についてブレインストーミングできます。それは、アーキテクチャ図、ユースケース、リスクと障害のリスト、またはあなたに関係があると思われるものである可能性があります。
いくつかのより正式なアプローチでは、図やユースケースなどを紙や電子形式で「成果物」として生成する必要がありますが、lotを作成できることがわかりました=余分な作業を行い、最終的にメインプロジェクトの実際の目的から切り離された一連のサブプロジェクトになり、あなたがしなければならない形式化されたプロセスの一部になります。誰も多くの注意を払っていないこと。ホワイトボードは、少なくとも私の経験では、実際に機能する最も単純なものです。それはあなたが望むように（カメラで）永続的であり、そして最も重要なことはあなたがあなたのアイデアをすぐに書き留めることを可能にします。
私は手にペンを置いた方がいいと思うので、私の考えを白い面に捨てるのが自然に思い浮かびますが、それが当てはまらない場合は、関連するものを決定するのに役立ついくつかの質問があります：
- 私が主任開発者だった場合、他の開発者がプロジェクトを完了している間に3か月間ハネムーンに行くつもりなら、彼らにどのような一般的な方向性を与えたいですか？彼らが知っていることを確認したいのですが、どのようなアイデアですか？どのライブラリやその他の役立つソリューションを確実に認識させたいですか？
- このプロジェクトが私の将来の経済的自立を確実にすることがわかっている100万ドルのアイデアである場合、私が3か月間私を無力化する重要な手術の予定がありました。プロジェクト？
（私が最初にアイデアを書き下ろすとき、私はそれらが私の現在の自分にとって意味があることだけを心配します。それらがダウンしたら、私はそれらをより批判的に見て、私の将来の自分や他の人にそれらが理解できるように変更を加えることができます。心配しすぎ他の人とのコミュニケーションについてas最初に書き留めておくと、ライターのブロックにつながる可能性があります。競合する目標によって頭が詰まっています。最初に取り除きます。後で明確にすることを心配します。）
お金を使って、少なくとも3 "x 4"のまともなホワイトボードを購入し、通常は作業しているスペースに掛けることをお勧めします。物理ホワイトボードには、どの仮想システムよりも多くの利点があります。
- 大きいです。多くのスペースを取ることで、その存在感を感じさせ、その上での計画はワークスペースの一部であるように感じ、常に正しい方向にあなたを向けるのに役立ちます。
- それは永続的に存在します。アクセスするために特定のアプリまたはWebサイトを起動する必要はなく、アクセス方法を忘れたり、そこにあることを忘れたりするリスクはありません。
- じっくり考えたいアイデアがあるとすぐにアクセスできます。
会議室でホワイトボードを使用し、携帯電話でスナップショットを撮っただけでは、多くのメリットが失われます。あなたがプログラミングでお金を稼ぐなら、それはまともなホワイトボードのコストに見合う価値があります。
ホワイトボードがいっぱいになったプロジェクトを中断する別のプロジェクトがある場合は、スマートフォンのスナップショットに頼る必要があるかもしれませんが、少なくとも3か月でthatが発生し、「緊急」プロジェクトが終了し、他のプロジェクトに戻る必要があります。それをホワイトボードで再現したい場合は、おそらく15分しかかかりません。その過程で大幅に改善できるため、時間の小さな投資は非常に価値があります。
3.プロジェクトを中断するコストを関係者に認識させる
飛行機のメタファーは役に立ちます。プロジェクトの開始と完了は飛行機の飛行のようなものです。フライトの途中で脱出すると、飛行機は空中に座って戻ってくるのを待つだけでなく、現在のプロジェクト/フライトから次のプロジェクト/フライトに移動するための何らかの方法が必要になります。実際、フェニックスからファーゴへのフライトの途中で、デンバーからデトロイトへ別の飛行機に乗るためにそのフライトを中断する必要があると言われた場合、デンバーの最初の飛行機を着陸させる必要があります（これは幸いなことに、飛行経路からそれほど遠くありません。実際の割り込みが常に当てはまるわけではありません）、貨物と乗客の扱いを誰かが理解する必要があります。彼らはただ座って永遠に待つわけではありません。
プロジェクトのこれのポイントは、1つのプロジェクトから別のプロジェクトへの移行には多大な時間の費用がかかり、対処しなければならない多くの損失が残るということです。
プロジェクトでは、作業中に頭の中で多くのことが明らかに発生し、[すべての考えではありませんは書面でメディアにシリアル化できますが、そうした考えのすべてのイオタではありません-are逆シリアル化されても、シリアル化されたままになります。思考の一部を書面で取り込むことはできますが、それは非常に損失の多い形式です。
問題（私が見ているように）は、プロジェクトマネージャーや他のビジネスの人々が、プロジェクトを（ガントチャートに明示的な依存関係がない限り）自由に並べ替えることができる一連のステップと見なし、人々の間で簡単に配布できることですまたはそれがビジネスにとって最も便利になるまで遅らせます。
ある程度のプログラミングを行った人なら誰でも、ソフトウェアプロジェクトをレゴブロックのように好きなように移動することはできないことを知っています。空の旅のメタファーは、少なくとも関係者が気まぐれで並べ替えられる一連の異なるステップとして明らかに扱うことができないと彼らが考えることができる具体的なものを与えていることがわかります。 理解このような中断にはコストがかかるという点を少なくとも簡単に理解できます。もちろん、それは彼らの決定ですが、彼らがあなたに別のプロジェクトを与えるために彼らが1つのプロジェクトを中断する前に、彼らにこれを知らせたいと思います。格闘するのではなく、役立つ情報と開発者の有益な視点を提供し、彼らがあなたから必要なことを何でもする準備ができていることを伝えます。しかし、あなたが伝えなければ知らないかもしれない情報を提供するだけです。
要するに：
- あなたがしているすべてを書き留めてくださいabout書き留めておく必要があるとは思わない場合でも、書き留めてください。短い鉛筆でも長い記憶を打ちます。
- 永続的にアクセスできる物理的なホワイトボードで全体像をブレインストーミングします。
- あなた可能性中断にコストがかかることを意思決定者に認識させる場合、プロジェクトの中断を回避し、少なくとも期待を設定して、プロジェクトを再開するときに少し時間がかかることを彼らに知らせます。
3か月前のバージョン管理ソフトウェアでプロジェクトの履歴を調べることができます。コミットメッセージと最新の差分を読んで、何に取り組んでいたのかを把握してください。
問題追跡システム（ Redmine または GitHub など）と組み合わせて、適切な分岐およびマージ戦略を備えたソース管理システムを使用すると、変更を区分化するのに役立ちます作成し、指示を与え、不足している「コンテキスト」をワークフローの自然な部分として文書化します。
- コードの変更を開始する前に、問題追跡システムに「問題」が記録されていることを確認してください。それはあなたの仕事の欠けている「私が何をしていた」部分をカバーします。
- ソース管理システムにブランチを作成し、そのブランチでの変更が前述の問題のみに関連していることを確認してください。これは、変更を分離し、変更の履歴を提供するのに役立ちます。「どこで中断しましたか？」という質問に答えます。後で作業に戻ったら。
- 変更が完了したら、トランクにマージして、問題を閉じます。
どのようにプロジェクトをドキュメント化すれば、いつでも振り返って、離れたところから行くのに数分以上かかることはありません。
まず、これは、数分で簡単に把握できるプロジェクト内の高レベルの説明とコード構造があることを意味します。明確な構造とコメントのない膨大な数のコード行とは対照的です。
ベストプラクティスはありますか？
以下は、非常に小さなプロジェクトから非常に大きなプロジェクトで20年以上のキャリアを通じて採用したベストプラクティスであり、それらは私と私のチームによく役立ちました。プロジェクトが大きくなるにつれて、リストされている順に適用します。
バージョン管理を使用してくださいこれにより、何が発生したか、いつ、誰が変更を適用したかについての無料の記録が得られます。また、いつでも以前のバージョンに簡単にフォールバックできます。
Modularizeコード（言語とプログラミング環境に応じて、クラス、モジュール、パッケージ、コンポーネントを使用）。
ドキュメントコード。これには、各ファイルの上部にある要約ドキュメント（これは何をするのか？理由？使用方法？）と、関数、プロシージャ、クラス、およびメソッドのレベルでの特定のコメント（何をするのか？引数と戻り値/）が含まれます。タイプ？副作用？）。
コーディング中に
TODOおよびFIXMEコメントを追加します。これは、必然的にコードベースに入り、後でWTF？！と尋ねる癖の理由と内容を思い出すのに役立ちます。例えば。：//TODO shall actually compute X and return it ... some code that does not compute X yet (maybe returns a fixed value instead) //FIXME make this constant time instead of n^2 as it is now ... some code that works but is not efficient yetダイアグラムを描画する習慣をつけてくださいモジュール/オブジェクト/システム間の呼び出しのシーケンスなどの複雑な動作や構造を文書化します。個人的に私は MLet すぐに使用でき、Niceグラフィックを作成し、最も重要なことに邪魔になりません。しかしもちろん、あなたはあなたが仕事をするのを見つけたどんな描画ツールも使うべきです。このような図面の目的は、システムを詳細に指定することではなく、簡潔に伝えることです（!!）。
早い段階でユニットテストを追加します。単体テストは、回帰テストに最適であるだけでなく、モジュールの使用法ドキュメントの形式でもあります。
早い段階でコード外部ドキュメントを追加します。 READMEから始めます。プロジェクトの実行と開発に必要な依存関係、インストール方法、実行方法について説明しています。
繰り返し作業を自動化する習慣をつけてください。例えば。コンパイル/ビルド/テストサイクルは、何らかの形でスクリプト化する必要があります（たとえば、JavaScriptでは
grunt、in Pythonfabric、in JavaMaven）。これは、戻ってきたときにすばやく速度を上げるのに役立ちます。プロジェクトが拡大するにつれて、ソースコードドキュメントを生成してドキュメントを追加します（JavaDocスタイルのコメントと適切なツールを使用してHTMLまたは=を生成しますPDFそれから）。
プロジェクトが単一のコンポーネントを超えて大きくなり、さらに複雑な展開がある場合は、必ず設計とアーキテクチャのドキュメントを追加してください。繰り返しますが、これの目的は、細部の詳細ではなく、構造と依存関係を伝えることです。
長い答えがたくさんあります。これは私が最も役立つものについての短いものです：
- クリーンなコード。
- クリーンコード
- クリーンコード
- バージョン管理（差分とコミットコメント）。
- ポストイットノート、Todoリスト、かんばんボード（例：TrelloおよびEvernoteを参照）
ただし、Diffs、Commitコメント、Post-Itメモ、Todo-Lists、またはKanban-Boardは、コンテキストが不足しているため、時間の経過とともに誤って解釈される可能性があります。したがって、最も重要なことは次のとおりです。
クリーンコード
私は日々の仕事の日記をつけています。今日何をしたか、今日何が難しかったか、次のステップは何か、将来のために今日私はどんなアイデアを持っているか。また、その日の様子について少し説明を加えます。興味深い会話や会議はありましたか？何か怒りや喜びがありましたか？これは、後でジャーナルを読むときに物事を見通しに入れるのに役立ちます。
しばらくしてプロジェクトに戻ったとき、ジャーナルの最後のいくつかのエントリを読んで、プロジェクトに慣れました。開発プロセスを覚えておくには、これらの日常的な詳細すべてが非常に重要です。彼らは、製品の使い方だけでなく、プロジェクトでの作業の様子を思い出させるので、TODOリストや通常のプロジェクトドキュメントと比べて、実際に大きな違いが生まれます。
私にとって、プロジェクトを再開する最も簡単な方法は、作業に関するメモを常に記録しておくことです。 Microsoftの「OneNote」は、ノートのページの保持とグループ化に特に適していることがわかりました。特に、検索バーを使用すると、何かに関するメモをすばやく簡単に見つけることができます。
以下は、OneNoteでプロジェクトの進捗を再開するのに役立ついくつかのことです。
毎日/毎週のログ-プロジェクトですでに行った進捗状況を把握するのに役立つように、毎日または毎週の進捗ログを保持します。
To-doリスト-一般的なTo-Doリストがありますが、自分が取り組んでいるプロジェクトの個別のTo-Doリストも保持しているので、まだやっていないことを覚えていますプロジェクトのために。 // TODO：アイテムをコードに残すこともあります。
プロジェクトノート-私がメモするものには、問題/プロジェクト追跡項目へのリンク、コードのスニペット、発生した問題、行われた決定、考えられる解決策の計画と説明、コード変更のリスト、コードリポジトリディレクトリへのリンクが含まれます。プロジェクトのメールとプロジェクトドキュメントへのリンク。
そのため、プロジェクトに戻るたびに、ノートを開くことができ、ほぼ即座に、プロジェクトでどれだけの進捗があったか、やらなければならない作業がどれだけ残っているか、さらには自分の考えの列を確認できます。
プロジェクトの追跡、ToDoリスト、Trelloなどに関する提案に加えて、TDDを実践している場合に役立つ、プロジェクトに戻るたびに新しい失敗するテストを実装して、常にプロジェクトから離れることができます（明日、来週、または来月）
座って「Run Tests」を実行し、中断したところから再開します。
コメント/ ToDoリスト/コミットに加えて、現実的であることが重要です。
サイズ、複雑さ、作業を終えた状態によっては、プロジェクトを再開するにはしばらく時間がかかる場合があります。多くの相互作用するコンポーネントの実質的なコードベースの場合、フルスピードになるまでに数日かかる場合があります。
古き良き忍耐が役に立つでしょう。
しばらくしてプロジェクトに戻ってきて困惑したとき、私は通常、最も単純で最小のタスク単位を選択して実装します。一度にたくさんのことを思い出そうとして迷うのを防ぎ、自信を少し高めます。多くの場合、私は数時間でますます大きなタスクを自動的に取り上げます。