msawady’s engineering-note

なにも分からないエンジニアです。

【GitHub】【タスク管理】GitHub Project を使って開発リーダーをやってみた

Task Management GitHub

はじめに

  • 1月くらいから React-Redux を利用したフロントエンド開発のリーダーをやりました。
  • 自社ではタスク管理にJIRA や Redmine を使うのが定番ですが、今回は実験的に GitHub Project を使ってみました。
  • 一通り開発が終わったので感想などを書いていこうと思います。
    • GitHub Project の利用を考えている方の参考になると幸いです。

どんな感じのプロジェクトだったか

概要

  • すでに導入しているシステムのエンハンス
    • サーバーサイドは導入済みのシステムがある
    • フロントエンドは大幅刷新に向けた PoC が終わった状態
  • 開発期間は 3ヶ月
    • 画面開発、および打鍵も含めた単体テストまでが開発チームのスコープ
  • フロントエンド開発メンバーは 4人
  • 2週間ごとのイテレーション開発

GitHub Project の使い方

ルール

  • Issue を上げるときに Project/Milestone を指定する
  • 上がっている Issue に紐づく Pull Request は Project を指定しない
    • Issue を上げるほどでもない修正は直接 PR を上げて Project を指定する
  • PR は Issue へのリンクをする(nnnとするだけなので簡単)

Milestone

  • 各イテレーションごとに Milestone を作成
    • タスク(Issue) に Milestone を設定してスケジュール管理

レーン

  • 開発中はTo do -> Doing -> Review -> Done
  • 終盤に BugFix が増えてきてからは To do と Doing の間に Triagedレーン を追加

Tag

デフォルトでこのようなタグが用意されています。
これに加えて、「ボタンにアイコンをつける」のような細かい改善タスクを捉えてスキマ時間で取り組むために、自分たちのプロジェクトでは以下のものを追加しました。

また、終盤に BugFix が増えてきてからは以下の2つの Tag を追加しました。

  • flash fix: パッと直して大丈夫なバグ
  • need discussion: 修正内容を議論/検討してから直したいバグ

開発リーダー(自分) が Issue の内容を確認(Triage)してからメンバーが対応することで、
need discussion なバグの修正方針を事前にすり合わせることが出来て、レビューでの突き返しが減りました。

GitHub Project への感想

総じて、機能が足りてないところはあるが、非機能がイケてるから使いやすいという印象です。
小規模なプロジェクトだと、JIRAやRedmineよりも足回りが良いので使いやすいように思いました。

良いところ

  • デフォルトでカンバンがメインUIなので、状況把握が楽
    • カンバンでの Tag の見やすさなど、総じて UI が良い感じ
  • Issue, Pull Request のリンクが楽。#nnn ですぐにリンクができる
    • Issue の検討段階の議論と、実装段階の議論がすぐに結びつく
    • 他の Issue から参照するのも楽なので、他の Issue での議論の内容を活かしやすい
    • 既存のコードへのパーマリンクも出来るので議論自体もしやすい
  • ある程度は自動でレーンを動いてくれるので、ステータス変更忘れを防げる

イマイチなところ

  • カンバンで Milestone でのフィルタが出来ない。
  • 一覧のテーブルエクスポートが(機能としては)出来ない。
    • SIer のエンジニアなので「Bug一覧」とかをデフォルトで csv エクスポートとかできると嬉しい
    • APIリクエストして、Python でゴニョゴニョして...とかは出来ますし、やりましたが...ねぇ？

別に... なところ

  • Commit と Issue のリンクができる
    • あ、やってんな、とは思うけど、最終的に Pull Request の単位で見るので....
  • ワークフローの制御(クローズできるのはリーダーだけ、みたいな)が出来ない
    • そもそも、ワークフローと実際の業務が合ってないので、別に困らない
      • 検討 -> 実装 -> テスト とリニアに進むとは限らない
    • その観点だと、チェックリストが埋まってないとクローズ出来ない、とかは合っても良い
      • ドキュメント修正・実装修正・テスト、3つがすべて完了していること、みたいな？

まとめ

小規模な開発チームであれば、GitHub Project はオススメです。特に、Issue の検討段階の議論と、実装段階の議論がすぐに結びつく はめちゃめちゃ大きいと感じました。
大規模なチームではレポーティング周りの機能がちょっと物足りないかもしれませんが、APIが充実しているので必要に応じてツールを作っていけば対応できそうです。