大規模アジャイルチーム

ここでは、小さなアジャイルチームから非常に大きいアジャイルプログラムまで様々なサイズのアジャイルチームを作り上げるための戦略を説明する。プログラムとも呼ばれる大きいアジャイルチームのケースはさらに詳細に述べ、彼らをサポートする方法を説明する。

ここでは、次の項目について説明する。

アジャイルチームを作り上げる

図1は2016年のソフトウェア開発のスケール調査(2016 Agility at Scale survey)における、アジャイルチームの大きさに関する要約である。回答者の約60%が10人以下の小規模チームで働いている事を示している。しかし、多くの人々の回答が中規模チームで、さらに何人かは大規模アジャイルチームで働いている事を示している。とはいうものの、チームを大・中・小に分類する基準は、まったくない。ここでは、2〜15人を小規模チーム、12〜50人を中規模チーム、35人以上を大規模チームとする。このサイズ定義を意図的に重複させているのは、この問題(チームの規模の表現)についての合意が無いからだ。

図1. アジャイルチームサイズ

2016scala-survey

このページの図はDADチームにおける役割(主な役割と補助的役割の両方)で描かれている。この節では、小規模アジャイルチームの組織構造から始め、大規模チームの組織構造まで説明する。

小規模アジャイルチーム

我々は2〜15人のアジャイルチームを小規模と考える。図2は小規模アジャイルチームのよくあるチーム構成を示す。小規模チームでは、チームリード(スクラムにおけるスクラムマスターロールの発展形)とアーキテクチャーオーナーは、常にでは無いが多くの場合、同じ人だ。これは難易度が高いかもしれない。なぜなら、優れたチームリードは信頼できる人で、リーダーシップスキルが必要である一方、優れたアーキテクチャーオーナーは堅実な専門的スキルと既存のインフラストラクチャーの知識が必要であり、これらすべてを1人の人間が備えるのは、難しいからだ。

図2. 小規模アジャイルチームの(理論的な)組織構造

smallteam

我々は図2に見られるような組織構造についてよく話す。なぜなら、シンプルなチーム構成は説明するのに便利だからだ。その一方で、図3はより一般的で現実的な構成だ。チームは分離された状態でもなく、アジャイルチームでもない。図3は、アジャイルチームが頻繁に”脇役”に助けてもらう事を示している。例えば、Oracleデータベースを設定しようとしているチームを考えてみよう。チームがオラクルの専門知識を持っていない場合、時間がかかり間違いをおこしやすいだろう。しかし、経験豊富なOracle DBAに声をかけられるなら、彼は数時間、Oracleのセットアップと設定を効率的に手伝ってくれるだろう。その過程で、いくつかのヒントとコツを学ぶことさえ出来るだろう。同様に、プロダクトオーナーは、複雑な要件をチームに説明するために、時にはドメインエキスパートを招集する必要がある。チームが(アジャイルチームの約3分の1が遭遇する)コンプライアンスの問題、ドメインの複雑さ、または技術的な複雑さに直面した場合は、1人または複数の独立テスターの助けを借りて自分達の仕事を検証することができる。

図3. 小規模アジャイルチームの(現実的な)組織構造

smallteam-actual

中規模チーム

チームを10人以下で維持することについては非常に良いアドバイスがたくさんある。しかしながら、我々は実際に25〜30人からなる(チームオブチームではない)単一のアジャイルチームをいくつか経験した。これらのチームは、小規模アジャイルチームと同様のやり方で作られていたが、いくつかの違いがあった。第一に、チームリードとアーキテクチャーオーナーはたいてい違う人だ。次に、チームには、プロダクトオーナーをサポートするビジネスアナリストや複数のテストに特化したメンバーなど、複数のスペシャリストが含まれることがよくある。

図4. 中規模アジャイルチームの組織構造

mediumteam

