Plan:Product Planning エンジニアリングチーム - 私たちの働き方

このページでは Product Planning チーム として私たちが従うすべてのプロセスを説明します。

作業サイクル

GitLab の月単位のマイルストーンスケジュールに従っています。 最終週はカットオフ前のコードマージで忙しいため、 最初の週を回顧、プランニング、Issue のリファインメントに充てます。 毎週月曜日に集まりますが、毎回のミーティングの目的は異なります。

第1週 - 回顧、プランニング、リファインメント

ミーティング: 回顧。非同期の回顧はうまくいきませんでした。

フォーカス: リファインメントとマイルストーンプランニング。 エンジニアは週の終わりまでに必要なリファインメントを行いながら、マイルストーンの自分の作業を自分で計画します。

第2週 - マイルストーンキックオフ

ミーティング: マイルストーンプランの確認。 計画が目標に沿っており、エンジニアが納品に自信を持っていることを確認するためのチェックポイント。

フォーカス: 実行。 計画にコミットしたら、マイルストーンの残りを集中して実行することに費やします。

第3週（および第4週）- 実行

一部のマイルストーンは5週間のため、第4週には特別なことは計画しません。

ミーティング: 一般的な議論 誰もがアジェンダにトピックを追加できます:

• 回顧のフォローアップとアクションアイテム
• マイルストーンの進捗
• 特定の Issue
• など

フォーカス: 実行。

マイルストーンの最終週 - マイルストーンチェックインと次のプランの草稿

ミーティング: 次のマイルストーンの高レベルプランの草稿作成。 PM と EM はミーティング前にプランを草稿し、プロジェクト DRI をアサインします。 エンジニアは積極的に未完了の Issue を次のマイルストーンまたはバックログに移動します。

フォーカス: マイルストーンの作業を完成させること。

マイルストーンプランニング

現在のマイルストーンのリリースの翌週に、次のマイルストーンのプランニング Issue が自動化によって作成され、こちらで確認できます。 Issue が作成されたら、プロダクトマネージャーは Issue の説明に初期情報（マイルストーンの大まかなテーマ、製品の優先事項、成果物の領域など）を記入し、マイルストーンプランニングボードを整理します。

17.8 から、マイルストーンの Issue をスケジュールする方法を変更しました。以下のステップを参照してください:

1. プロダクトマネージャーは、エンジニアリングマネージャーとプロダクトデザイナーと協力して、今後のマイルストーンの候補 Issue リストを特定します。
   • Issue の数と工数は、ローリングキャパシティ（前のマイルストーンからのキャリーオーバー作業）、今後のマイルストーンにおけるチームの利用可能なキャパシティ、潜在的な休暇や祝日に基づいて決定されます。
   • これらの Issue には、アサインされたマイルストーンと共に ~workflow::planning breakdown ラベルがあり、エンジニアリングによってトリアージされる準備ができていることを意味します。
2. 特定された候補 Issue リストは、月末の最終週までに PM によってマイルストーンプランニング Issue に投稿されます。
3. エンジニアリングマネージャーはその後、今後のマイルストーン開始の2週間前にこれらの Issue をすべてのチームメンバーにアサインします。
   • Issue の担当者はチームメンバーの可用性と、特定の製品エリアへの取り組みに対するチームメンバーの表明された関心に基づいて選ばれます。
   • さらに、担当者が Issue の製品エリアに不慣れであることが分かっている場合は、トリアージ中のコラボレーションを促進するためにオプションで SME をトリアージ通知に含めることができます。
4. Issue のアサインと合わせて、EM は担当者（および SME が含まれる場合はそれも）に対して、Definition of Ready に従って週の間に Issue をトリアージするための時間を確保し、現在のマイルストーンの最終週前に完了させるよう通知するコメントも含めます。
   • このトリアージの目的は、担当者が次のマイルストーンで何に取り組むかを把握し、実装を開始するために必要なすべての情報を持っていることを確認し、最終的に Issue を ~workflow::ready for development 状態に移動することです。
   • Issue のトリアージ中には複数の結果が考えられます:
     • Issue が単一の Issue として大きすぎる場合、同一マイルストーンで出荷する場合はサブタスク、複数のマイルストーンで出荷する場合は複数の Issue に分割します。
     • Issue に追跡 Issue が存在しないまたはバックログや将来のマイルストーンに存在するブロッキング依存関係がある場合、依存関係を解消するために今後のマイルストーンに関連 Issue を持ち込み、同様にトリアージし、元の Issue はブロッキング Issue のスケジュールに従って PM との調整でマイルストーンから除外します。
     • Issue がこの時点で実装不可能な場合は、PM と EM にメンションして適切な対応が取られるよう提起します。
