私は、自分が唯一の開発者、プロジェクトマネージャー、デザイナー、QT担当者（はい、わかっています...悪い！）であるプロジェクトに多くの時間を費やし、時にはクライアントでもあります。

私は、フリースタイルで座って仕事をするだけでなく、プロジェクトがどれだけ時間がかかるまで、プロジェクトを計画し、自分自身を管理するためにあらゆることを試しました。 -男は毎朝チャートを燃やします（冗談ではありません）。

一人で仕事に多くの時間を費やしている人にとって、自分自身を整理し、（1人の）大規模なプロジェクトを管理し、生産性を可能な限り高く保つ最良の方法は何ですか？

目標の明確なリストを保持することは重要です。機能クリープが自己管理プロジェクトを引き継ぐのは簡単です。TDDの「動作したら完了」というアプローチも役立ちます。これにより、完璧主義者になることができなくなります。

本当に役立つのは、特定の状況で他のエンジニアやプロジェクトマネージャーが何を言うかを想像することです。しばしば、私は悪いコードから「自分自身を恥ずかしく思う」ことができます、またはスケジュールがずれているならば、軌道に乗ることができます。

どうぞ... http://xp.c2.com/ExtremeProgrammingForOne.html

XPは小規模なチームに最適であるため、うまくスケールダウンします。

• 機能リクエストのスプレッドシートを作成し、それらに優先順位を付けて、一番上のものを選択できます。
• 受け入れ基準（完了したように見えるもの）を定義し、それを実行可能なテストにコード化します
• 次に、実行するエンジニアリングタスクを定義します
• 単体テストを作成し、最も簡単なこと（YAGNI）を実行し、常にリファクタリングします。目標は、外部受入テストに合格することです
• 各セッションのタイムボックス。効果的な時間管理のために、ポモドーロのテクニックもご覧ください。
• バージョン管理を使用し、CIサーバー/バッチファイルをセットアップして、ソフトウェアのインストールまたはzipを作成します
• 頻繁にデモ。フィードバックを元のスプレッドシートにルーティングし、優先順位を変更します

1つのチームでできなかった唯一のことは、PairProgrammingです。

ソロで作業している場合。アドバイスは次のとおりです。

1. 低レベルの作業はできるだけ少なくします。簡単にコーディングできると思われるものを含めて、できるだけ多くのライブラリとツールを使用してください（ライブラリを使用しないでください）。
2. トップダウンのアプローチを取ります。本当に必要なものだけをコーディングしてください。
3. 抽象用語で問題を見つけたら、Googleで検索し、すでに証明されている学術コミュニティの研究論文を使用します。アルゴリズムをコーディングするだけです。
4. 可能な限り自由に変更できるようにシステムを設計してください。（ここからコードをコピーして貼り付けることを含む）。目的は、間違いを犯したことに気付いたときに時間を節約することです。間違えたときに捨てなければならない作業量を最小限に抑えるようにしてください。（あちこちからコピーアンドペーストする代わりに）捨てなければならないコードの一部は、そのコードの記述を失った時間と同等です。
5. 多くの自動化されたテストがあるので、変更するたびに回帰テストを定期的に実行できます。
6. 設計の責任を分離します（つまり、結合を減らします）。可能な限りモジュール化する
7. デバッガを使用してデバッグし、バイナリ検索を使用して欠陥を見つけます。
8. コードを常にリファクタリングして、（明示的な）結合とパブリックメソッドの公開（暗黙的な結合）を減らします。
9. 本当に何もない。これは、私が何か新しいことを思いつくことができる場合に備えてここにあります：P

コードレビュー。

これらは、同じプロジェクトで作業していない人にコードを説明するので、それがどのように機能するかについてのあなたの仮定を持たないので、特に役立ちます。

また、会社に関する知識を共有するという追加の利点もあるため、他の誰かがプロジェクトに携わる必要がある場合（他の人が忙しく、病気で、辞職または解雇されたため）、ゼロから始める必要はありません。 。

ストーリー、顧客との激しいやり取り、頻繁なリリース、テスト駆動開発に依存する独自のバージョンのアジャイルを開発しました。私はWikiを使用してストーリーを追跡し、顧客にできる限りストーリーを作成してもらい、顧客に協力してリリースの優先順位付けと整理を依頼しています。TDDを使用して設計と実装を推進しています。お客様が頻繁にリリースを試すことができるQAサーバーをセットアップし（新しい機能が開発されるたびに毎日）、フィードバックを迅速に得ることができます。QAにリリースせずに3回以上反復することはめったにありません。お客様は、QAバージョンに十分な機能をいつ導入するか、そしてリストにない機能をこれ以上開発する必要がないかを決定することができます。