図5は、単一のディシプリンドアジャイルチームだ。ここでは、ピーク時には1つの部屋で26人が作業していた。このチームは、ちょっと混雑していた。チームは部屋の大きさを上回って成長したが、より大きなスペースが利用できなかったからだ。このような規模のチームでよく見られる問題は、毎日のスタンドアップミーティングが長くなりすぎることだ。スクラムが定めた3つの質問 – 昨日やった事は何か?今日は何をする予定か?何か問題はあるか? – に25人が答えたとき、1時間以上かかることは驚くべき事ではない。このチームは毎日の調整会議をタスクボード(付箋が貼られたホワイトボード)の周りに立ち、妨げになりうる問題についてだけ話した。会議は、ほとんど10分以内に終わった。

図5. 中規模アジャイルチームの例

Medium-Sized Agile Team

中規模のチームオブチーム

12人から50人の中規模のチームは、多くの場合図6のように「チームオブチーム」に編成される。サブチームを編成するための戦略はいろいろあり、最も一般的なものはフィーチャーチームまたはコンポーネントチームだ。一部のコンポーネントチームには、複数のスペシャリストがいる。たとえば、セキュリティフレームワーク/コンポーネントを構築するチームには、セキュリティスペシャリストが含まれる可能性がある。

図6. チームオブチームに編成された中規模アジャイルチームの組織構造

midmulti

各サブチームは、通常、デイリースタンドアップミーティングまたはデイリースクラムミーティングと呼ばれる毎日の調整会議を介して、自分達の取り組みを調整する。サブチーム間の調整は各チームの代表1人ずつによる、「スクラムオブスクラム」(SoS)と呼ばれる第2のデイリースタンドアップミーティングで行われる。SoSの目的は、各サブチームの代表者が発生した問題(もししたら、あるサブチームは別のサブチームに依存しているかもしれない、あるサブチームは別のサブチームの助けを必要としているかもしれない、など)をチーム全体で調整することだ。サブチームの数が4~5を超えるとSoSが崩れ始めることがわかっており、そのためにより洗練された大規模チームの調整戦略が必要となる。

大規模チーム/プログラム

大規模なチーム(おそらく35人以上)は、多くの場合、図7に示すような構造に組織化されている。これは、図6の拡張であり、リーダーシップチームと、多くの場合、統合の役割を持つ人物を明示的に含む。このリーダーシップチームは、独立テストチームおよび統合チームの潜在的なサポートを受けて、大規模なプログラムをサポートするために必要な調整構造を提供する。この構造については、次のセクションで詳しく説明する。

図7. 大規模アジャイルチーム/プログラムの組織構造

largeteam

図6から図7のチーム構造に追加された興味深いものはプログラムマネージャーで、スペシャリストの役割である。プログラムマネージャーは、チームの全体的な調整と管理を担当する。チームに50人、100人、200人以上の人がいるときは、これらの努力だけでも大変な尽力である。彼らは、リーダーシップチームの中の様々なサブチーム間の問題を容易にする責任もある。「小さめ」のプログラム、たとえば50人〜100人の場合、プログラムマネージャーはリーダーシップサブチームの中の1つのチームリードを兼ねるかもしれない。

大規模アジャイルチームを支える

図7のように、「チームオブチーム」に組織化された大規模なアジャイルチームは、いくつかの支援構造を持っている。これらの構造を以下に示す:

プロダクトデリバリーチーム

プロダクトデリバリーチームの目的は、予算管理、報告書作成、スケジューリング、および人事管理の問題などのチーム管理の問題がタイムリーで積極的に処理されるようにすることである。このチームは、チームリードチーム、プログラム/プロジェクト/ポートフォリオ管理オフィス/チーム、または単に管理チームと呼ばれることがある。これらのチームの責任には、サブチーム間の依存関係の交渉、リリーススケジュールの調整、サブチームの立上げまたは解散が含まれる(これらの活動は、DADのプログラム管理プロセスブレードに取り込まれている)。また、人々をうまくサブチームに加入させたりサブチームから異動させたりする事で、成長/学習する機会を提供することも含まれる(これらの活動は、DADの人材管理プロセスブレードに取り込まれている)。そして、もちろん、プロダクトデリバリーチームは、異なるサブチームの間で起こるあらゆる問題を常にチェックし、解決を支援する。