5. Issue のトリアージの終了時に、Issue が取り組める準備ができていると判断された場合は、Issue に以下の属性があることを確認してください:
   • ワークフローラベルを ~workflow::ready for development に変更する。
   • Issue の説明に実装計画がある（技術的な詳細も含む場合がある）。
   • 元の Issue が分割された場合の子タスクまたは関連 Issue。
6. 今後のマイルストーン開始の1週間前に、EM の責任はすべての候補 Issue がポイント5のガイダンスに従って ~workflow::ready for development に移動したか、またはポイント4で概説された適切なトリアージアクションが取られたことを確認することです。

ワークアイテムタイプ

デフォルトのワークアイテムタイプは Issue です。迷ったら Issue を作成してください — 後で Epic やタスクに変換できます。

すべての Issue はほぼ同じサイズである必要があります。各 Issue が1週間以内に収まるまで作業を分解します。それより大きい場合は Epic にします。

より大きなプロジェクトでワークアイテムタイプをどのように使用するかについては、プロジェクト例: ボードを参照してください。

キャパシティプランニング

工数の見積もり

1人のエンジニアの1週間の集中作業に収まる Issue に作業を分解します。それより大きいものには Epic を作成します。ウェイトは使用せず、すべての Issue が同様のサイズになることを目指します。

可視性を向上させ、評価を助けるために、Issue に計画されたマイルストーンをアサインする前に、Issue のタスクに分解できます。

スパイクを検討する

~"workflow::ready for development" に到達する作業がスコープ外または不明確な場合は、 さらなるリファインメントのために ~"workflow::planning breakdown" に戻す必要があります。 これによる混乱を避けるため、発生回数を減らすよう、より慎重に計画します。常に可能なわけではありませんが、設計と検証フェーズ中にエンジニアリング DRI をアサインするなど、ビルドフェーズの前に複雑さを特定することを目指します。

しかし、開発作業が開始されるまで複雑さを正確に見積もれないことがあります。プランニング中にこれが予想される場合は、スパイクを作成してスパイクレポートを作成することを検討してください。 Issue の参加者、特に PM にスパイクが必要なことを通知し、別の Issue を作成して以下のステップに従います:

1. スパイクの目標でタイトルを付ける;
2. ~spike、~backend、および対応するステージ/グループラベルを追加する;
3. 回答すべき未知事項と質問をリストアップする;
4. 行う必要のある意思決定（アーキテクチャ的またはその他）をリストアップする;
5. スパイクを完了するために必要な専門性を特定する（例: バックエンド、フロントエンド、UX）し、それぞれから DRI をアサインする;
6. Issue を元の Issue のブロッキングとしてマークする;
7. ~“workflow::ready for development” でラベル付けして現在のマイルストーンにアサインする。

成果物は Issue の説明に記載された質問に答えるスパイクレポートです。 このレポートは通常スパイク Issue に直接文書化され、 調査結果、質問への回答、作成された PoC MR へのリンクが含まれます。

より大きなイニシアチブについては、設計ドキュメントの作成に関する推奨事項に従うことを検討してください。

速度向上のためのコラボレーション

チームとして、密接なコラボレーションが必要な機能に取り組むことが多いです。このようなプロジェクトが持続可能で予測可能かつやりがいのあるペースで進むのに役立つ技術と特性のリストを特定しました。このような機能の例として Epic リンキングがありました。

