Azure DevOpsで複数のチームを運用する
Azure DevOpsで複数のチームで開発していて、全てのチームメンバーのwork itemが単一のTeamとSprintで管理されていてカオスなことになっています。どうにかしたいです(´・ω・) というお悩みのおたよりを頂いたので、複数のチームとそのwork itemを上手い事Azure DevOps上で運用する方法について書いてみます。
「もうAzDO上でチーム作っててIterationも何回も繰り返してるしもうwork itemもめっちゃ作っちゃってるよ、、、」という場合でも大丈夫。割とそんなコスト掛けずに構成し直せます。
AzDOで複数チームを運用していく方法はNexusやScrum of Scrumsみたいな大規模アジャイルでめちゃくちゃ使えるので是非使ってみてください。
前提
今回はこんな感じになってるのをいい感じに構成し直そうと思います。
- 実際のチームはFrontend-Dev, Backend-Dev, Operators, Architectsの機能チームに分かれて運営されている
- AzDOでは全チームメンバーがProject Devsという単一のTeamとSprintでいっしょくたになっている
- 各メンバーは、複数のチームに所属することもある
1.現実のチーム運用を反映してAzDOでチーム構成をする
まず前提として、AzDOでチームを構成して運用していく際には現実のチーム構成、運用を反映するような構成にしておいた方がよいです。
AzDOでのチーム構成が現実と一致していない場合の困りポイント
AzDOでのチーム構成が現実のチーム構成と一致していない場合、下記のようなデメリットがあります。
- 単純にタスク管理がしにくい
- １つのチームにめちゃくちゃ多い人数が所属することになり、チーム運用がしにくい[1]。
- Burndown Chart, Velocityなどのチームの生産性を測るメトリクスが正常に作動しない（←これが地味に結構困るポイント。これらのメトリクスはTeam Sprint単位で計測されるので、一つのTeam Sprintに実際には別々のチームで動いているメンバーが全員登録されていてそのTeam Sprintでしか運用していないと、ばらばらに動いているメンバーが1つのチームとして認識されてしまい、正確にチームパフォーマンスの測定ができなくなります）
Team, Area Pathの設定
今回の場合、現実のチーム構成はこんな感じになっています。
Project Dev Team
└──Architects
└──Backend-Devs
└──Frontend-Devs
└──Operators
現実に合わせてAzDOではこんな感じにチーム構成しようと思います。
では、このチーム構成を作るためにAzDOのProject Settings > Teamsにいきます
New Teamを押下
こんな感じでチームを設定します。
各項目はそれぞれ以下のような値を設定して下さい。
※個人が複数のTeamに所属する場合、複数のTeamにまたがって所属することも可能なので普通にここのMembersの項目でそれぞれのTeam作成時にメンバーを追加して下さい。
- Name：チーム名
- Members: 所属させたいメンバーを選択
- Descriptions: チームに関する説明
- Administrators: このチームの管理者
- Permissions: このチームのAzDOのPJに対する権限
ハイライトの箇所Create an area path with name of the teamにチェックを付けます。
Area Pathはチームでwork itemを分ける際に使用されるフィールドで、基本的に複数チームでwork itemを運用する際はこのArea Path単位で区切られて運用されるので、AzDO上で複数のチーム単位で作業を分けて運用していきたい場合はこのArea pathをチームごとに設定する必要があります。
Area pathについて詳しくはこちらを。
こんな感じで必要なチーム分作ります。
Area Pathの階層構造を設定する
現実のチーム構成はこう↓なので、Area Pathもこれが反映されていればOKです。
Project Dev Team
└──Architects
└──Backend-Devs
└──Frontend-Devs
└──Operators
今回は、Project-DevsのTeamではすべてのTeamのwork itemがBacklogで見れると嬉しいので、Project-DevsですべてのTeamのArea Pathを含めるようにします。
Project Settings > TeamsにいってProject Devsを選択します。
Iterations and Area Pathsを選択
選択すると、Project-DevsのTeam Configurationに移動します。Areasのタブに切替えます。
Project-Devsは最初にAzDOでProjectを作成したときにできるTeam（名前だけわかりやすくProject-Devsに変更しています）で、これはDefaultとして設定されており、紐づくArea PathもDefault areaが指定されています。
Area Pathの構成をちょっと確認すると、今回のように新たにTeamを作成した場合、Project作成時に作成されるDefaultのTeamのArea pathのsub areaとして新しく作成したチームのArea Pathが存在します。
このArea Pathの階層関係はProject Settigns > Project Configurations > Areasで確認できます。
※手動でArea PathにさらにChildのArea pathを指定することもできます。例えば、Frontend-Devsの配下に更にFrontend-UIUX Team, Frontend-QA Team等の配下のTeamを作成してそのArea PathをFrontened-Devsの配下のArea Pathにする、とかもできますが、複雑になってチーム・タスク管理がし辛くなるのであまりArea Pathの階層を深くするのはおすすめしません(´・ω・｀)
Project-DevsのTeam Configuation > Areasに戻ります。
このDefaultのArea Pathが配下のFrontend-DevsとかBackend-Devsとかの配下のTeamのArea Pathを含めるようになればいいので、下記のように、・・・からInclude sub areasを選択します。
こんな感じで、1) Area pathに紐づくTeamのbacklogがあなたのTeamでも出てきますよ、
2) この配下のArea pathの全てのwork itemがこの操作によって更新入るのでちょっと時間かかるかもよ、みたいなメッセージが出てきます。
OKを押下してください。
処理が完了したらこんな感じでsub-areas are includedって表示されるようになります。
これでこのProject-DevsのTeamでは配下にあるArea Pathに紐づくすべてのTeamのwork item
がBacklogで見れるようになります。
※「もうwork itemめっちゃ作っちゃってるよ、、、」という場合は、各PBIのArea Pathをそれぞれのチームごとに該当するArea pathに指定してください
これでArea Pathの構成と階層構造の構成は完了です。
詳しく見たい方はこちらのdocsをどうぞ。
複数のArea Pathで分割した場合のBacklogの見え方
では、上記のステップの後にBacklogがどういう風に見えるようになってるか確認してみます。
各機能チームのBacklogには以下のようなPBIがそれぞれ登録されている状態です。
- Architects
- Backend-Devs
- Frontend-Devs
- Operators
※Teamの切り替えはここでできます
これらのTeamの全てのArea Pathを配下に持つProject-Devsに切り替えると、こんな感じで全てのBacklogにあるPBIが表示されます。
Project-DevsでBacklogの順番を変えた場合、その順番はそのArea pathのTeamのBacklogにも反映されます。例えば、Architectsの最優先PBIとして「技術的負債の評価と修正計画の策定」を先にやってもらおうと思ってProject-DevsのBacklogで優先順位の第1位にした場合、
- Project-DevsのBacklog
こんな感じでArchitects TeamのBacklogでも設定した優先順位が反映されて「技術的負債の評価と修正計画の策定」のPBIが第1位になります。
- ArchitectsのBacklog
各Areaでフィルターすることもできます。が、このフィルターを適用している状態ではPBIの優先順位の変更はできません。
これで、Project-DevのTeamに所属するメンバーは全TeamのPBIの確認と順番の変更ができるようになりました。
2.Team Sprintの設定
BacklogではTeamごとに表示することができるようになりましたが、今のままではBoards > Sprintに行ったときにSprintのTaskboardで各Teamが選べるようにはなっていません。
せっかくBacklogをTeamごとにわけたので、SprintのTaskboardもTeamごとに分けてSprint内でのタスク管理・運用もTeamごとにできるようにしたい所です。
これを実現するためには、作ったTeamに適用されるIterationを設定して、Team Sprintを作成する必要があります。
Project Settings > Teams > 設定したいTeamを選択して Iterations and Area Pathsを選択
Team Configurationに移動するので、Iterationsのタブに切替
こんな感じで、今このTeamにはIterationが設定されていません。SprintのTaskboardでこのTeamが表示されないのはこのためです。
このTeamが参照するIterationを追加します。
+ Select Iteration(s) を選択して
どのIterationから始めるか選択します。現在のIterationがSprint6であればSprint6を選択するとよいでしょう。
Team Sprintを設定したので、TeamのBacklogから各PBIのIterationを設定します。
TeamのBacklogで以下のようにSprintにdrag&dropするか
※このPlanningセクションはここのView Optionsから表示できる
もしくは、操作したいPBIを選択した状態...を押下 > Edit
Iteration Path == Sprint6 って設定してもIterationを設定できます。
これで、こんな感じでSprintのTask BoardにさっきSprint6に指定したPBIが出てくるようになり、SprintのTask BoardでTeamごとにPBIを運用していけるようになりました。
Sprintを追加していく場合、ここのView OptionsからPlanningセクションを開いて
ここのNew Sprintから新しいSprintを追加していけます。
(非推奨) 各Teamを別々のIterationで運営する
管理がめんどうになるのであまりお勧めしませんが、Architect Teamは1ヶ月Sprint, それ以外のTeamは1週間Sprintで動く、みたいなのもできはします。
※Iterationの管理がめんどくなるので、MSの以下DocsでもすべてのTeamでは同じSprint期間で設定した方がいいよ、と言っています。
どうしてもやる場合は、Project Configuration > Iterationsにいって、
DefaultのIterationからNew childでsub iterationの追加ができます。
こんな感じで任意のIteration nameを設定します。
そうするとこんな感じでIterationが追加されます。
この1st Release PhaseのIterationは10/1-10/31の1ヶ月Sprintなので、その配下に1週間
SprintのSprint8, 9を入れたい場合、こんな感じでSprint8, 9を1st Release Phaseにdragすると
こういう風にIterationを階層構造にできます
たとえば、Architects Teamのみこの1ヶ月Sprintの1st Release Phaseの単位で動いて欲しい場合、Area path == Architects のPBIのIterationを1st Release Phaseに変更すればよいです。
ですが、Iterationの期間をチームで変えて階層構造にしたりするのは正直メンテコスト結構高いのであんまりおすすめはしません(´・ω・｀)
仮に1st Release Phase, 2nd Release Phase単位でチームが分かれているのであれば、そのチーム単位でAzDOでTeamとArea Pathを設定することをお勧めします。
Iterationを分けないといけないパターンは、どうしてもこの日数単位で管理せねばならないとか日数単位で縛りたいときにのみ使って下さい。
-
1つのチームの最適な人数構成はTwo-Pizza Rule:2つのピザを分け合える人数 に基いて大体10人ぐらいをオペレーションする感じにするといいと思います ↩︎
Discussion
いくつかの誤字を指摘して頂いたので修正