図8に、プロダクトデリバリーチームの一般的な構造を示す。各デリバリー(サブ)チームのチームリードは、プロダクトデリバリーチームのメンバーである事を示している。プログラムマネージャーの役割を持つ人がこのチームを先導する事も示しているが、これはチームの範囲に応じてポートフォリオマネージャーまたはプロダクトデリバリーリード/マネージャーの役割を持つ人でもかまわない。すべてのアジャイルチームと同じように、プロダクトデリバリーチームも自己組織化する。いくつかの戦略が実施されており、先に説明したスクラム・オブ・スクラム(SoS)戦略が一般的になりつつある。しかし、プロダクトデリバリーチームによっては、一般的な問題について議論する毎週1時間の会議をベースに、それをサポートするチーム間の特定の問題に対処するチームリード間のアドホック会議を必要に応じて開催する場合もある。もちろんプロダクトデリバリーチームは、学習しながら状況変化に応じて、戦略を進化させることもできる。

図8. アジャイルプロダクトデリバリーチームの組織構造

productdeliveryteams

プロダクトマネージメントチーム

プロダクトオーナーチームまたはプロダクトオーナーシップチームとも呼ばれるプロダクトマネージメントチームの目的は、サブチームをまたがった要件の管理である。これには、プログラムまたはポートフォリオのビジョンの策定と進化、プログラム全体の作業の優先順位付け、特定の要件を実装するサブチームの決定、および異なるチームによって実施される要件間の依存の管理が含まれる。これらの活動については、プロダクトマネージメントプロセスブレード(工事中)で詳細に説明する。今のところ、The Product Owner Team(未翻訳)を参照のこと。

図9(図8に類似)は、アジャイルプロダクトマネージメントチームの組織構造を示す。各デリバリーチームのプロダクトオーナーがプロダクトマネージメントチームのメンバーである。このチームは、チーフプロダクトオーナー(プロダクトマネージャーまたはプロダクトマネジメントディレクターと呼ばれることもある)の役割を担う人物によってリードされる。小規模なプロダクトマネージメントチームでは、チーフプロダクトオーナーは、多くの場合、1つまたは複数のデリバリーチームのプロダクトオーナーである。プロダクトマネージメントチームは自己組織化し、どのように連携するかを決定する。プロダクトマネージメントチームは、毎日30分から60分で作業を調整する場合もある。別のチームでは週に数時間の会議をする場合もある。また、プロダクトマネージメントチームにとっては、主要な利害関係者と定期的に会合し、新しく入った作業の確認と、優先順位の交渉をオープンな方法で行うことも一般的だ。この会合は組織によって異なるが、毎週、隔週または毎月定期的に行われる。

図9. アジャイルプロダクトマネジメントチームの組織構造

productmanagementteams

図9には示されていないが、多くのプロダクトマネージメントチームには、ビジネスアナリスト(DADがスペシャリストの役割と考えるもの)とドメインエキスパートが含まれている。agile business analystsは、@スケールで作業するプロダクトオーナー達を支援する。また、多くの場合、問題のドメインが複雑で深い分析が必要な状況や、より高いレベルの要件文書を必要とする規制状況において、利害関係者が地理的に分散しているときに彼らを援助する。ドメインエキスパートは、必要に応じて呼ばれ、プロダクトオーナーが複雑なドメインの問題に取り組むのを助ける。

アーキテクチャーチーム

