Azure DevOps全体の概要については、こちらをご覧ください。
https://qiita.com/mstakaha1113/items/1cf45a5119e1397d0315
"Boards(ボード)"は、開発の根幹を成す大切なサービスです。
サービスとして何があるのかご紹介します。
超概要なので、具体的な画面の説明はありません。
"Boards"のメニュー
かなりザックリした説明になります。あえて抽象的な言葉で説明しています。
- Work Items : 作業の一覧です。自分に割り当てられている作業をすばやく見つけたい時などに使います。
- Boards : 作業をカード型で提示し、ドラッグアンドドロップでステータス更新できます。付箋紙に書いた作業をホワイトボード上に貼りだしたような見せ方です。いわゆる"Kanban(かんばん)"と呼ばれているもので、作業の流れを可視化します。
- Backlogs : こちらも作業の一覧です。Work Itemsは"個人"に主眼を置いていますが、こちらは"プロジェクト全体"に主眼を置いています。どんな要求があるのか、どんな作業があるのか、どんな順番で実施するのかを確認したり整理するときに使います。
- Sprints : こちらも作業の一覧です。Backlogsとの大きな差としては時間軸があります。Backlogsが"大きな流れ"に主眼を置くのに対して、Sprintsは"短期間に何をするのか"に主眼を置きます。
- Queries : クエリですので、自分たちにとって有益な条件で作業を見えるように絞り込むのに使います。
"Work Item(作業)"には種類がある
"Boards"は、プロジェクトを進捗させるために必要な様々なWork Itemを取り扱いますので、いくつかの種類が準備されています。
ここでは、とりあえず最初に覚えたい４つについて記載します。
- Epic : 最終的に何をなぜ提供したいのかを書きます。重厚長大なドキュメントを書くわけではなく、箇条書きにします。箇条書きの１項目を１Epicとして記載します。
- Feature : Epicを分解して、具体的な要求に落とし込みます。Featureを書いてみて、大きかったらEpicにしていく方が現実的です。
- User Story : Featureを形にする上で実際にやることが何なのか、実装ベースで記載します。アジャイル開発は短期間に小さな機能を完成させるという行為を繰り返します。この１単位期間でちょうど完成する程度の大きさを意識します。
- Task : User Storyを実現するための１つ１つの実際の作業を記載します。
はじめは、FeatureかUser Storyから書くことをおすすめします。自分の立ち位置が"想いを伝える側"であればFeatureから書き始め、Featureが大きいとか、複数の中身が詰まっていると感じたらEpicに変更して、さらに具体的な要求事項をFeatureとしてぶら下げるという順番で使いましょう。
自分の立ち位置が"形にする側"であればUser Storyから書き始め、それはどんな要求事項があるから存在するUser Storyなのかを考えてFeatureを書き出します。
場合によってはいくつかのFeatureの根幹が同じであることに気づくと思います。その時はFeatureをまとめるEpicを作成しましょう。
よくわからない場合は、全部User Storyとして書いてみてください。
記載内容をふんわりと眺めると、目線の高さが異なっていることに気づくと思います。
その違和感をベースにとりあえず各々の種別を変更します。
もう１度全体を眺めると、足りないピースが見えてきますので、埋めてください。
Taskは本当に実行する作業です。人が具体的に紐付くのは基本的にこのTaskです。
コツ
機能を中心に書かない
WBSを書く際、よく機能名を羅列して、その機能名ごとのタスク(設計とか製造とか)を並べるというようなことをするかと思います。
アジャイル開発では、機能が揃うことは結果論であって、はじめから決まっているわけではありません。
想いがあって、それを実現する手段が機能であると考えます。予算や期間、ニーズの変動に伴い、同じことを実現するにしても実装方法はいくつも存在します。
例えば"ユーザーの新規登録"は新規登録画面だけが手段ではありません。明日からユーザー登録を受け付けなければならないと決まっているなら、例えば必要事項を明記してメールを送ってもらうというのも、良し悪しは別にして実現手段の１つになりえます。
具体的な数値目標を据えるが、絶対条件とはしない
要件定義を実施する場合、非機能要件を中心に具体的な数値目標を記載したことがあるのではないでしょうか。
たとえば、"画面のレスポンスは３秒以内"みたいなものです。
これは大切な要件です。アジャイル開発であっても具体的な目標とすべき数値は据えます。
具体的な数値目標を与えることで、どう実現すべきか(そもそも夢物語なのか)が見えてきます。
ただし、"この目標を達成しなければならない"という絶対的な条件にするかどうか別の話題です。
基本的には達成することを意識しますが、アジャイル開発では失敗も糧にします。
ただ批判したり、個人攻撃をしたり、ベンダーいじめをするための数値目標として記載するのではなく、なぜ達成できなかったのかを建設的に話し合うための材料にします。
そして改めて、達成することが大切なのか、他の方式をトライするのか、全員で協議します。
余談ですが、目標達成可否判断とリリース可否判断は完全一致しませんので、ご注意ください。
たとえば３秒目標が４秒になっても、儲かるからリリースするという判断もできます。
まとめ
"Boards"をどう使うのかを学ぶと、アジャイル開発の基本的な考え方を学ぶことができます。
最初からうまくいくわけはありませんので、まずはUser StoryとTaskを使って実作業をまわしてみましょう。