著者の自己紹介
著者の名はイナバくん。
フロントエンドエンジニア。
プライベートでは、登山家・禁煙家。
某アパレル企業に常駐していて、自社プロダクトをスクラム開発しています。
この記事で話すこと
- スクラム開発におけるGitHub Projectsの便利なところ
- GitHub Projectsでまだ出来ないこと
※ スクラム開発の各用語(スプリント, PBI, SBI など) が分かる方向けの解説になります。
GitHub Projectsを導入する前の課題
主にMiroの愚痴になります。
(※ Miroはホワイトボードとしては素晴らしいツールです
)
課題1: タスクとPull Ruquest(以下PR)を紐付けできない
PRをMergeした自動でタスクのステータスがDoneになる、みたいな事をパッと設定できない。。
課題2: タスクをMarkdown形式で書けない
Miroには付箋やカードはあり、リンクや太字は使えるのですが、Markdownは使えず、画像も貼り付けできません。
課題3: タスクの見積もりの合計を自動算出できない
スクラム開発において、スプリント内の見積もり数の合計や、増減値を出す機会が多いです。
Miroだと他ツールのように自動算出ができません。。
課題4: ホワイトボード故に自由度が高すぎてカオスになる
PBI・SBI・undone task などスクラム開発の全てをmiroで管理していたので、付箋だらけでカオスになっていました。
いざ、GitHub Projectsを導入！
GitHub Projectの始め方は公式ドキュメントを参照してください。
まず、スクラム開発でProjectsを使うにあたって、設定からカスタムフィールドをいくつか追加します。
カスタムフィールドを追加する
- Sprint: スプリント期間を設定する(カレンダーから開始日・終了日・期間を設定できる)
- Status: PBIのステータス
- idea box: アイディア置き場
- ice box: what, whyが明確になっていて見積もり可能
- ready: 見積もり済で着手可能
- selected: スプリントにて進行中
- PO review: タスク完了していて、POレビュー可能
- done: 完了
- Task Status: タスクのステータス
- to do: 未着手
- doing: 進行中
- reviewing: レビュー中
- done: 完了
- Task Size: タスクの見積もり(1, 2, 3, 5, ... のようにフィボナッチ数列の数値で入力する)
ビューを作成する
GitHub Projects では、アイテムを様々なレイアウトで並べることができます。
(このレイアウトをビューと言います)
- テーブル形式
- カンバンボード形式
- ロードマップ形式
僕らのチームでは、2 を使ってタスク管理をしていました。
ビュー 1. プロダクトバックログ(PBIのステータス管理)
まず、ステータスをカラムしてカンバンを作成します。
PBIをステータス管理したいので、SBIなどのPBI以外のカードが表示されないようにフィルター設定します。
ビュー 2. スプリントバックログ(開発者のタスクボード)
SBIでも同様に、ステータスをカラムにして、カンバン作成します。
PBIとSBIは、Group(A, B, C, ...)によってグループ化して、1レーンにまとめています。
(このタスク同士の紐付け・親子設定ができないことがGitHub Projectsの弱点であり、後ほど詳しく解説します)
便利なところ
便利1: タスクをPRと紐付けられる
GitHub Projects のアイテムは、レポジトリのissueに変換できます。
issueとPRが紐づいていると、PRがスプリント内の何の活動なのかが一目瞭然なので便利です。
また、PRがmergeされたら自動でissueのステータスをdoneにできます。
※ issueとPRの紐付け方法: 公式ドキュメント
便利2: バーンアップチャートを自動生成できる
スプリント中のタスクの増減や、消化スピードなどを計測できます。
グラフの種類や、縦軸・横軸はカスタマイズできます。
便利3: そもそもUIがシンプルで見やすい
スクラム開発をする上で、他にもJiraなど多機能なツールもありますが、多機能ゆえにUIがゴチャゴチャしていて見にくい印象を受けます。。
その点、GitHubはエンジニアなら見慣れたUIなので、ツール自体の学習コストが低いです。
また、スクラムのイベント手続きと開発作業を、どちらも同じツールでできるため、スイッチングコストも減らすことができます。
便利4: viewを自由にカスタマイズできる
テーブルやカンバンなど見た目を自由に変えることができます。
また、好きなカスタムフィールドをカラムやグループなどにセットできて、フィルターも使えるので、一般的なスクラムチームにおける必要なViewはカスタマイズして作ることができます。
GitHub Projectsでまだ出来ないこと
GitHub Projectsは導入しやすい上に、とても便利で素晴らしいのですが、2022/07 に出来た機能なので、まだまだ物足りなさもあります。
できないこと 1: 自由なworkflow設定
GitHub Projectsのworkflowを使うと、日々のタスクアイテムやPR・issueの操作を自動化できます。
例えば、
- PR を「ready for review」にしたら、PRに紐づくタスクのアイテムのステータスを「reviewing」にする
- PRをmergeしたら、PRに紐づくタスクのアイテムのステータスを「Done」にする
などを自動化したいです。
ですが、まだworkflow設定では、デフォルトのカスタムフィールドについてのプログラムしかできません。
なので、上記のような自動化をするにはGitHub Actions を作成する必要があります。
できないこと 2: PBIとSBIの紐付け
GitHub Projectsのアイテムやissue同士には、まだ依存関係や親子関係を設定することはできません。
なので、スクラム開発においては、PBIの子タスクであるSBIを表現することができません。
(僕らのチームでは、Groupを使ってPBI・SBIをまとめています。)
ただ、こちらはGitHub が機能の追加予定があるそうです。
まとめ
GitHub にレポジトリがあるプロジェクトで、気軽にタスク管理をしたい時はGitHub Projectsがオススメです。
導入しやすく、学習コストも低く、開発との相性もGoodです。
ただ、まだ足りない機能もあるので、足りない部分はGitHub Actions で補完するか、諦めて他のツール使いましょう。