Test Governance グループのワークフロー

このページには Test Governance グループの公式ワークフローが記載されています

Test Governance ワークフロー

workflows.png

ワークフローラベルの定義

これらの定義は Infrastructure Platforms プロジェクト管理 のガイドラインに基づいています。

workflow-infra::Triage

  • 目的: すべての新しい Issue のエントリーポイント。
  • ここに置くもの:
  • 整理:
    • 優先度が割り当てられた Issue は workflow-infra::Proposal に移動すべきです
    • 1 つの Issue に複数のワークフローラベルを付けてはいけません
    • 優先度ラベルを持つ Issue を Triage 列に残してはいけません
    • 現在、Issue 作成時にこのラベルを自動割り当てするメカニズムは存在しません
  • 詳細なプロセス情報については、#processes-and-their-frequencies セクションを参照してください。

workflow-infra::Proposal

  • 目的: チームがリファインメントプロセスを開始する場所。
  • 整理:
    • Issue は優先度の高い順に整理されます
    • 同じ優先度の Issue は作成日順（古いものが先）に並べられます
    • リファインされた Issue は workflow-infra::Ready に移動すべきです
  • 詳細なリファインメントプロセスについては、#processes-and-their-frequencies セクションを参照してください。

workflow-infra::Ready

  • 目的: すでにリファインされた Issue のみを含みます。
  • 整理とルール:
    • リファインメント中に Issue を複数の子アイテムに分割する必要がある場合は、Epic に格上げします。この列には子アイテムのみが表示されます
    • 同じ親 Epic の Issue はまとめてグループ化する必要があります
    • 担当者が割り当てられているが、すぐには作業されない Issue は上部に置き、優先度順に整理します
    • 担当者が割り当てられていない Issue はその後に続き、やはり優先度順に整理します
    • マネージャーとプロジェクトリードは必要に応じて Issue の順序を再整理する責任があります
  • Issue を担当する場合: チームメンバーは:
    • 自分を割り当てます（まだ割り当てられていない場合）
    • 時間の見積もりに基づいて開始日と期日を設定します（作業の進行に合わせて調整可能）
    • Issue を workflow-infra::In Progress に移動します
  • 注意: 担当者のいる Issue は常に上部にあります。なぜなら、それらは今四半期に計画されているからです。チームメンバーが割り当てられた Issue をすべて完了したら、リストの次の未割り当て Issue を担当します。その Issue に将来の四半期ラベルがある場合は、正しいラベルに更新し、マネージャーまたはプロジェクトリードに四半期計画 Issue を更新するよう通知してください。

workflow-infra::In Progress

  • 目的: 積極的に作業が進められている担当者のいる Issue のみを含みます。
  • キャパシティガイドライン:
    • この列の総 Issue 数はチームサイズの 3 倍を超えてはいけません
    • チームメンバーは同時に 3 件以上の進行中アイテムを持ってはいけません
    • これらの制限はチームの生産性・士気・ウェルネスを確保するためです
  • 担当者の責任:
    • リンクされた MR がレビュアーと共にレビュー準備ができたら、対応する Issue を workflow-infra::Under Review に移動します
    • MR がマージされたら、以下のいずれかに移動します:
      • 監視/検証が必要な場合は workflow-infra::Verify
      • 実装が正常に動作していることが確認された場合は workflow-infra::Done（Issue を閉じることができます）
  • 追加アクション:
    • 作業をデモできる場合: 次のデモセッションでのスケジュールを検討する
    • フォローアップ作業が必要な場合: 適切な優先度ラベルを付けて別の Issue を作成し、適切な列に移動する
    • ブロックされた場合: workflow-infra::Blocked に移動し、次のステップを決定するためにプロジェクトリードまたはマネージャーとコミュニケーションする
    • 追加の MR が必要な場合: 適切なラベルを持つ新しいリンク Issue を作成する
    • より高い優先度の作業（P1 の可能性あり）に再割り当てされた場合: 現在の Issue を workflow-infra::Stalled に移動し、より高い優先度の Issue を完了した後に戻るか、マネージャーと協力して優先順位/担当を変更する
  • ヒント: 現在の Issue が Under Review に移動したら、workflow-infra::Ready から新しい Issue を担当することを検討してください。

