Create

こんにちは

私たちはCreateステージであり、DevOps部門内のチームグループです。私たちはGitLab製品内の3つの領域で構成されています。

チーム	エンジニアリングマネージャー
Createステージ	André Luís
Create:Code Review	François Rosé
Create:Source Code	Andre Richards (バックエンド & フロントエンド)
Create:Import	Thiago Figueiró (フルスタック) — レポート先 Florbela Viegas
Create:Remote Development	—

ミッション

私たちは何をしますか？

Createステージは、効率とコラボレーションを改善することにより、ソフトウェア開発チームの提供を加速し、サイクルタイムを短縮することを支援します。私たちのステージは、DevOpsライフサイクルの始まりをサポートするツールを提供します。

誰にサービスを提供しますか？

私たちは以下のためのツールを構築します:

• ソフトウェア開発者
• DevOpsエンジニア
• 開発チームリード
• プロダクトマネージャー
• プロダクトデザイナー

どのようにサービスを提供しますか？

製品ビジョンハンドブックページは、各タイプのGitLabユーザーにどのようにサービスを提供するかについての具体的な例を提供します。

ビジョン

次の領域は、年内の私たちの方向性として定義されています:

• 高速で信頼性が高く、簡単に管理できるGitストレージ
• バイナリファイルワークフロー
• 楽しいコードレビュー
• OSSおよび多くのチームにわたる大規模組織内でのより良いコラボレーション
• 編集エクスペリエンスの統合
• より良い統合

プロフェッショナル開発

各チームメンバーは、スキルと知識の改善に向けて前向きなステップを取ることが奨励されます。

スキルセットの成長は、GitLab製品へのより洞察に富んだコントリビューションにつながります。専門知識が成長するにつれて、製品と企業への影響も成長します。GitLabでは、チームメンバーのプロフェッショナル開発に投資することが重要です。

もっと学びたい分野がある場合は、マネージャーに連絡して、好みの分野で成長できる環境を提供してもらってください。推奨されるリソースは以下のとおりです:

エンジニアリングマネージャー

• 推奨書籍
• トレーニング教材

個人コントリビューター

• プロフェッショナル開発
• 推奨書籍
• トレーニング教材
• 個人コントリビューターからマネージャーへの移行
• スキップレベルミーティング
• イテレーション

私たちの働き方

各チームは、自分たちの製品とチームのニーズに最も適した方法で作業します。

• Createエンジニアリングマネージャー
• Remote Developmentチーム
• Code Reviewチーム
• Source Codeチーム バックエンド、フロントエンド

製品とデザインとの協働

可能な場合は、製品開発フローに従います。

プロダクトマネージャーとエンジニアリングマネージャー間の週次コールは、各グループの共有カレンダーにリストされています。誰でも参加でき、これらのコールはグループに影響を与える障害、懸念、ステータス更新、成果物、その他の考えについて議論するために使用されます。

月次マイルストーン計画Issueは、次のマイルストーンが始まる前の週に作成されるようトリガーされます。PM（プロダクトマネージャー）、EM（エンジニアリングマネージャー）、PD（プロダクトデザイナー）が一緒にマイルストーンを計画します。

製品と完了の定義を定義する

ビルドトラック中、Issueまたはエピックの説明内で、成功の測定値が定量的または定性的な成功メトリクスで何であるかを文書化します。プロダクトマネージャーとプロダクトデザイナーは、これらのメトリクスを提案し、Engineeringとコラボレートして計測および検証する責任があります。

クロスチーム計画と精緻化

これらのガイドラインは、クロスチーム依存関係の識別と、早期のコラボレーションを促進することを目的としています。このプロセスは、製品開発フロー、ビルドフェーズ1: 計画の一部として行われ、エピックおよび/またはIssueの実行のスケジュールを設定する前に行う必要があります。

Planning breakdown

Planning Breakdownステージで回答する主な質問は次のとおりです:

• 要求の意図を理解するのに十分なほど要件が明確か？
• 達成する作業の境界を知っているか？（例: 別のチームが維持するコード）

どちらかの答えが「No」の場合、DRIの要求の理解を向上させるためにディスカッションが継続されます。

エンジニアリング出力:

• 未解決の質問またはディスカッションを識別し解決する。
• Issueが他のチームに関連する場合に他のチームに関与する（例: 共有コードに触れる、APIに影響する、ロードマップに影響する）。
• 説明で他のチームへの依存関係を説明し、EM、PM、安定したカウンターパートに関与し、早期コラボレーションを促進する。
• エピックの場合: エピック内に下書きの実装Issueを作成する。
• すべてのIssueにRefinementステータスを適用する。

