全体は部分の総和に勝る。

- アリストテレス

システムチームの概要

アジャイル定義/構築/テスト(DBT)チームは、短い時間枠内で品質の良い動作するソフトウェアを構築する技能を持つクロスファンクショナルチームである。システムレベルのソリューションは主にこのチームの努力によって構築される。しかしながら、プログラムあるいは企業の世界ではこのチームは完全に自己完結しない。単独で完全にシステムソリューションを全般に統合し評価できるチームは滅多にない。システムが大きいほど、1つのチームだけで完結できる可能性は少なくなる。また、アジャイルへの移行中には、ソフトウェア資産の統合を開発サイクルの終盤で1回のみで行うのではなく、頻繁に(時間毎、日次、週次)行うには、通常は追加のインフラ作業が必要である。そのために、「システムチーム」と呼ばれる別の専門的なチームを形成する。

詳細

役割の概要

システムチームはアジャイルリリース列車における特殊なチームである。継続的インテグレーション、ビルド環境、テストプラットフォームとテスト自動化フレームワークはもちろん、アジャイルチームが作成したコードの結合、エンドツーエンドのシステムテスト、各反復での利害関係者へのソリューションのシステムデモなど、アジャイル開発環境インフラの構築と利用を支援することはこのチームの主要な責務である。システムチームは発展するエンドツーエンドソリューションの有効性と完全性に関する迅速なフィードバックを提供し、チームや他の利害関係者をサポートする。システムチームが、各 リリースを支援する特別の役割を果たす場合もある。

しかし、これらの作業はシステムチームとアジャイルチームの間で共有しなければならない。そうしないと、システムチームはボトルネックになりうるし、アジャイルチームも真の価値を提供できるだけの能力が備わらないし、責任が取れない。

責務

システムチームの典型的な主要な責務は以下のとおりである。

開発インフラの構築

優れたインフラでサポートすることでプログラムのベロシティーが高まるため、システムチームは以下を行う。

  • 継続的インテグレーション、自動化されたビルド、妥当性検証テストの自動ビルドを含むインフラを構築し、メンテナンスする。
  • システムデモ、QAやユーザーテストなどのためのプラットフォームと環境を構築する。
  • 自動配置のためのシステム、ユーティリティ、スクリプトを作成する。
  • データやサービスプロバイダ、ホスティング設備などの第三者との連携の技術的側面を促進する。

システムの結合

複雑なソフトウェアシステムの場合は、システムチームは以下のことも行わなければならない。

  • 適切なプログラムブランチモデルのための判断とポリシーを決定し、それらを維持できるよう支援する。
  • システムレベルの結合スクリプトを実行する。自動化が不可能な場合やまだ適用されていない場合は、手動で結合を行う。
  • コンポーネントチームに協力し、コンポーネント間のインタフェースを定義する。
  • 日常的な活動を支援するために、他のチームのスタンドアップミーティングに参加する。

エンドツーエンドのテストとシステム性能テスト

システムチームはいくつかの自動化されたテストに関する責務も果たす場合がある。

  • リリース計画策定とバックログ手入れに参加して、結合とテストストーリーを定義する。
  • 新たな自動化されたテストシナリオを作成する。
  • テストシナリオを拡張して、より大きなデータセットを作成する。
  • 個々のチームによって設計されたテストケースを順番付きのスイートにまとめる。
  • 新たなフィーチャーやストーリーについて、手動テストを実施したり、自動化されたテストを実行する。
  • 時間のかかるテストを優先的に実施し、可能であれば再現テストスイートのリファクタリングや実行を行う。
  • 再現テストスイートの作成に協力し、チームが自分自身で再現テストを実行できるようにする。
  • システム性能が非機能要求(NFR)を満たしているかをテストし、システムアーキテクトと協力してシステムの十分でない部分やボトルネックを識別する。

システムデモ

各スプリントにおける適切な時点で、チームはシステムデモで利害関係者たちに現在のシステムソリューション全体を示さなければならない。システムチームは通常このデモの開催を支援し、また、新たなシステム機能を確実にデモできるデモ環境が十分であるように支援する。

リリース

システムチームはユニークなスキルや発展するソリューションを見渡せる目を持つ場合が多い。このチームにはシニアQA要員が含まれるかもしれないし、システムアーキテクトがチームメンバーの1人であるかもしれない。彼らは複数の反復をまたがるソリューションを見てきて、それが何であるか、何をするか、意図したすべての要求をどのようにして満たすかを通常は理解している。この観点から、システムチームは直接にリリース支援に関わり、列車がソリューションを準備し、パッケージングし、ターゲット環境へリリースするのを支援するために必要なことを行う。

規模の大きな価値のストリームにおけるシステムチーム

先に説明したように、システムチームはほとんどの場合、1つのARTの専任である。しかし、大きな価値のストリーム連携してシステムチームの役割を果たすには、違ったチーム構造が必要になる場合がある。価値のストリームのスコープと複雑性に応じて、以下の3つのパターンのシステムチームが見られた。

  1. ARTごとに1つのシステムチームが存在する。他からの支援がなくても、効果的に連携してシステムの結合と妥当性検証を行うことができる。
  2. 価値のストリームレベルだけに1つのシステムチームが存在する。このチームがARTのための責務を遂行できる。
  3. 価値のストリームレベルに1つのシステムチームが存在する。さらに、リリース列車の中に、関連するチームまたは同等の役割が存在する。

どのパターンを利用するかの判断は、価値のストリームの個々の背景に主に依存する。ただし、その他にも、アジャイルチームの方向性(フィーチャーやコンポーネント)、価値のストリームにおけるARTの構造(フィーチャーやサブシステムを中心として作られたもの)、ソリューションアーキテクチャー、列車をまたがるブランチ/統合ポリシー、システムテスト可能性、開発インフラなどの、一般的な要因が関係する場合もある。

システム結合とテストの労力のバランス

最後に述べておくが、システムチームはシステムの問題に対する完全なソリューションではない。実際、システムチームが存在しているからといって、システムチームだけがシステム全体についての知識を持っているわけではない。アジャイルチームも、自分たちが作っているものの全体像を明確に理解していなければならない。そうでなければ、フィーチャーチームやとコンポーネントチームの一部が優秀であっても、良好な経済的成果にはつながらない。プラクティスが適切に共有されて初めて効果的なシステム開発が成り立つ。たとえば、もしNFRをテストするのがシステムチームだけで、個々のチームでは軽量の性能テストすら行なわなければ、重要な品質テストをパスするために必要な手戻り作業によって全体のプログラムベロシティーが引き下げられるだろう。同様に、アジャイルチームが、直接やり取りするコンポーネントとすら継続的に結合していない場合は、システムチームによる結合作業は、長く痛みを伴うプロセスになる。図1に示すように、プログラムベロシティーを最大化するには、バランス感覚が必要となる。

図 1.アジャイルチームとシステムチームの間のシステム統合に関する労力の最適なバランス。成熟度と自動化度が高くなるにつれ、最適ポイントは左に移動する。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011. 第4章 (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last update 16 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.