スクラムにおけるGitHub/ZenHubの使い方の例(discussion-sidebar編)

丹内です。

前回、GitHubの使い方についてブログを書いたのですが、その段階ではZenHubに関する機能や、一部のGitHubの機能(Labelsなど)をうまく使えていないというのが課題になっていました。

最近になってやっと使い方が落ち着いてきたので、まとめます。

Discussion Sidebar

前提として、ZenHubを導入済みだとします。

ZenHubを導入すると、GitHubのサイドバーが以下のようになります。

以下、項目ごとに解説していきます。

Pipeline

ZenHubによって追加される項目です。

Trelloのように、IssueやPull Requestの進行状況を設定できます。

Issue/PR横のサイドバーにある歯車マークをクリックすると、設定できる小窓が出てきます。

さらに、Boards画面に行くと、これまたTrelloのように全タスクの進行状況を一覧できます。

進行状況の各項目は、あとで詳細に解説します。

Labels

IssueやPRに対して、複数のラベルをつけることができます。

複数つけることができるのですが、たいていは1つのラベルのみが付きます。迷ったら複数つけても良いと思います。(discussionしつつspike、など)

例えばDiscussionのIssueで議論していて途中からSpikeになり、ラベルを張り替えることもあります。

現在のところ、Issue/Pull Requestに対して以下の様なラベルを運用しています。

Story

スクラムで言うところのストーリーとなるIssueに付けます。

このラベルが付いたIssueにのみ、後述のEstimateを、計画時にストーリーポイントとして設定します。

Task

ストーリーと言うPBI(Product Backlog Items)を実現するための、作業の実行単位です。つまりタスクです。

コメントからは、ストーリーのIssueをリンクしておきます。

Chore

Pivotal Trackerでもある、直接的な価値にはつながらないけれど必要な雑務、に付けます。

ドキュメントの整備等があると思います。

Spike

あるストーリーやタスクに着手するために、事前に行う必要があるIssueに付けます。

先行的な、技術的調査などが該当します。

Discussion

議論スレとなるIssueに付けます。

仕様や実装方針など、積極的な議論を前提としたIssueにはこのラベルを付けます。

Daily Report

日報になるIssueに付けます。

毎日業務終了前に、以下のフォーマットで日報を提出しています。タイトルは「日報 YYYY-mm-dd」のフォーマットです。

# 丹内
#### 今日やったこと
- あれ
- これ

#### 明日やること
- それ
- どれ

#### 不安なこと
- hoge
- fuga

翌日出社した時に、朝会でこれをチラ見して、不安なことを解消します。

この方法だとリモートの人との朝会でも、リンクを共有することでコンテキストを揃えやすくなり、タイムボックスを守りやすくなります。

Milestone

ZenHubで追加される項目です。

スクラムのスプリントを設定しています。

Milestone名のフォーマットは、スプリント開始日と何回目かを使って、「YYYYmmdd: Sprint 1」としています。

ストーリーに適切にストーリーポイントを振っている(Estimate)と、以下のようにバーンダウンチャートを見ることができます。

このバーンダウンチャートも、ZenHub導入によって追加される機能です。

Estimate

ZenHubで追加される項目です。

ストーリーのラベルがついたIssueにのみ、ストーリーを設定しています。

Assignee

Issue/PullRequestの担当者を設定します。

ZenHub Boards

Boardsでは、各Issue/Pull Requestの状態を一望できます。

また、その項目はTrelloのようにカスタマイズすることができます。

現在のところ、以下のように運用しています。

Icebox

思いついたIssueはまずここに入れます。

各自が好き勝手にIceboxに突っ込んでいきます。

開発以外の用途でも、例えば「日報を書くようにしましょう」や「RSpecをアップデートしたいです」という名前でDiscussionのIssueを立てたりもします。

Backlog

IceboxのIssueから、実際に着手することが決まったものを移します。

普通は、計画ミーティングでここに入るものが決まり、スプリントの最初にIceboxから移します。

ここに移される段階で、受け入れ条件や成果物が明確に規定されていなければなりません。

In Progress

実行中のIssue/PRが入ります。

実行中のもののみなので、メンバー数以上が同時にIn Progressになることはありません。

むしろ、ペアワーク時は人数以下になります。

Review

完了したストーリーやレビュー待ちのPull Requestは、このステータスになります。

前回のエントリでは[WIP]をつける規約を紹介しましたが、ZenHubを導入しているなら、Boardsで一覧できるので、この機能を使ったほうが良いです。

Closed

完了したIssue/Pull Requestが入ります。

間違って作業中のPull RequestをBoardsでClosedにしてしまうと、途中でもClosesしてしまいます。Issueも同様です。

そもそも完了の定義を満たしたIssue/PRのみが完了(Close)されるべきですし、ここの操作は気をつけて行いましょう。

releaseタグとGitHub Flow

releaseタグの機能は使っていません。

理由は、現在行っているプロジェクトはGit Flowで行っており、リリース管理はmasterブランチへのコミットで行えるからです。

しかしながら、例えばハッカソンやスタートアップのような非常に速い開発が求められる場合は、GitHub Flowで開発してreleaseタグで管理を行うというのが良いと思います。

まとめ

前回は触れられなかった、Discussion Sidebarの使い方を紹介しました。

重要な事は、

規則は必要になったら追加すること

定期的に見なおすこと

この2点です。

GitHubを使いこなすと、生産性の高いリモートワークや、価値の高い作業記録を行うことができます

どんどん学習・改善して、良い仕事ができるようになりたいです。