1. 機能はマイルストーン開始前に設計・分解され、適切であればスパイクも含まれます。
2. スパイクの参加者が機能の納品に参加します。
3. クローズ前に、各担当者と PM の承認サインオフとともに承認基準で説明が更新されます。これが納品されるものです。
4. (ワークアイテムのような)より大きなイニシアチブの一部となる取り組みについては、API 設計や機能などに関する大きな意思決定でアーキテクチャドキュメントが最新の状態に保たれます。
5. 要件は明確に定義され、単一のマイルストーン内で達成可能であり、ビジネス価値を提供する目標が設定されています。より大きな機能の場合、作業は複数のマイルストーンにまたがる場合があります。
6. 別のマイルストーンで納品する必要がある項目は最初に特定・優先されます(マイグレーション、セキュリティ Issue、その他のマルチバージョン互換性の問題など)。
7. ドキュメントの安定したカウンターパートはスパイクの開始時から含まれます。
8. ドメインの専門知識、キャパシティ、コンテキスト切り替えの少なさを確保するために、レビューはできる限りチーム内で完結させます。
9. EM と PM は不要な/気を散らす作業を取り除くか制限します。
10. 機能を主要な成果物として設定します。
11. 期日を事前に明確に定義します。
12. すべての今後および進行中の作業に DRI をアサインします。
13. Slack と同期コミュニケーションを使って定期的な更新を記録します。
14. マイルストーン中にチームメンバーが休暇を取る場合、進行中の作業を別のチームメンバーに引き渡す計画を立てます。

職能間のコラボレーション

ワークフローラベル

ほとんどの Issue、特に機能は、他の職能と協力して作業します。 単一の Issue はしばしばフロントエンドとバックエンドで共有され、 進捗が異なる段階にある場合は特に、どのワークフローラベルを適用すべきかが分かりにくいことがあります。

他のチームメンバーに対する可視性を確保するために、フロントエンドとバックエンドのコンポーネントを持つ Issue の場合:

• キャパシティがあれば、できる限り早く自分をアサインする;
• フロントエンドとバックエンドの両方の DRI がアサインされたら、小さなキックオフの議論を開催することを検討する。
• バックエンドの作業がマージおよび検証されたら、~“backend complete” ラベルを追加する。

私たちは予測可能性よりも速度を重視します。 開発を進める前にカウンターパートを待つべきかどうかは自分で判断してください。

~“backend complete” ラベルの使用

~“backend complete” ラベルは、複数の専門性（通常はバックエンドとフロントエンド）を持つ Issue に追加され、バックエンドコンポーネントが完了していることを示します。バックエンドエンジニアは、バックエンドの作業が機能的に完了し、マージされ、検証されたがフロントエンドまたは他の作業が継続中の場合にこのラベルを追加する必要があります。

Definition of Ready

プランニングと分解のプロセス中に、通常、必要な技術的作業の概要を示す Issue やタスクを作成する必要があります。

Definition of Ready は、Issue やタスクが取り組まれる準備ができているかどうかを確認するための合意されたガイドラインのセットです。その目的は、「ready for development」ワークフローラベルを追加して誰かが作業を完了できると期待できるかどうかを判断する際の参照として使用することです。

Issue やタスクが ready for development と見なすのに適しているかどうかを判断するには、以下の Definition of Ready を考慮してください。

1. 作業は十分な詳細で説明されています。以前のコンテキストや仮定された知識のない読者が、どのような作業を行うかを理解できます。何をするのか、なぜするのかが説明されています。
2. 承認基準または要件が明確に定義されています。これにより、担当者は作業のスコープを理解し、意図された Happy パスと Sad パスが機能し、テストされているかを確認できます。
   • 承認基準または要件に関連するライセンスレベルとフィーチャーフラグを含めることも推奨されます。
3. 作業をブロックまたはブロックされている他の作業が正しい関係でリンクされています。
4. デザイン、ドキュメント、外部リンクなどの関連リソースが添付されています。
5. テクニカルライティングの支援を求める必要があるなど、クロスファンクショナルな依存関係が説明されています。
6. 更新または追加が必要なドキュメントがリンクされています。

エンジニアリング作業のための Issue やタスクを作成するプロセス中に、追加の明確さを求めたり、仮定をしないようにするために質問する必要がある場合があります。また、作業を適切なサイズのチャンクに分解するのに十分な情報がないと感じることもあります。前進する道が明確でない場合はスパイクを検討してください。

なぜ？

プランニング/分解プロセス中に、いくつかのことを念頭に置くことが重要です:

1. Issue/タスクの著者が作業する人ではないかもしれない
2. Issue/タスクにすぐに取り掛からないかもしれない

