アジャイルのメリットを享受するために最低限必要なチームサイズはありますか？
私は、開発チームの規模を繰り返し削減している会社で働いており、以前の10人のチームは製品ごとに1人の開発者（および5つの製品間で共有された2、3人のテスター）になりました。私たちは以前、比較的大きな会社からスピンオフしていたため、かなりプロセスが重く、その多段ウォーターフォールプロセスを継承していました。
ソフトウェアを十分な速さでリリースしていないこと、およびこれがプロセスの障害である可能性が高いことが経営陣から判明しました（90％の人員の損失はおそらく役に立たなかったものの、それが原因である可能性があります）。設計ドキュメントの作成などに時間を費やさないようにするために、アジャイルプロセスに移行するよう求めてきました。
アジャイルへの切り替えが一人のチームで役立つかどうかについて私はちょうど興味があると思います。多くのメリットはチームメンバー間の可視性の向上とコミュニケーションの向上からもたらされると私は理解していましたが、私は自分のしていることを理解しており、マネージャーもそうです。とにかく製品をテストする人がいないので、すでにTDDを行っています。
TL; DRバージョン：私が本当に求めていることは、1人の「チーム」でアジャイルを実装できますか、それからメリットがあるか、それとも通常はそれ以上のものですか？大規模なチームに効果的ですか？
チェックアウト https://groups.google.com/forum/#!forum/solo-scrum
および https://stackoverflow.com/questions/829497/agile-methods-specifically-taylored-to-working-solo
更新：
最初のリンクはSolo Scrum Googleグループへのリンクです。ここで説明する最も明白な利点は、タイムボックススプリントを使用してスコープを管理し、プロジェクトの速度を決定することです。どちらも非常に優れています。
2つ目のリンクは、Stackoverflowに関する以前のディスカッションへのリンクです。これは重複した質問であることを示している可能性がありますが、リンクするほうが便利だと思いました。それは順番に http://c2.com/xp/ExtremeProgrammingForOne.html へのリンクですXP solo（sans pair programming ）。
1
最小チームサイズは1
アジャイルは、ワークフローを調整するために選択する原則と実践のコレクションです。ワンマンショーの場合は、自分に合ったものを選びます。
XP/TDDは、1人のチームにとって美しく機能します。そして、あなたは毎日のスタンドアップミーティングとペアプログラミングの潜在的に時間を浪費する慣行をスキップするようになります。
あなたの主な問題は「アジャイル化」ではなく、ドキュメントです。 Scott Amblerによるアジャイル/リーンのドキュメント に関するこの記事は、おそらくあなたとあなたの同僚にとって興味深い読み物でしょう。
アジャイルは、文書化しないことではありません。あなたはまだ文書化します、それはあなたがそれを作成するために費やされる時間を最小限にしながら価値を最大化するために何をどのように文書化するかを選択するだけです。要件を把握し、設計を実行し、実装の決定を文書化し、プロジェクトに必要な範囲でのみ、必要に応じてライフサイクル全体にわたって完全なトレーサビリティを確保します。重要なプロジェクト情報と決定を取得しないことは、プロジェクトを失敗させる確実な方法です。
楽しい小さなボーナスとして、個人向けのアジャイルについての私の見解を示します。
アジャイル手法はチーム向けに設計されています。スクラムでは通常、プロダクトオーナーとスクラムマスターと共に約3〜9人の開発者が必要です（プロダクトオーナーとスクラムマスターは同じ人物であってはなりません）。エクストリームプログラミングでは、多くの場合4〜7人が必要です。
その理由は、主流のアジャイル方法論で一般的に使用されているプラクティスの多くは、単一の開発者にスケールダウンしないためです。これの主な例は、XP=でのペアプログラミングとコードレビューの強調です。これは、ソロ開発者では実際には実行できません。
単一の開発者はアジャイルになることができますが、それは調整されたプロセスでなければなりません。ほとんどのアジャイルメソッドは、継続的インテグレーション、ユニットテスト、テスト駆動開発、リファクタリング、KISSとYAGNIの原則など）のいくつかの組み合わせを必要とします。これらの多くは「ベストプラクティス」になっています。より多くの計画主導の方法論についてソロ開発者がソフトウェアの作成と配信に干渉しない限り、ソロ開発者がそれらのいくつかを利用できない理由はありません。
ドキュメンテーションを制限したい場合、これがあなたを妨げているなら、私はそれに焦点を当てます。ドキュメンテーションは単なるアジャイルの一部であり、それを実装する方法を知っている誰かがあなたの会社にいるようには聞こえません。これは、トレーニング、賛同、調整などのために、コードのリリースを短期間で遅らせる可能性があります。90％のレイオフの後、生産遅延のための次の素晴らしい万能薬を探すだけの力があります。
一人の男のチームから来ている（うまくいけば長い間ではないが）。
アジャイルは、将来のプロジェクトでは自分だけではなく、もっと多くの開発者になるつもりでいるという意味で、自分のために努力しています。高レベルのWBSを作成し、ユーザーストーリー、ユーザーストーリーの下のタスク、テストケースを作成し、マネージャーが見たり理解したりできる方法でプロジェクトを適切に追跡します。私は頭の中で「知っている」だけなので少し面倒かもしれませんが、とにかく純粋に、約束されたがまだ発生していない神秘的な未来のチームのために努力するために時間をかけます。私の後を追う人たちにとって、良いプロセスを先導していると思います。
私が少量で行うドキュメンテーションは、ほとんどがフロー図とユースケース図ですが、一般に、それについて本当に複雑で重要なことを忘れない限り、低レベルのものはありません。また、将来の人々が「トレーニング」などのために新しい環境を用意しなければならない場合のために、配置図も作成します。
私は自分でTDDをゆっくりと教えていますが、まだ完成していません。レガシーアプリケーションの純粋な意味で、大きくて危険な一連の機能をリファクタリングすることなく行うのは非常に困難です。まだ苦労している複雑な新機能ですが、結局、TDDの終盤である100％のカバレッジを目指しています。私はそこに到達するための最良の道をとらないかもしれません。
それは間違いなくできますが、ほとんどの場合必要性からです。
代わりに、5つの製品の単一の製品バックログを持つ5人の開発者からなる単一のチームを形成できるのに、アジャイルを1人のチームとして実行するのはなぜですか。 1週間または2週間の繰り返しを試して、一度に1つの製品に焦点を合わせ、5人のエンジニアがまとまりのある自己組織化チームとして協力して、生産性がどのように向上するかを確認します。リリースする頻度に応じて、スプリントの長さを調整する必要があります。私は、ビジネスが製品の更新の間に10週間待つことを望まないかもしれないと推測しています。その場合、1週間のスプリント期間がより適切に機能する可能性があります。 1つのスプリントで2つの製品に取り組むこともできますが、これを避けて1つの製品の目標に焦点を当て、生産的かつ品質の高い方法でそれを行うことができるように最善を尽くします。
選択した方法に関係なく、5人の開発者と5つのプロジェクトの合計がある場合、IMOが1人の製品を1人の製品に専念させるのは賢明ではないアプローチです。
アジャイルプラクティスの多くは、0を超えるチームに効果をもたらします。たとえば、ソース管理や摩擦のない開発などは、チームがどれほど小さくても常に効果を発揮します。
これは、ビジネス側からの賛同があるのか、それとも経営陣が開発のせいにする新しいものがあるのかによって異なります（チームサイズの90％削減に基づくと、状況のように聞こえます）。 higher visibility and more communication between team membersは、開発者の間だけを意味するのではありません。ビジネス側は、時間の経過を確認し、正しい優先順位を設定することが重要です。
私たちの会社のビジネス側とIT側の間の信頼が大幅に増加しました。これは、各チームに毎日のスタンドアップに参加するプロダクトオーナーがいて、彼らが私たちの時間の経過を見て、彼らが次の作業について決定を下す人たち。マネージャーが絶えずリクエストにぶつかり、状況がすり抜けたり、1日の中ですべてを完了するのに十分な時間がない場合に開発が非難されたりする代わりに、優先順位を設定し、スプリントに何を含めるかに関する決定。
したがって、プロセスに関与する予定のプロダクトオーナーからのコミットメントがある場合、はい、アジャイルプロセスは1つのチームにとっても非常に効果的です。しかし、これが開発者をスケープゴートにするもう1つの方法である場合、アジャイルは誰にとっても失敗します。