単一の開発者はどのようにアジャイルメソッドを利用できますか？
私はフリーランサーで、単一の開発者として働いています。すべての場合において、私はさまざまな帽子をかぶっている人です。私はスクラムマスターであり、開発の唯一の人物です。私ではないのは製品所有者ですか？
フリーランサーが利用できるアジャイルメソッドと無料ツールはありますか？
アジャイルの目標は...
すべてのフィードバックループを可能な限り最小限に抑える
作成されたドキュメント/フォームの観点からプロジェクトのオーバーヘッドを最小限に抑え、チームメンバー間のリアルタイム（できれば対面）のコミュニケーションであるはるかに高い帯域幅のメディアに置き換えます.
アジャイルについてより多くの研究を行うと、多くはチームとメンバー間の相互作用について話します。これは、N人ごとにメンバー内のコミュニケーションの数がNずつ増えるためです。Nが上がると、トレーニング/知識の普及、努力の調整などの追加の課題に直面します...
アジャイルチームが直面する多くの問題、あなたは間違いなく心配する必要はありませんが、私が焦点を当てる主な領域は（1）-フィードバックループの最小化です。単一の開発者であっても、問題（要件、設計、実装のいずれであるか）を早く識別すればするほど、それらの問題を修正するコストが安くなるため、非常に便利です。
これは私がすることです：
定期的に顧客と会うことをポイントにして、彼らが顧客であることを確認してください...
- 何をしたかを正確に把握し、できるだけ早くフィードバックを提供する
- 次に何に取り組んでいるのかを理解し、すでに完了していると彼らが見ているものを考慮して、それらが実際に必要な機能であることを確認
展開/パッケージングの解決に少し時間をかけてください。わずかな初期費用で、ボタンを1回クリックするだけで、アプリケーションの完全に展開可能なバージョンを展開して、即座にテストできます。継続的インテグレーションサーバーが1人のチームにどれだけのメリットをもたらすかはわかりません。
アジャイルチームが行うのと同じように、製品のバックログを管理できます。しかし、あなたは自分で作業しているので、どんな種類の派手なソフトウェアや投稿されたメモのあるホワイトボードの使用もスキップし、作業項目をリストしたテキストファイル（おそらくExcelシート）に直接行きます。それらに優先順位を付け、定期的に見直して、見落としがないこと、および重要なものが最初に処理されることを確認します。もう少し手の込んだものを試したい場合は Trello が良いオプションかもしれません
TDDへの移行を検討してください。 1年前、私は少し懐疑的で、TDDは他のものに依存しない低レベルのユーティリティにのみ役立つと考えました。しかし、昨年、私はこのアプローチを何度か試しましたが、そのたびに結果に非常に驚きました。はい、それは多額の先行投資コストですが、コードを簡単にテスト/検証できるようにすることの利点は、結局あなたに驚くほど早く返済することになるようです。
- TDDは、コードに誤りがあるかどうかを即座に通知し、クラス/関数が境界条件で適切に動作することを簡単に確認できます。代替手段は通常「最善を尽くす」ことですが、テスト中にバグを見つけてしまい、問題の特定とデバッグに何時間も費やすことになります。
- 単体テストを実施すれば、新しい機能が追加されても、デザインのリファクタリングや大幅な変更にそれほど恐れることはありません。私はTDDなしで気づきました、ほとんどの人は既にテストされた（そして当然のことながら）テストされたコードに触れるのを恐れる傾向があります。多くの場合、それらはますます追加され続けていますが、すでに存在するものを変更することを恐れており、コードはv1.0が出荷される前でも従来のスパゲッティの混乱のように見えます。
- テストが実施されていて、自由にリファクタリングできるので、後で必要に応じてデザインを変更する方がはるかに簡単になるので、デザインを最初から正しくすることについてそれほどストレスをかける必要がないという利点もあります。
あなた自身の回顧展を実施してください。アジャイルの重要なメッセージの1つは、変化は歓迎されるべきであり、同じことがオーバーで行われているリズムに決して落ち着いてはならないということです。定期的に自分の行動を評価し、異なるアプローチがより効率的になると感じた場合は、領域を特定するようにしてください。プロセスを調整することを恐れないでください（または、今のところ他の理由で何が起こるかを確認するために、場合によっては大幅に変更することもできます）、特定の状況に合わせてプラクティスを調整してください。
私が提供したアドバイスは、主に製品として販売されたアプリケーションでの作業を含む、私が行った作業のタイプに基づいています。私たちは同じコードベースに取り組み、新しいリリースごとに同じアプリケーションを拡張/改善し続けます。主な収入源がサービスとしてのコーディングである場合（つまり、コードを記述して販売し、二度と表示されない場合）は、アドバイスが異なる場合があります。私が得ている印象は、サービス領域の開発者はTDDや他の多くのプラクティスをスキップする傾向があるということです。代わりに、完了までの時間（つまり、コストの最小化）に焦点を合わせ、v1.0（最初と最後のバージョン）が顧客の承認基準を確実に通過するようにします。
おそらく、パーソナルeXtremeプログラミングはあなたが見てみたいものかもしれませんか？
https://www.google.nl/search?q=personal+extreme+programming
これは、極端なプログラミング手法と、カーネギーメロン大学のワッツS.ハンフリーが考案したパーソナルソフトウェアプロセス（PSP）の手法を組み合わせた方法です。 PSPはそのアプローチが非常に厳格であり、アジャイルではありません。 PXPは、個人用ソフトウェア開発のより機敏な適応です。 PXPは、あなたが主流と呼んでいるものではありませんが、私は過去にそれを使用したことがあります。このトピックについて読んだいくつかの論文に基づいて、PXPアプローチを採用しました。
https://research.uni-sofia.bg/bitstream/10506/647/1/S3T2009_37_YDzhurov_IKrasteva_SIlieva.pdf
http://dl.acm.org/citation.cfm?id=1593127
PXPには、次のPSPプラクティスが含まれます。
•タイムレコーディング：基本的にタイムシート。これは、進捗率を判断するのに役立ちます。
•サイズ測定：実行した作業量を測定するには、何らかの指標が必要です。通常、これはコード行（LoC）に要約されます。
•Defect Type Standard：発生したバグのタイプを分類するためのリスト。
•プロセス改善提案：自分のプロセスを改善するための何らかの計画が必要です。基本的には、自己評価とレビューのためにいくつかのアクティビティを計画する必要があります。実装する前に計画を立てる必要があります。 （そして、それを微調整するために時々計画を見直してください）
•欠陥の記録：発見したバグを追跡して、後で動作を分析できるようにする必要があります。
•コードレビュー：これは少しトリッキーですが、どういうわけかコードをレビューする必要があります。自分の仕事から精神的に離れることができるまで、私はこれが特に興味深いとは思いません。それでも、通常は他の人ほど簡単に自分の欠点を見つけられません。
いくつかのXP関連する活動もあります：
•継続的インテグレーション：PXPには、ソース管理のバージョン管理、自動ビルド、自動テスト実行、および自動欠陥送信の手法が含まれています。この方法は非常に便利です。 （私はゲートチェックインアプローチを好みますが、そのためにはいくつかのスクリプトを設定する必要があります。
•シンプルなデザイン：KISS！あなたはおそらく私が何を話しているか知っています。 （そうでない場合は、ググってください）
•小規模なリリース：スプリントのマイルストーンを十分に小さくして、物事を見通しのよい状態に保ち、約束した機能に膨大な時間を費やすリスクを冒さないでください。
•リファクタリング：標準のアジャイルプラクティス。
•テスト駆動開発：これもあまり慣れてはいけません。
•スパイクソリューション：初めての問題や解決が難しい問題がある場合は、大きなプロジェクトに統合する前に、一歩下がってスタンドアロン設定で解決してください。
TL; DR：まとめると、PSP/TSP（CMMi）スタイルで存在する追跡の厳格さから、XPマイナスXPスタイルのプロセス。
ツールに関しては、 https://www.flying-donut.com をご覧ください。これは新しいオンライン製品で、ソロプロジェクトやチームプロジェクトに使用して、大きな成功を収めています。スクラムに触発されており、あらゆる反復プロジェクトを簡単にホストできます。 Flying Donutでは、イテレーションとアイテムに取り組んでいます。アイテムはタスクに分解されます。バックログを整理するための良い方法があり、そのGUIはすばやい応答時間でクリーンです。
方法論に関しては、方法論はクライアントへの明確なコミュニケーションパスを持っているので、スクラムはフリーランサーに適していると思います。そして、はい、あなたは製品の所有者になります。製品の所有者とは、クライアントが欲しいものを確実に手に入れることのできる所有者です。そして、あなたは機能的なコードを提供するチームになります。最後に、あなたはスクラムマスターとなり、スケジュールどおりであることを確認し、チーム（あなた）が持っている障害を取り除きます。それはそれが難しいように聞こえます。反復モードが役に立ちます。毎週または隔週のスプリントを行っており、クライアントとの明確なコミュニケーションパスがあり、クライアントが彼の得ているものを見ている場合、クライアントが考えていなかった潜在的な新たな要件にすばやく対応できます。
免責事項：私はそれを構築するのを手伝って以来、私は何ヶ月もフライングドーナツを使用しています。