一人のための最良の開発方法論？
私は、自分が唯一の開発者、プロジェクトマネージャー、デザイナー、QT担当者（はい、わかっています...悪い！）であるプロジェクトに取り組んでいます。
私は、プロジェクトを計画して自分で管理するために、フリースタイルで座って作業するだけでなく、プロジェクトが完了するまで、ほぼすべてのことを試してみました。 -毎朝チャートを燃やします（冗談ではありません）。
一人で多くの時間を費やしている人にとって、自分を整理し、大規模な（1人の）プロジェクトを管理し、生産性を可能な限り高く保つための最良の方法は何ですか？
あなたの目標の明確なリストを維持することは不可欠です。機能クリープが自己管理プロジェクトを引き継ぐのは簡単です。 TDDの「機能するときに完了する」というアプローチも役立ちます。これは完全主義者になることを防ぎます。
本当に役立つのは、特定の状況で別のエンジニアやプロジェクトマネージャーが何を言うかを想像することです。しばしば私は悪いコードから「自分を恥じる」ことができる、あるいはスケジュールがずれていれば軌道に戻ることができる。
どうぞ... http://xp.c2.com/ExtremeProgrammingForOne.html
XPは小規模なチームに最適であるため、適切にスケールダウンします。
- 機能リクエストのスプレッドシートを作成し、優先順位を付けて、一番上のものを選択できます。
- 受け入れ基準を定義し（どのように見えるか）、それを実行可能なテストにコード化します
- 次に、完了するためのエンジニアリングタスクを定義します
- 単体テストを作成し、最も単純なこと（YAGNI）を実行し、常にリファクタリングします。目標は、外部受け入れテストに合格することです
- 各セッションのタイムボックス。効果的な時間管理については、 ポモドーロテクニック もご覧ください。
- バージョン管理を使用してCIサーバー/バッチファイルをセットアップし、ソフトウェアのインストールまたはZipを作成します
- 頻繁にデモ。フィードバックを元のスプレッドシートにルーティングし、優先順位を付け直す
1つのチームで実行できなかった唯一のことは、PairProgrammingです。
あなたが一人で働いているなら。ここにアドバイスがあります：
- 低レベルの作業をできるだけ少なくします。簡単にコーディングできると思うものを含めて、できる限り多くのライブラリとツールを使用します（そうしないで、ライブラリを使用してください）。
- トップダウンのアプローチを取る。本当に必要なものだけをコーディングしてください。
- 抽象用語で問題を見つけたら、グーグルで検索し、すでに証明されている学術コミュニティからの研究論文を使用してください。あなただけのアルゴリズムをコーディングする必要があります。
- できる限り自由に変更できるようにシステムを設計してください。 （ここからいくつかのコードをコピーして貼り付けます）。目的は、あなたが間違いを犯したことに気づいたときに時間を節約することです。間違えたときに捨てなければならない作業量を最小限に抑えるようにしてください。 （あちこちからコピーアンドペーストする代わりに）捨てなければならないコードの一部は、そのコードの記述を失った時間と同じです。
- 変更を加えるたびに定期的に回帰テストを実行できるように、自動テストをたくさん用意する
- 設計の責任を分離します（つまり、結合を減らします）。可能な限りモジュール化する
- デバッガーを使用してデバッグし、バイナリ検索を使用して欠陥を見つけます。
- 常にコードをリファクタリングして、（明示的な）結合とパブリックメソッドの公開（暗黙的な結合）を減らします。
- 本当に何もない。これは私が何か新しいものを思い付くことができるようにここにあります：P
コードレビュー。
これらは、同じプロジェクトで作業したことがない人にコードを説明するので特に役立ちます。そうすれば、コードがどのように機能するかについての想定がなくなります。
また、会社全体で知識を共有できるという利点もあるので、他の誰かがプロジェクトに取り組む必要があるとき（他の場所で忙しい、病気、辞任、解雇など）、ゼロから始める必要はありません。 。
私は自分のバージョンのアジャイルを公開しました。アジャイルは、ストーリー、激しい顧客との対話、頻繁なリリース、テスト駆動開発に依存しています。私はwikiを使用してストーリーを追跡し、お客様にできるだけ多くの記事を書いてもらい、お客様に私と協力してリリースの優先順位を付けて整理します。 TDDを使用して、設計と実装を推進します。私は、顧客が頻繁なリリースを試すことができるQAサーバーをセットアップし（新機能が開発されるたびに毎日）、フィードバックを迅速に受け取ることができるようにします。 QAをリリースせずに3回を超えるイテレーションを行うことはほとんどありません。顧客は、QAバージョンに公開するのに十分な機能があるかどうか、そしてリストにない機能を開発する必要がないかどうかを決定します。
私の会社では、私たちのグループはすべて同じプロジェクトに取り組んでいますが、比較的独立したプロジェクトに取り組んでいます。私たちがここでよく行うことの1つは、やっていることが少しトリッキーに思えるか、何かを実装するための複数の方法で道路の分岐点にいるとき、他の誰かをつかんで前に賛否両論について話し合うことです続行します。コードのレビューが終了したと考えるまで待つと、コードレビューで明らかに多くの欠陥が明らかになりますが、大規模なアーキテクチャの変更を検討するためにすでに多くの時間を費やしています。
また、私はテスト駆動開発が最近飽和している少し流行語であることを理解していますが、それはあなたが行くにつれて品質チェックを提供し、テストを書くことが困難になったときあなたはおそらくあなたのいくつかの再構築が必要であることを知っているのでソロ開発者にとって大きな助けになるでしょう。コード。また、後でメンテナが誤ってコードを破壊して、検出が困難にならないようにするのにも役立ちます。
以下をお勧めします：
- テスト駆動開発
- コードで「TODO：ここに注意」を頻繁に使用すると、すぐに実行できないことがわかり、クライアントが電話をかけるのを待たずにFacebookに留まる時間があるときに戻ってきます。
- あなたのクライアントが結果だけでなくコードを見てそれを買うようにあなたのコードを書いてください、あなたのクライアントがコードレビューの議長であると想像してください。
- アサートのコードを入力してください
私は100％説教したことを実践できたと言えるかもしれませんが、BDDはあなたの状況で採用する良いアプローチのようです：
詳細はこちらをご覧ください： http://en.wikipedia.org/wiki/Behavior_driven_development
哲学：XP/TDD + GTD
一般的な概要：
- 関係者へのインタビュー
- 画面のモックアップ、ウォークスルー、紙のプロトタイプ（必要に応じて）
- 機能/ストーリーブレーンストーミング（関係者の有無にかかわらず）
- テストケースのブレーンストーミング（利害関係者の有無にかかわらず）
- 全体的な設計/アーキテクチャの思考時間（必要に応じて）
- 反復計画（利害関係者と共に）
- 反復
- プロセスのレビュー、トレーニング、メンテナンス計画など（必要に応じて）
私はよく似たボートに乗っています。私はアジャイルの原則（そして私はそれらを理解しています）を可能な限り守るよう努めています。私はおそらく「正しく」物事を行っていませんが、アジャイルの原則に従うことを試みることによって私のプロジェクトで大きな成功を収めました。ショートカットを取るだけではいけないことを確認するチームがいないため、膨大な訓練が必要です。
ReSharperなどのコードフォーマットツールを使用すると、少なくとも視覚的には、コードを他の開発者が簡単に取得できることがわかります。
実際の方法論に関しては、単一の開発者が特定の方法論に固執することは困難です。私は一般的に一人で働くコンサルタントですが、私もクライアントもアジャイルプロセスを使用するのが最も簡単だと思います。私は通常、クライアントに自分の要件をTracなどのツールに直接入力してもらうようにします（または私が代わりに行います）。これは、他の開発者がコードの目的を特定するのに役立つだけでなく、3か月後にも自分自身を助けます！
プロジェクトの人数に関係なく、適切な方法があれば役立ちます。そのため、一度に1つ選択して、ドメインに適用してマッピングする方法を確認し、それらの成功を測定してください。
おそらくもっと興味深いのは、プロジェクトに取り組んでいるのは1人しかいないので、どの方法論を捨てないようにするかということです。
そして、私にとって際立っている重要なものはソース管理です（はい、これはツールですが、ワークフローの一部であり、プロセスでもあります）。 「複数の人が同時にコードを編集するのをサポートする必要がない」ので、これをパスにしたくなるかもしれません。
皮肉なことに、GITのような分散バージョン管理ソリューションは、SVNのようなものよりも個人に適していることがわかりました。
それが捨てられた場合、コードは方法論で少しおおらかになる可能性がありますが、重要なことは何であれ、1人のチームプロジェクトとしてそれを扱うあなたの方法は非常に素晴らしく、規律があります。
あなたではなく、次に読む人のためにコードを書いてください...彼/彼女に親切にしてください。 「捨てる」コードでさえ、永久に残ります。
コードレビューは良いスタートだと思いますが、特定の問題/問題またはいくつかの拡張（たとえば、新しいコーディング基準を満たすためにレガシーコードを変更する）に取り組むためにペアコードレビューやペアプログラミングを行うなど、非公式で楽しいものになったら気に入っています。 ）。時々、2組の目が1組よりも優れていて楽しいこともあるので、共有したり、話し合ったりすることの方が開かれているように感じます。また、公式/非公式のランチやセッションについて話し合って、個別に、またはグループとして何をしたかについて話すこともできます。問題をどのように解決したか、または使用した新しいパターンについて言及しますか？
アジャイル
機能、ストーリー、およびテストケースは、より正式なドキュメントよりもはるかに有益であり、一連の実際のテストは、何かを使用する方法または何かがどのように機能するかを示すのに、大量の枯れ木よりも優れています
また、反復の合間に作業を引き渡すのも簡単です。
私自身のコンサルタントとして、どのような割り当てでも常に少なくとも2人の開発者がいる方法を見つけることをお勧めします。
アジャイルに移行すること、および他の人がフォローできるストーリーやテストのアジャイルトレースを残すことに同意しますが、他のプロセスや方法論がstickになるとは思いません。