アーキテクチャーチームの目的は、プログラムまたはエンタープライズレベルでアーキテクチャー戦略を策定し、その戦略を顧客(ITおよびビジネス利害関係者の両方)に伝え、開発チームやその他の利害関係者と協力しながらその戦略を徐々に進化させ、時間の経過と共に生じるアーキテクチャーレベルの技術的問題(例えば、進化するインターフェースや基礎的な技術インフラストラクチャーの変更など)を解決することである。このチームは、アーキテクチャーオーナーチーム、アジャイルアーキテクチャーチーム、またはエンタープライズアーキテクチャーチームと呼ばれることもある。このチームが実行することを選択できるアクティビティの詳細な説明は、DADのエンタープライズアーキテクチャープロセスブレードで説明する。

図10(図8および図9と類似)は、アーキテクチャーチームの組織構造を示す。チーフアーキテクトまたはチーフエンタープライズアーキテクトとも呼ばれるチーフアーキテクチャーオーナーがチームを率いている。各デリバリーチームのアーキテクチャーオーナーは、アーキテクチャーチームのメンバーである。これにより、彼らは全体的な戦略の進化に合わせて、学習内容を共有でき、必要に応じて助けを借りられ、取り組んでいるソリューションのアーキテクチャー面の変更を交渉できる。チーフアーキテクチャーオーナーは、多くの場合、1つ以上のデリバリーチームのアーキテクチャーオーナーである。他のリーダーシップチームと同様に、アーキテクチャーチームも自己組織化するだろう。チームによって毎週1時間、2週間に1回、および毎月1回、ミーティングを開催する。アーキテクチャーオーナーは、重大になったアーキテクチャーの問題を議論するために、アーキテクチャーチームの全員または一部にアドホック会議を要求することもよくある。

図10. アジャイルアーキテクチャーチームの組織構造

architectureteams

図10では、1つのプログラムまたは大規模アジャイルチームのアーキテクチャーチームを示しているが、非常に大規模な組織では、アーキテクチャーチーム全体が階層構造になっている。ある大規模な金融機関(事実上、世界中の金融会社連合)には、全体的な企業レベルで1つ、主要部門ごとに1つずつ、必要なら主要プログラムごとに1つずつのアーキテクチャーチームが存在した。

独立テスト/統合チーム

先に述べたように、アジャイルチームが大きくなる2つの主な理由は、ドメインの複雑さ、技術的な複雑さ、またはその両方に取り組んでいるからである。これが意味することの1つは、テストに必要な努力にこの複雑さが反映されることである。つまり、より複雑なものはテストするのがより難しくなる。それに対処するために、チームはparallel independent testingプラクティスを摘要するだろう。図11に示すように、基本的には、各開発サブチームは、もちろんチームで出来る最善のテストを行うが、エンドツーエンドの統合テストなどのより複雑な作業は、テストサブチームが行う。テストサブチームは、すべての開発サブチームをサポートする。各開発サブチームの作業ビルドを取得し、それらのビルドを単一のプロダクション前のテスト環境に統合し、潜在的な欠陥の発見に努め、見つけた欠陥を適切な開発サブチームに報告する。開発サブチームは、報告された欠陥を新しい要件と同様に、優先順位付けし、見積もり、適切な対応を行う。図11は、各サブチームが1つのビルド/リリースを各反復で提供していることを示しているが、各反復ごとにいくつかのビルドを提供するのが一般的である。開発サブチームは、独立テスト/統合チームと、提供リズムを交渉しておく必要がある。

図11. 並行した独立テスト

10-independent-testing

