私は、開発チームの規模を繰り返し削減している会社で働いており、以前の10人のチームは、製品ごとに1人の開発者（および5つの製品間で共有された2、3人のテスター）になりました。私たちは以前、かなり大きなプロセスを要し、大企業からのスピンオフであり、その多段階ウォーターフォールプロセスを継承していました。

ソフトウェアを十分な速さでリリースしていないこと、およびこれがプロセスの障害である可能性が高いことが経営陣から判明しました（90％の人員の損失はおそらく助けにはならなかったものの、それが原因である可能性があります）。設計ドキュメントの作成などに時間を費やさないようにするために、アジャイルプロセスに移行するよう強く求められてきました。

アジャイルへの切り替えが一人のチームで役立つかどうかについて私はちょうど興味があると思います。多くのメリットは、チームメンバー間の可視性の向上とコミュニケーションの向上から得られると私は理解していましたが、私は自分のしていることを理解しており、マネージャーもそうです。とにかく製品をテストする人がいないので、私はすでにTDDを行っています。

TL; DRバージョン：私が本当に求めていることは、1人の「チーム」でアジャイルを実装できますか、それから何かメリットがあると思いますか、それとも通常、大規模なチームにとってより効果的なものですか？

チェックアウトhttps://groups.google.com/forum/#!forum/solo-scrumを

および/programming/829497/agile-methods-specifically-taylored-to-working-solo

更新：
最初のリンクはSolo Scrum Google Groupへのリンクです。ここで説明する最も明白な利点は、タイムボックススプリントを使用してスコープを管理し、プロジェクトの速度を決定することです。どちらも非常に優れています。

2番目のリンクはStackoverflowに関する以前のディスカッションへのリンクです。これは重複した質問であることを示している可能性がありますが、リンクするほうが便利だと思いました。これは、http：//c2.com/xp/ExtremeProgrammingForOne.htmlへのリンクです。このリンクには、XPソロ（sansペアプログラミング）の実行に関する多くのリンクと情報があります。

1

最小チームサイズは1

アジャイルは、ワークフローを調整するために選択する原則と実践のコレクションです。ワンマンショーの場合は、自分に合ったものを選びます。

XP / TDDは、1人のチームにとって美しく機能します。そして、あなたは毎日のスタンドアップミーティングとペアプログラミングの潜在的に時間を浪費する慣行をスキップすることができます。

あなたの主な問題は「アジャイル化」ではなく、ドキュメントです。スコット・アンブラーによるアジャイル/リーンのドキュメントに関するこの記事は、おそらくあなたとあなたの同僚にとって興味深い読み物でしょう。

アジャイルは、文書化しないということではありません。あなたはまだ文書化します、それはあなたがそれを作成するために費やされる時間を最小限にしながら価値を最大化するために何をどのように文書化するかを選択するだけです。要件を把握し、設計を実行し、実装の決定を文書化し、必要に応じて、プロジェクトが必要とする範囲内でのみ、ライフサイクル全体にわたって完全に追跡可能です。重要なプロジェクト情報と決定を取得しないことは、プロジェクトを失敗させる確実な方法です。

楽しい小さなボーナスとして、個人向けのアジャイルについての私の見解を以下に示します。

アジャイル手法はチーム向けに設計されています。スクラムでは通常、プロダクトオーナーとスクラムマスターと共に約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つの方法である場合、アジャイルは誰にとっても失敗します。