チームの状況の透明化のためのAzure DevOpsのダッシュボードおすすめ構成
･ﾟ｡:.ﾒﾘｰｸﾘｽﾏｽ(ﾉ｡･ω･)八(｡･ω･｡)八(･ω･｡)ﾉ由･ﾟ｡:.
Azure DevOpsのアドカレ24日目に参加させて頂きました。
クリスマスイブの本日は、チームの作業状況の透明化に役立つおすすめのAzure DevOpsのダッシュボード構成をご紹介したいと思います。
この前お仕事でスクラムでの作業状況の共有はどうあるべき？そのためにAzure DevOpsでどんな構成ができる？というお話をしていたので、その時話していたことを基に書いてみました。
スクラムにおける作業状況と進捗の共有
ダッシュボードのおすすめ構成の話に入る前に、スクラム開発において作業状況や進捗の共有はどうあった方がいいのか、ということを確認してみます。
スクラムの本質的なマインドセットや価値基準を表すいわゆる三本柱、5つの価値基準はScrum Guide 2020では以下のように定義されています。
-
三本柱
-
5つの価値基準
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチーム
は、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチ
ームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに
能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。スク
ラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
透明性を実現するためには、全てのチームメンバーが、プロジェクトの進行状況、問題点、利用可能なリソースに関して完全な情報を持っている必要があります。
バックログ、スプリントゴール、進行中の作業がリアルタイムで全員に見える形で公開、共有することによって透明性が実現できます。
また、常に状況が透明化されていることによって即座に問題の特定と、改善のためのアクションを即座に実行できる適応が実現されます。
一言でいうと、スクラムでの作業状況の共有は 「いつ、だれでも、チームの状況がリアルタイムに確認できる」状態であるのが望ましいといえるでしょう。
おすすめAzure DevOpsのダッシュボード構成
Azure DevOpsでは、チームの作業状況（進捗状況、生産性、テスト状況、ビルド状況）を可視化できるダッシュボード機能が提供されています。
このダッシュボード上で、様々なメトリクスを構成できるようになっています。
画面上部のEditを押下して、
Add Widgetからお好きなメトリクス等の追加ができます。
Editを押下した状態だと、以下のように追加したWidgetをドラッグ&ドロップで移動できたり、
Widgetの⚙を押下すると、Widgetの名称変更やダッシュボードに表示する際のサイズ、表示するフィールドの編集ができます。
スクラム開発で作業状況の共有のためにダッシュボードに追加する場合、この辺がいいかなと思います。
Sprint Goal
これは作業状況を表すわけではありませんが、個人的にこのダッシュボードで見せている作業状況は何に向かっての作業なのか分かったほうが内容を読取りやすいと思うので、個人的にはSprint Goalを追加すると良いかなと思います。
進捗状況の透明化
Burndown（現在のSprintでのその日時点での残作業）
残りの作業量と経過した時間の関係を表し、チームが 現在のスプリントの計画を完了するために順調に進んでいるかどうかを判断できます。
- 縦軸（Y軸）：残りの作業量（例えば、ストーリーポイント、タスク数、または時間）。
- 横軸（X軸）：時間の経過（通常、スプリントの日数またはマイルストーンまでの時間）。
オレンジのTotal Scopeは、スプリントの開始後に追加された作業項目の数を、グレーのIdeal Trendは、作業項目の数、スプリントの日数、および稼働日数に基づいて計算された理想的な進み具合です。
青は現在のSprintで計画されたwork itemに対して見積もられたRemainingのその日時点での合計値が表示されます。
上手く進んでいる場合、スプリントでの作業を見積もるプランニングを行うスプリント開始日にBurndownの青はMaxになって、そこからスプリントで作業が進んでいくので、最終日に向かって徐々にチャートが下降していって、最終日には上記の図のようにゼロになります。
逆に、最終日まであと2日しかないのに全然下降してなかったり、前日からの減りが少なすぎる場合はなんらかの理由で作業が計画通りに終わっていない為、再計画が必要ですし、スプリントの途中で急激に青が上昇していたら、当初の想定外のタイミングで作業量が増えていることになるため、計画時点での見積もり誤りか割り込み作業が入った事を疑った方がいいかなと思います。
Sprint Capacity（現時点でのSprintでのCapacity）
現在のスプリントのチームのキャパシティが棒グラフで表示されます。
Azure Boards > SprintsのCapacityで以下のように各メンバーの今回のSprintでのCapacity（１日当たり何時間働けるか）を設定すると、
TaskboardのWork detailsを選択したときに、
こんな感じで現時点でのチーム全体のスプリントでの作業可能時間が表示されます。
このSprint CapacityのWidgetを追加すると、チームの現時点でのスプリントでの作業可能時間
がダッシュボードで表示され、気が付いたらCapacityオーバーしてた！このままじゃ間に合わない！という事態を防ぐことができ、無理な計画の回避や早期の再計画が可能になります。
CFD(Cumulative Workflow Diaglam: 累積ワークフロー図)
各Stateにいる作業項目の数を表します。
- 縦軸（Y軸）： 累積された作業項目数
- 横軸（X軸）： 時間の経過（通常は日付）
各色分けされたゾーンは、ワークフローの異なる段階（例：To Do、In Progress、Done）を表します。ゾーンの幅は、その段階にある作業項目の量を示します。幅が広いほど多くの項目がその状態にあります。
このゾーンが均等に平行であればあるほど、作業項目は一定の時間を掛けて順調に次のstateに移っているため、作業フローは安定しています。
特定のStateのゾーンが突然広がっている場合は、その段階で作業が滞留していることを示し、ボトルネックが存在する可能性があります。
CFDをダッシュボードに構成することで、開発プロセスの流れの中でボトルネックや滞りが発生している場所を特定できます。
これにより、チームは問題に素早く対応し、プロセスを改善することができます。
開発生産性の透明化
Lead TimeとCycle Time
この2つはDevOpsやアジャイルの文脈で開発の生産性を測る代表的な2つのメトリクスです。
Laed Timeは作業項目が登録されてからDoneになるまでの時間を、Cycle Timeは実際に作業が着手されてからDoneになる時間を表します。
これもCFDと同様に、異常に長いリードタイムやサイクルタイムを観察することで、プロセスのどこに問題があるのか、どこがボトルネックになっているのかを迅速に識別できます。
これにより、早期に介入し、プロジェクトの遅延を防ぐことができます。
また、リードタイムとサイクルタイムのデータを基に、将来のプロジェクトやタスクの所要時間をより正確に予測することができるようになります。
これはリソース計画、スケジューリング、クライアントへの納期のコミュニケーションにおいて非常に有用なデータになります。
Velocity
VelocityはSprintでDoneにしたPBIのEfforの合計を表し、チームがそのSprintでどれだけの作業量をこなせたかを表します。
これもLead Time, Cycle Timeと同様に、チームが将来のスプリントでどの程度の作業を完了できるかを予測できます。これは、プランニングとリソースの割り当てに役立ち、リアルな期待値を設定するのに役立ちます。
さらにAzure DevOpsではAzure BoardsでforecastingというVelocityに基いてBacklogのPBIが実行できるSprintを予測してくれる機能があるので、この機能のinputとしても、現実を反映したVelocityをトラッキングできることはメリットになるかなと思います。
forecasting機能は、Boards > BacklogsのView OptionsからForecastingをonにして使用できます。
１つのSprintでのVelocityを設定することによって、
以下のようにBacklogsに登録されたPBIが、どのSprintで実行可能か予測してくれます。
その他リスク管理等
これはお好みですが、上記のようなチームの作業状況やパフォーマンスに加えて、以下のような一覧も、作業状況や要検討事項を常にトラックできるようにダッシュボードに構成するとよいかなとおもいます。
ChangeRequest一覧
リスク一覧
課題一覧
バグ一覧
これらは、Bug以外はカスタムで作成したwork itemです。
カスタムのwork itemの作り方はこちらの記事をご覧ください。
これらをBoards > Queriesで以下のような条件でwork item typeを指定し、まだDoneになっていないitemを抽出するクエリを作成し、
ダッシュボードでQuery ResultsのWidgetを追加して、
Widgetの設定から表示するクエリを選択して追加できます。
まとめ
Azure DevOpsのダッシュボードで上記のようなメトリクス等をWidgetとして構成することによって、チームの状況を透明化することができ、早期に問題の特定と適応が可能になります。
また、作業状況の透明化によって状況共有の会議を頻繁に開催したり、そのための資料作りに追われなくなるというメリットもあります。
Other Reference
Azure DevOpsのダッシュボードで構成できるWidgetのカタログがMSのDocsで提供されています。
こちらも是非ご覧ください
Discussion