Azure Boards 入門時の Choose a process
Azure DevOps のプロジェクトマネジメント機能である Azure Boards では、要求、バグ、タスクなどのソフトウェアエンジニアリングで扱う項目を Work item という単位で扱うことができます。 Work item に相当する情報は、類似のツールで "チケット", "Issue" と呼ばれることがあります。 Azure Boards では、何という Work item を設けるかを定義し、どの画面で表示するのかを決めることができます。 この設定を工夫することによって Azure Boards を使う組織全体の活動効率向上が期待できます。
Azure Boards 入門時には、概要を理解した後に設定の工夫をすることになるでしょう。 その際に、私が思う最も理解しておくべきことが Choose a process というコンセプトです。 このコンセプトは Microsoft のドキュメントに書かれています。 これを理解できないと、同種のツールの経験があっても Azure Boards のことは何もわからないのではないかと思えるほどのコンセプトです。
何を理解すべきか順に説明します。
必ず4つの中から1つを選ぶことを理解する
Basic, Agile, Scrum, CMMI という4つのプロセステンプレートが用意されています。 プロセステンプレートによって用意されている Work item type が異なります。 Work item には State(状態) と Reason (状態遷移理由) があり、状態遷移もプロセステンプレートによって異なります。 テンプレートの内容をカスタマイズしたい場合は、カスタマイズの元をこれら4つから選んで継承し、新たなプロセスを作ります。 それぞれのプロセステンプレートを継承して my-basic, my-agile, my-scrum, my-cmmi を作ると次のような画面になります。
テンプレートを使わずにゼロから定義することはできません。
設定したい Work item type の名前やワークフローなどが既に頭にある方は恐らく面食らうことでしょう。私はそうでした。
カスタマイズするにしても必ず4つの中から選ばないといけないのです。
なので、実現したいプロセスに最も近いプロセステンプレートを選択することが有用になります。
Backlog level と Work item type と Work item 表示画面の関係を理解する
4つのプロセステンプレートの名前は Basic, Agile, Scrum, CMMI です。 選ぶ際に理解しておくべきことは、Backlog level と Work item type と Work item 表示画面の関係だと思います。
例えば Agile プロセステンプレートの場合、Work item type 同士の階層関係は以下のようになっています。
Boards 画面では、Feature を親として User Story を子とした表示か、または、User Story を親として Task を子とした表示かを選ぶことができます。Backlog level は Portfolio backlog または Requirement backlog です。
Backlogs 画面では 、Feature, User Story, Task の3階層をツリー形式で表示することができます。子を省略して Feature のみ、User Story のみの表示にすることもできます。Backlog level は Portfolio backlog または Requirement backlog です。
Sprints 画面では、User Story を親、Task を子とした表示ができます。Backlog level は Iteration backlog です。
このように、Work item の階層と Work item type と Work item 表示画面には関係があります。
Backlog level には、最上位の Portfolio backlog, 中位の Requirement backlog, 最下位の Iteration backlog の3階層があります。 Backlog level を3より増やすことはできません。各Work item 表示画面において扱える最大の階層数は3です。 親子関係の設定自体は何階層でも設定できますが、それがわかるようには表示されないのです。 例えば、Task の子に Task を設定することはできますが、Boards 画面でも Backlogs 画面でも Sprints 画面でも Task 同士の親子関係は表現されません。 なので、実現しようとしているプロセスにおける Work item type の階層数が3におさまるようにする必要があります。
3つの Backlog level に何の Work item type を当てはめるかの決定が必要であることを理解する
4つのプロセステンプレートにおける各 Backlog level に当てはめられている Work item type の名前は以下のようになっています。
- Basic では、Epic -> Issue -> Task
- Agile では、Feature -> User Story -> Task
- Scrum では、Feature -> Product Backlog Item -> Task
- CMMI では、Feature -> Requirement -> Task
Backlog level と Work item type の関係は設定することができます。以下は Agile を継承した my-agile での例です。
どれかがそのまま使えそうか、名前、フィールド、状態から考えてみましょう。 どれかが使えそうならさして悩むことはありません。
しかし、アジャイルプラクティスになじみがない場合は Epic, Feature, User Story, Product Backlog Item のどれもわからない、Requirement (要求) ならまだわかるが Requirement と呼ぶことは無いという場合もよくあるのではないでしょうか。 そのような場合は、Azure Boards を使おうとしている組織が扱う最上位の項目を何と呼ぶか、その項目と親とし Task を子とする項目を何と呼ぶか、組織における Task とは典型的には何かに向き合うことになると思います。 これは組織に Backlog level と Work item type という概念を初めて導入する機会になり得るため、熟慮すべき点だと思います。
また、Agile, Scrum, CMMI では Bug を Task と同列に扱うか、User Stocy, Product Backlog Item, Requirement と同列に扱うかを選択できます。 ここも一緒に考慮すべき点だと思います。 尚、この設定ではプロセステンプレートを設定する Organization Settings ではなく Project Settings にあり、迷いやすいのではないかと思います。
Epic, Feature などの用意された Work item type とは名前が異なるだけで内容自体は従来から組織で扱っているという場合は、既存の Work item type をリネームかコピーすればよいと思うかもしれません。 しかし、残念ながら Work item type のリネームとコピーは不可能です。 フィールドは既存のものと同じで名前が異なる Work item type を作るには、新規に Work item type を作り、同じフィールドを1つずつ作るしかないのです。
おわりに
以上、Azure Boards 入門時に、コンセプトの中から特に押さえておくべきと私が思う Choose a process について解説しました。 私は入門時に4つのテンプレートから必ず選ぶ、Backlog level は3階層までという点はなかなか理解できず苦労しました。 Azure Boards はググっても日本語情報が少ない印象です。 Azure Board を使い始める際に日本語で概要をつかむには以下の情報が有用だと思います。
合わせて本文も Azure Board 理解の一助となることを祈ります。