優先度ラベルの定義

  • GitLab の本番 P1: 絶対に重大。これらは通常、リアルタイムで顧客やデプロイメントに影響する本番インシデントです。他のすべての P1 より優先されます。したがって、直ちに割り当てられ、作業される必要があります。
  • チームの priority::1（P1）: 非常に重要。これらの Issue の完了は、ビジネスに直接影響を与える別の高優先度プロジェクトの成果に直接影響するか、それをアンブロックします。できるだけ早く割り当て・リファイン・作業を開始する必要があります。同四半期またはプロジェクト期限のいずれか早い方までに完了することが期待されます。
  • priority::2（P2）: チームのミッションとロードマップにとって重要。すべての P1 が割り当てられ積極的に作業された後、四半期ごとにリファイン・割り当てされます。1〜2 四半期以内に完了できます。
  • priority::3（P3）: あると便利。次の 3〜4 四半期以内、または時間とリソースが許す場合もしくは P2 に格上げされた場合に検討できます。
  • priority::4（P4）: あれば良い。会計年度内に取り組む予定はありませんが、時間とリソースが許す場合に高い優先度に格上げできます。

プロセスとその頻度

トリアージ

  • 理由: 適切な優先度ラベルを追加することで、重要度や緊急性によって Issue/リクエストを評価・分類し、どれが即時対応を必要とするかを判断するため。
  • タイミング: EM および/またはスタッフエンジニアが決定
  • 誰が: EM および/またはスタッフエンジニア
  • 対象: 新しく作成された Issue および/または RFH
  • 方法:
    • 拒否または別チームにリダイレクトする Issue を特定します。workflow-infra::Cancelled ラベルを適用して拒否された Issue を閉じます
    • 受け入れた Issue に優先度を割り当て、降順（P2、P3、P4 の順）で workflow-infra::Proposal に移動します
    • P1 Issue は即時リファインメントのために直接 workflow-infra::Proposal に移動します（トリアージ不要）。P1 のリファインメントはできるだけ早く、理想的には同じ週以内に行うべきです。P1 Issue は常にどの列の一番上に置く必要があります
    • プロジェクトの成功を所有する DRI を割り当てます。DRI はこの決定を下すために他のチームメンバーや他のチームにコンサルテーションを求めることができます

リファインメント

  • 理由: チームが価値あるアイテムに取り組み、曖昧さを減らし、継続的なコラボレーションと改善を促進するために、優先順位付けされた・明確な・詳細なプロダクトバックログを維持するため。また、チームメンバーが新しいタスクに対して利用可能になったときに取り組める準備の整った作業の健全なプールを確保するため。
  • タイミング: 毎週、同期（すべてのタイムゾーンをカバーするために 2 セッション）と非同期を交互に
  • 誰が: Test Governance チーム
  • 対象: Epics、Issues
  • 方法:
    • ミーティングアジェンダは毎週リファインすべき Issue と Epic で作成・用意されます。リファインメントセッション中に、チームは作業する Issue を選択し、Small 以上のサイズの Issue のタスクを分解します。目標は 1 つの Issue を閉じるために 1 つの MR のみが必要なことです。複数の MR があれば、複数の Issue が必要なことを示します。これは GitLab のイテレーション価値を尊重するためです。
    • 準備の定義（DoR） - リファインされた Issue は以下を持つ必要があります:
      • 完了の定義を持つ 1 つの明確なタスク
      • フィボナッチ数列を使用した重み: 1、2、3、5、8、13（時間をかけてチームが改良する）
      • 解決策と成果についての実装に関わるすべてのチームメンバー間での整合
    • リファインメント中に、チームが Issue にブロッカーとなる依存関係があると判断した場合、workflow-infra::Blocked に移動します。アンブロックするために何が必要かを明確に述べるか、DRI・EM・スタッフエンジニアと協力して解決またはアンブロックしてください。
    • プロジェクトに担当者が付いたら、リファインメントアジェンダに含める必要はありません。プロジェクトの DRI はプロジェクトの進め方とコミュニケーション方法を自分たちで決定できます。

