プロジェクト管理ツールとしてGitHubを"普通に"使う
※ここでは「プロジェクト」をチームで達成する計画という意味で使っていて、「 Project 」をGitHubのカンバンツールという意味で使っています。
タスク管理にGitHubを使う一連の記事の中の一つです。今回はプロジェクト管理ツールを新たに導入しなくても、GitHubの機能を普通に使うだけで実はうまくいったという話です。
- 情シスのタスクをGitHubのissueで管理するようにしたら捗った
- プロジェクト管理ツールとしてGitHubを"普通に"使う ←ここ
- Google Cloud Functions (Python) を使ってみた
- GitHub App を作ってPythonからAPIを叩いてみた
- Google Apps Script から Google Cloud Functions のHTTPトリガーを実行してみた
今自分が関わっている開発プロジェクトではアサイン時はミニマルで、自分とCTOで設計しつつスプレッドシートで１週間毎の計画をたてるところから始まりました。Trelloを検討したりWrikeを導入してみたり試行錯誤しながらやっていましたが、結果的に「GitHubの Project で良いのでは？」ということで落ち着きました。
タスクは Issue に集約する
基本的にタスクは細かいものも含めて全て Issue を立てます。例えば以下のようなものを含みます。
- 通常の To Do
- 仕様決め
- バグ報告
- リファクタリング
- 個人的に気になっていること
- リリース作業
- 通しテスト
- ...
とりあえず必要だと思われるものは立てて、それぞれに応じたタグを付けておきます。立てたものはあとからスプリントプランニングのときなどに、やるかやらないか・工数見積・優先度などを考慮してバックログに組み込みます。
Issue の中で細かくやることがある場合はチェックリストを作っておきます。そうすると Issue 一覧画面などでインジケーターを表示してくれます。
Issue のテンプレートを用意しておく
GitHubの
Issue
はテンプレートを用意することができます。
1
具体的にはリポジトリのルートディレクトリ直下に
.github/ISSUE_TEMPLATE.md
か
.github/ISSUE_TEMPLATE
というディレクトリの下に任意のファイルを作成することで実現可能です。
---
name: Sample template
about: サンプルテンプレート。
title: ''
labels: ''
assignees: itkr
---
## 概要
issueの内容
ちなみに
.github/PULL_REQUEST_TEMPLATE.md
で Pull Request のテンプレートも作成できます。
## 概要
## チェックリスト
- [ ] テスト
- [ ] ドキュメント
テンプレートを作っておくことで足りない情報を防ぐことができ、このプロジェクトで作っているサービスの利用者（社内の人）もバグ報告などで迷うことが少なくできます。
全体の Project とスプリントごとの Project を作成する
あまり活用しているという声を聞いたことがないのですが、実はGitHubではリポジトリやOrganizationごとに Project というものを複数作成することができます。Trelloを使ったことがある方ならイメージしやすいと思いますが、いわゆるカンバンを作成することができる機能です。
立てた Issue をそのリポジトリ全体の Project と、スプリントごとの Project に配置します。こうすることで全体の Issue がどれくらい溜まっていて、直近のスプリントでは何をしなければならないのかをチームで共有することができます。
スプリントごとに Project を作成することはスプリントごとにやることを把握することに役立ちますが、スプリントごとに「やったこと」を把握することにも役立ちます。基本的にスプリントの終了するときにリリースブランチを切ってデプロイ作業を行いますが、そのデプロイ対象のコミットにタグを付けておいて Project 名とタグ名を一致させておき、簡易的なリリースノートの代わりにできます。
ちなみにプロジェクトは「 A successful Git branching model 」(GitFlow) に従っていてmasterブランチにマージするとCircleCIでテストが通ればデプロイされるようになっています。テストも自動化しています。
Project に To do ・ In progress ・ Done を作る
GitHubが最初から用意している Automated kanban というテンプレートを利用すると
- To do
- In progress
- Done
というカラムが作成されます。これはあとから設定もできますが、このテンプレートで作っておくと Issue を Project に追加すると自動で To do に入り、 Issue をクローズすると自動で Done に入ります。(作業を開始するときは作業者が手動で In progress に移動します)
また、 To do はグレー、 In progress は紫、 Done は緑にインジケーターが表示されるのでその Project がどれだけ進んでいるかを視覚的に把握しやすくなります。
この３つのカラムで足りない場合は状況に応じてカラムは追加します。例えば Waiting など。
まとめ
チームの規模やプロジェクトの進め方によっては、新しく管理ツールを導入することもなくGitHubの標準の機能を普通に使うだけで行えることを紹介しました。
人数が増えて技術者以外の人もプロジェクトに関わってくるとまた別の方法が必要になるかもしれませんが、前の記事にも書いたとおりGitHubに集約するメリットしては技術者が見慣れたUIであることと余計なライセンス料を必要としないことだと思います。また、ツールを行き来して集中力が途切れてしまうのも防ぐ効果もあるのではないかと思います。