働き方
バックログリファインメント
エンジニアリングチームは毎週、今後の Issue をレビューするためにバックログリファインメントプロセスを完了します。この取り組みの目的は、すべての Issue にウェイトを付けることで、チームの見積もりキャパシティと Issue の見積もりウェイトを使って、各マイルストーンをより正確に計画できるようにすることです。
このバックログリファインメントプロセスに加えて、チームのエンジニアは、単純でバックログリファインメントを必要としない Issue にウェイトを追加できます。
このプロセスは 3 つのステップで行われます。
ステップ 1：リファインメント対象 Issue の特定
Engineering Manager は毎週、リファインメントする Issue を選びます。合計 5 件の Issue を目標にしています。 良い候補だと思う Issue があれば、その Issue 自体でメンションしてください
コンテキストスイッチを増やしすぎないよう、リファインメントはテーマを揃えるようにしています。候補を探すのに適した場所：
- Infradev Issues
- ウェイトなしで次のマイルストーンに予定されている Issue
- Security Issues
- Missed-SLO
- Approaching-SLO
- バグ
- ウェイトなしの Issue
選定後、Engineering Manager は ai-framework::ready for next refinement ラベルを適用し、Refinement Botを使用して、すべての候補をまとめたリファインメント Issue を生成します。
ステップ 2：Issue のリファインメント
その週の間に、チームの各エンジニアはバックログリファインメント対象として選ばれた Issue のリストを確認します。現在のバックログリファインメント Issue。
各 Issue について、各チームメンバーは Issue をレビューし、以下の情報を提供します：
- 見積もりウェイト。
- Issue を別の Issue またはマージリクエストに分割する方法。
考慮事項：
- 会話は元の Issue 上で続けます。
- このプロセス中、より多くの情報が集まるにつれて、Issue の説明とラベルを更新する必要があります。
- 効率化のため、既存のフィードバック次第では、Issue が引き続き ready の定義を満たしている限り、一部の Issue のリファインメントをスキップすることもできます。
- 修正内容が明確で簡単な場合は、Issue を自分たちにアサインし、ウェイトを 1 にして修正をプッシュできます。
Issue が ready の定義を満たしている場合、開発予定に組み込まれる可能性が高くなります。
ウェイト付けと見積もりプロセス
ウェイトガイドライン
Issue は Fibonacci sequence（0、1、2、3、5、8、13+）を使ってウェイト付けされます：
- ウェイト 0： 最小の Issue（typo、軽微なフォーマット、テストを伴わない単純なコード変更）
- ウェイト 1： 不確実性が最小限の単純な Issue（新しいコントリビューターに適しています）
- ウェイト 2： 複数のコード/テスト更新を必要とするわかりやすい Issue
- ウェイト 3： ある程度の複雑さはあるが、スコープを管理できる大きめの Issue
- ウェイト 5： 通常は分割すべきもの。リスクの低い大規模な手作業更新では許容されます
- ウェイト 8/13+： 分割が必要であることを示すプレースホルダーのウェイト。即時実装には大きすぎる、または不確実すぎます
ウェイト更新プロセス
次のマイルストーンにアサインされたすべての Issue は、Engineering Manager が Deliverable ラベルを適用する前にウェイト付けされている必要があります。Engineering Manager はウェイトがアサインされているか確認し、ウェイトが 5 以上の場合は Issue をより小さなものに分割します。
Engineering Manager と Product Manager は、次のマイルストーンにアサインされた Issue のウェイト付けを、週次チームミーティング中に依頼する責任があります。必要に応じて質問できるよう、ミーティング前にエンジニアに Issue の説明を読んで準備してもらう必要があります。このプロセスは複数のミーティングに分けることができます。
c955a93f)