GitHub Projects勉強会を開催しました

こんにちは！ROUTE06 Software Engineerの@yoshida-m-3です。

GitHub Projectsがアップデートを続けていることは知っていましたが、実際のプロジェクトで使用できるかは確証がありませんでした。そこでチーム内でGitHub Projectsの勉強会を開催し、実際に検証することにしました。

見るべき人に見るべき情報を確実に届けたい

プロジェクト情報の管理において、「各関係者に適切な粒度で情報を確実に届けること」が重要だと考えています。情報の可視化にはカンバンを使うことが多いですが、情報が多いと重要な情報が隠れてしまう可能性があります。
情報の粒度は見るべき人の立場によって異なります。エンジニアはIssue単位の情報が必要ですが、プロダクトオーナー・マネージャーはEpic単位の情報が必要であり、時系列の進捗情報も必要な場合があります。

GitHub ProjectsのTable, Board, Roadmapなどのレイアウトを使って複数のViewを作成することで、見るべき人の立場に合わせた情報の見せ方・粒度をコントロールできます。

それでは、実際の運用フローを機能追加・バグ修正等を行う基本と締切日のあるプロジェクトに大別して見ていきたいと思います。

フロー (基本)

GitHub Projectsの複数のViewを定義する機能を活用し、「見るべき人」と「フェーズ」に着目して、以下のようなフローを定義しました。

新しいIssueが作成されると、Workflowの機能を使って自動的に「New」のViewにIssueを追加します。Issueは日々大量に作成されるため、すべてに手を付けることはできません。直近で対応する優先度の高いIssueを選んでBacklogへ移動し、優先度順に並び替えます。

■ ユーザーアクション
■ GitHub Projects View

Backlogには優先順に並んだIssueが表示されます。優先度を考慮しながら次回のSprintで対応するIssueにIterationを設定します。 Planningでは、チームメンバー間で課題の理解を深め、見積もりを行います。
Boardにはエンジニアの作業に関連するステータスのレーンだけが表示され、タスクに集中することができるようになりました。

フロー (プロジェクト)

締切日が設定されているプロジェクトの場合、プロダクトマネージャーはマイルストーンを作成して、実現するためのEpicを定義します。Epicは、IssueにEpicラベルが付けられたものです。
次に、作成されたEpicを実現するために、プロダクトマネージャーやリーダーがIssueを作成します。RoadmapではEpicが時系列に表示されるため、プロダクトマネージャーは進捗管理のためにこれを参照します。