読者です 読者をやめる 読者になる 読者になる

今更ながGitHubのカンバン機能「Project」を使って見る

GitHub Projects

http://dev.classmethod.jp/tool/git/github-projects/

目的

プロジェクトで、ClientとServer間のコミュニケーションの効率化/作業の見える化をしたかった

概要

ディレクターとデザイナーとのコミュニケーションは別ツールを使用。 Projectは基本プロジェクトのエンジニア間での連携で使用するつもりです。

GitHub Projectは大きく分け3つの概念があります。

  • Project
  • Card
  • Note





Projectについて

Projectは名前のとおりです。発足したプロジェクト名を記載してください Projectの単位ですが2通りあります。

  • organization単位(Organizationプランのみ)
  • repository単位

どちらでもいいと思いますが、 organization単位で作成しておくと、一目でどういうプロジェクトが 動いているのかを確認できるので私はこちらをお勧めします。

Cardについて

CardはProjectに1対多で紐づく概念です。 役割や概念の違いで分けるといいと思います。

Noteについて

NoteはCardに1対多で紐づく概念です。 役割や概念に関係するTopicsを記載するものと考えていいと思います。

またNoteはRepositoryのIssueの情報と紐づけることができます。





ルールExample

こういうツール系はある程度ルールを決めておくと運用しやすいですね

Projectのルール

  • 命名規則
    • {事業部名}_{サービス名}_{Version}
    • もちろん英語

Cardのルール

  • 画面機能構成がわかるカードを1つ
  • 大枠の仕様がわかるカードを1つ
  • あとは役割別でCardを作成(ex: Android, iOS, API etc)

Noteのルール

  • 命名規則
    • [画面機能構成名][新規 or 修正 or 要望]-{簡潔なタイトル}
  • 着手中のものはIssueと紐付けて自分をassigneesとして登録
  • 要望のものはIssueと紐付けて要望に対応してほしい人をassigneesとして登録
  • CloseしたIssueのNoteはその機能がリリースされてからCardから削除する

Issueの運用ルール

  • 基本的に直接Issueは登録しない(NoteをIssueに紐づける)
  • タイトルはNoteの命名規則に従う(自然と統一されるはず)
  • ボールを持っている人がassignees
  • labelはNoteのルールの[新規 or 修正 or 要望]に従う
    • 新規 ラベルなし
    • 修正 bugs
    • 要望 help_wanted

Commitルール

  • CommitのタイトルはIssueのタイトル名#nでコミット(Issueのタイトルコピペ)
  • 詳細を記載するっ場合は改行して記載





良いなと感じているところ

プロジェクトを開くと開発で必要な情報がどこにあるのか一目でわかるかも? 誰が今何をやっているのかわかるので、自分のタスクの優先順位づけがしやすくなる?

足りないと感じているところ

期日を設定しにくい(他のツールと組み合わせたりして改善?) まだ運用の準備段階なので何とも言えないですが、

運用し始めてからも改善していけたらと思います。