Azure Boards - 設定その１

はじめに

Azure Pipelinesに関しては割と書いてくれる人が多いですが、Boardsはそうでもない…と思います。なんとなくというか、スモールスタートのまま使っていてもいいのですが、ある程度規模が大きくなってくるとそうもいかない場面が出てきます。Boardsはとっつきにくいかもしれないですが、大きなチーム規模になってもかなりスケールする作りになっているので、是非活用してほしいと思っています。余すところなく、とはいかないかもしれないですが、もう一段階活用するためにはどうすればいいか、ということでまとめてみます。結構長くなりそうなので(というか、これはKDPの書籍の元ネタにしようかなぁと目論んでいる感じだったりしますが)何回かにわけて書きます。

Azure DevOps Servicesで書いていますが、大半の内容はAzure DevOps Server 2019.1でも適用可能です。

チームプロジェクトとしてのバックログやイテレーション設定

Azure DevOpsのチームプロジェクトを作ると、次はバックログやイテレーションの設定を行います。やらなくても使えることは使えるのですが、Basicプロセス以外の場合、カンバンにバックログが永遠に残ってしまい、かなり賑やかなことになります。「このバックログ終わったのにいつまでも表示されてうざい」ということがないように、面倒ですが最初にしっかりやりましょう。

設定はhttps://dev.azure.com/{organization}/{Project}/_settings/workから行います。

イテレーション

(画像内にtypoがあるけど見逃して)

バックログの作業を行うとき、どこの期間で実施するか登録します(いつやるか未定、とりあえず積み上げておくみたいなものもありますが)。この「いつやるか」というイテレーション(スクラムではSprint)を構築します。チームプロジェクトで最初と最後の日付を決めておいて、その配下に子ツリーとして複数階層で構築できます。正直ここのUIなんとかならんのかと思うんですが…。どんどん追加していくと、下にしか出てこないので、長期間やるようなチームプロジェクトだと追加が大変なんです。ここREST APIもなくて結構困ってます。

話がそれましたが、ツリーとして作る場合、二つ考え方があると思います。ひとつは上のように「年」などを上位にして、その配下にイテレーションの具体的な期間を切っていくやり方。もうひとつはざっくりfeature(機能)とかrequirementで作ってしまって、その下にイテレーションを切っていくとか。

前者はカレンダーの通りに切っていくのでみんなにわかりやすいですね。指定の期限までにきっちりタスクを消化していくタイプのプロジェクトだとわかりやすいです。

後者は特定の要求事項でまとめていくのでそこまでやっていくということで区切りがわかりやすくなるかなと思います。特にお客さんからのマイルストーンが提示されているような場合に便利かなと思います。これは開発チーム全体の意向となるので、みんなで合意したほうがいいかなと思います。

ここには載せてないですが、単純にiteration xxでシンプルに一階層だけでいくという方法もありますね。自社のサービスなんかでは便利でしょう。

エリア

次はAreaです。これはちょっと説明が難しいですが、次に説明するチームプロジェクト内のチームにも影響します。ある程度の規模になっていくと、日々生産されるバグやタスクで全体が見づらくなってきます。GitHubではリポジトリとissueが一対一ですが、Azure DevOpsのGitリポジトリの場合一対多の関係になるので、ざっと全件見ると大変なことになります。

それでは困るので、ある程度の単位で分割する必要があります。GitHubのissueにラベルをつけるように、タスクにタグをつけることもできるのですが、それよりは予めAreaを定義しておいて、「このタスクはこのArea」としておく運用が便利です。このAreaは次で紹介するチームに直接紐づけられるので、チームで作業すべきタスクが明確になり、他のチームと混在して表示されることがなくなります。

Areaもイテレーションどうように親子階層が作れるので、特定のチームの中でさらにバッチであるとか、HTML関係の修正であるとかさらに細分化もできます。細分化しすぎるのもよくないですが、しておけばAnalytics Viewを使ってタスク数や負荷状態の可視化にもつながるので、Areaはチームを分割しなくても使うことを意識しておいた方がいいでしょう。

チームとは

前段落まででチーム、という言葉が何回か出てきました。Azure DevOpsでチームプロジェクトを作ると、必ずデフォルトのチームが作られます。おそらく多くの方や使い始めた方はこのチーム一つで運用されていると思います。

その前にチームプロジェクトどういう単位で作ればいいのよ？という話がありますが、これはリリースする単位で作ると考えてもらえればわかりやすいです。リリースする単位の中には単一もしくは複数のリポジトリがありますが、それぞれで依存していることが多いはずです。

リポジトリの閲覧権限はなくても、成果物を共有し、成果物に対するissueやバックログを見て、お互いの進捗状況を確認できるようになっているような関係性が期待されています。

