Azure DevOps でスクラムを実現する

スクラムとは？

Azure DevOps の利用方法をご紹介する前にスクラムについて軽く触れておきます。

スクラムは実際のマーケットからのフィードバックをすぐにプロダクトへ反映させることを可能としたフレームワークです。
フレームワークの特徴は以下です。

• 固定された期間（スプリント）でプロダクトを開発します。
• 要求はプロタクトバックログという優先順位付けされたリストに保管されます。
• 役割、イベント、ルール、作成物が提供され、チームはこのフレームワークの範囲内で自分達のプロセスを作っていく必要があります。
• クロスファンクショナルチーム※である必要があります。

※ クロスファンクショナルチーム
部門あるいは会社を横断的に様々な経験・知識を持ったメンバーで構成されたチーム。

スクラムの役割、イベント、スケジュール

スクラムのフレームワークで提供されている役割とイベントの説明と、clouXion 開発チームの実際のスケジュールをご紹介します。

３つの役割

プロダクトオーナー：
開発が必要な機能を決定し、開発チームにプロダクトのゴールを示す役割を担います。機能の範囲や内容をまとめた「プロダクトバックログ」を管理します。スクラムチームから⽣み出されるプロダクトの価値を最⼤化することに責任を持ちます。

スクラムマスター：
開発を円滑に進めるための業務が主な役割です。スクラムがうまく回っているか、業務の障害がないかチェックし、スムーズに進められるよう調整を行います。スクラムガイドで定義されたスクラムを確⽴させることに責任を持ちます。

開発者チーム：
プログラムを実際に開発する役割を担い、数名のメンバーで構成されます。 各メンバーは専門分野を持つことが多いものの、開発で行われるどの役割も担える「多能工」であることが特徴です。 専門家として、開発手法や成果物に責任を持ちます。

スクラムイベントとスケジュール

clouXion 開発チームは 2週間を 1スプリントとしています。

スプリントプランニング：
スプリント初めにプロダクトオーナーと開発チームがスプリントプランニングを一緒に実施し、次のスプリントでどのプロダクトバックログアイテムを実装するかを検討します。

デイリースクラム：
毎日、同じ時間に同じ場所で開発チームは 15分～30分、スプリントのゴールに向けての 進捗状況を確認し、その日の計画を行います。

バックログリファイメント：
プロダクトバックログアイテムに対して、詳細な説明の追加、見積り、並び替えをします。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスです。clouXion 開発チームでは1スプリントに 2度（毎週）行っています。

スプリントレビュー：
スプリントの終わりに実施する、検査と適応の場です。ステークホルダーはチームがスプリントの中で何を作ったのかレビューします。開発者チーム、プロダクトオーナー、ステークホルダーが一体となってプロダクトの方向性を決めます。

レトロスペクティブ：
全てのスプリントはレトロスペクティブで終わります。 このイベントではチームは自分たちのふるまいやプロセスを見直し、次スプリントでの改善アクションを決めます。

役割、イベントは以下の記事が1枚に纏められていて分かりやすいです。

【参考】
スクラムの概要を 1分で理解できるイラスト【2018版】 | Ryuzee.com

各イベントでの Azure DevOps 利用方法

本題のスクラムにおいて実際どのように Azure DevOps を利用しているか、イベント毎に紹介していきます。

デイリースクラム

Azure DevOps の "Boards > Sprints > Taskboard" でタスク管理をしています。 9/15 〜 9/28 のスプリントを表示しています。
上図の は Product Backlog Item （以降 PBI）と呼ばれるものです。
上図では PBI を閉じて表示しています。

PBI とは？

