DMMグループの一番深くておもしろいトコロ。
テクノロジー

『ZenHub x GitHub』を軸としたスクラム開発のプロセス設計

DMMグループの一番深くておもしろいトコロ。

はじめに

こんにちは、プラットフォーム事業本部の石垣雅人(@i35_267)です。
現在は、DMM.comのサービスで利用されるプラットフォーム基盤でPO(ProductOwner)をしております。

今回は、『プロジェクト管理ツール』について『ZenHub』を利用することになった経緯とその運用方法について記載していきます。

https://www.zenhub.com/

ZenHubとは

ZenHubの公式サイトにある『What is ZenHub？』には、下のように述べられています。

ZenHub is not your typical GitHub Issue tracker. For one, every feature is crafted specifically for fast-moving software teams. Rather than forcing teams to leave GitHub and jump into another tool (resulting in double work, informational silos, and missed updates), it transforms GitHub into a fully featured project management platform.
Wasted time spent context switching is eliminated. And because everything is fuelled by your GitHub Issues and Pull Requests, you're always working from the most up-to-date data possible. It's the fullest possible integration where you already work.
What is ZenHub? Using ZenHub for project management in GitHub

つまり、ZenHubはGitHub Issueを追跡するだけのものではなく、GitHub IssueおよびPull Requestsを軸として、別のツールへの切り替えや二重更新などの『ムダ』から解放され、すべてが高速になるようなプロジェクト管理プラットフォームです。

 

スクラム開発における親和性

 

プロジェクト管理ツールには開発手法との親和性が強く求められます。
今回『ZenHub』を導入したチームではスクラム開発手法を取り入れているため、下記の機能が最低限必要でした。

  1. Product Backlog Itemが作成できる。
  2. Storyが作成できる。
  3. Storyに対してProduct Backlog Itemを紐づけることができる。
  4. スプリントが作成できる。
  5. Burndown chartsおよびVelocity Trackingが可視化できる。

まず、これらの基準を満たすものとしてAtlassian製のJIRAか、今回述べるZenHubに落ち着きました。
そして、次にポイントになったのが、『チケット管理』と『リポジトリ管理』の親和性でした。

たとえば、AtlassianのBitBucketをリポジトリ管理に利用している場合にはJIRAやTrello。一方、GitHubを使っているのであれば、ZenHubのようなチケットからリポジトリのコミット履歴やPull Requestが確認できたり、チケットとリポジトリで相互リンクの関係を作れていたりすることが重要だと考えております。

今回は、リポジトリ管理としてGitHubを利用するというチーム方針のため、ZenHubを採用する形となりました。
公式サイトにもJIRAとの比較がありますのでご覧ください。

https://www.zenhub.com/jira-alternative

Agile Concepts in GitHub and ZenHub

ZenHubにはAgile開発に必要な機能が揃っています。
上で述べたスクラム開発における親和性の5項目が、ZenHubではどのようなツールで提供されているのか見ていきます。

1. Product Backlog Itemが作成できる。
ZenHubにおけるProduct Backlog Itemは、GitHubでいうIssueにあたります。
Issueについては、GitHub上からでもZenHub上からでも作成できます。もちろん作成されたissueはGitHub,ZenHubの両方から閲覧可能です。

※上 : GitHub / 下 : ZenHub

 

2. Storyが作成できる。
3. Storyに対してProduct Backlog Itemを紐づけることができる。
スクラム開発では、ユーザストーリーをベースにひとつのストーリーが完了するまでに必要なProduct Backlog Itemを紐づけられるべきです。 一般的にこのような仕組みは『Epic』という機能で補完されます。もちろんZenHubにも『Epic』機能があります。

引用 : Using Epics in ZenHub for projects and user stories

4. スプリントが作成できる。
スクラム開発をするうえで『スプリント』機能は必須です。 ZenHubでは『Milestone』機能が提供されて一定期間のタイムボックスを選択してスプリントが作成できます。

参考 : Create GitHub Milestones across a multi-repo Board

