株式会社くむ

Appearance

課題管理方針 ​

このページでは、案件における課題管理の方針について定義します。

課題管理ツール ​

GitHub IssuesとProjectsで課題管理を行います。

NOTE

お客様によって、TrelloやPivotal Tracker、ExcelやGoogleスプレッドシートなどでの管理を希望される場合がありますが、開発効率担保の観点から原則対応致しかねます。

課題のステータスと開発の流れ ​

課題（Issue）のステータスは以下の通りです。

  1. Spec Review（起票直後のステータス）
  2. TODO（開発未着手段階のステータス）
  3. In Progress（開発着手中のステータス）
  4. Impl Review（コードレビュー段階のステータス）
  5. Shipping（Pull Requestマージ時のステータス）
  6. Done（リリースと本番での動作確認完了後のステータス）

開発の流れは以下の通りです。開発者は下記の活動を行う際に、上記の中から適切なIssueのステータスを選択して更新します。

起票前後 ​

新たな開発課題は、GitHub Issuesに登録します。起票は誰が行なっても構いません。その開発が最も関連するリポジトリのIssuesに登録します。起票後に別のリポジトリに紐つけるべきだと判明した場合は、そのIssueをトランスファーします。

GitHub Actionsのワークフロー（以下、GHA）により、起票されたIssueは自動でProjectsに登録されます。この際にProjectsのメタデータの設定や優先度設定を行います。

1. Spec Review ​

登録されたIssueに担当者がアサインされると自動でPull Requestが作成されるGHAが組まれています。アサインされた開発者はこのPull Requestに仕様と検査仕様を記述します。この段階で仕様が大きすぎる場合にはIssueの分割を検討します。

仕様と検査仕様は、Pull RequestのDescriptionに記述します。原則プレーンテキストで記述し、必要に応じてスクリーンショットの添付やMermaidによるチャート作成をします。

NOTE

PowerPointなどの外部ツールを用いて作図する場合は、その図だけでなく、ファイルも添付して下さい。

仕様と検査仕様の記述が完了した段階で、仕様レビューを行います。仕様レビューは、Issueのコメント欄で行います。レビューの結果、仕様に修正が必要な場合は、Issueの内容を修正し、再度仕様レビューを行います。

NOTE

仕様レビューは、コードレビュー段階での大きな手戻りを防止する狙いがあります。軽度で自明な変更の場合は、その旨を記述してスキップできます。

2. TODO ​

Spec Reviewを終え、着手可能な状態となったIssueのステータスです。着手を始めたらIn Progressに変更します。

3. In Progress ​

開発中のステータスです。Pull RequestはDraft状態です。

開発が完了したら、セルフレビューを行います。セルフレビューでは、以下の活動を行います。詳しくはレビュー基準を参照して下さい。

  1. 全差分へのコメントと開発者自身のApprove
    • GitHub Actionsのボットが作成したPull Requestでない場合、Approveができないため、セルフレビュー完了コメントを残します
  2. 実装が検査仕様を充足するか確認
  3. Pull Requestにauto-testラベルを付与しCIに問題がないことを確認
  4. デモ動画とエビデンスの添付
    • 既存の機能が改修の影響を受けず正常動作していることを動画で残す必要はない
    • 全ての検査仕様を満たしていることを動画で残す必要はない
    • 1分以内、最大3つの動画まで
    • 音声の入れられるスクリーンキャストツール

セルフレビューが完了したら、以下の操作を行います。

  • Pull Requestにレビュアーをアサインし、レビュー依頼をメンション
  • ステータスをImpl Reviewに変更
  • Pull RequestをDraftからReady for reviewに変更

4. Impl Review ​

コードレビュー中のステータスです。

以下の条件を満たす時、最後のレビュー者がmainブランチにマージします。1と2が同一人物でも構いません。

  1. 担当者以外の1人以上の開発者のApprove
  2. 情報処理安全確保支援士のApprove

マージ後、GHAにより本番環境へのリリース用Pull Requestが自動で作成・更新されます。

5. Shipping ​

Pull Requestがmainブランチにマージされ、リリースと本番環境での動作確認を待つ状態です。リリース用のPull Requestがマージされると、リリースとリリースノートの作成がされます。

6. Done ​

リリースと本番環境での動作確認の完了後に、Issueをこのステータスに設定します。原則的にIssueはReopenしません。もし、再度対応が必要な場合は、新たなIssueを起票し、古いIssueを関連づけてください。

スプリント ​

スプリントは1週間とします。開発者はこの単位で課題対応を計画、実行、見直しを繰り返します。

NOTE

当社はスクラムのコンセプトから学びますが、スクラムは実施しません。

参考: スクラムガイド（2020年版） End Note

While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Issueに記述すべき内容 ​

  • 外型的コミュニケーション
    • 要求仕様、素材要求など

Pull Requestに記述すべき内容 ​

  • 設計、検査仕様、ADR、進捗
    • 進捗は、残タスクのリストなどは可、作業日報は不要
    • × 単純な会話、業務連絡など