Azure DevOps Boards(ボード)の超概要
↑超概要についてはこちらで触れております。
今回は、実際に "Boards(ボード)" への登録をおこない、どんな項目が存在するのかを確認したいと思います。
新規プロジェクトを作成
Agile プロジェクトを作成します。
Azure DevOps Boards(ボード)で扱うプロセスには種類がある
↑プロジェクトのプロセスについてはこちらで触れております。
Epicを扱えるように設定変更する
Agileプロジェクトのデフォルト状態ではEpicの扱うがオプション（基本的には使わないでしょ）という雰囲気になっています。
登録はできるけど、Backlog等における可視化は意識されていない状態です。
今回は、Epicも取り扱いたいと思いますので、まずは設定変更します。
場所はこちら。左下の "Project settings" から、 "Team configuration" を選択します。
"Backlog navigation levels" という項目の "Epics" のチェックを入れます。
特に保存等は無く、チェックを入れた時点で設定変更が反映されます。
他の設定については今回は触れません。
実際の登録
それでは実際にWork Itemを登録していきたいと思います。
（画面の中の項目は、現時点での項目です。）
登録作業は、Excelも含め様々な場所から実施できますが、今回は "Work Items" からの登録を行います。
Epicの登録
Epic登録時の必須入力項目は"タイトル"のみです。
その他項目については、具体的にわかる範囲をわかった段階で記載していけば問題ありません。
それでは１つ１つの項目についてみていきましょう。
| No. | 項目名 | 説明 |
|---|---|---|
| 1 | Title | Work Itemのタイトル、255文字以内で入力します |
| 2 | Assigned To | 対応者がアサインされたら選択します |
| 3 | State | Work Itemのステータス、はじめは"New"で、作業を進めるにつれて変更していきます |
| 4 | Reason | ステータス変更の理由、基本的にはデフォルトで表示されるものを使います |
| 5 | Area | "エリアパス"を定義している場合に選択します |
| 6 | Iteration | 対応する"イテレーション"を選択します |
| 7 | Description | Work Item の説明、Epicの場合だと、実現したいビジネス要求をザックリと記載します |
| 8 | Discussion | Descriptionに対して議論の内容を記載します。@マークでメンションしたりできます（直接会って話す場合も、議論の過程を各々が書き込みながら進めることをおすすめします。これが要求仕様の根幹となるため、経緯を残すというのは大切です。） |
| 9 | Priority | 1(高)～4(低)で選択します。ビジネスの目線で優先度を決めるのがポイントです。(1～4の基準は表下に記載) |
| 10 | Risk | このEpicに内在するリスク。うまくいかなくなる可能性がある場合に、その度合いをHigh/Medium/Lowから選択します |
| 11 | Effort | 相対的な見積もりを数値で記入します。(詳細は表下に記載) |
| 12 | Business Value | このEpicがリリースされた場合にビジネスに与えるインパクトを、他のEpicとの相対値で記入します。数値が大きいほどインパクトも大きいと考えます。通常、このような情報はバックログアイテムの優先順位で決めますが、そうではないパターンを採用する場合に利用します |
| 13 | Time Criticality | リリースまでに時間がかかるとビジネスバリューはどうなるのかを検討し、時間が経過すると価値を失うEpicは大きな値を入力します |
| 14 | Start Date | 予定開始日(もしくは実際の開始日)を選択します |
| 15 | Target Date | Epicの完了予定日を選択します |
| 16 | Value area | ビジネス目線の価値訴求を意図したEpicなのか、アーキテクチャ目線でビジネスの価値訴求をサポートするためのEpicなのかを選択します |
| 17 | Development(Add link) | 関連するリポジトリを選択します |
| 18 | Related Work(Add link) | 関連するWork Itemsを選択します |
| 19 | 切り替えタブ | 履歴等を見るタブへの切り替えをおこないます |
| 20 | タグ | 任意のタグを付与することができます |
| 21 | Save(Save & Close) | 保存ボタン |
| 22 | 補助メニュー | "Save"以外にもWork Itemの種別変更、削除や移動などWork Itemそのものの性質を変更することができますので、それらのメニューが入っています |
Priorityの参考基準
１：これが無いと製品として成立しないし、可及的速やかに対処しなければならない
２：これが無いと製品として成立しないが、すぐに対処しなくてもいい（デフォルト）
３：やれるときにやる
４：取り急ぎ対処しなくてもいい
EpicのEffort
数値は工数ではなく、プランニングポーカーなどを使って算出したストーリーポイント等を記載することが好ましいです。ただし、User Storyほど具体的なストーリーポイントの算出はできません（Epic記入時には中身は決まってません＝見積もり不可能です）ので、ビジネス目線で見た"当てずっぽう"でかまいません。ほかのEpicとの感覚的な差を表現ください。またEpic同士の比較ですので、配下のFeatureを合算した値になるとか、その配下のUser Storyのストーリーポイントの合算になるとか意識しなくても結構です。
このあたりは、会社やチームの特性にもよると思いますので、適宜みなさんが扱いやすい形でご利用ください。（もしくは使わないでください）
Featureの登録
Epicと同じですので省略
User Storyの登録
User Story登録時の必須入力項目も"タイトル"のみです。
その他項目については、具体的にわかる範囲をわかった段階で記載していけば問題ありません。
追加で説明が必要な項目は２つです。
| No. | 項目名 | 説明 |
|---|---|---|
| 1 | Acceptance Criteria | User Storyを完遂できていると判断できる条件を記載します。何ができなければならないのか、何ができてはいけないのかを具体的に記載します |
| 2 | Story Points | プランニングポーカーなどを用いて導き出した他のUser Storyとの相対的な見積もり値を記入します。当該User Story開始前に、ストーリーポイントが見積れるようにDescriptionとAcceptance Criteriaを詳細につめます。その時の模様はDiscussionに残します。 |
Taskの登録
Task登録時の必須入力項目も"タイトル"のみです。
その他項目については、具体的にわかる範囲をわかった段階で記載していけば問題ありません。
追加で説明が必要な項目は５つです。
| No. | 項目名 | 説明 |
|---|---|---|
| 1 | Activity | なに系の作業なのかを選択します。種別ごとに見積もりを行いたい場合には選択します(選択肢は表下に記載) |
| 2 | Original Estimate | 元々の見積もり時間、もしくは日数を記入します。 |
| 3 | Remaining | 残りの作業を完遂するに必要だと思っている時間、もしくは日数を記入します。作業中、こちらは日々更新していきます。 |
| 4 | Completed | 完了した作業に関して消費した時間、もしくは日数を記入します。作業中、こちらも日々更新していきます。 |
| 5 | Integrated in Build | バグに関するビルド名を記入します（が、テスト関係を理解する必要があるので、とりあえず放置で良いです） |
Activityの種別
- Deployment ： リリースやデプロイに関わるタスク
- Design ： 設計に関わるタスク
- Development ： 製造に関わるタスク
- Documentation ： 文書作成に関わるタスク
- Requirement ： 要件決めに関わるタスク
- Testing ： テストに関わるタスク
まとめ
主要なWork Itemについて、項目の説明をしました。
コツは
- 項目をカンペキに埋めようとしないこと
- チームにとって有益な項目は、必要なタイミングまでに埋めること
- 管理でご飯を食べる人のために項目を埋めないこと
です。