この時点まで私が読んで研究してきたことはすべて、アジャイル/スクラムが約4〜6人のメンバーのチームといかにうまく機能するかを説明しています。
私の現在のショップでは、約8人の開発者がいますが、プロジェクトの量の性質とサポートする部門の数を考えると、特定のプロジェクトに割り当てられる人が1人または2人を超えることはありません。
1人または2人の開発者のチームでアジャイル/スクラムを使用できますか?私は上司にこの方法論の使用を開始するように働きかけていますが、小規模な開発者向けに物事を縮小する方法を説明したり、特定のメンバーを確実に増やすために説得したりする必要があります事業。
プロジェクトで特定のアジャイル原則を使用できることは確かです。スクラムを使用する必要はなく、機能するものを何でも使用しますあなたにとって最高。一部のXPメソッドといくつかのスクラムプラクティスから確実に利益を得ることができます。しかし、おそらく「本では」ではありません。1〜2人のチームは、わずかなオーバーヘッドスクラムでさえも小さすぎます。本が言うこと、そしてあなたがしばらくして無関係になったと思うことをすべて落とすこと。遡及的なことを落とさないでください、あなたが抱えている問題について議論し、それらの解決策を見つけることに費やす時間の価値は確かです。
はい、1人でスクラム/アジャイルの原則を使用できます。個人的な生産性が必要な場合は、 Pomodoroテクニック または [〜#〜] gtd [〜#〜] を参照してください。
大きなチームではコミュニケーションの管理が難しくなるため、アジャイル手法は小さなチームに適しています。 1人または2人でプロジェクト(および顧客)を開発すると、非常に簡単にアジャイルな方法で作業できるはずです。 アジャイルマニフェスト をアジャイルへの良いスタートとして読むことをお勧めします。スクラムについては、 トレンチからのスクラム を参照することをお勧めします。 かんばん が流行しているようで、 個人のかんばん もあります!
私があなただったら、かんばんを使って自分のタスクと優先順位を管理および視覚化し、XPプラクティスのいくつかを採用します。テスト駆動開発、レトロスペクティブ、タイムボックス化はおそらく良いでしょう。始めに、後で振り返ってみると、必要と思われるプラクティスをさらに特定できます。
かんばんは非常に非規範的です。 本当にに必要なことは、次のとおりです。
アイデアは、有用であると思われる他のプラクティスを利用することであり、XPはこれらのプラクティスの優れた情報源です。
免責事項:私はこれを試したことはありませんが、私が同じ立場にあった場合、それは試すことの私のリストの一番上になります。
絶対に問題ありません。個々の開発者がアジャイルを使用する方法の詳細については、Pragmatic Programmerの本をチェックしてください。個々の作業用のスクラムリソースを入手することは困難ですが、反復的な開発の主な概念は、あらゆる規模の作業グループに適用できます。
さまざまなアジャイル手法のテクニックを使用できると思いますが、 (Scrum Guide )で説明されているように、スクラムを使用しないでください。スクラムは4〜11人のチーム用に設計されています。しかし、スクラムを含むアジャイル手法の多くは、出発点を提供できます。
私は最近、スクラムに関するこの本を読みました: スクラムによるアジャイルプロジェクト管理
私にとってそれはスクラムに関する私の最初の本であり、私のためにそれをしました、それは本当に根本的な原則が重要であるものに焦点を合わせています。これらの原則のいくつかは、1〜2人のチームに適用され、支援できると思います。
はい、アジャイルメソッドは2人の開発者でのみ使用できますが、専任のカスタマー/プロダクトマネージャーが常に必要です。開発者が1人だけの場合、私は個人的にチームで作業したいという理由だけでなく、プログラムを実際にペアリングすることができないため、すべてのコード共有の機会を逃しているため、ほとんどノーと言えます。 4〜6人の開発者+ 1人の製品マネージャーは、アジャイルプロジェクトに最適なサイズです。それ以上に、サブチームが形成する傾向があり、それが目的をやや損なう。
もちろんあなたの正確な状況はわかりませんが、多くのプロジェクトを同時に実行していることはseemsと私には思われます。私の提案は、並行プロジェクトの量を減らすというアイデアを売り込むのではなく、たとえば、2つのチームがそれぞれ1つのプロジェクトに取り組んでいることです。これは、状況を改善し、アジャイルプロセスを適用しやすくするための最初のステップです。
タスクの切り替えやプロジェクトのゴミ箱の悪さについては、多くのことを言う必要がありますが、実際には良いことは何もありません。ずっと。
別の見方をすると:
sameスクラムチームの8人の開発者全員を検討してみませんか?これにより、プロジェクト間のクロストーク効果を得ることができます。たぶん、あなたは特定のプロジェクトに人々をコミットする必要さえありませんか?
より多くの人々があなたの店に追加されるとき、あなたはおそらくチームを2つのより小さなものに分けることができます。
2人の開発者は、明示的にそうするつもりがなくても、本能的にアジャイルのようなシステムにデフォルト設定すると思います。彼らは自然にお互いに話し合い、POで繰り返します。