ZenHubを活用した開発プロセス最適化の例
続いて、ZenHubを利用してチームの中でどう開発していくかを一例をもとに記載していきます。
プロセス
- Organizationの中で基本操作しています。
- Product Backlog Itemの可視化のため、専用の「backlog」というGitHubリポジトリを用意して、その中にZenHubのBoradを用意します。
- PO（ProductOwner）は、普段どおり「backlog」に対してProduct Backlogを作っていきます。
- ScrumTeamのDeveloperは、対象リポジトリ（例：api、infra、lambda）に対してバグや改善ポイントをIssueとして発行していきます。
- ZenHubのBoardには、Organizationと紐づくリポジトリのIssueをMergeする機能があります。「backlog」のBoardに指定したリポジトリのIssueがすべて可視化できるようにします。
メリットとしては、GitHubリポジトリに起因してIssueを発行することで、そのIssueはどこに対してコミットすれば良いのかがまずわかります。また、「backlog」のような専用のBoardを用意して、それぞれのリポジトリに発行されたIssueを集約することで、一元管理できるのも大きなメリットです。
スクラムとの親和性を考えたパイプラインの例
作業を可視化するためのパイプラインについてです。ZenHubではデフォルトのレーンを提供しています。
プロダクト開発のパイプライン（出典：How the ZenHub team uses kanban boards in GitHub – For beginners）
もちろんそのまま利用する形でも良いのですが、私たちのチームではスクラムに合ったカスタマイズをしています。そのカスタマイズ例を紹介します。
- Opportunity Backlog：各リポジトリに発行されたIssueがここに積まれていきます。
- Story：Epicを利用してユーザーストーリーに沿ったものが積まれていきます。
- Story in progress：「Story」のレーンのなかで現在進行中のものをここに配置して、どのStoryに着手しているのかを可視化します。
- Backlog：オポチュニティバックログ（Opportunity Backlog）から精査されたプロダクトバックログをここに積んでいきます。
- Doing：現在進行中のスプリントバックログアイテム（Sprint Backlog Item）です。
- Review/QA：レビューや問い合わせ待ちのものを配置します。
- Resolved：完了したスプリントバックログアイテムについて、一度ここのレーンに持っていき、デイリースクラムで皆で確認後にCloseのレーンに持っていきます。
- Closed：完了したスプリントバックログアイテムです。
補足
アイテムには、Milestone、Epic、Labelsを必ず紐づけます。そして、Estimate、Assigneesはスプリントプランニングの際に紐づけます。