5. Burndown chartsおよびVelocity Trackingが可視化できる。
スプリントの経過や成果について、Burndown chartsおよびVelocity Trackingを利用しますが、ZenHubにもしっかりと備わっています。

引用 : Creating Burndown charts in ZenHub using GitHub Milestones

引用 : Using Velocity charts in ZenHub

Development Process

続いて、ZenHubを利用した開発プロセスについて、チームの事例を記載していきます。

全体図

プロセス
1. Organizationの中で基本操作しています。
2. Product Backlog Itemの可視化のため、専用の『backlog』というGitHubリポジトリを用意して、その中にZenHubのBoradを用意します。
3. PO(ProductOwner)は、普段どおり『backlog』に対してProduct Backlogを作っていきます。
4. ScrumTeamのDeveloperは、対象リポジトリ(ex.api, infra, lambda)に対してバグや改善ポイントをIssueとして発行していきます。
5. ZenHubのBoardには、Organizationと紐づくリポジトリのIssueをMergeする機能があります。『backlog』のBoardに指定したリポジトリのIssueがすべて可視化できるようにします。※詳細は、 『ZenHub x GitHub』複数リポジトリをマージして、ひとつのBoardでIssueを一元管理しよう！を御覧ください。

メリットとしては、GitHubリポジトリに起因してIssueを発行することで、そのIssueはどこに対してコミットすれば良いのかがまずわかります。
また、『backlog』のような専用のBoardを用意して、それぞれのリポジトリに発行されたIssueを集約することで、一元管理できるのも大きなメリットです。

Product Development Pipelines

作業を可視化するためのパイプラインについてです。
ZenHubではデフォルトのレーンを提供しています。

引用 : How the ZenHub team uses kanban boards in GitHub – For beginners

もちろんそのまま利用する形でも良いのですが、私たちのチームではスクラム開発用にカスタマイズしています。

  1. 『Opportunity Backlog』 : 各リポジトリに発行されたIssueがここに積まれていきます。
  2. 『Story』 : Epicを利用してユーザーストーリーに沿ったものが積まれていきます。
  3. 『Story in progress』: 『Story』のレーンのなかで現在進行中のものをここに配置して、どのStoryに着手しているのかを可視化します。
  4. 『Backlog』 : Opportunity Backlogから精査されたProduct Backlogをここに積んでいきます。
  5. 『Doing』: 現在進行中のSprint Backlog Itemです。
  6. 『Review/QA』: レビューや問い合わせ待ちのものを配置します。
  7. 『Resolved』: 完了したSprint Backlog Itemについて、一度ここのレーンに持っていき、DailyScrumで皆で確認後にCloseのレーンに持っていきます。
  8. 『Closed』 : 完了したSprint Backlog Itemです。

補足
Product Backlog Itemには、Milestone, Epic, Labelsを必ず紐づけます。※Estimate, Assigneesはスプリントプランニングの際に紐づけます。
ZenHubのフィルター機能を使って、スプリントに紐付いたSprint Backlog Itemだけを見るためです。

Tips

ZenHubには、他にも様々な便利な機能がありますので紹介させてください。

ショートカット機能
ZenHub上での操作は、ほとんどショートカットコマンドが用意されています。 以下にまとめられておりまので、ぜひご覧ください。

https://qiita.com/i35_267/items/536ffbe26ed9e60083d3

ZenHub API
ZenHubではAPIが提供されているので、様々なカスタマイズが可能です。
たとえば、ZenHub上でReview/QAに一定期間あるIssueを通知することなども可能です。

https://github.com/ZenHubIO/API

Issueを作成するなどの処理は、ZenHubではなくGitHubのAPIで可能です。それについては以下をあわせてご覧ください。

https://docs.github.com/ja/rest?apiVersion=2022-11-28

まとめ

今回は、プロジェクト管理ツールとしてZenHubを紹介させていただきました。
特にGitHubを使っている方は、ZenHubを利用することで様々なメリットを得られると思いますので、ぜひ利用してみてください。

 

 

  • 開発プロセス

シェア

関連する記事