私たちの Definition of Ready は、上記の2点が問題にならないよう、作業が十分に定義されることを確保するのに役立つ必要があります。

私たちの非同期性と分散チームの性質上、Definition of Ready を厳格な品質ゲートとして扱うと生産性に悪影響を与える可能性があります。このため、Definition of Ready はルールとしてではなくガイドとして使用すべきで、Issue/タスクが Definition of Ready を完全に満たしていなくても、作業の着手を妨げるべきではありません。

Issue やタスクは変更可能です — 計画を変更したり、欠けているコンテキストを追加したり、開発中に行われた意思決定を文書化したりすることは常に可能です。

ヘルスステータス

Issue がマイルストーンで納品できるかどうかの可視性を助けるために、チームはヘルスステータスを使って素早くコミュニケーションします。 マイルストーンの開始時に、主要な成果物に関連するすべての Issue に「On track」ステータスが割り当てられます。マイルストーンを通じて、機能 DRI は必要に応じて Issue ステータスを更新する責任があります。ヘルスステータスが「On Track」以外のステータスに設定された場合、機能 DRI はその理由と、チームの他のメンバーが助ける方法があるかどうかについての詳細をコメントで残すべきです。 ヘルスステータスを使用することで、プロダクトおよびエンジニアリングマネージャー、デザイナー、その他のエンジニアなどのステークホルダーは、現在のマイルストーンに入らない可能性があるものについての素早く簡単な概要を把握できます。

ドキュメント

ドキュメントは定義の完了に従い、新しい機能または変更された機能のコードに伴う必要があります。これはフィーチャーフラグの後ろに隠れた機能でコラボレーションしている場合に複雑になることがあります。

すべてのフィーチャーフラグはデフォルトで無効から始まるため、フィーチャーフラグテンプレートを使用して、ユーザーによるテストが安全になったらすぐに機能を文書化することを目指すべきです。 機能が高性能かつ安定するのを待たずに、安全でデータを破損または中間状態に残さないようになったらすぐにドキュメントを作成してください。

使用可能な機能を導入する最初の MR にドキュメントを含めるよう努めてください。UI がない API 追加の場合はそれを文書化し、FE エンジニアが作業を進めるにつれてそれを更新できるようにします。フィーチャーフラグのロールアウトが進むにつれて、ドキュメントを更新する必要があります。

これにより、リリースカットオフに伴うことが多いドキュメント提供の急ぎを避けられます。

取り組む作業の選択

チームのビルドボードには常に現在のリリースの作業が、実装に関連するワークフロー列と共に表示されます。~backend でフィルタリングするとバックエンドエンジニアが取り組む Issue が表示されます。

解決できる自信がない場合はトップの項目を取らなくても構いませんが、その場合は #s_plan に投稿してください。これはおそらく Issue をより適切に指定する必要があることを意味します。

方向性項目

顧客向けの成果物であり、高インパクトな項目には ~“direction” のラベルが付きます。これらの項目はリリースカットオフの2日前までに本番環境に入れ、検証のための十分な時間を確保するよう努めています。

重大度の高い Issue

スケジュールされていない Issue の作業

GitLab の全員は影響を測定し、活動量を測定しないため、自分の裁量で作業を管理する自由があります。これの一部として、通常の月次リリースの一部としてスケジュールされていない項目に取り組む機会があります。これはハンドブックの他の場所にある項目のほとんどを繰り返すものであり、それらを明示するためにここにあります:

1. 私たちは人々が自分自身の上司であることを期待し、私たち自身で GitLab を使います。重要だと思うものがあれば、スケジュールに入れるようリクエストするか、他のタスクを念頭に置きながら自分で提案に取り組むことができます。
2. 時々、Issue バッシュのような GitLab チームメンバーが参加できるイベントがあります。誰もが参加を歓迎されています。
3. 特定の時間を確保したいが、既存のイベントのトピックに興味がない場合は、「For Scheduling」のラベルを Issue に付け、マネージャーを可視性のためにコピーしてください。

取り組む作業を選んだら、以下を実施してください:

1. 標準ワークフローに従い、自分にアサインしてください。
2. #s_plan でシェアしてください（さらに広く、#development や #backend などでも構いません）。

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