では、チームプロジェクトの中のチームとはなんでしょう。このくらいの開発者や利害関係者であればさほど気にすることはないと思います。

• メンバーは大体10人くらいまで
• 全員で開発、運用全てのライフサイクルになんらかの関わりがある
• 成果物はソース含めてみんな見てもよく、信頼できる
• みんなで同じビルド/リリース状況を確認したい

問題はこの範囲を超えるような場合です。

• 10人を超えるような人員がいる(11人だからわけないといけない、ということではないですが、10人超えると多分加速度的に増えていくんじゃないかなと思います)
• 自然にある程度の開発領域の分割が行われている
• 利害関係者と開発者は明確にわけたい
• 独自でビルドやリリース状況を監視しなければならない

ひとつのプロダクトを提供するためのチームではあるものの、あまりに情報が多くなると人間が受け止めるのが難しくなってきます。そういう状況で情報を整理する単位で分担するためのチームを作っていくといいのではないかなと思います。

もちろんできないこともあります。

• TFVC(Subversionのような中央管理式のバージョン管理)はチームプロジェクトに一つだけなので、複数のチームでも共有
• チームごとに開発プロセスを変更したい

二番目は特に、「うちのチームはこのテンプレートでは合わないんだよね、うちのチームだけはScrumにちょい足しした開発テンプレート使いたい」なんてことはできません。それはチームプロジェクト全体の設計です。チームは違っても開発プロセスは同じやり方を使う必要があります。

そんなことで、このチームプロジェクトには3つのチームが作られています。新規チームを作るには、右上のNew Teamをクリックします。

チームの名前、追加するメンバー(チームプロジェクトへ事前に追加しておく必要があります。もちろんAzure DevOpsグループを追加しても構いません)、チームの説明(任意)、管理者、権限(Azure DevOpsセキュリティグループなど)を指定します。

最後のCreate an area path with the name of the teamはあとで出てきますが、チームの名前がついたarea pathをこのタイミングで作っておくかどうかということです。これを作っておくとチームが分担する作業がどれかバックログとしてすぐわかり、莫大バックログの中から「うちのチームの作業どれだっけ」と迷子になることを防ぎます。

管理職やプロダクトオーナーの立場ではこのArea path単位で見ることにより、チームがどれくらいのタスクを抱えているのか、どのくらいのバックログを消化しているのかAnalytics Viewで見やすくなります。他のチームと混同しなくてもいいように、最初のうちはチームの名前でArea pathを作るとわかりやすいです。

チームで効率的に作業するための設定

チームプロジェクトでイテレーションとAreaを決めました。しかし、全チームのイテレーションやエリアが見えてしまうとせっかく情報を整理しようとしたのに、全部見えてしまって困ります。

そのようなチームだけが見えればいいバックログを整理するためにTeam Iteration/Areaだけをカンバンに表示できます。やり方はTeamアイコンのIterations and Area Pathsをクリックして、編集します。

チームエリア設定

まずはAreaを設定しましょう。初期状態ではチームプロジェクトのデフォルトで設定されているAreaのみ表示されます。

Select areaをクリックして、チームプロジェクトで登録されているAreaを選択します。複数選択可能です(余計なものが見えてますが気にしないで…)。チームプロジェクトで定義されているAreaから自分のチームの担当のAreaを追加します。なので、チーム作成時に使ったCreate New Teamの画面にあるCreate an area path with the name of the teamにチェックを入れておけば、作ったチームのArea Pathができているので、そのAreaを追加するだけで最初は事足りることが多いです。

イテレーション設定

同様にチーム独自のイテレーションを登録します。デフォルトではチームプロジェクトの最上位のイテレーションが登録されているので、選ぶのも大変ですし、カンバンに表示されるバックログも多くなります。ここでチームのイテレーションを設定しておくことで、カンバンに表示されるバックログの件数を少なくできます。

こんな感じで必要なイテレーションのみ登録すると、カンバンには選択したイテレーションのタスクやバックログのみ表示されます。「新しくバックログ登録したのに、カンバンに表示されない」という場合、バックログのイテレーションをここで登録していないことが原因なので、確認してください。

このDefault iterationはバックログやタスクを作るときに既定で選択されるIterationの値です。スプリントが切り替わったときに管理者がここを切り替えてあげるとタスク作るときに初期状態で選ばれるため、楽といえば楽です。現在のAzure DevOpsではカレンダー上の日付や登録状況から「このイテレーションじゃないかな？」と提案してくれますが、これをやっとくとみんなが楽になります。

おわりに

まずはチームとしての設定編で書きました。次はBoardsのカンバン関係の設定について紹介予定です。