『ZenHub x GitHub Project x GitHub』を利用した開発プロセスの考察
このページは、ZenHub x GitHub Project x GitHubを利用した開発プロセスについて記載していきます。
2018–07–18 追記
下記により具体的な運用について載せました。
他ツールとの絞り込みの観点からいうと、前提として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』があります。
所管としては、シンプルでよいがちょっと機能が足りないなといった印象を受けましたが、最近になっていろいろな機能が拡張された模様
いいとおもったのは、2つあります。
1つ目は、Organization単位でカンバンボードを作成できるところです。
ZenHubだとどうしても、リポジトリ単位でのチケット作成になるため複数プロダクトに対するものがここは使いどころがありそうです。
2つ目は、絞り込み機能です。issue作成者や承認者などで絞り込みが可能です。
考察 : 実際のチーム運用に落とし込んだときの構想
下記に運用に落とし込んだときのフローや懸念点を記載します。
まず、第一に考えるられる懸念点は下記です。
- 機能的には、ZenHubのほうが機能としては充実。
- しかしチーム運用を考えたときに複数リポジトリに対してチケットの可視化ができないのは厳しい。
- なので、Organization単位でチケット可視化ができるgithub projectを使いたいところだが機能が少なくてちょっと厳しい。EpicやLabel機能がない。
- 複数プロダクトを持つとプロダクトごとにスクラムボードを分ける必要がでてくる。別にいいのか…?
- 上記2つのプロダクトのリポジトリの他にプロダクトに紐付いたDDLやLambdaなどリポジトリは作るだろうと考えると、妥協策としてはリポジトリとかはあまり意識せずに『プロダクト』の核となるリポジトリにチケットを集約させるになる。
- ただ、そうすると例えばLambdaのリポジトリに対して、issueを発行しても核となるリポジトリへチケットが発行されずにIssue登録→PBI追加という良さが半減してします。
『いろいろいじった感想』
- 下記のような形で、Zenhubでは複数リポジトリに紐付いているタスクをマージすることができるので、上記のZenHubでの複数のプロジェクトにまたがったチケット可視化できない問題は解消しました。
『結論』
- 一旦、ZenHub x GitHubで運用してみようと思います。経過については別途記載できるタイミングでしていこうとおもいます。