Azure DevOpsは便利ですが、設定や用語を一から学ぶ必要があり、またセットアップを一からしていく日本語の記事があまりないと思うので、ちょうどAZ-400の勉強もかねてまとめてみます。
本記事はAzure Boards編です。
前提として、Scrum Templateを使っていきます。
Scrumの知識があると単語とかわかりやすいかと思います。
https://scrumguides.org/
（なお、貼っているスクショは新規かサンプルプロジェクトのものです。）
デフォルトでも使えなくはありませんが、意外とあまり知られていないカスタマイズすることでさらに使いやすくすることができます。
Boardsの設定
Project Settings、Organization Settingsから実施する設定類です。
Iterationを設定する
これはカスタマイズというより使い始めの初期設定の様なものです。
左下のProject Settings > Boards > Project configurationからIterationを設定します。今回は1 Iterationを2週間とします。
もう一か所、Project Settings > Boards > Team configurationにも反映されていることを確認します。（プロジェクト単位とチーム単位でIterationを異なる期間で区切れるようです。基本同期しているはずですが、念のため確認。)
Iterationの設定が完了したらBoardsが使えるようになります。
これはIterationの期間が終わったら毎回次のIterationをまた10個くらい作る必要があり、DevOps側で自動化してほしいところであります。
Processをカスタマイズしてみる
Organization Settings > Boards > Processにいく。
※Organization Settingsは左上のAzure DevOpsのロゴをクリックした状態で、左下の歯車アイコンを見てみるとOrganization Settingsに飛べます。
お前さっきまでProject Settingsやなかったんかい。。正直このUIはどうかと思う。
Azure DevOpsは前提として、一つのOrganizationに複数のプロジェクトを紐づけることができます。プロセスのテンプレートは共通のOrganizationの設定になります。
今回はデフォルトのTemplateのうちScrumを設定しています。Scrum TemplateではEpic > Feature > Product Backlog Item（PBI）> Taskという階層構造になっています。
デフォルトのプロセスは編集不可なのでここからデフォルトのプロセスを継承して独自のプロセスを作ることができます。
おすすめのカスタマイズポイントは以下です。
独自のItemの作成
デフォルトだけだと、「あれ、この作業はProduct Backlog Itemなのか？」と迷うような場面がありますが、Item Typeを追加することできます。例えば、
- PBIと同階層にScrum Event、社内業務
- タスクと同階層にQA（お客さんとのやり取り用）、Meeting
ScrumイベントやQA等開発以外のタスクにどれだけ時間がかけているか後々把握しやすくなります。
例えばScrumEventはPBIと同レベルに作るならBacklogLevelも設定してやります。
ScrumEventの配下用にMeetingを追加してやりましょう。
MeetingのStateはTaskと合わせて
LayoutもTaskに合わせて
Levelを合わせて
Sprints > Column Optionから適当に合わせて
ScrumEventがPBIと同レベル、MeetingがTaskと同レベルで作れるようになりました。
Taskの表示項目の変更
タスクはデフォルトだとこんな表示です。
ですがAzure DevOpsのWork Itemは裏で様々な値を持っており、表示・非表示はもちろん、追加・削除もすることができます。
ここではRemaining Work（残作業時間）しか出ていないので、All processes > [新プロセス名] > [Item名] > Layout > [New field] からOriginal Estimate（当初見積もり）とCompleted Work（作業済み時間）を追加しましょう。
これがあると、当初見積もりが4時間なのに、もう8時間作業している、メンバーの作業見積もりが甘いんじゃないかとか、色々気づきを得ることができます。（タスクの時間を毎日しっかり入力していることが前提ですが。）
PBIにテンプレートを設定する
PBIのDescriptionを初回作成した場合、最初は何を書けばいいかわからない人もいるかもしれないので、まずはテンプレートを表示するようにしましょう。
PBIのRuleをDescriptionが空の場合、テンプレートを表示するように設定します。
Thenには以下のように表示したいテンプレートをhtml形式で記載します。
<b>目的</b>
<br>
<br>
<b>背景</b>
<br>
<br>
<b>DoR</b>
<br>
<br>
<b>概要</b>
<br>
<br>
<b>成果物</b>
<br>
<br>
PBIの作成画面にテンプレートが表示されるようになりました。
Original Estimateを入れたら自動的にRemaining Workに値が入るようにする
入力項目が増えると人は嫌がるものです。Task作成時にOriginal Estimateを入れると自動的に値がRemaining Workにも入るようにしてあげましょう。ユーザーは後はCompleted WorkとRemaining Workだけを更新していけばよくなります。
※2024/07/05 書いていた設定に誤りがあったため修正しました。
（どうやらTask更新時に毎回チェックプロセスが走るようで、元のA value is defined for...だとRemaining Workを手動で更新すると、Original Estimateで上書きされてしまうようになっていました。）
なお、カスタムプロセスを作った後はプロジェクトでそのプロセスを利用するようにプロセスを変更する必要があります。
バグを要件として管理する
バグの管理の仕方を決めます。
おおざっぱに言って、バグを①PBIレベルで管理するか、②タスクレベルで管理するか、③それとも完全に別で管理するかということになります。
①の場合はPBIと同階層なので、SprintsやBacklogsに表示されるようになります。Bugの下にタスクを作ることができます。
②の場合はPBIの下にBugを作ることができるようになります。
③の場合は別管理なので、ボード類に表れなくなるようです。クエリで管理していくことになります。
業務では①しか使ったことがないのですが、バグはタスクとして管理するには複雑、大きすぎることが多く、PBIレベルでタスクをぶら下げて管理するほうが個人的には好きです。
各種ボードについて
初心者が参ってしまうのが、ボードの種類が多く、かつ違いが分かりづらいので、何をどこで表示、作成できるのかわからない、ということでしょうか。
個人的な使い方ですが、ざっくりこんな感じです。
-
Work Items：
Itemを全部表示したいときに使う。あまり使わない。 -
Boards：
PBI以上を一覧で表示する。が、Backlogsかクエリで見ればいいので、あまり使わない。 -
Backlogs：
主な使い方は2つ。
①右上の表示フィルタをEpicsにするとItemの階層構造を表示する。
②表示フィルタをBacklog Itemsにして、フィルタのParentsをOffにしてPBI（とバグ）の一覧を表示する。
ここで左にあるOrderがPBIの優先順位となるので、この画面を見ながらお客さんと話すことが多い。 -
Sprints：作業者やチームリードが見るのがここ。自分にアサインされているタスク、進捗状況の把握・更新に使う。
- Queries：WorkItemに対するクエリを実行できます。担当者、Iteration等すべての項目でフィルタリングが可能です。とてもよく使います。
-
Delivery Plans：PBIにIteration Pathを設定すれば使えるようになります。Microsoft Projectのようにガントチャートを作れます。
各種ボードの表示のカスタマイズ
デフォルトだとボードに表示したい項目がないときが多いので、表示してあげましょう。なお、これはプロジェクト単位で設定できないため、人ごとに設定する必要があります。
Backlogs
表示項目
上のColumn Optionsから表示したい項目を選ぶことができます。
Assigned To（担当者名）やWork時間、Estimate時間等用途に応じて表示しましょう。
Sprints
デフォルトだとAssigned toとStateしか表示されません。
Sprints画面の右上の歯車から、表示する項目を増やせます。
Capacity
毎Iterationの頭に1日に何時間プロジェクトにアサインされているか、休暇取る予定はあるか、等を入力します。契約上労働時間は8だとしても、8時間フルにプロジェクトワークできるわけではないので、6時間くらいにするのが無難でしょう。マネージャとかだともっと少なくてもいいかもしれません。祝日とかがある場合はTeam days offに入れましょう。
In Progressの後にIn Reviewを追加
※これはこういう事もできるよというご紹介です。レビューはレビュータスクとしてレビュワーをアサインするのが本来だと思います。お客さんやマネージャとかタスクがあるけどDevOpsでタスク管理していない場合は使えるかもしれません。
先ほど上で紹介したProcessのカスタマイズのところから、Taskを選択し、新たなStateとしてIn Reviewを追加します。
そのうえでSprints画面 > Column OptionsにIn Reviewというカラムを追加します。
In Reviewができました。
色々書きましたがこんな感じでしょうか。とりあえずこれでAzure Boardsの基本的なカスタマイズはできるようになったかなと思います。
カラムやWork Item Typeは自分勝手に作るのではなく、Scrumに則って作ってみるといいかなと思います。
その他おすすめ
こちらにも色々便利そうな設定が。