ソロ開発者向けのアジャイル

ソロ開発者としてアジャイルプロセスの概念をどのように実装しますか？アジャイルは、アプリケーションをより速いペースで開発するのに便利なようですが、非常にチーム指向でもあります...

• テスト駆動開発を行うことにより
• 小さなスプリントで開発することにより
• 顧客との多くの接触を持つことにより

カウボーイ開発についての論文を読んだことは覚えています。これはソロ開発者にとって不可欠なアジャイルですが、どこで見つけたのか思い出せません。

klez（すべての良い提案）からの答えに加えて、私は以下を提案します：

• 製品バックログの保持
  製品バックログは、基本的に、この製品のある段階で完了する予定のすべてのアイテムのリストです。
• スプリントのバーンダウンと製品のバーンダウンの維持
  スプリントのバーンダウンは、このスプリントで完了することに決めたすべてのタスクのリストから開始します（製品バックログのサブセットは、一定の期間（たとえば2週間）完了します）必要な作業の見積もり。物事に印を付けるとき、それらを完了として印を付けます。それにより、そのスプリントの残りの作業を削減（または全焼）します。
  同様に、製品のバーンダウンは、製品バックログ全体の残りの作業を追跡します
• 相対推定と速度の概念の採用
  相対推定は、他のタスク（またはストーリー）をガイドとして使用する推定手法です。たとえば、タスクAがタスクBより簡単で、タスクCの約2倍複雑であることがわかっている場合、タスクAの「ポイント」がそれらの期待値に対して正しいことを確認します。
  重要なのは、必要な作業量を正しく推測することではなく、推定値を互いに一致させることです。
  速度は、スプリントで何点の「ポイント」を達成したかの尺度です。相対的な推定により一貫性が確保されている場合、この速度を使用して、今後のスプリントで実行される可能性が高いタスクを推定できます。ただし、速度は常に修正する必要があります。

• （タイムボクシングに加えて）進行中の作業を制限します。（カンバンではなく）反復法を使用している場合でも、速度が反復あたり8ポイントであるとします。一度に8つすべての作業を開始しないでください。ストーリーの数またはストーリーポイントのいずれかによってWIPを制限することは問題ありません。
• すべてのユーザーストーリーの受け入れテストを自動化します。一般的に可能な限り自動化します。
• ユーザーストーリーを小さくしすぎる側の誤り。経験則として、最大のストーリーと最小のストーリーの比率を3：1にします。スクラムのストーリーを過小評価し、それが大きすぎると判明した場合、複数の開発者がそれをまとめて軌道に乗せることができます。しかし、あなたは十分な人がいません。
• 通常のサイズのチームコンテキストで、ユーザーストーリーからスパイクを分割するかどうかをためらう場合-ソロまたは小規模チームコンテキストで、ためらうことなくスパイクを実行します。これにより、ストーリーをより小さく予測しやすくすることができます。
• 一般にレトロスペクティブはアジャイルにおいて重要であるため、カンバン（パーソナルかんばん）は、レトロスペクティブプロセスがよりデータ駆動型であるため、ここで追加ポイントを獲得します。十分な人員がいない場合、トリプルニッケルをプレイするのは困難です。

これらのことは、おそらくソロと小規模チーム（2人または3人の開発者）の両方の状況に当てはまります。

追加：この回答を書いてからしばらくして、この会議の講演を見つけて非常に感銘を受けました：個人的なかんばん：個々のコーダーの最適化

• 明確に定義されたスプリントに取り組むか、または意図的にかんばんアプローチを選択します。誤ってかんばんにならないでください
• 最初にバグ、次に機能。
• 価値と機能の肥大化に引き続き注力してください。（YAGNI over Gold Plating）
• 回顧も同様に貴重です。同様に重要なことは、プロセスの変更を小さなチャンクで行うことです。ATMを配信するための外部機能が実際にない場合を除き、今日はTDD、Mock、およびIoCを一発で開始すると決めてはいけません。一度に1つずつ持ち込みます。

最終的に、私はアジャイルを本当に「あなたのチームと顧客にとって意味のあることをし、過去に働いていたように見えるために古い慣行を順守しない」と定義します。

アジャイルは、チームに対しても個人に対しても同様に機能します。自分に合ったプロセスを見つけ、プロジェクトが既に開始されていれば、状況の変化に適応できるようにすることです。また、ソフトウェアが実際に「完成」しているかどうかに関係なく、顧客に価値を定期的に提供することも重要です。

アジャイルプロセスは非常に反復的です。作業は短いTimeBoxes / sprints / cycles / iterationsで行われます。一部の設計作業が事前に必要になる場合がありますが、システムを実行するために必要なものについて詳しく学習するにつれて、リファクタリングすることができます。単体テストは、ほぼすべてのアジャイル開発方法のバックボーンであり、ソフトウェアが機能しているかどうか、およびソフトウェアへの追加/変更が既存のコードベースを破壊するかどうかを示します。

BDD / TDDに準拠している場合、風に合わせて要件を変更し、それに応じて機能の優先順位を調整できます。システム全体を構築してすべてのテストを頻繁に実行し、各スプリントの最後に作業コードを提供する場合、あなたはすでにアジャイルです。

ワオ。トラブルが発生したときに電話をかけることができるフックに友人を置き、コーディングの問題について話し合うようにします。私の言いたいことを知っています...問題を大声で説明するだけで、90％の時間で私の頭に解決策がもたらされます。