図12に、独立テストチーム/統合チーム(ITIT)の現実的な組織構造を示す。このようなチームは、統合チーム(SAFe)、品質保証チーム(より一般的な名前)、または単にテストチームと呼ばれる事がある。図12に示すように、ITITは通常、チームリード、複数の独立テスター、複数のインテグレーター(いない場合もある)で構成される。チームリードは、通常、テストとリーダーシップ/マネジメントの両方の責任を持つシニアテスターである。独立テスターは、多くの場合、より熟練を要するテスト形態にフォーカスしている。2〜3例を挙げると、プロダクション前の統合テスト、探索的テスト(開発サブチームも当然行うことができ、またしなければならないこと)、セキュリティテスト(これは高価なテストツールとセキュリティ専門知識を必要とする可能性がある)、ユーザビリティテストなどがある。インテグレーターは、各サブチームのビルドを統合するのに必要な作業を行い、その間にインストールテストを実行する。小さなITITでは、1人でテストと統合の両方を行う事もある(チームリード、独立テスター、およびインテグレーターが役割であり、ポジションや人ではないことを忘れてはならないない)。また、大きなITITだと5〜6人のこともある(当然ながら、テストの大部分は開発サブチーム内で行われている事を忘れてはならない)。

図12. 独立テストおよび統合チームの組織構造

testandintegrationteams

独立テストチーム/統合チームは、大規模チーム専用ではない。規制領域では、ITITによってサポートされている中小規模のチームもある。これは、一部の規制、特に生命/健康に重大な領域の規制では、独立したテストが必要なためである。これはすべてのテストが独立していなければならない(ウォーターフォールチーム内のよくある誤解)という意味ではなく、いくつかのテストだけが独立している必要がある、という意味である。ここで説明した独立テストのアプローチは、この種のテストもライフサイクルの早い段階に進め、潜在的な欠陥を修正するための平均コストを削減する方法の1つになる。

大規模チームの全体像

図13は、図7と同じ大規模チームの構造を、様々なサブチームの観点から示している。図8〜図10に見られるように、チームリード、プロダクトオーナー、アーキテクチャーオーナーの役目を果たす複数のデリバリーチームのそれぞれのメンバーは、それぞれプロダクトデリバリー、プロダクトマネージメント、アーキテクチャーチームのメンバーになる。それぞれのチームは、自己組織化し、ふさわしい活動となるように調整する。また、デリバリー/開発サブチームは、より複雑なテストを実行する独立テスト/統合チームによってもサポートされる。そうしなければ、それらのテストがライフサイクルの終了時に残されかねない。

図13. 大規模チームのハイレベル組織構造

highlevelstructureoflargeteam

これまで、デリバリー/開発サブチームを取り巻く、調整とリーダーシップの構成をどのように組織するかを説明してきた。ここからは、サブチーム自体を組織するための戦略を説明する。

大規模アジャイルチームの組織化戦略

大規模または地理的に分散した(未翻訳)サブチームを編成するための、4つの基本戦略がある(それぞれの比較を表1に示す)。

  1. コンポーネントチーム。このアプローチでは、各サブチームが1つ以上のサブシステムまたはモジュールの責任を負うことで、異なったチーム間で必要な情報共有とコラボレーションの量を減らすことができる。ただしチームの一部が自宅で働いていると困難なことがありうる。コンポーネントチームを、アーキテクチャーを中心に効果的に組織化するためには、そのアーキテクチャーを確認するのに十分な時間を事前に投資する必要がある。
  2. フィーチャーチーム。フィーチャーチームは、ユーザーストーリーやユースケースなどの機能要件をエンドツーエンドで実装する責任がある。これは、よくソリューションの垂直スライスの実装と呼ばれる。特定のフィーチャーチームは、例えば金融機関内の仲介または生命保険などの単一ビジネスライン(LoB)の要件に焦点を当てるので、LoBの専門知識を得ることができる。フィーチャーチームが、組織内の特定のアプリケーションまたはシステムに固有の要件を引き受ける場合もある。
  3. ファンクショナル(職能)チームいくつかの大規模チームは、アーキテクチャチーム、開発チーム、テストチーム、デプロイメントチームなどの開発職務チームによって組織される。各チームはそれぞれの専門職務に焦点を当て、成果を他のファンクショナル(職能)チームに引き継ぐ。
  4. 内部オープンソースチーム。すべての成果物が組織にとって非公開であっても、コンポーネントやサブシステムをオープンソースの方法で開発することがある。他のチームの開発者が、コンポーネントを自発的に開発し、徐々に進化させる。Scott(筆者)がIBMに所属していたとき、この戦略はいくつかのIBM製品で再利用された数個の重要なコンポーネントについて実際に採用していた。この戦略に関する詳細な考え方については、Reuse Through Internal Open Sourceを参照のこと。

