"Boards(ボード)"は、開発の根幹を成す大切なサービスです。

プロジェクトを運営するにあたり、様々なスタイルがあります。
ウォーターフォールとかアジャイルとか。
これらを意識して、Azure DevOpsでは "プロセス" という設定を準備しています。
Azure DevOpsのBoardsはプロジェクト作成時に、どのプロセスで運営するかの選択が必要です。

選択肢によって、プロジェクトがデフォルトで扱える機能が少しずつ変わってきます。
自分でカスタマイズはできますが、できるだけデフォルトを使いこなして独自色を出さない方が、長い目でみたらチームの学習コストも下がりますのでベターです。
（「本気のプロジェクトはデフォルトのままプロジェクト作成しないでね」っていう矛盾を後で書きます。）

プロセスの種類

Basic

１番シンプルでフレキシブルなテンプレートが発行されます。とりあえずAzure DevOpsを使い始めるというときは、チームのメンバーがBoardsの基本的な使い方を理解するのに最適です。メンバー同士で作業を共有する程度の利用であれば、こちらで十分だと思います。

Agile

アジャイル開発を実施することを意識したテンプレートが発行されます。Basicのような(実際にはもっと細かくなった)作業についての情報に加えコードレビュー、テストやフィードバックについての情報なども取り扱います。

Scrum

スクラム開発を実施することを意識したテンプレートが発行されます。Agile同様な情報をScrumらしく取り扱えるようにしてあります。(差異は別途)

CMMI

CMMI(能力成熟度モデル統合)を意識したテンプレートが発行されます。より厳密な問題管理・変更管理・リスク管理等を実施したい（していることを表現したい）場合は有効です。

プロセス間の差

各々のプロセスが、デフォルト状態でどのようになっているのかを確認したいと思います。
（Azure DevOpsは随時機能が更新されていくため、現時点でのお話しです）

ざっくり－細かい

ざっくり： Basic <-> Agile/Scrum <-> CMMI ：細かい
Basicはできることがシンプル、AgileとScrumは言葉の差異と予実管理面に差があります、CMMIは変更管理等について細かくなっています。

Basic は主にタスク管理

Basicプロジェクトの"Work Items"で画面中央"＋New Work Item"をクリックしてみました。
選択できるのは"Epic""Issue""Task"の３つです。
参考までに、実際に入力してみます。（中身はてきとうです）

この３つに加えて、テスト管理ができますが、とりあえず省略しています。
Basicは、いつ誰が何をするのかを可視化することができます（それくらいしかできないとも言えます）

Agile はアジャイル開発を意識したつくり（当たり前ですが）

選択できるのは"Bug""Epic""Feature""Issue""Task""Test Case""User Story"の７つです。
こちらも実際に入力して表示してみます。（中身はてきとうです）

Agileは、いつ誰が何をするのかに加え、バグやテストを意識しています。アプリケーションを構築する上では管理すべき対象です。
またIssueとして、チームがプロジェクトを遂行する上で管理すべき問題や懸念に関しても意識的に管理することができます。

余談ですが、Issueを"杞憂"も書いて良いとする雰囲気作りをおすすめします。
笑ってクローズできるIssueをたくさん書く文化があると、実は見過ごしてはいけないものを検知できることがあります。
この雰囲気作りができていると、後からコソコソと「やっぱり起きると思ってたんだよ、あの問題」という発言を排除できます。プロジェクトに一体感が出てきて、問題が起きた時に犯人捜しや批判の応酬を未然に防ぐことができます。

Scrum はスクラム開発を意識したつくり（こちらも当たり前ですが）

選択できるのは"Bug""Epic""Feature""Impediment""Product Backlog Item""Task""Test Case"の７つです。(画面はAgileとほぼ同じなので省略)
こちらも実際に入力して表示してみます。（中身はてきとうです）

細かくは違うのですが、とりあえずAgileと同じで言葉が違うくらいに記憶いただければ今は良いと思います。

CMMI はCMMIを意識したつくり（こちらも当たり前ですが）

選択できるのは"Bug""Change Request""Epic""Feature""Issue""Requirement""Review""Risk""Task""Test Case"の１０こです。
こちらも実際に入力して表示してみます。（中身はてきとうです）

CMMIなので、チームの今の状況（カオスなチームなのか、指示されれば全員が動けるのか、自立してチームが動いているのか）を記録し可視化、今後の成長のために何をしていくのかをガチガチに管理していくこととなります。

管理の拡張に備える

基本的には、Azure DevOpsがデフォルトで備えている機能で問題なくプロジェクトはまわせると思います。しかしながら、過去の慣例から項目追加等の対応が必要となることが多くあります。
しかも、そういう情報はプロジェクトが始まってからチームの外部からもたらされます。
（端的に言いますと、厄介ごとは後から持ち込まれるといっています）

そのような変化に対応するため、プロセスの拡張がしやすい状況を作っておくことをおすすめします。
もちろん後からでも設定できますので、よくわからないうちは、デフォルトのまま使っていただけたらと思います。

プロセスの継承

Azure DevOpsでは、元となるプロセスを指定して、それを拡張するという作業を行います。

組織全体を見る画面に遷移する

Azure DevOpsは、"組織(Organization)"という単位で１回まとめて、その下に個々の"プロジェクト"をぶら下げるという形でプロジェクトを管理しています。
全体的なプロセスとかユーザー登録とかは"組織"に設定します。
左上の"Azure DevOps"というところをクリックしてください。

"Organization Setting" をクリック

拡張したいプロセスを選択して"Create inherited process"をクリック

拡張プロセスの作成

できました。

プロジェクト作成時にも、選択肢として現れます

まとめ

"Boards" でプロジェクトを管理する場合、どのようなプロセスで仕事をまわすのかを決める必要がある
BasicプロセスからCMMIプロセスまで、デフォルトで４種類の選択肢が提供されている
どれかのプロセスをベースにして拡張したプロセスを生成することができる

Azure DevOps Boards(ボード)で扱うプロセスには種類がある