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

Plan:Knowledge チーム

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

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

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

チームメンバー

チームメンバー情報は 原文 (英語) を参照してください。

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

チームメンバー情報は 原文 (英語) を参照してください。

採用チャート

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

私たちの働き方

取り組む作業の選択

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

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

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

キャパシティ

工数の見積もり

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

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

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

リファインメント

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

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

### 実装計画

<!--
開発準備完了とは、以下の質問に「はい」と答えられることを意味します:

- この Issue は十分に小さいですか？そうでない場合は、より小さな Issue に分割してください
- 正しいドメイン（例: フロントエンド、バックエンド）に割り当てられていますか？そうでない場合は、それぞれのドメインの2つの Issue に分割してください
– Issue は明確で理解しやすいですか？そうでない場合は、さらに明確化の質問をして、受け取り次第説明を更新してください

2つ以上の MR が必要な場合は、説明に以下のような表を追加することを検討してください（例: `実装計画` の下）。
-->

| 説明 | MR |
|-|-|
| MR 1 | |
| MR 2 | |
| ドキュメント | |

**理由:**

<!--
この Issue をどのように分解するかについての最初の考えを追加してください。箇条書きで構いません。

これはおそらく以下のようなコード変更が必要になります:

- 六角ドライバーをソニックスクリュードライバーに交換する
- バックアップを磁気テープに書き直す
- セマフォフラッグを送り上げて他者に警告する

以前の例へのリンク。先行技術に関する議論。提案されたデザインのシンプルさ/複雑さの顕著な例。
-->

/label ~"workflow::ready for development"

/label ~"frontend-weight::X"

/label ~"backend-weight::X"

/weight X

バグのウェイト付け

リファインメント

ボードウォーク（週次）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非同期ファースト

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

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

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

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

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

ワークフロー

ラベルの使用

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

非同期更新

私たちはチームメンバー、カウンターパート、ユーザーがそれぞれの Epic や 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:Knowledge - マイルストーンフィルターを適用して現在のリリースの作業を確認する
• Slack の #s_plan
• 録画されたミーティング
• 回顧

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