新しいシステムの開発を計画する初期段階では、どの開発モデルに従うかが最重要のようです。私は常に、クラシック ウォーターフォール (またはハイブリッド ウォーターフォール/反復プロトタイピング) が中規模から大規模のプロジェクトに最適なアプローチであると信じてきました。プロジェクトが一定の規模になると、アジャイル/XP/スクラムのパラダイムでは、複雑な要件、大規模なチーム、複数のサブシステム間の複雑さ、ドキュメントの必要性、人事異動などを説明できなくなります。等
システムのサイズ、チームのサイズ、LOC などに関して、このようなアジャイル方法論の限界は何ですか?
スクラムは、「スクラム オブ スクラム」を使用してスケーリングできます。
スクラム アライアンスからは、スクラム オブ スクラム ミーティングの実施に関する次のアドバイスが得られます。
スクラム オブ スクラム ミーティングは、スクラムを大規模なプロジェクト チームに拡張する際の重要な手法です。これらの会議では、特に重複と統合の領域に焦点を当てて、チームのクラスターが自分たちの仕事について話し合うことができます。
本 Agile and Iterative Development もこの問題について議論しています。
BernieThompsonによるこのブログ投稿をご覧ください。
これは、Microsoftでスクラム/ XPをスケールアップするときに彼が遭遇した多くの問題とトレードオフの概要を示しており、非常に思慮深く興味深い解決策がいくつかあります。
同じブログに、あなたに関係するこれらの規模の問題を扱っている他の投稿があります-IMOは、「大人のためのアジャイル」に関するアイデアの金鉱です。
スクラムのすべてのアイデアは自動車製造から生まれましたが、それは人々の面でかなり大きいので、境界があるとは思いません。大きなプロジェクトでは、小さなチームから始めて、時間をかけて成長させる必要があります。スクラム オブ スクラムを介してやり取りする別のチームを維持すると、人々が協力する意思があれば、それは機能します。私たちのビジネスではいつものように、分割して征服します。大きな困難な問題を扱いやすい小さな塊に分割します。
チーム内の通信チャネルは上限として (N * N-1) / 2 に比例するため、大まかに O(N^2) と見なすことができます。アジャイル チームの分散型の性質は、参照の中心点がなく、そのような参照点がある場合よりもコミュニケーションが上限に近づくことを意味します。
書面による仕様とより正式な構造がある場合 (仕様ドキュメントの説明については、痛みのない機能仕様を参照してください)、コミュニケーションはハブ アンド スポーク モデルに近くなり、O(N) チャネルに近づきます (N 人のスタッフの場合)。プロジェクト）。私が見た経験則の解説のほとんどは、アジャイル チームのスイート スポットを 6 以下、上限を約 10 に設定していますが、マイレージはさまざまです。
PFS の記事で Joel (そうです、そのJoel) は、仕様を開発して所有することを役割とするProgram Managerの役割について説明しています。痛みのない機能仕様シリーズでは、これについてかなり詳しく説明しており、非技術的な管理者にも非常にアクセスしやすくなっています。私はかなりの数の人々にこの記事を紹介しました。
スクラム/XP を一連の小さなウォーターフォールとして描きます。最初は、適切で明確に定義されたバックログを取得するための事前の取り組みを行います。必ずしもシステム全体ではありませんが、製品のバックログ項目の 1 つまたは 2 つのスプリントに相当するものを取得したら、スプリントを開始するときだと主張します。スプリントと同時に、追加の PBI を作成する必要があります (そして、適切に優先順位を付け直します)。
システムが完全に定義される前に、ビジネス価値を提供できるという考え方です。
スケーリング スクラムまたはアジャイル アプローチは、環境によって異なります。
複数のチームを持つ複数のプロジェクトがある場合、スケーリングはチーム間でベスト プラクティスを共有するだけです。システム/プロジェクト間の統合が必要になったらすぐに注意してください。その時点で、チーム間のより緊密な統合が望ましいです。
1 つの大規模なプロジェクトがある場合 (ある時点で 45 人のチームがありました)、スケーリングにはさまざまなアプローチがあります。1 つのチームに複数のスタンドアップ (開発者のスタンドアップと BA/QA のスタンドアップ) を持たせることにしました。イテレーション マネージャーは両方に出席し、両側から少なくとも 1 人が他方に出席しました。カードの壁は 1 つでしたが、イテレーション前のもの (分析中のストーリー、追跡する生産バグ) とイテレーション後のもの (リリース/展開作業) が含まれていました。
私はまた、多くのスクラム チーム (最大 20 チーム - 一部は分散型 - それぞれ 10 から 20 メンバーの範囲) を持つ 1 つの非常に大規模なプロジェクトに参加しました。それぞれに個別のスタンドアップがあり、スクラム オブ スクラムとスクラム オブ スクラム オブ スクラムさえありました。ワークフローではなく、機能領域ごとにチームを分割したのは間違いだったと思います。私たちのセグメンテーションは、チーム間の面倒な統合管理の問題を伴うコード所有権のサイロを生み出しました。
つまり、スケーリングのサイズだけでなく、プロジェクトの内容も重要です。お客様の環境の規模に対処するためのより具体的なアプローチを聞くために、お客様の環境に関する詳細を自由に共有してください。
アジャイルは問題なくスケーリングします。それはロケット科学ではありません。実際、モジュール性がすべてです。ソフトウェア開発は CAS (Complex Adaptive System) であり、ほとんどすべての CAS と同様に、複雑さをより適切に制御するためのモジュールがあります。スクラム オブ スクラムは、開発プロセスのスケーリングのための可能なモジュラー アプローチの 1 つです。機能部門 (開発者、QA など) は、別のモジュラー アプローチです。最悪のケースは、大規模なプロジェクトでモジュールがまったくない場合です。
プロジェクトの性質に応じて、チームはプロジェクトでどのモジュールが機能するかを決定する場合があります。一般的なパターンは、結束力の低いモジュールに取り組むいくつかのチームを形成することです。各チームは完全に自律的である必要がありますが、他のチームとの相互作用は良好でなければなりません。
CAS からの類推は、たとえば人体です。心臓や肝臓などの臓器があります。それらは、神経系/血液/その他を介して相互作用する個別のモジュール (細胞のチーム:) です。