Plan:Product Planningエンジニアリングチーム - 私たちの働き方
イテレーション計画
19.0と19.1では、計画を簡素化し進行中の作業を減らすために、2週間のイテレーションを試験しています。
各マイルストーンは2つの2週間イテレーションに分割されます。マイルストーンが5週間ある場合、マイルストーンの最初の週はGitLabの開発者エクスペリエンスを改善することに専念します。
Plan:Product Planningボードは、現在の作業の唯一の情報源です:
- Ready for development — 現在のイテレーションのみ
- Planning breakdown — 次のイテレーション
近い将来取り組む予定がない場合、Issueはこれらのカラムに残るべきではありません。ボードにはこれを強制するWIP制限があります。IssueがReady for developmentに2週間以上、またはPlanning breakdownに4週間以上ある場合、すぐに着手する準備ができていない場合は、“New” に戻します。
私たちは計画用Issueを使って、イテレーション計画を調整・議論します。各プロジェクトには、それを分解しイテレーションを計画する責任のあるDRIが割り当てられます。
品質ローテーション
各イテレーションで、1名のエンジニアが品質ローテーションDRIを務めます。品質DRIはエラーバジェット、Sentryアラート、受信エスカレーションを監視し、緊急のアイテムがない時には高重大度のメンテナンスIssueに取り組みます。完全な範囲とダッシュボードについてはwikiページを参照してください。
作業の流れを保つ
進行中の作業を減らしIssueを動かし続けるために、いくつかのメカニズムを使用します:
- ボードカラムのWIP制限は、任意のワークフローステージのオーバーロードを防ぎます。
- ヘルスステータスエスカレーション — Issueが1つのカラムに長く留まりすぎている場合、ヘルスステータスを自動的にエスカレーションします。ワークフロー状態が変わるとヘルスステータスはクリアされます。Issueは
~"Untrack Health Status"ラベルでオプトアウトできます。 - レビューを優先する — より進んでいる作業を優先する: 自分の進行中の作業よりレビュー、新しいことを始めるより進行中の作業。可能な場合は、複雑なレビューをチーム内に保持し、立ち上げ時間を減らすために同じレビュアーに固執します。
作業の分解
デフォルトのワークアイテムタイプはissueです。迷ったときはIssueを作成してください — 後でエピックまたはタスクに変換できます。
| タイプ | 対応するもの | タイムライン | 例 |
|---|---|---|---|
| Issue | 1つのマージリクエスト、1人、1つのカテゴリー（FEまたはBE） | 1週間未満 | “ボードカードコンポーネントを追加”、“保存ビューAPI用のfilterクエリパラメーターを作成” |
| Epic | 複数のIssueをグループ化するスコープ化された成果物 | 1週間から3マイルストーン | “保存ビューでのBoards Alpha”、“ワークアイテムカード” |
| Task | Issue内のチェックリスト項目/リマインダー | — | “changelogを更新”、“ドキュメントを更新” |
より大きなプロジェクトでワークアイテムタイプをどう使うかについては、プロジェクト例: Boardsを参照してください。私たちはウェイトを使用しません。
良いIssueとは
- 1人のエンジニアが1週間以下で完了できるほど小さい。それより大きい場合は、エピックに昇格するか、スパイクを作成して分解することを検討します。
- Issueを初めて見るチームメンバーが始めるのに十分なIssue固有の詳細（要件、決定、制約）を含む。
- 要件または受け入れ基準へのリンク — Figmaデザイン、wikiページ、エピックの説明、または設計ドキュメント。Issueにコンテンツをコピーする必要はありません。
- 部門横断的なニーズをメモする — 例: “FE + BEが必要”、“UIテキスト用にTWレビューが必要”。
- 他のIssueとのブロックおよび関連関係をマークします。
スパイクと概念実証
オープンな質問が多すぎる、またはスコープが不明確なIssueには、Plan - Spikeテンプレートを使用してスパイクまたはPoC Issueを作成し、調査または試用実装にキャパシティを充てます。
目標は、エンジニアリングDRI、製品、UXの間で何を構築するか、それをどう構築するか、おおよそどのくらいの労力がかかるかについての共通理解です。これにより、プロジェクトをIssueに分解する、アルファバージョンの定義、または設計ドキュメントにつながる可能性があります。
ミーティング
すべてのタイムゾーンをカバーするために、毎週月曜日に3つの週次同期ミーティングを開催します: APAC+EMEA、EMEA+AMER、AMER+APAC。誰でもトピックを持ち込むことができます — 現在のプロジェクト、質問、ブロッカー。
各マイルストーンの最初の週には、これらのミーティングをレトロスペクティブに使用します。3つのセッションすべてが同じレトロボードを共有します。
ドキュメント
機能フラグの背後にある機能であっても、進めるにつれてドキュメントを書きます。本番環境にまだ準備できていない機能をマークするには、機能フラグドキュメントガイドラインを使用します。これにより、マイルストーンの終わりにドキュメントの急ぎ作業を回避できます。
c955a93f)