Plan:Planner Intelligence エンジニアリングチーム

Plan:Planner Intelligence チーム

Plan:Planner Intelligence チームは Knowledge Management カテゴリを開発しています:

• Wiki
• GitLab Pages
• テキストエディタ
• Markdown

詳細は方向性ページをご覧ください。

チームメンバー

Name	Role
Armin Pašalić	Manager, Engineering, Plan:Planner Intelligence
Janis Altherr	Senior Fullstack Engineer, Plan:Planner Intelligence
Asherah Connor	Senior Backend Engineer, Plan:Planner Intelligence
Naman Jagdish Gala	Senior Backend Engineer, Plan:Planner Intelligence
Piotr Skorupa	Backend Engineer, Plan:Planner Intelligence
Richard Chan	Backend Engineer, Plan:Planner Intelligence
Vanessa Otto	Staff Frontend Engineer, Plan:Planner Intelligence

安定したカウンターパート

Name	Role
Abhimanyu Singh	Engineering Manager, Security Governance:AI Control Plane
Costel Maxim	Senior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Heinrich Lee Yu	Principal Engineer, Plan
John Hope	Director of Engineering, Plan
Natalia Tepluhina	Principal Engineer, Plan
Pratyaksh Golash	Senior Backend Engineer, Security Governance:AI Control Plane
Raounak Sharma	Senior Backend Engineer, Security Governance:AI Control Plane
Rahul Barnwal	Backend Engineer, Security Governance:AI Control Plane
Matthew Macfarlane	Senior Product Manager, Plan:Planner Intelligence

採用チャート

現在の求人については採用ページをご覧ください。

私たちの働き方

取り組む作業の選択

ビルドボードには今後のリリース作業が表示されます。~“workflow::ready for development” 列は優先度順に並んでいます。

エンジニアリングマネージャーはマイルストーンの開始時に以下のラベルを追加します:

解決できる自信がない場合はトップの項目を取らなくても構いませんが、#g_planner-intelligence に投稿してください。

キャパシティ

工数の見積もり

今後の作業に関わる工数を見積もる際は、Plan ステージの他のグループと同じアプローチと数値スケールを使用します。

通常、3 ヶ月のローリング平均がチームのキャパシティの良い指標となります。Planner Intelligence は新しいチームであり、明確な過去データがないため、最初はキャパシティの判断が難しい場合があります。

PM と EM はチームのキャパシティの最大 75% に ~Deliverable Issue を収め、残りを ~Stretch Issue に割り当てることを目指します。

リファインメント

エンジニアリングマネージャーは毎週のチームミーティングで ~"workflow::refinement" の Issue をレビューします。 最高優先度の Issue は個々のエンジニアにアサインされ、そのエンジニアが Issue を ~workflow::ready for development に移動させる責任を持ちます。

エンジニアは以下のテンプレートを Issue の説明に追加できます:

### Implementation plan

<!--
Ready for development means replying yes to the following questions:

- Is this issue sufficiently small enough? If not, break it into smaller issues
- Is it assigned to the correct domain (e.g. frontend, backend)? If not, break it into two issues for the respective domains
– Is the issue clear and easy to understand? If not, try asking further clarification questions and update the description once they are received

If more than 2 MRs are needed, consider adding a table like the following to the description (e.g. under `Implementation plan`).
-->

| Description | MR |
|-|-|
| MR 1 | |
| MR 2 | |
| Documentation | |

**Reasoning:**

<!--
Add some initial thoughts on how you might break down this issue. A bulleted list is fine.

This will likely require the code changes similar to the following:

- replace the hex driver with a sonic screwdriver
- rewrite backups to magnetic tape
- send up semaphore flags to warn others

Links to previous examples. Discussions on prior art. Notice examples of the simplicity/complexity in the proposed designs.
-->

/label ~"workflow::ready for development"

/label ~"frontend-weight::X"

/label ~"backend-weight::X"

/weight X

バグのウェイト付け

リファインメント

ボードウォーク（週次）

チームメンバーは週に 1 回、ビルドボードを歩く集まりを行います。25 分がこのシンクコールに割り当てられていますが、それよりはるかに早く完了することもあります。EM が DRI であり、PM を除いて出席はオプションです。録画されて #g_planner-intelligence Slack チャンネルで共有されます。セキュリティや他の機密 Issue が議論されない場合のみ、録画は公開されます。アジェンダは社内でアクセス可能であり、すべてのチームメンバーがアップデートと質問を追加することを推奨されます。

このミーティングの目的は:

• 進行中の作業の状況を更新する
• ブロッカーとリスクを特定する
• 再優先化する
• 助けを求める

DRI はこのミーティングを待つのではなく、ワークフローラベルとヘルスステータスを継続的に最新の状態に保つ必要があります。

プランニングミーティング（月次）

プランニングミーティングはマイルストーン開始前に月に 1 回開催されます。プロダクトマネージャーがスケジュールの DRI です。

