GitLabでプロジェクト管理する方法ついて調べる

GitLabでの管理の構造

Issue(Epicの中のプロセス単位)

• 最小単位のタスクや課題を登録
• ラベルを活用してカテゴリ（例: bug enhancement infra）や担当部署を整理
• AssigneeとDue Dateを設定して責任と期日を明確化

Epic(大きなテーマやプロジェクトの単位)

• 複数のIssueを紐づけることが可能
• Epicで階層構造を持たせることもできる

Milestone(期間軸の管理)

• ある意味のある期間(四半期だったりイテレーションの単位)に対応させる
• EpicやIssueをMilestoneに割り当てることで、この期間で何を完了させるかを可視化する

Board(進捗管理)

• カンバン形式で管理が可能
• ラベルや担当者ごとにカスタマイズできる
• 定例MTGでBoardをベースに進捗確認するのが良い

プロジェクト管理例

Wikiを中心にした定例運用

• 定例のアジェンダや決定事項をWikiに集約
  • フロー情報としてしか残らないため、どこかに残したい場合は次のような対応としたい
    • IssueやEpic、Milestoneに関わる情報の場合はそこに追記し、どの定例での決定事項かを記載する(できればリンクを貼る)
    • プロジェクト全体的なことであれば、プロジェクトルールなどのドキュメントを作成してそこに記載するようにする

イテレーション単位で対応することを計画し、Epicに切り出す

• 各イテレーション単位で対応するテーマを整理する
• それをイテレーションの中での最上位のEpicとして持たせる

Epicの中でどのように進めていけるかを整理する

• スタートとゴールからインプット、プロセス、アウトプットを整理していく
  • プロセスには必ずインプット、プロセス、アウトプットがあるため、そこを丸っと洗い出す
• プロセスの単位で子Epicを作成する
  • 一つのプロセスの解像度が荒い場合は専門家に聞くか、サブプロセスを定義して孫Epicを作成していく
• そうして全てのプロセスをEpicで表現し、インプットとアウトプットの依存関係で整理する

Epicの中でIssueを作成し、進捗を追えるようにする

• 最小のEpic=Work Package、IssueがActibityとする
• Issueの中でどんな作業を行えばいいかを整理し、Start Date,Due Dateを記載する
• AssigneeとReviewerを登録し、誰がそのIssueに責任を持っているかをはっきりする
• 定例会の中ではIssueのAssigneeに説明を求めるようにする