さよならスプレッドシート Azure DevOps の Azure Boards でスクラム開発一元化!(前編)

目次

本記事は前編と後編に分けてお届けいたします。
前編と後編を合わせた記事の目次は以下の通りです。

  1. 前編
    • はじめに Azure DevOps について
    • スクラム開発をAzure Boardsで管理する
    • プロジェクト作成時にプロセスを設定
    • ポートフォリオバックログどうなる?
    • プロダクトバックログどうなる?
    • リファインメントどうなる?
  2. 後編
    • スプリントプランニングどうなる?
    • デイリースクラムどうなる?
    • スプリントレビューどうなる?
    • レトロスペクティブどうなる?
    • まとめ

f:id:ecb_mkobayashi:20191115115003p:plain

はじめに Azure DevOps について

こんにちは、アーキテクトの小林です。
現在 ecbeing 社内のソースコード管理・課題管理・自動ビルド&デプロイを Azure DevOps に集約しようというプロジェクトが始動しています。

今まではどうだったのかというと、以下のようにプロジェクトや部署に応じて採用しているツールがバラバラでした...。

  • ソースコード管理: Subversion / Git(BitBucket / Backlog)
  • 課題管理: trac / Redmine / Backlog
  • 自動ビルド: Jenkins / BitBucket Pipeline / AWS CodePipeline

tracやRedmine、Jenkinsなどのイントラネットで使うオープンソースソフトウェアは「便利そうだからとりあえず使ってみる」というはじまりから定着するパターンが多く、管理者が不在になりがち。管理者がいないとアップデートが後回しになってしまいます。その結果、古いバージョンのまま「動いているからいいや」と使い続け、いろいろな困ったことが噴出しはじめます。

また、使っているツールも違ってくるとプロジェクトや部署での教育負担も発生してしまいます。

これらのバラバラになっていたツールを、すべてすっきり Azure DevOps に集約することができます!

Azure DevOps Services(SaaS版)であれば OS のバージョンアップやソフトウェアのバージョンアップも不要になりますし、価格も1ユーザー672円ととってもリーズナブル。Visual Studio サブスクリプションのユーザーであれば、なんと無料で使えてしまいます!

トータルコスト削減!これを使わない手はないのです!

...ということで、社内への Azure DevOps 移行の啓蒙活動もかねて、今後数回にわたって Azure DevOps の紹介記事をアップしていきたいと思っています。

スクラム開発を Azure Boards で管理する

最初にご紹介するのは Azure DevOps に含まれる Azure Boards です。
Azure Boards は、スクラム開発もしっかり管理できるようにつくられた課題管理システムです。
Microsoft 社の実に9万人以上もの内部ユーザーがこれをつかっており、1日に閲覧される課題数は500万件だそうです。
超一流のエンジニア集団が徹底的に使い込んで洗練させてきたツールですから、満足できるツールであることは間違いありませんね。

社内ではまだスクラム開発に取り組んでいるチームは多くはありません。しかし、すでに1年半以上も継続して取り組んでいるチームもあります。ある程度慣れ親しんだやり方をチームごとに微調整しながら進めていますので、今までのやり方をいきなり大きく変えるのは負担になってしまいます。

そこで今回の記事では Azure Boards でスクラム開発を管理するようにしたら「○○が××になるという」という体裁でまとめることで、変わる部分についてしっかり理解を深め、チームごとにタイミングを見計らって移行してもらおうと考えました。

プロジェクト作成時にプロセスを設定

Azure DevOpsのプロジェクトを作成する一番最初に、実は重要な「プロセス」という設定項目があります。

プロセスはプロジェクト作成時の「Advanced」の隠し項目内の「Work item prosess」という選択項目から「Basic」「Agile」「Scrum」「CMMI」という4つの選択項目から選びます。

プロセスは後からでも変更可能なのですが、ある程度進めてから変更すると、すでに作成しまったWork ItemやBoardの設定などを手動で調整する必要があるそうです。最初からしっかりと設定したおいた方が絶対に良いです。
スクラム開発をしている場合いろいろなスクラム用語がピッタリとマッチして気持ちいい「Scrum」を選ぶのがおすすめです。

以下はプロジェクト作成時に「Scrum」を選択する手順です。
f:id:ecb_mkobayashi:20191114192147p:plain
なお、この記事の後編の手順でこの「Scrum」のプロセスをカスタムしています。
プロセスをカスタムすると「{組織名} Scrum」というカスタムプロセスが自動的に作成されますので、プルダウンにその選択肢がある場合は「{組織名} Scrum」を選べばよいと思います。カスタムしまくった「俺様 Scrum」になっているかもしれませんので、その点はコミュニケーションで解決してください。