Refinement

Issueを精緻化するように割り当てられたエンジニアは、Issueが成功した精緻化と実行に必要な情報を欠いている場合に質問し、反対意見を述べることが奨励されます。

精緻化ガイドライン

1. Issueの完全性を確認します:
   • 該当する場合、UIを含む必要なデザインがある。
   • 機能が明確に明示されている。
   • 技術的な詳細がアウトラインされており、ディスカッションが解決されている。
   • 依存関係が呼び出されている。
2. Issueが完全でない場合:
   • Issueを完成させるのに役立つ関連する人々をタグ付けし、必要なものをアウトラインする。
   • EMとPMをタグ付けし、ブロッカーを認識させる。
3. Issueが完全に理解されていることを確認します。
   • 実装される最終的な説明でIssueの説明を更新する。
   • 実装計画でIssueの説明を更新する。

誰かがIssueとその実装を理解するためには、すべてのコメントを読む必要はないはずです。必要な情報は、唯一の情報源として説明に含まれている必要があります。

実装計画

この要求に対処するために更新する必要のあるステップとコードの一部のリスト。 実装計画では、他のチームメンバーまたはチームの責任を呼び出し、関連するエンジニアリングマネージャーが計画に同意していることを確認する必要があります。

実装計画の目的は、Issueの批判的分析を促し、DRIにアプリケーションのどの部分がタッチされるかを考えさせることです。実装計画はまた、他のエンジニアがIssueをレビューし、依存関係を持つ可能性のあるアプリケーションの領域や、見落とされている可能性のある領域をハイライトすることを許可します。

複雑な変更については、別のエンジニアからのレビューをリクエストし、対象分野の専門家をループに入れることを検討します。

意思決定プロセス

Createのチームが従う、明確で信頼性のある意思決定プロセスを確保するためのワークフローの詳細については、意思決定プロセスを参照してください。

テンプレート

プロセスをより透明かつ効率的にするためにテンプレートを使用します。プラクティスを一度文書化し、頻繁に再利用することは、ステージ全体を通じてガイダンスとサポートを提供します。

Createステージ運用ダッシュボード

このダッシュボードは、Createステージ全体で品質と信頼性を維持するための中央コマンドセンターとして機能します。私たちのQuality Firstマインドセットに沿って、このwikiを使用してシステムと顧客体験の運用上の健全性を追跡、監視、行動します。

私たちのコミットメント

品質と信頼性は交渉の余地がありません。このwikiで主要なメトリクスを追跡し、明確な目標を設定することで、トレンドが間違った方向に動くときに品質と信頼性の懸念事項が、非インターロック機能作業よりも優先されることを保証します。

どのように機能するか

infradev issue、バグ、エラーバジェット、インシデント、または顧客エスカレーションがネガティブにトレンドしているか、目標を逃している場合、品質と信頼性の問題に対処するために、非インターロック機能からチームキャパシティをすぐにシフトします。これにより、品質と信頼性の問題が優先される運用上の規律が作成されます。

• Wikiはinfradev issueとバグ（オープン対クローズ）の週次トレンドを表示
• 信頼性指標としてエラーバジェットステータス（🟢🔴）を監視
• 目標に対する期限切れS1-S4 infradev issueとバグを追跡
• システム信頼性と顧客への影響の測定値として、アクティブインシデントと顧客エスカレーションを追跡
• メトリクスが低下したり目標を逃したりした場合、非必須の機能作業を一時停止または遅延させ、品質と信頼性の修復にチームメンバーのキャパシティをリダイレクト

結果

• チームが障害や顧客の痛みに反応的にではなく、低下するメトリクスに積極的に対応するため、品質と信頼性が第一優先事項として維持されます。（製品プロセスに従って）
• インターロックコミットメント（専用の信頼性イニシアチブを含む）は継続しますが、裁量的機能は品質と信頼性のニーズに譲り、システム安定性、製品の整合性、または顧客体験を損なう技術的負債を決して蓄積しないことを保証します。

バグ解決戦略

私たちは、タイムリーな解決を確保し、バックログの蓄積を防ぎ、定義されたバグバーンダウンサイクルを通じて予測可能なチームキャパシティを維持する、持続可能なバグ管理プロセスに従っています。

バグバーンダウンサイクルの概要

バグバーンダウンサイクルは、システムヘルスを回復し品質基準を満たすために、チームが既存のバグの解決を優先する集中的でフォーカスされた期間です。チームは、バグの負債が重要なしきい値に達したときにこのサイクルに入ります。