表1. チームの組織化戦略の比較

チーム戦略 長所 短所 備考
 コンポーネントチーム
  •  サブチーム間のコミュニケーションを減らせる。
  • チームはコンポーネントに固有の技術的専門知識を築ける。
  • 疎結合かつ凝集度の高いアーキテクチャーが必要である。
  •  機能の依存管理は、複雑になるかもしれない。
  • 要件をコンポーネントごとに集約する必要がある。
  • 凝集度が高く、疎結合のコンポーネントまたはサブシステムに適用する。
  •  技術的専門知識を必要とするセキュリティフレームワークやデータベースカプセル化サービスなどの技術指向コンポーネントに適用する。
 フィーチャーチーム
  •  チームはビジネスのサブセットに集中できる。
  • フィーチャーをチームに簡単に割り当てられるかもしれない。
  •  共通の、開発の決まりごとが必要である。
  • 洗練された構成管理が必要である。
  • 技術的な依存関係の管理が、複雑になるかもしれない。
  • 要件の依存関係の管理が、複雑になるかもしれない。
  •  開発者が問題のドメインを深く理解することを要求する複雑なLoBやアプリケーションに適用する。
 ファンクショナル(職能)チーム
  •  個人の職務の専門化ができる。
  • 従来のやり方に深い経験を持つ人々が受け入れやすい。
  •  多能工ではなく、専門家になるよう動機付けられる。
  • チーム間のコミュニケーションが重要だが、オーバーヘッドである。
  • より多くの文書とそのレビューが必要である。
  • より一層の監視が必要である。
  • プロジェクト全体および組織のリスクを増加させる。
  •  統合チームがソリューション全体を統合し、エンドツーエンドでテストすることは、多くの場合、理にかなっている。
  • 開発とテストが別々の場所で実行される「follow-the-sun」戦略をサポートする。
 内部オープンソースチーム
  •  共通コンポーネントまたはサブシステムの開発をサポートする。
  • 複数の開発チームにこれらのコンポーネントの開発コストを分散できる。
  •  この作業に取り組むためには、他のチームにも、少なくともパートタイムで、開発者を提供してもらう必要がある。
  • オープンソース開発を反映した管理とガバナンスの構築が必要である。
  •  「パブリックな」オープンソースの取り組みに深い経験を持つ開発者と供に、組織に導入する。

これらの戦略は組合せ可能で、多くの場合そうされることに注意すること。

チーム規模による作業方法への影響

大規模チームは、直面する課題に対処するためにしばしば以下の戦略を採用する。

  1. 少し多めに先行要求探索を実行
  2. 少し多めに先行アーキテクチャーモデリングを実行
  3. 少し多めに先行計画を実行
  4. より洗練された調整戦略の採用
  5. より洗練されたテスト戦略の採用
  6. 定期的な統合

戦略#1:少し多めに先行要求探索を実行

図14のプロセスゴール図は、初期のスコープを探索するのゴールである。この方向付けのゴールは、ソリューションの初期要件を引き出し、明文化する戦略である。自信を持って構築を開始できるのに十分なだけ、利害関係者が何を望んでいるかを理解する仕事をする。なぜなら、大規模なチームは通常、小規模のチームよりも複雑な問題に取り組んでいる。チームが取り組んでいる問題を理解していることを確認するためには、先行要求探索を少し多めに実行する(とは言え徹底的にではない)必要がある事は、想像に難くない。これは、多くの場合、チームはいくつかのビュー形式(*訳注1)を扱う必要があることを意味する。チームは様々な視点で問題を探索する必要があり、また、あまり複雑でない問題に取り組んでいるよりも少しだけ詳細に明文化することになりがちだ。