私の会社では、私たちのグループはすべて同じプロジェクトで作業していますが、比較的独立した部分で作業しています。私たちがここでよくしていることの1つは、あなたがしていることが少しトリッキーなように思えるか、何かを実装する方法が複数ある道の分岐点にいるとき、他の誰かをつかんで長所と短所について議論することです続行します。コードのレビューが完了したとみなすまで待つと、通常、コードのレビューで多くの欠陥が明らかになりますが、大規模なアーキテクチャの変更を検討するのに多くの時間を費やしています。

また、テスト駆動開発は最近飽和しているちょっとした流行語ですが、進行中の品質チェックを提供し、テストの記述が難しくなると、おそらく再構築が必要になることがわかっているため、ソロ開発者にとって大きな助けになりますコード。また、後のメンテナーがコードを誤って検出しにくくするのを防ぐのにも役立ちます。

次のことをお勧めします。

1. テスト駆動開発
2. コードで「TODO：note here」を簡単に使用できます。すぐにできないことを見つけたら、代わりにFacebookに留まってクライアントがコールバックするのを待つ時間があるときにそれらに戻ります。
3. クライアントが結果だけでなくコードを見て購入するので、コードを書きます。クライアントがコードレビューの議長になると想像してください。
4. アサートのコードを記入してください

私は自分が100％説教していることを実践できたと言えればいいのですが、BDDはあなたの状況において良いアプローチだと思われます：

詳細はこちらのリンクをご覧ください：http : //en.wikipedia.org/wiki/Behavior_driven_development

よく似た船に乗っています。私は可能な限りアジャイルの原則を理解しようとしています。おそらく「正しく」やっていませんが、アジャイルの原則に従うことでプロジェクトで大きな成功を収めています。ショートカットを取り始めるだけではないことを確認するチームがないため、膨大な訓練が必要です。

ReSharperなどのコードフォーマットツールを使用すると、少なくとも視覚的には、他の開発者がコードを簡単に見つけられるようになります。

実際の方法論の観点では、1人の開発者が特定の方法に固執することは困難です。私は一般的に単独で働くコンサルタントであり、自分とクライアントの両方にとってアジャイルプロセスを使用するのが最も簡単だと感じています。私は通常、クライアントに要件をTracなどのツールに直接入力させます（または、クライアントに代わって）これは、他の開発者がコードの目的を特定するのに役立つだけでなく、自分自身も3か月先になります！

哲学：XP / TDD + GTD

一般的な概要：

• ステークホルダーにインタビューする
• スクリーンモックアップ、ウォークスルー、紙のプロトタイプ（必要に応じて）
• 機能/ストーリーのブレーンストーミング（利害関係者の有無にかかわらず）
• テストケースブレーンストーミング（利害関係者の有無にかかわらず）
• 全体的な設計/アーキテクチャの思考時間（必要に応じて）
• 反復計画（利害関係者と）
• 繰り返し
• プロセスレビュー、トレーニング、メンテナンス計画など（必要に応じて）

プロジェクトの人数に関係なく、適切な方法論が役立ちます。そのため、一度に1つずつ選択して、ドメインに適用してマッピングする方法を確認し、それらの成功を測定します。

おそらくもっと興味深いのは、プロジェクトに取り組んでいるのは1人だけなので、どの方法論を捨てないかという質問です。

そして、私にとって最も重要なのはソース管理です（はい、それはツールですが、ワークフローの一部であり、プロセスでもあります）。「複数の人が同時にコードを編集するのをサポートする必要がない」ため、人々はこれをパスにしたいと思うかもしれません。

皮肉なことに、GITのようなバージョン管理ソリューションを配布する方が、SVNのような個人にとっては良いと思います。

それが捨てられた場合、コードは方法論で少しルーズでグースになる可能性がありますが、重要なことは何でもあり、1人のチームプロジェクトとしてそれを扱うあなたの方法は非常に素晴らしく、規律があります。

コードを書いて、次に読む人のために、あなたではなく...彼に親切にしてください。「捨てる」コードでさえ、いつまでも残ります。

アジャイル

機能、ストーリー、およびテストケースは、正式なドキュメントよりもはるかに有益であり、一連の作業テストは、枯れ木よりも何かの使用方法や動作の方法を示すのに優れています

また、反復間で作業を引き渡すのも簡単です。

私のコンサルタントとして、私はあなたがどんな割り当てでも少なくとも2人の開発者が常にいる方法を見つけることを提案します。

アジャイルになり、他の人が従うことができるストーリーやテストのアジャイルな痕跡を残すことに同意しますが、私は人々がソロで作業している間、それや他のプロセスや方法論が固執するとは思いません。

コードレビューは良いスタートだと思いますが、特定の問題/問題またはいくつかの機能強化に取り組むためにペアコードレビューやペアプログラミングを行うなど、非公式で楽しいときに気に入っています（たとえば、新しいコーディング標準に合わせてレガシーコードを変更する）。時々、2組の目が1組よりも優れており、また楽しいこともあります。また、フォーマル/インフォーマルランチのように、セッションを議論して、個々に行ったことやグループとして話したこともあります。たとえば、使用した新しいパターンや問題の解決方法について説明します。