• 顧客中心の機能要件であり、「どうやって (How） 」作るか？よりも「何を (What）」をするか、「何故 (Why）」必要かの説明をしている。
• PBI に特化した受け入れ条件が記載されている。
• 開発チームにより相対見積もりがされている。

上から下にいくにつれて優先度が低いものになります。 開発チームは優先度の高い、上側の PBI から着手することになります。

実際には PBI を開いて上図のようにタスクが見える状態でデイリースクラムをスタートします。
Taskboard を見ながらそれぞれのタスクの進捗を確認します。このタイミングで困っていること (進捗を妨げている障害) を発見し、解決に向けてお互いがフォローしていくように進めます。 議論が必要な話題が出た場合は、デイリースクラム後に関係者で話し合います。 clouXion 開発チームではすべての仕事を Taskboard で表現していますので、Taskboard さえ見ていればチームの状況が把握できるようになっています。他の進捗管理ツールを使用していません。

Taskboard で表現している仕事の例

• 問い合わせ対応
• マニュアルの更新
• リリース作業
• 機能開発
• 運用の建付け
• 事務作業 etc …

デイリースクラム時には Analytics タブを開いてバーンダウンチャートも確認します。バーンダウンチャートではチームの残作業量が可視化されていますので、スプリントが順調に進んでいるかの目安として確認します。Remailing Capacity ラインは Capacity タブで設定した個人の稼働出来る時間の合計になっています。Capacity タブについての説明は割愛します。

バックログリファイメント

Azure DevOps の "Boards > Backlogs> Backlog" で PBI を管理しています。 上図のリストをプロダクトバックログ※と言います。Taskboard 同様にこちらも上から下にいくにつれて優先度が低いものになります。プロダクトオーナー (以降 PO) によって優先度が並び替えられた PBI を上から順に開発チームが「どうやって (How）」作るか？を議論して着手可能な状態にします。その後、相対見積もりを行います。

• ※ プロダクトバックログ
  ロードマップと要件に基づいて開発チームが行う作業に優先順位を設定したリストです。

Estimate を使用して相対見積もりを行っています。 こちらは Azure DevOps の拡張機能であり、無料で入手することが可能です。Estimate はプランニングポーカー※を行うのに適したツールです。見積もり対象の PBI を選択し、Estimate work item(s) をクリックすることで見積りの画面に遷移します。

• ※ プランニングポーカー
  規模を相対的に見積もる手法のひとつです。何時間、何日といった絶対的な単位ではなく、他の PBI と比べてどのぐらいの規模か相対的に見積もります。 例えば、「A は 2ポイント、B は 2倍ぐらいだから 4ポイント」といった具合です。これを複数人のメンバーと話しながら行います。

見積もりはフィボナッチ数列を使っています。微妙な見積りの違いを避けます。 これは見積もりが大きくなるほど細かい差に意味がなくなるからです。

スプリントレビュー

そのスプリントで実施していた PBI について、受け入れ条件が満たしているか、あるいは完成の定義を満たしているか、関係者に対してデモンストレーションします。レビューの中で出てきた指摘について、軽微なものであれば同じスプリント内で修正します。大きな修正が必要な場合は新たな PBI を作成し、他 PBI も含めて改めて優先度を決定します。

開発チームは PBI 着手前に PO と受け入れ条件 (Acceptance Criteria) を固めて合意する必要があります。開発中に PO とコミュニケーションし、更新する場合もあります。

レトロスペクティブ

Azure DevOps の "Boards > Retrospectives" を使用して、レトロスペクティブ (振り返り) を行っています。 Retrospectivesは KPT 法※を実施するのに適したツールです 。こちらは Azure DevOps の拡張機能であり、無料で入手することが可能です。

• ※ KPT 法
  「Keep：成果が出ているので続けること」、「Problem：課題があり改善が必要なこと」、 「Try：新しく取り組むべきこと」の順に検討し、今後のアクションを決める。

スプリントプランニング

スプリントプランニング時にも Azure DevOps の "Boards > Backlogs> Backlog" を使用します。バックログリファイメントを経て優先度順に並び替えられた PBI を開発チームのスプリントバックログ※に移動してチームにアサインします。スプリントプランニングを経て、開発チームは新たなスプリントをスタートします。

• ※ スプリントバックログ
  現在のスプリント用に選択された PBI のリスト。

スクラム × Azure DevOps の Tips

clouXion 開発チームで使用しているいくつかの機能を Tips としてご紹介します。

自動入力で楽ちん

clouXion 開発チームでは以下のフィールドを使用しています。
「Original Estimate」：タスクの計画時間
「Remaining Work」：タスクの残作業時間
「Completed Work」：タスクにかけた時間（実績時間）

"Organization Settings > Bords > Process > 自身のプロセス（上図では Dragon Scrum） > Work Item（上図では Task） > Rules" にルールを設定することで、自動的に値を設定したり変更したりすることが出来ます。先ほど 3つのフィールドを使用しているとご紹介しましたが、Task を新規作成する際は「Original Estimate」「Remaining Work」が等しくなります。ですから、「Original Estimate」を入力したら「Remaining Work」に値をコピーするというルールを設定しています。作業者は 2つのフィールドに値を入力せずに済みます。このように Azure DevOps のフィールドであればルールを設定することで自動的に値を設定することが可能です。細かく設定をすることで作業者の負荷を下げることが可能です。

進捗の遅れが一目瞭然

Taskboard でタスクの進捗状況を見る際に、上図のように進捗に遅れが出ているタスクに色が付いていたら分かりやすくなります。タスクの更新が 1日滞っていた場合、色を付けるルールにしています。実際の設定は以下です。

Taskboard の右上にある歯車アイコンをクリックすると設定画面が開きます。Styles の新しいルールとして上図のように追加しています。ルール自体は複数追加できます。自分のチームにあったルールを設定してみてください。

さいごに

Azure DevOps を利用すれば全てのスクラムイベントに対応することが可能です。1つのツール、サービスに絞ることで標準化の観点でもメリットがあります。 Tips としてはまだまだご紹介出来ていないことが多々あります。
以下は一例です。

• Power Automate を使用して、メールを受け取ったらタスクを自動生成。
• Split! 拡張機能の１つで、スコープアウトを調整するために使用します。

Azure DevOps には今回ご紹介をさせていただいた機能以外にも、ソース管理や CI/CD を実現できるサービスも含まれており、スクラムをするために必要なツールがひと通り提供されています。

本記事が、スクラムで使用するツール、サービスをご検討されている方へ少しでも助けになれば幸いです。