*訳注1:図14に示す図は、当初の図では「ビュー形式」の下位にまとめられていたものが、「利用方法を探索する」「ドメインを探索する」「プロセスを探索する」「ユーザインタフェースへのニーズを探索する」「基本となる要求を探索する」に分割された

図14. 初期のスコープを探索するプロセスゴール

goal-inception-explore-initial-scope

重要なのは、どのチームメンバーをモデリングセッションに参加させるかだ。すべてのモデリングセッションに、チームメンバー全員を含めるのか?一部のメンバーだけを含むのか?各モデリングセッション中に一部のメンバーだけを含むが、全員がセッションの少なくとも一部に関与するように参加者を回すのか?すべてのモデリングセッションにチームメンバー全員を含めると、誰もが利害関係者が望むものを聞き、深入りした質問をする機会を提供できるという利点がある。しかしながら、この戦略は非常に大規模なチームには適していない。なぜなら、費用がかかり、誰もが参加することに興味を持っているわけでもなく、モデリングルームのスペースも限られているからである。すべてのセッションに一部のチームメンバーを含めることは、コストがかからず、より高速になる可能性がある。しかし、後でより大きなチームに初期の要件を伝える必要がある。モデリングセッションを通して一部のメンバーをローテーションすることで、全員が新しいモデリングスキルを習得する機会と、要件の少なくとも一部を聞く機会を得られる。しかし、依然としてチームの全員に要件全体を伝える必要があり、モデリングチームのメンバー変更のせいで、利害関係者が説明を繰り返さなければならないリスクがあるため、難しくなるかもしれない。

戦略#2:少し多めに先行アーキテクチャーモデリングを実行

図15のプロセスゴール図は、初期の技術戦略を特定するのゴールである。この方向付けのゴールは、利害関係者へのソリューションを生み出すためのアーキテクチャー戦略(または戦略案)をどのように特定するかを示す。要求探索と同様に、大規模チームは先行アーキテクチャモデリングに少し多めに努力を投資して、ソリューションを開発するための戦略を理解できるようにする。つまり、いくつかのビュー形式(*訳注2)を活用し、少しだけ詳細に明文化しようとすることだ。

*訳注2:図15に示す図は、当初の図では「ビュー形式」の下位にまとめられていたものが、「技術アーキテクチャの探索」「ビジネスアーキテクチャの探索」「ユーザインタフェースアーキテクチャの探索」「将来を考慮する」に分割された

図15. 初期の技術戦略を特定するプロセスゴール

goal-inception-identify-initial-technical-strategy

要求探索とアーキテクチャーモデリングの両方の場合、チームが大きくなればなるほど、より洗練された方法でモデルを明文化するだろう。たとえば、小規模チームではホワイトボードや紙(付箋紙やインデックスカードなど)などのinclusive modeling toolsを使用する傾向があるが、大規模チームではソフトウェアベースのツールを使用し結果を明文化するだろう。このような先行モデリングとその結果の明文化により大きな投資をすることで、チーム内で何を行う必要があるのか、そしてどのように行うのかをより強く理解することができる。この共通の理解は、今後のチーム内の調整を容易にし、それによってプロジェクトのリスクを軽減するだろう。

戦略#3:少し多めに先行計画を実行