終了基準: バグバーンダウンサイクルから離れる

終了するための要件（すべての重大度レベルに適用）

1. SLO遵守

   • サービスレベル目標（SLO）を逃したバグがゼロを達成
   • SLOを逃したバグなしで完全なマイルストーンを正常に完了

2. マイルストーン割り当て

   • すべてのバグを特定のリリースマイルストーンに割り当てる
   • “Backlog"ステータスのすべてのバグを排除
   • 適切な計画とキャパシティ管理のために、現在および将来のマイルストーンにバグを分散

3. 一貫した週次スループット

   • マイルストーンあたり最低X個のバグをクローズ（Xはチームキャパシティと過去のスループットに基づいてエンジニアリングマネージャーが決定）
   • 持続可能なペースを示すために、このしきい値を一貫して維持

4. 終了後のレビュー

   • バーンダウンサイクル終了後、週次コミットメント目標を再評価
   • 受信バグ率とチームキャパシティに基づいてコミットメントを調整

再開トリガー: バグバーンダウンサイクルに入る

次のいずれかの条件が発生した場合、チームはバグバーンダウンサイクルに入ります:

トリガー条件

• 単一のマイルストーン内でSLOを逃した2つ以上のバグが存在
• バグが**“Backlog”**ステータス（マイルストーンに割り当てられていない）で蓄積し始める
• チームが、マイルストーンあたりのバグクローズの最小Issue数しきい値を下回る

継続的な持続可能性プラクティス

発見時にすべての新しいバグをすぐに特定のマイルストーンに割り当てる。

チーム間の働き方

Createステージのチームは一緒に仕事をし、一緒に遊びます。私たちは互いに依存し、機能をサポートし補完することができて幸運です。クロスチームコラボレーションの例:

• Source CodeチームとGitalyチームはしばしばIssueで一緒にコラボレートします
• GitalyチームメンバーはSource CodeチームメンバーにGoプログラミング言語のメンタリングを行っています

四半期ごとに、クロスチームのボンディングアクティビティ、Create Team Dayに参加します。

私たちの価値観を生きる方法

エンジニアリングマネージャーは毎日私たちの価値観を生きています。

エンジニアリングマネージャーがGitLab Valuesをどう生きているかについて詳しく読む

結果を測定する方法

• OKR
• ダッシュボード
• Issueボード
• 監視

イテレーションを測定する方法

• ログ
• MR率

生産性を追跡する方法

タレントアセスメント中、エンジニアリングマネージャーはチームメンバーのパフォーマンスを評価するために包括的なアプローチを取ります。彼らは、各ジョブレベルの期待に対する公平な評価を確保するために、私たちのエコシステム全体にわたる多様な相互接続されたメトリクスのセットを検討します。これらのメトリクスには以下が含まれます:

• マージされたマージリクエスト
• 実施されたコードレビュー
• メンテナーおよびインタビュアーステータス
• 参加したインタビューの数
• メンタリング活動
• マージリクエストインパクト
• ヘルプ要求と一般的な顧客サポート
• クロスチームコラボレーションとリーダーシップ
• その他のコントリビューション

このアプローチにより、エンジニアのコントリビューションと成長について均整のとれた評価が可能になります。詳細については、タレントアセスメントページを参照してください。

どのメトリクスに焦点を当てるか？

現在、次のメトリクスについて月次の期待を設定しています:

• マージリクエスト率:
  • グループに適用する場合: 分子はプロジェクトのセットにマージされたマージリクエストの数（以下のメモを参照）。分母はグループの人数。
  • 個人に適用する場合: プロジェクトのセットにマージされたマージリクエストの数（以下のメモを参照）。
• レビュー率:
  • グループに適用する場合: 分子は、指定された期間（通常は月）にプロジェクトのセットにマージされたマージリクエストに提供されたコードレビューの数（以下のメモを参照）。分母はグループの人数。
  • 個人に適用する場合: 指定された期間（通常は月）にプロジェクトのセット（以下のメモを参照）にマージされたマージリクエストに提供されたコードレビューの数。

マネージャーがこれらのメトリクスを使用する方法

マネージャーは以下を行う必要があります:

• MRとレビュー率を診断シグナルとして扱い、ハードな生産性目標やノルマとして扱わない。持続的な逸脱は、自動的な判断ではなく、会話のトリガーとなるべきです。
• メトリクスを常に文脈で解釈する、以下を含む:
  • 作業のタイプ（複雑な機能、リファクタリング、実験、インフラ作業、技術的負債、インシデント）;
  • 非コーディング責任（メンタリング、インタビュー、メンテナーシップ、ヘルプ要求Issue、クロスチーム作業）;
  • 一時的な要因（オンボーディング、PTO、インシデント、役割の変更）。