四半期計画

  • 理由: 四半期計画は、チームメンバーが次の 3 ヶ月に取り組む内容とその順序を特定する戦略的なイベントです。明確さと透明性を提供し、コラボレーションを促進し、予測可能性を高め、チームが短期的な視点に迷い込まないようにするためのものです。
  • タイミング: 四半期ごと
  • 誰が: Test Governance チーム
  • 対象: Epics、Issues
  • 方法:
    • 理想的には計画 Issue を事前に十分に用意すべきですが、これは新しいワークフローを完全にリファインして採用した後の将来のことです。
    • チームは現四半期の最終週に、翌四半期の計画 Issue を確定します。
    • 同じ Epic の Issue は同じ四半期に検討すべきです。Epic のすべての子アイテムは Epic の優先度を継承する可能性があります。
    • 現四半期の最終週に、次の四半期の計画を開始し、今四半期に何が起きたかを振り返る（レトロ Issue を確認する）ための同期通話を行います。この通話の後、現在の四半期計画 Issue を閉じます。
    • 計画 Issue の例: https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/3930

振り返り

  • 理由: 振り返りは、チームメンバーが作業を振り返り、何がうまくいったか・何がうまくいかなかったかを特定し、将来の作業サイクルのプロセスと成果を改善するための実行可能な計画を作成するための専用スペースを提供することで、継続的な改善を促進するためのイベントです。
  • タイミング: 月次だが四半期ごとにまとめる
  • 誰が: Test Governance チーム
  • 対象: Epics、Issues、フィードバック、改善点、提案
  • 方法:
    • 各四半期には対応する 3 つのレトロ Issue があります。四半期の各月に、その月のレトロ Issue を開始・完了します。
    • チームメンバーは対応する月が始まったときにレトロ Issue に割り当てられます。
    • レトロ Issue は、思考・感情・フィードバック・不満を新鮮なうちに記録する場所として機能します
    • 各月の終わりに、対応する振り返り Issue がまとめられます。最初の 2 つは閉じられ、そのまとめが四半期最後の振り返りに引き継がれます。四半期の終わりに、すべてのまとめ・学んだ教訓・四半期をまとめるための実行可能なアイテムを確認する同期通話を行います。
    • 注意: 必要に応じてアドホックなレトロ Issue を作成できます。
    • レトロ Issue の例: https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/3931

チーム同期・知識共有

  • 理由: 知識共有を促進し、非同期の更新を提供し、チームのつながりを構築するため。
  • タイミング: 隔週
  • 誰が: Test Governance チーム
  • 対象: 知識共有・チームの注意事項・交流
  • 方法:
    • このミーティングを使用して、以下のトピック（これに限定されない）を同期します:
      • チームの運営方法
      • チームのコミットメント
      • 知識共有
      • チームメンバーがチームの注意を喚起したいその他のトピック
    • 更新とコメントは非同期的に追加されるため、ライブ会話はリアルタイムの議論が必要な項目に集中できます。

スタンドアップ

  • 理由: 進捗を確認し、ブロッカーを特定するため。
  • タイミング: 毎日
  • 誰が: 更新のある Test Governance チームメンバー
  • 対象: 重要な更新・助けを求めること
  • 方法:
    • チームメンバーは専用の Slack チャンネルで更新を共有するための Slack 通知を受け取ります。
    • 重要なことが何もなかった場合は更新をスキップしても構いません。
    • ブロックされているかまたは行き詰まっている場合は共有し、助けを求めることが重要です。

パイプライン DRI

  • 理由: インシデントやさまざまな Issue を迅速に解決し、重大な財務的または評判的損害を防ぐために高可用性を確保する SET のオンコール形式。
  • タイミング: タイムゾーンに応じて SET の週次ローテーション
  • 誰が: パイプライン DRI 当番の Test Governance チームメンバー
  • 対象: 複数の環境で実行されるスケジュールパイプライン
  • 方法: パイプライン DRI の責任 を参照してください。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License