図16のプロセスゴール図は、初期のリリース計画を策定するのゴールである。この方向付けのゴールは、初期計画の作成にどのようにアプローチするかを示す。構築(フェーズ)中に詳細は固まっていくものだが、それでもどうやって一緒に仕事をするのか、および仕事の大体のタイミングについて考えるべきだ。モデリングの場合と同様に、チームが大きくなればなるほど、思考に時間をかけたいと思うだろう。最低限、最初のリリース計画で確認する事は、他のチームとの主要な依存関係、サブチームが採用するケーデンス(特にイテレーション期間)、すべての主要な同期イベント(暫定計画やモデリングセッションなど)、および計画された終了日である。

図16. 初期のリリース計画を策定するプロセスゴール

goal-inception-develop-initial-release-plan

戦略#4:より洗練された調整戦略の採用

図17のプロセスゴール図は、活動を調整するのゴールである。この進行中のゴールは、チーム内や組織内の他のチームとの活動をどのように調整するかを示す。先に説明したように、チーム内で採用する調整戦略は、チームの規模が大きくなるにつれてより洗練されたものになる。小規模チームの運営は、ノンソロ(non-solo)作業戦略、日々の調整ミーティング、および情報ラジエーターによる作業の見える化で可能である。中規模チームは、チーム間で「スクラムオブスクラム」(SoS)という2番目の調整会議を開催する必要があり、より洗練された統合戦略(後述)に移行する必要があるかもしれない。大規模チームは、SoSよりもさらに洗練された調整戦略(アーキテクチャオーナーチーム、プロダクトオーナーチーム、内部管理チームなど)を採用する必要があるだろう。

図17. 活動を調整するプロセスゴール

goal-general-coordinate-activities

戦略#5:より洗練されたテスト戦略の採用

図18のプロセスゴール図は、デプロイ可能なリリースに近づけるのゴールである。この構築のゴールは、チームがソリューションをデプロイする準備ができていることを確実にする方法を示す。このゴールは、テスト、構成管理、文書化、および開発のデプロイ局面を扱う。先に述べたように、チームのサイズはしばしば複雑さに支配される。問題のドメインが複雑になればなるほど、または利用する技術基盤が複雑になればなるほど、複雑な問題に対処するための追加の人員が必要になる。これらの複雑性がさらに高まることで、agile testing and quality assuranceに対するより洗練されたアプローチの必要性が生じる。これには、(SAFeが統合チームと呼ぶ)並行した独立テストチームも含まれる。

図18. デプロイ可能なリリースに近づけるプロセスゴール

goal-construction-move-closer-to-deployable-release

戦略#6:定期的な統合

チームの規模に関係なく、アジャイルチームは自分達の成果物を定期的に統合しようと努めている。継続的インテグレーション(CI)により常にそうしているのがより良い。ソリューションが大きく複雑になるにつれて統合は難しくなる。そして、大規模チームはそのような複雑な問題に取り組む傾向がある。そのため、チームの規模が大きくなるほど統合が難しくなる傾向がある。10人の作業を統合することは合理的に単純だが、50人の作業の統合は少し難しくなり、数百人の作業の統合ははるかに難しくなる。その結果、DADの補助的役割の1つであるインテグレーターとして、チームの全体的な作業を統合することにフォーカスする人物(場合によってはサブチーム)が必要になるだろう。統合にフォーカスする人々は、進行中の並行した独立テストの取り組みと密接に関係する場合が多く、しばしばそのようなテストを直接担当する。

その他の参考文献

終わりに

この記事のゴールは、デリバリーチームのサイズに関する問題を探求することであった。小規模、中規模、および大規模のアジャイルチームでの経験を説明し、そのような状況でのアプローチが変わる必要がある(1つのプロセスサイズまたは1つの組織構造がすべてに適合するわけではない)ことを示した。プラクティス・コミュニティー(Guilds)、エンタープライズアーキテクチャチーム(未翻訳)などのITチーム、ソリューション提供チームと協力するオペレーションチームについては、説明しなかった。これらのトピックの詳細については、今後の記事を参照のこと。

オリジナル:Large Agile Teams
http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/
(翻訳 大脇斉)

Pocket