Azure DevOpsでAreaとサブチーム

動機、概要

小規模なプロジェクトであれば1つのチームだけで成り立つのですが、大規模なプロジェクトになってくると分野ごとでチームを分割する必要があるかもしれません。そんなケースにAzure DevOpsで対応する方法を書きたいと思います。

概念

Teams

そのものズバリでTeamsという設定があります。

初期状態ではプロジェクト名と同じ名称のTeamが一つだけ存在しています。

Area

単一チームで運用している場合にはあまり意識することはありませんが、Azure DevOpsにはAreaという概念があります。これはまさに担当エリアを表すものになります。

初期状態ではプロジェクト名と同じ名称のAreaが一つだけ存在しています。

Area x Team

さて、AreaとTeamはM:Nの多対多関係を取ることができます。Exampleプロジェクトの初期状態はExample Teamの担当はExampleエリアとなっています。

複数のAreaを作る

Child Areaとして作る

AreaはデフォルトのExampleエリアのChildとしてしか作成できません。

階層は複数階層可能で上図の例では3階層まで作っています。
e.g) Example\Purchase\Cart

Area Path

PBI等のWork ItemにはAreaという属性があり、そのItemがどこのAreaに所属するかを指定することが出来ます。

クエリ等で探すときにはArea Pathという属性として扱います。

複数のチームを作る

Project Settings/TeamsからNew Teamしましょう。

最下部にCreate an area path with the name of teamというチェックがあります。これは「チームを作ると同時にチームと同じ名前のAreaを作る」ということを意味します。今回は先にAreaを作ってあるのでOFFにします。

Team と Areaをマッピングする

Team configurationから行いますが、上部でなにげにTeam選択のドロップダウン操作ができます。これを使って設定したい対象チームをまず選んでください。

こちらのチームでは2つのAreaを担当する例です。複数Areaを担当する場合には1つだけDefault Areaを決めてください。Default AreaはWork Itemを作成するときにデフォルトで指定されるエリアになります。

こうしてチームとAreaのマッピング設定をした結果は Project configurationで眺めることが出来ます。

Boads, Backlogsの挙動

さて、こちらの例では

• 1,2はMoneyチームの担当バックログ
• 3はPenguinチームの担当バックログ

ということになります。

Penguinチーム

Monkeyチーム

Additional

以上で当初掲げていたことは実現できるのですが実用上の補足があります

Team毎の設定

単一チームで運用していたときには気にならなかったのですが、チームを複数分けることによってチーム個別設定が必要な箇所があります。これは忘れがちなので気をつけましょう。

チームごとに自治権があって良いといえば良いのですが、全チーム同じ設定にしておかないと迷うケースが多々あると思われます。

イテレーション

Backlog iteration

まずハマるのがこの設定です。チーム作成時にはこの欄は埋まっていないのですが設定必須です。設定しないとBoards, Backlogs viewでエラーが出ます。

Backlog iterationというのは「積ん読」状態のバックログが便宜上どのIteration pathにアサインされているのかを示します。Iterationは通常下記のような構造になっておりルートのExampleイテレーションは期間を設定されず「積ん読」を表すのが通例です。

Team assigned iteration

これは自分が便宜上作った用語ですが、Teamが使用可能なイテレーションはチームに対してアサインされている必要があります。何もアサインしていない状態では次のような表示になりスプリントをチームにアサインすることを促されます。

各チームで全く別のイテレーションリズムで進行していくことも可能ですが、SAFe, LeSS等では全サブチームが同じイテレーションリズムで進行することが推奨されています。理由としてはサブチーム分割した場合には各チームの成果物を統合して確認する必要があるケースが多いと思いますが、リズムがバラバラだと統合タイミングが難しくなるためです。

休日等の一般設定

これらの一般設定項目もチーム毎になります。

Backlog navigation levelsはハマりがちなポイントでデフォルトはEpicレベルは使用しない設定になっています。Epicを使用したい場合には「チームによってEpicが出ない」という事象に遭遇するかもしれません。

Working with bugsも場合によっては厄介です。バグをTask扱いとするか、PBI扱いとするかを決められるのですがチーム毎にバラすと管理がややこしくなるかもしれません。

かんばん Boardsの設定

かんばんBoardsは細かく設定ができるのですがこれも個別です。複数チームの看板を順々に見ていくSprint Reviewミーティングなどでは設定を揃えておかないと戸惑うことになるでしょう。

Sprint BoardのCapacity Days off

Sprint Boardではスプリントに祝日などがある場合、個人単位で休暇を取得する場合などにDays off(=休日）の登録をすることが出来ます。

個人個人の休暇はまぁ、チーム単位の管理でいいと思うのですが、祝日管理は全チームが日本の場合には揃えたいところですが、チーム個別に設定する必要があります。
（多国籍チームの場合には国ごとにNational Holidayが異なるのでこの機能がありがたいのですが）

全チーム分のPBIを串刺した管理

エリア単位での管理も重要なのですけれど、上位の管理者はプロジェクト全体を見渡したいものです。これが一番困るんじゃないでしょうか。自分も困りました。

All Teamを作る

デフォルトチームの名前を改名してもいいです。すべてのAreaを扱うことができるチームを作ります。そして、そのチームにすべてのAreaをマッピングするのです。

終わりに

いかがでしたでしょうか？ TeamとAreaのマッピングをすることで柔軟なチーム体制管理ができることがおわかりいただけたかと思います。

機会があれば活用してみてください。