80
60

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2019-06-24

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

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

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

プロセスの種類

Basic

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

Agile

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

Scrum

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

CMMI

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

プロセス間の差

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

ざっくり - 細かい

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

Basic は主にタスク管理

20190621-1-1.png
Basicプロジェクトの"Work Items"で画面中央"+New Work Item"をクリックしてみました。
選択できるのは"Epic""Issue""Task"の3つです。
参考までに、実際に入力してみます。(中身はてきとうです)
20190621-1-2.png
この3つに加えて、テスト管理ができますが、とりあえず省略しています。
Basicは、いつ誰が何をするのかを可視化することができます(それくらいしかできないとも言えます)

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

20190621-1-3.png
選択できるのは"Bug""Epic""Feature""Issue""Task""Test Case""User Story"の7つです。
こちらも実際に入力して表示してみます。(中身はてきとうです)
20190621-1-4.png
Agileは、いつ誰が何をするのかに加え、バグやテストを意識しています。アプリケーションを構築する上では管理すべき対象です。
またIssueとして、チームがプロジェクトを遂行する上で管理すべき問題や懸念に関しても意識的に管理することができます。

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

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

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

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

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

20190621-1-6.png
選択できるのは"Bug""Change Request""Epic""Feature""Issue""Requirement""Review""Risk""Task""Test Case"の10こです。
こちらも実際に入力して表示してみます。(中身はてきとうです)
20190621-1-7.png
CMMIなので、チームの今の状況(カオスなチームなのか、指示されれば全員が動けるのか、自立してチームが動いているのか)を記録し可視化、今後の成長のために何をしていくのかをガチガチに管理していくこととなります。

おすすめは?

個人的な思いですが、日本では"Agile"をおすすめします。(以下は個人的な偏見です)

  • Basicでは機能が足りない
  • 日本だと予実管理みたいなことで安心したいマネージャーが多いので、Scrumだと機能不足となる可能性がある
  • CMMIを厳密に回し始めると、日本だとオーバーヘッドが大きくなって、そこでご飯を食べる人が増える可能性が高い

よって、Agileが1番良いのではないかと、個人的には思っています。

管理の拡張に備える

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

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

プロセスの継承

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

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

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

"Organization Setting" をクリック

20190621-1-9.png

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

20190621-1-10.png

拡張プロセスの作成

20190621-1-11.png
できました。
20190621-1-12.png

プロジェクト作成時にも、選択肢として現れます
20190621-1-13.png

まとめ

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
80
60

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?