GitHub Issues/projects
チーム開発でGitHub issues/projectsを使ってみたところ、使い勝手が良かったのでメモ。
### 前提
・コーディングブートキャンプの最終課題に使用
・フルスタックエンジニアの初学者がはじめてプロジェクト管理にissue登録を使ってみた
・開発期間：約4週間
・チーム人数：4人
・各自が開発機能別にフルスタックで担当
project登録
カンバン方式を採用。
issueと紐づけているのでPRがマージされてクローズになると、自動的に「Done」へ移動。
全体の工数管理に利用。
マイルストーン設定
４週間あったのでマイルストーンを週ごとにひとつずつ設定し、マイルストーン別にタスクを登録。
これやっておくと期日までにできておかないといけないマイルストーンの進捗が％で把握できるのでわかりやすかった。
GitHub issues
issue登録にはラベルを活用。
4人チームだったので、issueタイトルの頭に「A/B/C/D」をつけて、どれが誰のタスクかひと目でわかるように登録。（「A-1」なら〇〇さん、「B-4」なら△△さん...という感じ）
プルリクエスト
PR出す際には、統一フォーマットを用意。
マージされたら自動でクローズするように
「closes # issue番号」をPRに記載。
コードレビュー
PRのレビュワーは学習効果を高めるため、2人ペアで相互にレビューをするように設定。
コードレビューしてくことで、あれ？と感じる部分などもあり、学習をはじめた当初から理解度が上がっていることも実感できた。
まとめ
GitHub projectsとissuesを使いこなすためには最初のフォーマット決めが大事。時間かかるがそのあとに起こる混乱を防ぐためには必要なコスト。しっかり全員でどう進めるかの認識合わせをすることが大切
今回使いきれなかった機能も今後試してみたい