ソースコントロールについて学んだ後、私がやった最初のことはsvnでプロジェクトを行うことです。 gitについて学んだ後、私は個人的なプロジェクトでそれを使用しました。 UML /デザインパターン/デザイン原則/ TDDについて学んだ後、私はそれらを個人的なプロジェクトに適用しました。どのように私はアジャイル開発に同じことをすることができますか？アジャイルはチームや大きなプロジェクトのためのものですか？これらの繰り返しの仕組みはどのように設定するのですか？個人的なプロジェクトにアジャイルを適用するには？
私はアジャイルは間違いなくチームプロジェクトだけではないと思います。アジャイルは、個人的なプロジェクトであっても、多くのタイプのプロジェクトに同様に適用される一連の価値を提唱しています。私はちょっと前のあなたの状況にあって、個人的な大学プロジェクトにアジャイル開発を適用しようとしていて、その過程で多くのことを学んでいました。アジャイルの考え方はあなたを与えることができるいくつかの有用なものが含まれます：最終製品に付加価値をものに
作業を。自分自身を機能のバックログにし、顧客であるかのように優先順位を付けます。次に、自分が今やりたいことではなく、製品の価値に基づいた機能を身に付けるように訓練します。これにより、使用しない不必要な、過剰に設計されたコードがたくさんあります。期限がある場合は、さらに重要です。
進化した設計をしてください：おそらく働きやすく、無慈悲にリファクタリングする最も単純なものから始めましょう。
最後の責任あるモーメントまでの決定を延期する。
自分自身をスプリントまたはイテレーションにする（大学のプロジェクトでは非常に重要）。
...
あなたは再びアジャイル方法論の一部の上に行けば、私はあなたが自分で適用できる価値観や慣行の多くを見つけることだと思います。
この回答を書いているうちに、少なくとも3つの他の回答が出てきて、私に打ち明けました。私はそれらすべてに同意します。この上
1人のプロジェクトにアジャイルコーディングを適用するのは難しいです。その利点の多くは、焦点を当てた領域ですばやくコラボレーションできる小規模のチームを対象としているためです。 - たび、あなたが方向を変えることができる
必要性を感じてください
多くのソロ開発者は、おそらくは、コード構造によっては他の人の負担がないため、いつでも同じように見えるため、アジャイル技術を採用しています。最大の違いは、プロジェクトの開始時です。あなたはまだ計画を立てる必要がありますが、何かを稼働させることは、他の方法論（すなわち、滝）よりももっと集中しています – Oli
アプリケーションに必要なタスクと機能のリストを作成します。それらの仕事を取ってcard wallに入れてください。
あなたは本当に自分でミーティングをすることはできませんが、午前中は、あなたがその日にやることと昨日成功したことを決めることができます。それらの作業を行い、それらを行い、次の作業に移動します。継続的に統合された稼働中のソフトウェアを提供しているすべてのポイントで、バックログを更新してください。バグを修正したばかりの「バグバッシュ日」があるかもしれません。それは一人のスクラムだろう。 :)
はストーリーのカードを思い付く方法論ですか？ TDD？設計とアーキテクチャはどこで行われていますか？ – kthakore
1人のプロジェクトでは、「Feature Driven」と言います。設計は、あなたが構築している機能を知った後に行われます。 –
1人のプロジェクトにスクラムを使用することは可能です。
あるバックログを作成し、次の週のための計画を作成し、各プロジェクトごとに半日更新burndowns。
いくつかの考え:)：あなたは、時間の長さにわたって何をしたいか選ぶところ
個人的な1人のプロジェクト、IMOではかなりアジャイルである可能性があります。
ここでのアドバイスはすべて役に立ちますが、通常は言及されていないアジャイルの重要な側面が1つあります。
アジャイルでは、自分が行ったこと、やっていること、行く場所、必要に応じて適切なコース修正を行うことを求めます。
私はBig VisibleチャートとBurndown/Burnupチャートがとても有用だと思うので、これらのチャートを簡単に作成するプログラムTask Analyticsを書きました。これは、小さなプロジェクトや1人のプロジェクトに最適です。
幸運。
素敵なプロジェクトです。 ...私は見通しを使用しない...申し訳ありません。私は似たようなものを作り、うまくいけばそれを他の人のためのオープンソースにしますが、いいですね。 – kthakore
ペア開発以外にも、複数の役割を果たしたい場合は、残りのプラクティスを実行できます。あなたと仕事をしたい人がいる場合は、ペア開発をすることもできます。
まず、製品のバックログを作成します。これは、開発したい機能やストーリーカードの優先順位リストです。単一の反復またはスプリントで完了できる作業よりも大きいカードはありません。スプリントが1〜2週間であれば、それは優先順位付けされた製品のバックログ上の機能またはストーリーカードのサイズを決定します。製品の所有者は、繰り返しごとに製品のバックログの優先順位を変更できます。製品のバックログから、反復およびリリース計画を作成することができます。
複数の役割を演じているので、ストーリーカードの作成に時間を費やす必要があります。ストーリーカードは、GUIをスケッチし、プライマリワークフローとセカンダリワークフローを記述し、最も重要なのは受け入れ基準を持つ必要があります。
書き込み済みのストーリーカードからサインオフしたら、カードで開発を開始できます。まずテストを書くためにTDD（テスト駆動開発）を使い、次にコードを書いてみましょう。あなたはカードが完了するまで繰り返すでしょう。合格基準は、どの単位テストを書くかを決めるのに役立ちます。
カードの開発が完了したら、自動機能テストを作成します。 Quick Test Pro、FIT、Cucumberなどの好きな自動ユニットテストツールを使用できます。私はあなたがリファクタリングしているときに将来的にリワークを促進することができるように、あらゆるプレイや記録機能から離れています。
ユニットテストが完了し、カードが通過したら、それは他のすべての自動機能テストに追加することができ、内のすべてのチェックイン時に少なくとも毎日実行する場合ではないことができます。
反復の終わりと作業ソフトウェアを本番環境に移行する前に、ユーザー受け入れテストを実行することができます。
開発者は、継続的な統合を使用する必要があります。自動ビルドは、ソースコード管理システムに頻繁にチェックインするたびに開始されます。
ストーリーカードが書かれた後、繰り返しのためにカードを開発する前に、カードを開発する（つまり、カードを開発するのに必要なタスクごとに見積もりを行う）ことができます。見積り内で必要なリファクタリングが完了しているか、特定した技術的負債を取り込む新しいストーリーカードを作成する必要があるかどうかを判断できます。
ご覧のとおり、メンバーのアジャイルチームは非常に遠くにいます。アジャイルなマネジメントプラクティスがコラボレーションを助け、重要なものを特定することができれば、そのプラクティスも恩恵を受けることができます。エンジニアリング（XP）プラクティスがコードを健全に保つことができ、持続可能なペースを支えていることを考えると、コードは柔軟性があり、強力なユニットと機能的な自動化テストハーネスを含み、持続可能なペースで無期限に開発を続けることができます。
どの大学のプロジェクトでこれを試してみましたか？私は4年目のプロジェクトでこれをやりたいと思っています（8〜16ヶ月）。 – kthakore
私のほうがずっと小さく、数ヶ月しかありませんでした。もっと長いプロジェクトでは、実際にもっと価値があると思います。あなたができる素晴らしいことは、誰かに顧客をプレイさせ、毎月または2か月の「リリースデモ」を提供することです。それは、ナンセンスではなく、顧客価値の考え方にあなたを強制し、あなたは早急にフィードバックを得るでしょう。おそらく、別の生徒にあなたのために遊ぶように促し、好意を返すこともできます。 – Avish
いいアイデア！また、最後の合理的な瞬間までの決定を延期することによって、何を意味するのでしょうか。それはスプリントの終わりまでですか？ – kthakore