『ZenHub x GitHub Project x GitHub』を利用した開発プロセスの考察

Masato Ishigaki

Published in

Masato Ishigaki

8 min readJun 15, 2018

このページは、ZenHub x GitHub Project x GitHubを利用した開発プロセスについて記載していきます。

2018–07–18 追記

下記により具体的な運用について載せました。

『ZenHub x GitHub』を使ったプロダクトバックログ運用について

以前、下記のような記事を書いたが運用が固まってきたので新しく書きます。

medium.com

他ツールとの絞り込みの観点からいうと、前提としてScrum開発で行うことを想定すると最低下記の機能が必要と考えました。

プロダクトバックログアイテムが作成できること。
ストーリーが作成できること(＝epic)
ストーリー(epic)に対して、プロダクトバックログアイテムを紐づけることができること。
スプリントが作成できること。
バーンダウンチャート及びベロシティーが図れること。ビジュアライズされていればなおよし。

上記のような基準でいくと、JIRAかZenhubに落ち着きました。

さらに、落とし所としてはチケット管理とリポジトリの関係についてはより近い製品を使ったほうがよいとおもっています。

たとえば、Atlassian性のBitBucketを利用している場合には、JIRAやTrelloを使ったほうがチケット発行→リポジトリへのブランチ作成やコミットの履歴などがJIRAで見れたりなど便利です。

今回は、リポジトリ管理を『GitHub』を利用しているのででチケット管理をZenHubおよびGitHub Projectをどのように使っていくと良いのかの考察をまとめます。

■ ZenHubとは

https://www.zenhub.com/
プロダクト管理ツール
要約すると、GitHubの特定のリポジトリに対してissuesなどを作成すると自動でタスク化される。それをタスク管理としてBacklogやDoneなど移動もできる。
レーンも自由に触れる。
Markdownで書ける。

Boards

いわゆる、プロダクト管理ボードです。

Reports

バーンダウンやベロシティーグラフなどが可視化できます。

■ 機能サマリー

ざっと、使えそうな機能を記載していきます。

デフォルトレーンの説明

引用 : https://qiita.com/yoheimuta/items/ddf4b278f3db79ce2a8f

New Issues

メンバーが自由に issue をつくったら、まずはこのパイプラインに放り込まれる
weekly triage meeting でこれらの issue をレビューして優先度をつける
この meeting を通じてこのパイプラインは空にする

Icebox

優先度が低いバックログ issue をこのパイプラインに置く
重複 issue を作らないようにすることや心理的な負担を下げて、優先度の高い issue に集中するために置く
将来的に優先度を上げる判断が出来る程度の情報が issue にあればいい

Backlog

優先度が高いバックログ issue を置く
意訳すると、sprint planning meetings でそのスプリント期間中に終わらせる issue をこのパイプラインに置く
このパイプラインは次の sprint planning meetings までに空になっていることが望ましい
補足：ここの空にするのは意味は、そのスプリントに紐付いた Backlog を空にするという意味で、全体での Backlog ではない（と思います、全体で空にできるにこしたことはないとは思います）

In-Progress

進行中の issue をこのパイプラインに置く
ここにある issue には必ずアサインされた担当者（この issue を完了にする責任を負う）が設定されていないといけない

Review/QA

他のメンバーによるレビューやテスト（ステージングテスト）期間にある issue をこのパイプラインに置く
開発はすでに完了している
例えば、レビュー依頼して忘れてしまう（または忘れられてしまう）ことを防げるようになると期待されます

Done

追加の作業はなく、クローズできる issue をこのパイプラインに置く
完了の定義が作業開始前から存在するとこのパイプラインは活きてくる
クローズする前に、確認が必要な指標や目的があれば、このパイプラインが使える
例えば、次の使い方が想定されます
サービスのリリース後の本番確認中のものを Close にしないで Done にする
AMI を作ったけど本番のインスタンスと入れ替えるまで Done にする
iOS や Android アプリの開発は終わったけどリリースがまだなら Done にする

もちろん、独自レーンも作れます。

Labels

ラベルもつけられます。

デフォルトでは下記があります。

Epic

エピックも作れます。

さらにIssueをEpicに変換することもできるので便利です。

Milestones

Sprint単位に作成できます。

バーンダウングラグ(Burndown charts)

スプリントごとにグラフ化できます。https://www.zenhub.com/guides/burndown-charts

ベロシティートラッキング(Velocity tracking)

スプリントごとに可視化できます。https://www.zenhub.com/guides/velocity-tracking

ざっとJIRAなどでできる機能はさらえるかなと思います。

■ GitHub Prpjectについて

ZenHubと同じようなタスク管理機能として、もう一つ『Github Project』があります。

所管としては、シンプルでよいがちょっと機能が足りないなといった印象を受けましたが、最近になっていろいろな機能が拡張された模様

いいとおもったのは、２つあります。

1つ目は、Organization単位でカンバンボードを作成できるところです。

ZenHubだとどうしても、リポジトリ単位でのチケット作成になるため複数プロダクトに対するものがここは使いどころがありそうです。

2つ目は、絞り込み機能です。issue作成者や承認者などで絞り込みが可能です。

考察 : 実際のチーム運用に落とし込んだときの構想

下記に運用に落とし込んだときのフローや懸念点を記載します。

まず、第一に考えるられる懸念点は下記です。

機能的には、ZenHubのほうが機能としては充実。
しかしチーム運用を考えたときに複数リポジトリに対してチケットの可視化ができないのは厳しい。
なので、Organization単位でチケット可視化ができるgithub projectを使いたいところだが機能が少なくてちょっと厳しい。EpicやLabel機能がない。
複数プロダクトを持つとプロダクトごとにスクラムボードを分ける必要がでてくる。別にいいのか…？
上記2つのプロダクトのリポジトリの他にプロダクトに紐付いたDDLやLambdaなどリポジトリは作るだろうと考えると、妥協策としてはリポジトリとかはあまり意識せずに『プロダクト』の核となるリポジトリにチケットを集約させるになる。
ただ、そうすると例えばLambdaのリポジトリに対して、issueを発行しても核となるリポジトリへチケットが発行されずにIssue登録→PBI追加という良さが半減してします。

『いろいろいじった感想』