• 次のことにつながるコーチングまたはインセンティブを避ける:
  • MR数を増やすためだけに作業を不自然に分割する;
  • レビュー数を増やすためだけに表面的または急いだレビューをする;
  • 複雑で目立たない作業を優先しない（例: マイグレーション、信頼性、他者を可能にすること）。
• エンジニア自身のデータを定期的に共有してレビューし、それが何を意味するか、何を意味しないかを説明し、それが彼らの作業をどのように反映しているかについての彼らの視点を招待する。
• メトリクスの解釈方法に重要な影響を与える場合は、チーム固有のコンテキスト（例: 重いインシデント負荷、レガシーオーナーシップ、または大規模なリファクタリング）をチームのハンドブックページに積極的に文書化する。
• パフォーマンス決定のための唯一の信頼できる情報源として企業全体のタレントアセスメントガイダンスを使用し、MRとレビュー関連のデータは決定的な要因ではなく、複数の入力の1つとして扱う。

ダッシュボード

• マージリクエスト率: tableauダッシュボード
• レビュー率: tableauダッシュボード

注意: Tableauへのアクセスがない場合、直接のマネージャーに連絡して、希望の期間のスクリーンショットを提供してもらうか、該当する場合は永続的なアクセスを提供するためのアクセス要求を開いてもらいます。

メモ:

1. これらのメトリクスには、製品に影響するすべてのMRが含まれます。データセットに含まれる特定のプロジェクトは、このシードファイルにリストされています。
2. このプロセスは、メトリクスセットを拡張し、チームのコントリビューションと進化する役割の期待との整合性を確保するために洗練することで、時間とともにイテレートします。変更はすべてのチームメンバーに明確に伝えられます。

各ジョブレベルのベースライン目標

下記の表では、シニアリティレベルに関連する各メトリクスのベースライン数値をアウトラインします。これらの数値は、ステージのエンジニアリングマネージャーとのコラボレーションから導出されました。上記でアウトラインされているように、それらはチームの健全性と個々のワークロードパターンを理解するための 唯一の入力 として扱われます。 それらは生産性またはパフォーマンスの完全な測定値として扱われません が、方向性のガイドとして設定されています。

注意: 数値はSource Code Backend、Source Code Frontend、Code Review Backend、Code Review Frontend、Code Creation、Editor Extensions、Remote Developmentのチームメンバーの過去データを活用して、2024年12月頃に最終更新されました。

これらのベースラインは、エンジニアリングマネージャーが、作業、責任、ローカルチームの条件のコンテキストでチームメンバーと議論できるトレンドと異常値を浮上させるのに役立ち、常により広範なシグナルセット（例: インシデント対応、アーキテクチャ作業、メンタリング、インタビュー、ヘルプ要求、クロスチームコラボレーション）と組み合わせて使用されます。

私たちのCREDIT価値観に沿って、バイアスを減らし、倒錯したインセンティブ（MR分割や表面的なレビューなど）を回避し、顧客のための意味のある成果と持続可能な働き方に焦点を維持するために、これらのベースラインを定期的にレビューおよび調整します。

目標は何を意味するか？

経験則として、明確な文脈的理由（例: 延長されたインシデント対応、主要なアーキテクチャ作業、重要なメンタリングまたはリーダーシップ責任、または長期休暇）がない限り、ほとんどのチームメンバーが特定の年の12か月のうち少なくとも6か月、これらのベースラインに近いまたは上回ることを期待します。

これらの期待は、会話とサポートを促進するためのガイドラインであり、厳密なノルマや自動的なパフォーマンス結果ではありません。チームまたは個人がどのように広く動作しているかを評価するためのキャリブレーション支援として使用できますが、評価は常に完全なタレントアセスメントフレームワークと組み合わせて行われます。

個人コントリビューターの場合、 これらの目標は、彼らが従事している役割とシニアリティの期待に合わせたヘルスステータスシグナルを提供できます。

エンジニアリングマネージャーの場合、 これらの目標は、チームメンバーをよりよくサポートするために、チームプロセス、計画、または個々のケースをレビューするシグナルを提供できます。

逸脱を正当化する特定の文脈を持つチームがある場合、その余分なコンテキストは、可能な限りハンドブックのチームページに文書化する必要があります。

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