ポートフォリオバックログどうなる?

現在、スクラムのプロダクトオーナーをやっています。最初の頃はプロダクトバックログだけで優先度を管理していました。

しかし、もっと大きな単位「エピック」でステークホルダーと優先度と交渉しなければならないことが多くなり、ポートフォリオバックログを作成するようになりました。

ポートフォリオバックログは以下のようなスプレッドシートを作成し共有していました。
f:id:ecb_mkobayashi:20191114192416j:plain
Azure Boards にも Epic という Work Item を作成することができます。 しかし Epic で作成した Work Item に対して便利な機能はほとんど作り込まれていません。 以下は Epic の Work Item の入力欄です。
f:id:ecb_mkobayashi:20191114192549j:plain
ポートフォリオバックログでは、エピックに対して S・M・L で規模を設定して予算感とスケジュール感、どのチームにいつごろアサインするかを決めたりしていました。これらの項目についてカスタムフィールドを追加すれば実現できそうな感じはしましたが、スプレッドシートよりも見やすいポートフォリオバックログの一覧にはなりそうもありません。

ただ、Epic の Work Item を作成しておけば、その下に Product Backlog Item の Work Item を作成してぶらさげることができます。
Epic と Product Backlog Item を構造化することで、一覧上で Epic の進捗が簡単に把握できるようになります。

以下は階層化された Work Item を Rollup columns を使って表示した画面のスクリーンショットです。
進捗がだいぶわかりやすく表示されますね。これは便利そうです。
f:id:ecb_mkobayashi:20191114193124p:plain
※出典: Microsoft Docs より

ということで、エピックの進捗を可視化するためにエピックを登録し、ポートフォリオバックログの全体の管理は今まで通りスプレッドシートでやろうと思います。

プロダクトバックログどうなる?

さて、つづいてはプロダクトバックログです。
プロダクトバックログも同じく以下のようなスプレッドシートを作成し共有していました。
f:id:ecb_mkobayashi:20191114193355j:plain
プロダクトバックログアイテムは「何々が実現できたらいいな」「こういう状態になっていたら完了」という情報がメインにあって、その他はプランニングポーカーで決定したストーリーポイントと進捗管理上の項目をいくつか用意して管理していました。

ためしにプロダクトバックログアイテムを Azure Boards の Product Backlog Item に記入してみた結果が以下の通りです。
f:id:ecb_mkobayashi:20191114193433j:plain
主要な項目は綺麗に収まってくれました。リファインメントやスプリントレビューが終わったという項目については State で管理できそうです。

ということで、プロダクトバックログをスプレッドシートで管理するのはやめることができそうです。

リファインメントどうなる?

つづいてプロダクトバックログのリファインメントです。
リファインメントはプロダクトバックログアイテムの内容説明を行うスクラムイベントです。
開発チームと質疑応答をしながら、ときには優先順位を上げたり下げたり、大きなアイテムを分割したりしていました。

Azure Boards にはリファインメントにちょうど良い Board という画面が提供されています。左メニューの「Boards」を選んだ状態がこの画面です。 f:id:ecb_mkobayashi:20191114193845j:plain
この画面で New のレーンにある項目を上から順番にプロダクトバックログアイテム開いて説明し、プランニングポーカーをしてストーリーポイントが決まったら Effort という項目に入力していきます。(上記スクリーンショットの数字が Effort です)

ドラッグアンドドロップで上下で優先順位を変更できますし、Approved にすることでリファインメント済みという状態を管理できます。
プロダクトバックログアイテムの内容説明、優先順位の変更、リファインメント完了といった繰り返し操作をマウスだけでサクサクできるのでとても便利です。

ということで、リファインメントは Azure Boards の Board 画面でやっていきたいと思います。

前編の記事は以上です。
さよならスプレッドシートと言っておきながら、ポートフォリオバックログはスプレッドシートによる管理を継続することになってしまいましたが、気にすることなく次の後編記事の公開をお待ちください!

※2019年11月21日追記 後編記事が公開されました。こちらからアクセスしてください。


~ecbeingでは スクラム開発と Azure DevOps に興味のあるエンジニアを大募集中です!~ careers.ecbeing.tech