はじめに
こんにちは、コンテナソリューション事業部の髙井です。
今日もみんな大好き ADO（Azure DevOps）について書いていきます。
初見ではわかりにくいプロジェクトの プロセス についてです。
スクラムに精通している人ならともかく「これからアジャイルっぽいことに挑戦するぞー！」という場合はなかなかとっつきにくいポイントなのかと思います。
そうした場合、最初に間違えて選んでしまったプロセスをあとから変えたくなったりすること請け負いです。
本記事では、プロセスの切替をメインに付随する概念の説明もしますので、切り替えをしない場合にも参考になればいいなと思って書いています。
プロジェクトのプロセス
ADOを使い始めようとすると、まずプロジェクトを作成する必要があります1。
そして、プロジェクトの作成時にプロセスを選択する必要があります。
名前から察しがつくとは思いますが、たとえばスクラム方式でプロジェクト管理をするなら [Scrum] を選択します。
ADOを使い始めていきなり選択するものなので、よくわからないまま適当に選んでスタートしてしまったというパターンも多いのではないでしょうか。
（訂正）ADO組織を作成して一番最初に作成するプロジェクトでは、そもそも強制的にBasicになる仕様でした。
新規作成の画面でも隠れている
一番最初のプロジェクトでなくても 新規作成の画面では設定箇所が隠れていたりする ので、あとからプロセスを変えたくなるシーンってそれなりにあるのではないかと思います。
プロセスをあとから変更するのはそれなりにめんどくさい
ADOでは、あとからプロセスを変更する機能がサポートされています。ただし、完全自動ではできません。
各プロセスで存在する作業項目（チケット）の構造が異なっており、うまく手作業で整合性を取る必要があります。
この手作業に関してMicrosoft Docsにページがあるため基本的にはそれを読めばよいのですが、読むのに少し前提知識が必要なので本記事で補足しようと思います。
ざっくり上記3点が分かればスムーズに移行できるでしょう。
Work Item Type（作業項目の種類）
まず、大きなポイントとしてWork Item Typeの違いがあります。日本語ドキュメントだと作業項目の種類と訳されていたりします。
たとえば、Basicのプロセスでは以下のような作業項目の構造になっています。
また、Scrumのプロセスでは以下のような構造になっています。
BasicからScrumに移行を考える際に、EpicとTaskは項目が共通していますが、IssueはScrumに含まれていません。
このように、移行先に存在しないWork Item Typeがあるとプロセスの移行は失敗します。
Inherited Process（継承されたプロセス）
移行先に存在しないWork Item Typeがあるなら、それらを追加してやればいいです。
しかし、システム組み込みで用意されているScrumプロセスに直接Issueタイプを組み込むことはできません。他のBasicプロセスを利用しているプロジェクトに影響が出てしまうからです。
そのため、Basicプロセスから派生させたプロセスを作ってそちらを改変します。
公式ドキュメントではInherited processだとか継承されたプロセスの種類と表記されています。
継承されたプロセスの作成
上で紹介したMicrosoft Docsにも記載がありますが、簡素な説明なため少し補足します。
冒頭のProject SettingsのProcess欄をクリックするか、Organization SettingsのProcessからプロセスの編集画面にいけます。
BasicからScrumならIssueを追加しますし、AgileからScrumに移行するならUser Storyを種類として追加します。
Work Item Typeを追加する際に、上記画面で [Create] するとフィールドの詳細設定に画面推移されますが、移行する目的を果たすだけなら詳細設定は省略して、プロセス切り替え実行に移ってよいです。
ただし、User StoryにおけるStory Pointsなどの情報を切替後も表示させ続けたい場合は、詳細画面でフィールドを手動で作成してください。
上記2枚の画像の差分を埋めるようなイメージです。[New group] で Plannning を作成して、そこに [New field] で Story Points を追加するなどしていきます。
いろいろ実験してみましたが、これらフィールドに入力していた値はたとえWork Item Typeを変えても消失しないようです。
たとえば、AgileプロセスでUser Storyを作成し、Story Pointsに値を入力し、フィールドを追加しないままScrumプロセスへ切り替え、さらにアイテムの種類をUser StoryからProduct Backlog Itemに変更しても値は消えませんでした。
その状態でProduct Backlog ItemにStory Pointsフィールドを追加すれば最初に入力していた値がちゃんと復元されます。
Workflow States（ワークフローの状態）
プロセス移行の山場は「継承されたプロセスの作成」で説明した部分ですが、実際に切り替えを行うと各ボードのカラムもプロセスごとに異なるため不一致となることに気付きます。
かんばんボード
Agileのかんばんボードは、New->Active->Resolved->Closedです。
Scrumのかんばんボードは、New->Approved->Commited->Doneです。
Scrumでは、Product Backlog Itemと同列でBugを扱うのがデフォルト設定です。
スプリントボード
Agileのスプリントボードは、New->Active->Resolved->Closedです。
Scrumのスプリントボードは、To Do->In Progress->Doneです。
AgileではTaskと同列でBugを扱うのがデフォルト設定です。
作業項目の状態を一致させる
このように、各プロセスでWorkflow Stateが異なり、それに伴い各ボードのColumnも異なるので、手作業で一致させる必要があります。
こちらは上で紹介したMicrosoft Docsに手順が細かめに載っていますので根本的に詰まることは少ないと思いますが、「AgileとScrumでそれぞれどんな状態があるんだっけ？」と作業中にいろいろ調べるのは面倒ですのでまとめておきました。
おわりに
このように、最初に選ぶシーンでミスりやすいプロセスですが、いったんプロジェクトが走り出してから「そもそもプロセスの選択がまちがってるっぽい！」と気付いて後から切り替えようとすると、そこそこ手間がかかります。
ADOではプロセスによってこのような機能の違いがある、ということが伝わるだけでもAzure DevOpsをぐっと使いこなしやすくなると思います。切り替え作業を行うことがなくてもプロセス周りの知識をご活用いただければ嬉しいです。
それでは、今回のところはここまで……え？こないだの記事で書くと予告していた「Application Gatewayを完全に理解する」はいつ書かれるのかですって？やー、書きたいことはいっぱいあるんですけどね。気長にオマチクダサイ……。
