インフラストラクチャプラットフォームのプロジェクト管理

プラットフォームにおけるプロジェクト管理

私たちは GitLab のエピックと Issue を使用して、作業の進捗とステータスを伝達しています。 インフラプラットフォームのすべてのチームは、チームメンバーが必要に応じて異なるプロジェクトに貢献しやすいよう、これらのガイドラインに従っています。

プロジェクトはグランドレビューで毎週レビューされます

エピック更新タイムライン

インフラプラットフォームのエピックはGitLab オペレーティングモデル（GOM）と整合しています。多くのエピックは次のいずれかです:

1. グランドレビューエピックの子エピック
2. オペレーティングモデル機能リードエピックにリンク済み

更新スケジュールは、これらのレベルを通じて情報をカスケードするよう設計されています:

• 木曜日 EoD（金曜日 02:00 UTC）: DRI がプロジェクトエピックを更新します（自動化が木曜日 00:00 UTC にプロンプトを送ります）
• 金曜日: リードが木曜日の情報を使用してグランドレビューと GOM 機能リードエピックを更新します
• 月曜日: リーダーシップチームが更新を議論します
• 火曜日: プラットフォームグランドレビューが行われます
• 水曜日: インフラ VP と PM がカスケードされた情報を使用する会社全体のオペレーティングモデルレビュー

このタイムラインにより、E-グループ目標と会社イニシアチブとの整合が確保され、エグゼクティブチームに至るすべてのレベルで戦略的意思決定のためのタイムリーかつ十分に裏付けられたデータが提供されます。

完了したエピックは ~“workflow-infra::In Progress” ラベルを持った状態で「オープン」のままにしてください。 プロジェクトを要約し、完了ステータスを共有するためにエピックの説明のステータスブロックを更新してください。

私たちは自動化を使用して各グループのトップレベルエピックにステータス情報を収集し、エピックのノートからステータス更新を収集します。 この自動化は毎日数回実行され、プロジェクトページに記載されているパイプラインを実行することでトリガーできます。

プロジェクトエピックのステータス更新

プロジェクトエピックで週次ステータス更新が有効になると、ステータス更新の提供方法についての指示を含むコメントが表示されます。

毎週木曜日、プロジェクトの DRI はエピックの説明のステータスブロックを以下のように更新する必要があります:

1. すべての貢献者によるプロジェクトへの費やした時間数を記録します。
2. 前回の更新以降の成果を簡単に強調します。
3. プロジェクトのブロッカーを示します。
4. 計画された次のステップ、または進捗のために必要な軽減策を示します。

プロジェクトエピックには自動的にコメントが生成されてステータスを報告します。 この機能を有効にするには、エピックがこれらのステップに従っていることを確認してください。

エピックのアサイニーは次のようなノートでメンションされます:

@<user> Reply to this note to update the status of your epic for YYYY-MM-DD
...

GitLab Duo エージェントチャットは更新の開始点を生成するのに役立ちます:

1. エピックを読み込み、メンションされているステータスノートに移動します（有効化後）。
2. サイドバーの「GitLab Duo Chat」をクリックし、エージェントモードを有効にします。
3. 以下のプロンプトを使用してステータスノートの更新の下書きを作成します

Please provide a terse high level summary of the last 7 days of activity using the child issues of this epic, highlighting new and issues that were closed in the last 7 days using the following format:

<overview>

:tada: **achievements**:
- ...
:issue-blocked: **blockers**:
- ...
:arrow_forward: **next**:
- ...

Give the status update in raw markdown (preformatted text) and do not use any markdown headings.

プロジェクトが完了したとき

1. エピックは「オープン」のままで ~“workflow-infra::In Progress” ラベルを保持し、次のプラットフォームグランドレビューのためにまだリストされるようにします。
2. DRI はエピックの説明を更新し、Participants セクションを含む各セクションが最新であることを確認する責任があります。
3. DRI はクロージングステータス（最終ステータス更新）を作成します。これには以下が含まれます:
   1. 元の問題
   2. 行われた変更の簡潔な説明
   3. プロジェクトが完了した今の影響についての情報
   4. デモ/ウォークスルービデオへのリンク
   5. グランドレビュアーにエピックをクローズするよう指示する案内
   6. 絵文字および/または称賛は歓迎されますが必須ではありません
   7. 注: プロジェクトの最終週に作業した時間数をステータス更新テンプレートの時間追跡フィールドに更新することを忘れないでください（エピック全体の累積時間ではありません）

完了したエピックは、次の Platforms Grand Review（GitLab Unfiltered アカウントでアクセス可能なプレイリスト）でレビュー、祝福、完了への更新、クローズが行われます。

クロージングステータスは年末チームサマリーを作成する際に役立ちます。

エピック

エピックには常に以下のセクションが必要です:

• 問題の声明
• プロジェクト完了に責任を持つ個人（DRI）
• 定義された終了基準
• 前のステータス更新とその他の記録すべき関連情報を含む開発ログ
• エピックの最新ステータス更新を含むステータス更新
• 開始日と推定完了日

セクションのフォーマット

