宿泊開発チームでエンジニアをしている @itinao です。
昨年の10月に入社しました。
今回は GitHub Projects を利用したタスク管理について記載します。
なんとなーく GitHub Projects 使うと、KANBANにしてみたり
リストにして使ってみたり
で終わってしまいます。
もっと色々できるんだよってことが伝えられればと思います。
背景
一休ではチームごとにタスクの管理方法が違い、
Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法が異なっています。
各ツールの印象は、、
- Google Spreadsheet
- 作り込めば便利なんだけど、壊れやすい...
- Jira
- 過去に使って、エンジニア目線だと操作感とかそんな好きになれなかったなあという印象があった..
- GitHub Projects
- エンジニアだととっつきやすいのと、ツールをアレコレ移動しなくて済む
個人的には Jira か GitHub Projects を使いたくて、
できれば GitHub Projects を選択したいという気持ちがありました。
そのモチベーションでやり方を考え、現在はこの記事の管理方法で落ち着いています。
どんな機能があるか
この4つを抑えておけば良いです。
Custom Fields / Views / Workflows / Insights
ざっくり概念。
Custom Fields
下記の種別でパラメータを作成でき、Draft / ISSUE / Pull request に値をセットすることができます。
種別 | 設定できる内容 |
---|---|
Text | テキスト |
Number | 数値 |
Date | 日付 |
Single select | 決められた項目のみ選択できる |
Iteration | 決められた間隔の時間ブロックを作り、その時間ブロックを選択できる |
★ 自身のチームではこのようなパラメータを作って運用しています。
名前 | 種別 | 設定内容 | 例 |
---|---|---|---|
Status | Single select | タスクの状態 | Backlog / In progress / In review / Done |
Epic | Single select | 作業階層の最上位の単位で、チームが目指す大きなゴールのようなもの | Epic1 / Epic2 / Epic3 / 改善 / ... |
Estimate | Number | 見積もり | 1, 2, 3, 5, 8, 13, ... → フィボナッチ数列で運用しているため、Single selectにしたいところだが Insights で積算を表示させたいので Number |
Sprint | Iteration | 区切りになる開発期間 | Sprint1, Sprint2, Sprint3, ... |
Function | Single select | どこの機能か リポジトリに近いイメージ |
管理画面Backend, 管理画面Frontend, ユーザー画面Backend, ... |
Priority | Single select | 優先順位 | 高, 中, 低 → 普段は使わないが、バグチケットなどで目印が欲しいときに使う |
Views
Table / Board / Roadmap のLayoutで、Draft / ISSUE / Pull requestを表示することができます。
Group by, Slice byが良い感じです。
Group by
設定した項目でグルーピング化し、表示してくれる
Slice by
設定した項目でフィルタリングし、左にメニューが表示される
★ 自身のチームでは、ざっくり、、4つの Viewを良く使っています。
種別 | イメージ | 説明 | 利用シーン |
---|---|---|---|
プロダクトバックログ | GitHub Projects全体のチケットをEpic単位で絞り込めるようにしている | 全体のタスクを眺める時 見積もりをする時 |
|
スプリントバックログ | 現在のSprintのタスクをAssignees単位で絞り込めるようにしている | 朝会/夕会で各々の作業を報告する時 | |
自身のタスク | 自身がアサインされているタスクをSprint単位で絞り込めるようにしている | 自身でアサインされているタスクを確認する時 | |
ADR | タスク管理という軸ではないが、議論したことを書いておく ・専用のリポジトリのISSUEを表示している ・GitHub Discussionsでも良い |
議論の場 |
Workflows
自由度は低いですが、
Draft / ISSUE / Pull request の操作をHookとして、特定のアクションを行うように設定ができます。
★自身のチームでは、このような設定をしています。
- ISSUE / Pull requeset をProjectsに追加した時、Statusを Backlogに設定する
- ISSUE / Pull requeset をクローズした時、Statusを Doneに設定する
- Pull requeset をマージした時、Statusを Doneに設定する
- ADRのリポジトリに
ラベル: ADR
のISSUEを作成した時、このProjectsに設定する
→ チケットの整理をしたくなるフェーズで Auto-archive items を設定する
ISSUEと Pull requestの紐づけ
ISSUEと Pull requestを紐付けることができ、
これを設定するとマージされたタイミングで紐づいている ISSUEがクローズされます。
Workflowsとセットで使うことで、自動的にステータスをDoneに更新することができます。
★ Pull requestのマージ → ISSUEのクローズ → Custom Fieldsのステータスが Doneになる
※ 注意点としては複数のPull requestを ISSUEに紐づけている場合、1つでもマージされるとISSUEがクローズされてしまう
Insights
Draft / ISSUE / Pull requestの状態を参照し、グラフを作ることができます。
★ 自身のチームではこのような設定をしています。
種別 | イメージ | 説明 |
---|---|---|
Burn Up | 作成されているISSUEとクローズされているISSUEの傾向を確認できる | |
EPIC | Epicごとのタスク量を確認できる(縦軸はチケットの合計) | |
Velocity | Sprintごとの進行速度を確認できる(縦軸はEstimateの合計) | |
Plan | Sprintごとに割り当てられているタスク量を見ることができる(縦軸はEstimateの合計) |
タスクの進め方
自身のチームでは、このようなステップでタスクを進めています。
まずはタスクの洗い出しと見積もりです。
- タスクの洗い出し
- 見積もり
↓ スプリントごとにタスクのアサイン〜開発〜整理を繰り返す
- タスクのアサイン
- 開発
- タスクの整理
タスクの洗い出し
スムーズに見積もりを行うために、何をどこまでやるかが整理できてると良いです。
なのでチケットに概要、どこまでやるかなどを書くルールにしています。
タスクの範囲が曖昧だと見積もりがブレがちになります。
## 概要 ◯◯を設定できるようにしたい ## やること - ◯◯が設定できるようになってる - backendと疎通し、DBにデータが保存できるようになっている - mainブランチにマージできている ## 補足 - GraphQLスキーマは決定している状態からスタート
見積もり
下記のようなルールで決めていきます。
- チケットの重さは 1, 2, 3, 5, 8, 13, .. (フィボナッチ数列)で書き、人日では表さない
- チケットの重さは 相対評価
- タスクA が 2で、タスクB が 8だった場合、B の工数は A の工数の 4倍あると見積もる ○
- タスクCが 2よりもかかりそうだけど、5まではいかないなあ。。と思ったら 3を設定 ○
- タスクをこなしていくと徐々に成熟していくイメージ
- 最初のうちはマトリクスを作って意識統一する
- 1: 数分で終わり、やる内容は明確、リスクがない
- 2: 数時間で終わり、やる内容は明確、リスクがない
- 3: 1日で終わり、やる内容は少し整理が必要、リスクがほとんどない
- 5: 数日で終わり、やる内容は整理が必要、リスクを考慮
- 8: 1週間で終わり、やる内容は複雑、リスクがある
- 個人の裁量で決めず、チームで決定する
- あの人だったら慣れてるから 1日で終わりそうだけど、、自分はもっとかかるかも ×
- (ブラウザでプランニングポーカーをするサービスがあるので、そちらを活用する)
- あの人だったら慣れてるから 1日で終わりそうだけど、、自分はもっとかかるかも ×
- できる限り小さい数字にする
- 小さくするのは手間だったりするので、手間にならない程度に分解する
- 分解することでタスクの解像度が上がる ○
- 小さくするのは手間だったりするので、手間にならない程度に分解する
チームで決められた値を見積もりに使うことで、
スプリント内でチームがどれくらいチケットを消化できるかが見えるようになります。
現状の課題と今後の展望
運用していると下記のような課題点が出てきました。
- サブタスクを作りたい
- 少し大きなチケットを消化する際にチケットを分けたくなることもあるが、現状サブタスクが作れない
- docs.github.com
- 2023年10月時点でプライベートベータ
- docs.github.com
- 少し大きなチケットを消化する際にチケットを分けたくなることもあるが、現状サブタスクが作れない
- バーンダウンチャートが見たい
- いまの進行速度だといつごろ開発が完了するのかを見たくなるが、現状見れない
Slice byは2023年8月に追加されて使いやすくなったように、今後の進化に期待です。 github.blog
今後の展望としては Qaseのようなテスト管理ツールと連携し、
自動テストの実行と絡めた バグチケットの連携まで出来るようになれれば良いなと思っています。
まとめ
タスクのチケット化・見積もりをする癖をチームに作るのが最初の課題かなと思います。
- スプリントごとにやることを決め、そのチケットを見ながら朝会などで会話する
- スプリントでどの程度タスクをこなせたのかを測り、いつ頃までに開発が完了するのかが分かるようになる
このようなフローになればチームの透明性も確保できて良い感じです◯
GitHub Projectsで 小中規模の開発に十分耐えられるので、ブラッシュアップしながら継続して使っていきたいと思います。
さいごに
一休では、ともに良いサービスをつくっていく仲間を募集中です!
カジュアル面談も実施しているので、お気軽にご応募ください。