ZenHubにアジャイル・スクラムのアイデアを注入する

GitHubと連携できるZenHubを使うところが増えてきた気がします。直感的に使いやすいツールですが、アジャイル・スクラムチームとして手はじめにどう使えばいいか迷う方もいるようなので、ざっくり使って調べてみました。

Repository

ZenHubはGitHubに紐づく便利さと同時に、リポジトリに紐付かざるを得ない宿命があります。

つまり、リポジトリに紐付かない作業も、どこかのリポジトリに所属しなければならない制約があるということだと思います。

バックログを構成する要素

まずは、ツール内に登場するオブジェクトや属性を整理してみます。

ということは、そういったリポジトリに紐付かない作業（つまり、ソースのコミットやPRのやりとりが発生しない作業）のためのリポジトリを、ダミーで用意するのがいいかもしれませんね。

Epic

Epicとは何かを考えるよりも、Epicをどう使うか考えるといいと思います。Epicはこのあと出てくるIssueより上位の概念です。Epicの中にIssueが作成され、Issueは複数作成できるため、複数EpicとIssueは親子関係となり、Epicは複数のIssueをたばねる役割をもたせられるということです。

さらに、Issueは複数のEpicを持てます。

操作上、EpicにEpicも設定できちゃうのですが、ZenHubがアラートを出してくれるので大丈夫。でも、ややこし！

試しにEpicとIssueを作ってみます。Epicを作ると同時に、Issueを追加できるページが表示されます。そこに2つのIssueを追加すると上記のようになります。

GitHub上で見てみましょう。ZenHubはGitHubと相思相愛なので、対象のリポジトリにIssueが3つできます。Epicは「Epic」というラベルが貼られただけのIssueです。

Issue

IssueはただのGitHub Issueです。Issueはその名の通り問題点、課題を指しますが、ZenHubにおけるアジャイルなプロジェクト運営ならば、タスクやバックログも意味するようになるはずです。

Issueで注意したいのは、依存関係をもたせられる点でしょう。Epicとは違い「依存」という形でEpicやIssueと繋げられ、「これができないとこっちができない」といった関係性を表現できます。

Sub-tasks

Sub-tasksは、Issueの説明にチェックボックスを記述すれば実現できます。すべてのチェックを終わらせられれば、IssueはDONEになります。

ただし、Board上（かんばん形式のView）からは見えなくなるので注意が必要です。

Epic、IssueとSub-tasksの使い方

もちろん現場によって色んな使い方をすればいいとお思いますが、ここまで考えると、EpicとIssueをどう使うべきかが見えてきます。

「An Introduction to ZenHub Epics」にはアジャイル開発との関係性が、上記のようにわかりやすく説明されています。

• Epicは大きなユーザーストーリー。EpicはIssueに分割できます。
• Issueは小さなユーザーストーリーです。IssueはSub-tasksに分割できます。
• Sub-tasksはユーザーストーリーを実現するためのタスクです。

ユーザーストーリーレベルの見える化でよければIssueまで使い、Sub-tasksは各個人のタスク管理として使えます。

タスクまでBoardでみたいなら、Issueをタスク（もしくはタスク or ユーザーストーリー）にせざるをえません。

ちなみに、ユーザーストーリーは、Wikipediaの表現がとてもわかりやすいです。

ユーザーストーリーとは、ソフトウェアシステムの1つ以上の機能の非公式の自然言語記述です。ユーザーストーリーは、多くの場合、エンドユーザーまたはシステムのユーザーの観点から書かれています。

User story – Wikipedia

さらに、親子関係や依存関係も活用できます。

• EpicやIssueの紐付けや依存関係を設定できます。依存関係はBlockerを意味します。
• EpicやIssueは多対多の親子関係を設定できます。

しかし、それぞれのオブジェクトの関連性が複雑になるため、親子関係や依存関係を利用しないのも手だと思います。

ZenHubとGitHub Issueの違いは「What is ZenHub vs. GitHub in an Issue」を参考にどうぞ。

時間を司る要素

Issueにも期限があっていいような気がしますが、Issueは見積もり（Estimate）をラベルとして設定します。このへんがバックログっぽくていいですね。

ZenHubでは時間を扱えるものとして、MilestoneとReleaseがあります。それぞれの特徴を見ていきましょう。

Milestone

マイルストーンは期限（Due date）を持てます。

マイルストーンには期限があるので、スプリントとして「Spint1」「Sprint2」という命名にしたり、ロードマップ上の特定期限を指してあげると良いと思います。

参考： What are GitHub Milestones? – Agile Concepts in GitHub and ZenHub

Release

ReleaseはReportから作成できます。リリースには開始日と終了日を設定できます。

開始と終了があるので、見積もりを入れれば上記のようなレポートが表示可能です。

ZenHubはReportが充実しています。見積もりなしでも表示できるレポートがあるので気軽にメトリクス測定できますね。すばらしい。

参考： Reports and gathering insights

Release対象となるIssueも確認できます。スコープに入れる or 入れないといった判断も簡単なので、スプリントバックログみたいにもつかえます。

JIRAのようにドラッグアンドドロップで優先順位付けを変更できるようになったら最高ですね。

MilestoneとReleaseの使い方

マイルストーンとリリースもシンプルに使うのであれば以下のようになるはずです。

• マイルストーンはイテレーション・スプリントとして固定期間
• リリースはマイルストーンをつみあげていった成果をリリースするもの

リリースの開始日はスプリントXなりに合わせるとシンプルです。さらに、リリース日 ＝ マイルストーンの期限日になるとわかりやすいです。

リリースはリリースノートといったレポート機能として存在するため、マイルストーンとの親子関係はありません。よって、その関係性は人間が意識して設定する必要があります。

属性

ZenHubにはそれ以外にもたくさんの属性があります。これらはEpicとIssue双方に付与できます。

• Labels： カテゴリが存在しないのでラベルを使って整理します。
• Assignees： アサインする人
• Milestone： 前述のマイルストーン
• Estimate： 見積もり
• Epics： 前述のマイルストーン
• Releases： 前述のリリース

まとめ

ZenHubのサイトはこちら。

参考：ZenHub – Agile Project Management for GitHub

かつてタモリさんは言っていました。

簡単なことを難しくするのがバカ。

繰り返しになりますが、ツールもプロセスもシンプルに使うべきです。

Be simple. Be happy.

最後に、この記事のタイトル「ZenHubにアジャイル・スクラムのアイデアを注入する」は「RedmineへScrumのアイデアを注入」へのオマージュです。