エピックの DRI はアサイニーにし、エピックのアサイニーは 1 人のみにしてください。

エピックの説明では以下の見出しと構造を使用してください:

参加者セクション

このセクションは動的で、現在エピックの作業に貢献している人々を含みます。 DRI と EM は参加者リストを適切に更新する責任があります。

### Participants

- @participant1
- @participant2
- @participantN

ステータスセクション

ステータスセクションはサブエピックで自動的に生成されます。 詳細についてはプロジェクトエピックのステータス更新セクションを参照してください。

これは Issue であるべきか、エピックであるべきか?

私たちはエピックを使用して、特定の目標を達成したり特定のインパクトにつながる一連の作業を一つのテーマの下に統合できることを示します。 エピックは 2 週間以上かかる可能性が高い、または既に 2 週間以上続いている任意の作業セットをカバーできます。 その後、その目標に向けた進捗を定期的に報告し、完了したときに作業のインパクトを明確に示すことができます。

特定の Issue タイプ

是正措置とセキュリティ Issue

私たちは ~"corrective action" または ~"security" とラベル付けされた是正措置とセキュリティ Issue にも取り組んでいます。 これらの Issue では、特定の SLO を満たすために severity::* ラベルが設定されます。

• セキュリティ Issue については深刻度別の解決までの時間の表を参照してください
• 是正措置の SLO は現在品質の定義に基づいています:

ラベル

インフラプラットフォームチームは以下のラベルセットを使用しています:

ワークフローラベル

私たちはスコープ付きワークフローラベルを活用して、作業のさまざまなステージを追跡します。 これらは各 Issue の作業の進行を示し、ブロッカーを取り除いたりフォーカスを変更しやすくします。

Issue はすべての状態を経由する必要はないかもしれませんが、標準的なワークフローの進行は以下の表の上から下への順序です:

状態ラベル	説明
	デフォルトラベル。タスクが提起され、正しいアクション、必要な作業、またはチームオーナーシップを決定するための努力が必要です
	トリアージ後に提案が作成され、レビューのために提出されます。 さらなる質問やブロッカーがない場合、Issue を「準備完了」に移動できます。
	提案が完了し、Issue は作業のピックアップを待っています。
	Issue が割り当てられ、作業が開始されました。 進行中は、後のステージで実行される検証のための手順を含めるよう Issue を更新してください。
	Issue はレビュー中の MR があります。
	MR がマージされ、初期の問題が解決されたことを確認するために変更の影響を確認するのを待っています。
	Issue は最新のグラフと測定値で更新され、このラベルが適用されると Issue はクローズできます。

他に重要な 3 つのワークフローラベルがあります:

状態ラベル	説明
	Issue の作業は外部要因または Issue を解決しないという決定により放棄されます。このラベルを適用した後、Issue はクローズされます。
	作業は放棄されませんが、他の作業の優先度が高いです。このラベルを適用した後、チームのエンジニアリングマネージャーが Issue でメンションされ、優先度を変更するかさらなる支援を見つけます。
	作業は外部依存関係または他の外部要因によりブロックされています。可能であれば、ブロッキング Issue も設定する必要があります。このラベルを適用した後、ラベルを削除できるまでチームによって定期的にトリアージされます。

カテゴリラベル

私たちはスコープ付きカテゴリラベルを使用して、実施される作業のタイプまたは領域を分類します。 これらのラベルは機能的カテゴリによって Issue を整理してフィルタリングするのに役立ちます。

gitlab-org グループのラベル

ステージグループは type ラベルを使用して gitlab-org グループのプロジェクトのマージリクエストにラベル付けします。 ステージグループに作業を実施させる必要がある場合、Issue の作成時に関連するステージグループラベルを適用するのが最善です。

トリアージ Ops

gitlab-com/gl-infra 配下のラベリングとボット通知については、gitlab-triage と triage-ops プロジェクトを使用しています。 ラベリング、SLO の適用、ワークフローラベル管理については、インフラプラットフォームのプロジェクトに対して均一に設定された共通ポリシーがあります。 追加のポリシーを追加する方法の詳細についてはプロジェクトの README.md を参照してください。

レトロスペクティブ

四半期末または大きな成果物の完了時に、チームはレトロスペクティブを実施して学びを記録する必要があります。 レトロスペクティブに決まったフォーマットはありませんが、エンジニアリングマネージャーはGitLab レトロスペクティブガイドラインを把握しておく必要があります。 レトロスペクティブ DRI はアクションのリストを特定し、Issue の説明のアクションサマリーセクションに統合します。

アクションを特定するプロセス:

1. 各スレッドにアクションをタイトルとしたコメントを追加します（H3 レベル）
2. 一部のスレッドはアクションを必要としない場合があり、透明性のためにスレッドの最後にこれを明示的に述べるとよいでしょう
3. アクションコメントの下に、チームが取れるアクションの提案を追加します
4. 貢献者にピンして、アクションと潜在的な改善に対してラウンドのバリデーションを得ます
5. 各アクションに Issue を作成し、アクションサマリーセクションにリストアップします

ページのソースコードを見る - ページの編集 - please contribute.