エンジニアの出席はオプションですが、参加は必須です。ミーティングにはアジェンダがあり、録画されます。以下のどれかまたはすべてが含まれる場合があります:

• 優先事項と期待値の設定。
• タスクの見積もり。
• スコープの分解とコラボレーション。
• 要件の明確化。
• キャパシティとキャリーオーバーの見積もり。

できる限りこれらのタスクは非同期で完了し、ミーティングで必要な作業を減らすべきです。ミーティングの目的は、今後のマイルストーンをできる限り成功できる状態で開始することです。

リファインメントセッション（アドホック）

チームメンバーは大きな Issue や新機能のためのリファインメントシンクミーティングを提案することを推奨されています。 目標は、問題に対するさまざまな視点を共有し、知識を共有しながら懸念点と未知の事項を探ることです。

リファインメントミーティングのアジェンダには以下のようなトピックが含まれる場合があります:

• 製品要件
• 技術的な課題
• 技術的な代替案
• 提案されたソリューションをどのようにイテレーションするか

成果として、ミーティングではマイルストーンを推定した Issue のリストが作成される場合があります。

非同期ファースト

ほとんどのプランニングは非同期で行われます。これをより効率的にするために、いくつかのツールとプロセスが観察されています。

Issue には 1 つのマイルストーンしか添付できないため、~"Next Up" ラベルを使って、マイルストーンがあるかどうかに関係なく、今後のマイルストーンの項目をマークします。PM と EM は、プランニングプロセス中の現在のマイルストーンを slip する可能性のある Item やプロスペクティブな Issue に追加する前に、このラベルをすべての Issue から削除する必要があります。

このラベルを使用することで、今後のマイルストーンを簡単に分析できます。プランニングボードは、現在のマイルストーンではなくこのラベルにスコープされているビルドボードを模倣しています。以下のために使用します:

• 提案されたすべての Issue の現在のワークフロー状態を表示する。
• 各リストのウェイト値を合計してキャパシティを計画する。
• マイルストーンが始まる前に解決できる可能性のあるブロッキング関係を理解する。

新しいマイルストーンが始まると、一括アクションで ~"Next Up" ラベルの付いたすべての Issue にマイルストーンを追加し、ラベル自体を削除できます。

ワークフロー

ラベルの使用

Issue の適切なラベル付けは、チームができる作業とやっている作業の分類、追跡可能性、定量化に役立ちます。一部のラベルは必須です。以下の表ではこれらを説明し、その理由を示します。

非同期更新

私たちはチームメンバー、カウンターパート、ユーザーがそれぞれのエピックや Issue のステータスを明確かつ簡単にアクセスできるよう努めています。

この情報の主要な情報源は ~workflow::* ラベルとヘルスステータスです。

しかし、Issue が ~"workflow::in dev"、~"workflow::in review" または ~"workflow::verification" で 1 週間以上費やす場合、DRI は “Knowledge - async update” コメントテンプレートを使って Issue に非同期更新を残します。

非同期更新が必要な Issue を追跡するには、以下の GLQL クエリを使用できます:

```glql
---
display: list
fields: title, labels("workflow::*"), healthStatus
---
group = "gitlab-org" and assignee = currentUser() and label in ("workflow::in dev", "workflow::in review", "workflow::verification") and opened = true
```

優先度ラベル

~Knowledge::P1/P2/P3 ラベルを使用して、~workflow::* ステップとマイルストーン内の Issue の優先度を示します。

• プロダクトマネージャーがこれらのラベルの DRI ですが、チームの全員がアサイン/調整できます。
• マイルストーンの開始前に、PM と EM はそのマイルストーンに含まれるすべての Issue の優先度を確認します。期待値は以下の通りです: - Issue の 40% が ~Knowledge::P1 - Issue の 30% が ~Knowledge::P2 - Issue の 30% が ~Knowledge::P3 で、これらの Issue は ~Deliverable にできません
• これらのラベルはマイルストーン外でも最高優先事項を追跡するために使用します。
• チームの誰かが Issue をスケジュールに入れたい場合は、適切な優先度ラベルを追加してください。
• 専用の P4 ラベルはなく、~Knowledge::P* ラベルを持たないことは ~Knowledge::P4 と同等です。
• Issue が別の ~workflow::* ステージに移動されると、優先度が変更される可能性があります。
• ~Knowledge::P* ラベルはバグにのみ使用される ~priority::* ラベルとは完全に異なります。

他のチームとのコラボレーション

手戻りを避けるため、以下のドメインで作業する際は早期に他のチームに働きかけます:

アプリケーションパフォーマンス

Grafana には、チームが担当するアプリケーション部分のパフォーマンスを表示する追加のダッシュボードがあります。

• ステージグループダッシュボード（28 日間のエラーバジェットを含む）
• エラーバジェット詳細

便利なリンク

• Plan:Planner Intelligence - マイルストーンフィルターを適用して現在のリリースの作業を確認する
• Slack の #s_plan
• 録画されたミーティング
• 回顧

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