目次
本記事は前編と後編に分けてお届けいたします。
前編と後編を合わせた記事の目次は以下の通りです。
- 前編
- はじめに Azure DevOps について
- スクラム開発をAzure Boardsで管理する
- プロジェクト作成時にプロセスを設定
- ポートフォリオバックログどうなる？
- プロダクトバックログどうなる？
- リファインメントどうなる？
- 後編
- スプリントプランニングどうなる？
- デイリースクラムどうなる？
- スプリントレビューどうなる？
- レトロスペクティブどうなる？
- まとめ
このページは後編となっていますので、まだ前編をお読みでない方は上記リンクから前編にご移動をお願いします。
スプリントプランニングどうなる？
スプリントプランニングで行われる作業で大事なことは以下の３点です。
- チームのキャパシティを明らかにする
- スプリントバックログを作成する
- スプリントで取り組むプロダクトバックログアイテムを選択する（コミットメント）
チームのキャパシティとは、チームのメンバーが稼働できる時間の合計です。
スプリントバックログの作成とは、プロダクトバックログアイテムをさらに詳細なタスクに分解して作業時間を見積もる作業です。
チームのキャパシティがスプリントバックログのタスクの作業時間以内に収まればコミットメントとなります。
これらの作業は以下のような計算式が組み込まれたスプレッドシートを作成し共有していました。
書きだしたタスクは Backlog のチケットを作成する必要がありましたので、地道にコピペで転記していました。
また、さらに付箋にタスクをすべて書き出してホワイトボードにも貼り付けていました。
これがなかなかの手間。いつも「これ、地味に大変そうだなー」と開発チームの作業を眺めていました。
これらの情報・作業はすべて Azure Boards で完結できます。
まずチームのキャパシティは Sprints メニューの Capacity 画面で管理します。
Capacity 画面では、チームのメンバーの一覧が表示されます。
※出典： Microsoft Docs
表示されていないメンバーがいれば「Add user」で追加してください。
主な入力項目は以下の３つです。
Teams days off：開発チーム全体の休日をカレンダーで設定します。土日以外の祝日や年末年始などを設定します。
Days off：個々の開発チームメンバーの休日をカレンダーで設定します。休暇をとる場合に設定します。
Capacity per day：開発チームメンバーが1日に稼働できる時間を設定します。
※Activityという項目は、開発チームのスキルセットが異なっていて対処できないタスクがある場合に使うと良いそうです。
スプレッドシートで管理していたときはスクラムイベントの所要時間や個々のスクラム以外の稼働を細かく入力して管理していましたが、Azure Boards の Capacity per day では「1日にだいたいどれくらい稼働できるのか？」という緩めの管理になってしまいました。でも、もろもろを加味した数値を Capacity per day 入れれば大丈夫ですので、これはこれでシンプルになって良いかなと思いました。（もともと機械のように時間通り動けるわけではないですので）
つづいてスプリントバックログを作成する方法です。
スプリントバックログを作成する前に、プロダクトバックログアイテムをスプリントに割り当てる必要があります。
プロダクトバックログアイテムをスプリントに割り当てるのは Backlog という画面を使います。
画面右側に Planning というペインが表示されますので、その中のスプリントに各プロダクトバックログアイテムをドラッグアンドドロップします。
この操作でスプリントとプロダクトバックログアイテムを紐づけることができます。
スプリントバックログは Taskboard 画面で作成できます。
[＋]ボタンで、プロダクトバックログアイテムにタスクを作成し、タイトルと見積工数を入力していきます。
タスクの割り方は、1日程度で終わるレベルの粒度になるように作成するがスクラム開発のコツです。
これでチームのキャパシティとスプリントバックログが作成できあがりました。
ここまで来ると、今回のスプリントでどこまで消化できるかが Work details とバーンダウンチャートで見通せるようになります。
まず、Work details は、Taskboard 画面の View Options から開くことができます。
Work details ではチームのキャパシティとタスクの見積工数の割合がバーで表示されます。
バーンダウンチャートは Analytics 画面で表示できます。
Remaining Capacity のチャートがチームのキャパシティです。
右上にはスプリントプランニングで設定した工数の合計である Remaining Work が表示されています。
どちらのグラフでも、スプリントにおけるチームのキャパシティ内でタスクをこなせるかどうかが判断できます。
タスクがキャパシティをオーバーしてしまう場合は、入りきらないプロダクトバックログアイテムをその次のスプリントに先送りします。
タスクがキャパシティを下回って余裕がある場合は、次の優先度のプロダクトバックログアイテムをスプリントに加えます。
ということで、スプリントプランニングは Azure Boards で十分に管理できることがわかりました。
キャパシティの把握と、タスクの見積もりのためにスプリントプランニングでスプレッドシートをつかってきましたが、スプレッドシートは使わなくてもよくなりました。
スプレッドシートから Redmine や Backlog への転記、付箋への書き起こし作業も削減できてこのあたりの効率化は大満足です。
デイリースクラムどうなる？
デイリースクラムは朝会です。
朝会はスクラム開発でなくてもやっていると思いますが、スクラム開発ではホワイトボードの前にいつも同じ時間に集合して、立ったまま短時間で行います。
Azure Boards のデイリースクラムは Taskboard 画面で実施できます。
新たに着手するタスクについては「In Progress」にドラッグアンドドロップして、「Unassinged」になっている欄に自分の名前を設定し「今日はこのタスクをやります」と宣言します。
すでに進行中のタスクについては、作業した分だけ数値が減るはずですので、残りの作業時間を更新しておきます。実績の入力は日々の終業時に行うのが良いでしょう。
タスクの進捗の遅れはデイリースクラムで報告されるべき問題ですので、予定通りに進んでいないことを共有しましょう。
ところで、プロジェクト作成時に選んだプロセスが「Scrum」の場合、タスクに対して「初期の見積時間」と「実際の作業時間」を入力することができないため、タスクの予実管理ができません。
以下の手順でタスクに予実管理用の項目を２つ追加しておくようにしましょう。
この手順によって、各タスクに初期の見積時間と実際の作業時間を入力する欄を拡張することができました。
並び替えもできますので、すきな位置に入力欄を移動してください。
項目を拡張したあと、作業時間は以下の要領で入力していきます。
※Taskboard 画面の各カードに表示・編集できるようにカスタムすることも可能です。
スクラム開発の初期の頃は、たいてい予定通りにタスクが消化できません。
レトロスペクティブ（振り返り会）でそれぞれのタスクで予実を振り返ることで見積精度の向上に役立てることができます。これらの情報はチームの成長のためには欠かせない情報ですので嘘偽りない入力を徹底しましょう。
さて、今まではホワイトボードの前に立ってアナログで実施していたデイリースクラム。この良さをそのまま維持したいということで、ホワイトボード替わりに大きめのモニターも購入してしまいました。
Taskboard 画面をフルスクリーンで開けば、いままでとほぼ同じようにデイリースクラムできます！
モニターは DMM.make の43インチ4K液晶モニターで約50,000円。
モニタースタンドは55インチのサイズまで対応しているもので約8,000円。
モニターを Wifi で表示できるようマイクロソフトワイヤレスディスプレイアダプターV2を約6,000円。
すべて Amazon で調達しましたが、個人でも普通に買えるくらいのお値段で済みました。
ということで、デイリースクラムも Azure Boards で対応できることが確認できました。
※ホワイトボードならちょっとした伝達事項を書いておくことができたりするので便利なのですが、Taskboard 画面ではメモは書けません。この点が不満な方は Dashboard 画面も併用するようにしてください。
スプリントレビューどうなる？
スプリントの終盤におこなう成果物を確認するミーティングです。
開発チームがデモや成果物を準備しておいて、プロダクトオーナーとステークホルダーがレビューします。
ここでは、受け入れ条件に合致したものかどうかを確認が行われるとともに、成果物に対するフィードバックが発生します。
リファインメントの場合と同じく Board という画面で臨みましょう。
スプリントで進行中のプロダクトバックログアイテムをひとつひとつ開いてレビューします。 
成果物に対してフィードバックがあれば「Discussion」に入力していきます。
同じスプリント期間内で対応できるものであればタスクを追加して、追加の作業を実施します。
対応できない場合、そのプロダクトバックログアイテムはミッション失敗です。次のスプリントに繰り越しましょう。
スプリント内にフィードバックの対応が終わるか、成果物が問題なければプロダクトバックログアイテムを「Done」に移動しましょう。
こんな感じで、スプリントレビューも Azure Boards で問題なく対応できることが確認できました。
レトロスペクティブどうなる？
レトロスペクティブは、スプリントの振り返り会です。
レトロスペクティブを開始する前には、これまでのスプリントの活動状況に関して客観的なデータを揃える必要があります。
たとえばバーンダウンチャート、ベロシティ、完了したタスク数、完了したバックログアイテム数などなどの情報です。
これまでは情報を視覚化するためにレトロスペクティブの直前にスプレッドシートに転記して一苦労していましたが、Azure Boards であればその必要はもうありません。
まずはベロシティ。チームのパフォーマンスの変化を視覚化できます。
Boards メニューの Analytics 画面から「View full report」を選択します。
「Velocity by」の項目を「Suｍ of Effort」にすることで、直近のスプリントにおいてストーリーポイントをどれだけ消化できたのかが視覚化できます。
同じ開発チームのメンバーであれば、一定のストーリーポイントの消化が安定して維持できるようになっていくはずですので、チームが現在良い状態なのか悪い状態なのか容易に判断できます。
つづいてバーンダウンチャート。日々のタスクの進捗状況を更新していれば、まったく手間がかかりません。
Azure DevOps Demo Generator を使うと、さまざまなチャートをダッシュボードに張り付けたサンプルプロジェクトを生成することができます。
以下は SmartHotel360 のサンプルプロジェクトのダッシュボードです。
たくさんのチャートのサンプルから気に入ったチャートを自分のプロジェクトで真似してみましょう。
Microsoft Docs には Widget catalog というページがあって、さまざまな Widget が紹介されています。
ひととおりの情報はそろえることができましたので、あとは会議の進行です。
Azure DevOps には Retrospectives という無料のエクステンションが公開されています。
これをつかうことで KPT から Work Item を作成し、対応状況のトラッキングもできます。
以下はレトロスペクティブの作成時の画面です。とりあえず Keep、Problem、Tryの３カラムで作成してみました。
以下は、それぞれのカラムにメンバーの発言を記録した場合のサンプルです。
レトロスペクティブの画面には４つのタブがあります。
Collect：メンバーの発言を記録します
Group：似通った発言をグループ化できます
Vote：各発言にたいして投票ができます
Act：会議の結果決まったことからWork Itemを作成できます
レトロスペクティブでもスプレッドシートの出番はなくなりました。
至れり尽くせりで素晴らしいです。
まとめ
さて、前編・後編の二回にわたって、Azure DevOps の Azure Boards をご紹介いたしました。
Azure Boards がなかなか使えそうだと思っていただけたらうれしいです。
いい話ばかりしてきましたが、少し残念な話もここで１つ。
Azure DevOps Services は画面を日本語表示させることができません。
それだけではなく、Azure DevOps のドキュメントも英語しか用意されていません。
日本語による Azure DevOps の紹介記事も少ないので、正直に言ってキツかったです。
しかし日本語化されていない、日本語の情報が少ない、こんなことは Azure DevOps の持っているポテンシャルを考えれば些細なことで時間が解決する問題です。Azure DevOps に統合され一元化されることによって、管理面・教育面では大きなメリットがあります。
Azure DevOps には底知れぬ奥深さがありまして、まだまだ学習中です。
これからも引き続き Azure DevOps を学び、役に立つ情報のご紹介を続けていきたいと思いますので、どうぞご期待ください。
そういえばスプレッドシートの話が残っていました。
スプレッドシートはプロダクトオーナーによるポートフォリオバックログで引き続き使っていきますが、スクラムマスターと開発チームはスプレッドシートから解放され、退屈な転記作業を大幅に削減できるようになりました！
～ecbeingでは スクラム開発と Azure DevOps に興味のあるエンジニアを大募集中です！～
careers.ecbeing.tech
