Plan:Project Management

Plan: Project Management

すべてのチームメンバーと安定したカウンターパートを表示

このチーム全体の責任は、Project Management Group に記載されています。これは特に、ワークアイテム、ボード、マイルストーン、イテレーション、To-Do リスト、タイムトラッキング、プランニングアナリティクス、通知に関する GitLab の機能を扱うことを意味します。

• 質問があります。誰に聞けばいいですか?

GitLab Issue では、質問はまずプロダクトマネージャー（@gweaver）にメンションしてください。UX に関する質問は、プロダクトデザイナー（@nickleonard）にメンションしてください。GitLab チームメンバーは、#s_plan も使用できます。

方向性

GitLab > Dev Section > Plan Stage > Project Management Group

パフォーマンス指標

顧客価値

• Paid Monthly Active Users (Paid GMAU)
• Monthly Active Users
• System Usability Score (SuS) - Project Management 製品サーフェスエリアに起因する detractor の数を、四半期ローリングベースで減少させる

製品品質

• ターゲット Error Budget、> 99.95%
• Escaped defects - canary または本番で見つかった欠陥や脆弱性についてファイルされたバグまたはセキュリティ Issue の数（月次ローリングベース）

プロセス

• Open MR Age (OMA)
• Open MR Review Time (OMRT)
• Merge Request Rate - エンジニア1人あたりの月次ローリングベースでの平均 MR 数
• Lead Time - Issue が workflow::validation backlog から closed まで流れるのにかかる中央値の日数。
• Validation Track Cycle Time - Issue が workflow::validation backlog から workflow::planning breakdown まで流れるのにかかる中央値の日数。
• Build Track Phase 1 Cycle Time - Issue が workflow::planning breakdown から workflow::ready for development まで流れるのにかかる中央値の日数。
• Build Track Phase 2 Cycle Time - Issue が workflow::ready for development から closed まで流れるのにかかる中央値の日数。
• Product Development Flow ワークフローラベルの採用

プロセス改善の取り組みの履歴

私たちの働き方

• GitLab 価値観 に従って。
• 透明性: ほぼすべてが公開で、可能な限りミーティングを記録/ライブ配信します。
• 自分が取り組みたいものに取り組む機会があります。
• 誰でも貢献できます。サイロはありません。
• #s_plan_standup でオプションの非同期日次スタンドアップを行います。

キャパシティ計画

次のリリースのキャパシティを計画する際、私たちは次のことを考慮します。

1. 次のリリース中のチームの可用性。（オフィスを離れているかどうか、または時間に対する他の需要が来るかどうか。）
2. 現在開発中だが完了していない仕事。
3. グループごとの過去の納品（重みによる）。

最初の項目は、最大キャパシティとの比較を私たちに与えます。例えば、チームに4人いて、そのうち1人が月の半分オフを取る場合、チームは最大キャパシティの 87.5% (7/8) を持っていると言えます。

2番目の項目は難しく、特に Issue が他の Issue をブロックしている場合、Issue を開始した後にどれだけの仕事が残っているかを過小評価しやすいです。私たちは現在、繰り越される Issue の重み付けを変更しません（元の重みを保持するため）。そのため、これは現時点ではかなり曖昧です。

3番目の項目は、過去にどうしていたかを示します。トレンドが下向きの場合、これを レトロスペクティブ で議論することを検討できます。

繰り越し重み（項目2）を期待キャパシティ（項目1と3の積）から差し引くと、次のリリースのキャパシティが分かるはずです。

ワークフロー

Issue と Epic は一般的に、私たちの Product Development Flow に従います。

2022年1月から、計画ケイデンスをマイルストーンからイテレーションにシフトする3〜6か月の実験を実施します。主な目標は、よりタイムリーで質の高い意思決定を可能にするため、より小さなバッチで計画を立てることです。イテレーション計画は、30分間の週次 Engineering/Product/UX シンクで行われます。重み付けされ ~workflow::ready for development とマークされた Issue のみが、今後のイテレーションにスケジュールされます。イテレーションを活用しますが、文書化された プロダクト開発タイムライン には引き続き従います。

Project Management ボード:

• Validation Track
• Build Track
• Iteration Planning
• Milestone Planning
• Team

テーマ

少数の優先度の高い機能が、一定期間の「テーマ」として選ばれます。テーマは、直接貢献しないチームメンバーであっても、チーム全体が成果物を中心に結集する機会を提供します。これらのアイテムは、関係するすべての人によって、小さなイテレーションを提供し、仕事のブロックを解除し続けるという観点で、特に注意深く扱われます。チームごとに同時に進行中のテーマは決して2つを超えてはなりません。

• Slack チャンネルは #f_[feature name] という規約で作成されます。
• Epic 階層が作成され、サブ Epic がイテレーションにマッピングされ、それぞれがマイルストーン内で達成可能です。
• イテレーションは独立に達成できる複数の Issue に分割され、PM はそれらを通常通りスケジュールします。
• 定期的な「オフィスアワー」コールなど、他のアクションも確立される可能性があります。

チームメンバーは、複雑さが明らかになるにつれてイテレーションを継続的に洗練するよう協力します。

成功したテーマの例:

1. Requirements Management (#f_requirements-management、Epic)
2. Jira Importer (#f_jira-importer、Epic)

顧客との対話

理想的な世界では、顧客との対話のすべてにクロスファンクショナルな代表者が参加します。これを実現するために、セールス経由で顧客とのコールをスケジュールしている人、ユーザビリティリサーチを実施している人、または顧客や見込み客と話す時間を一般的にセットアップしている人は、イベントに Plan Customer Interviews カレンダー を招待者として追加することが推奨されます。これにより、共有カレンダーに今後の顧客とユーザーのインタラクションが自動的に登録されます。すべてのチームメンバーは、参加して聞くだけのためであっても、参加することが歓迎され推奨されます。

[email protected] という URL を使って、カレンダーを購読し、スケジュールしている顧客ミーティングに参加者として招待できます。

レトロスペクティブ

Plan ステージは、GitLab Issue で月次レトロスペクティブを実施しています。 これらは、最初の議論中は機密扱いとなり、 各月の [GitLab レトロスペクティブ] に間に合うように公開されます。 詳細は、[team retrospectives] を参照してください。

レトロスペクティブ Issue は、[async-retrospectives] プロジェクト内のスケジュールされたパイプラインによって作成されます。動作の詳細については、そのプロジェクトの README を参照してください。

• GitLab retrospective
• team retrospectives
• async-retrospectives
• retros

プロダクトシャドーイング

エンジニアリングのチームメンバーは、プロダクトの安定したカウンターパートをシャドーイングできます。シャドーイングセッションは2営業日、または役割の異なる機能で経験を最大化するため複数日に分割された相当する期間続きます。チームのカウンターパートをシャドーイングするには:

1. plan プロジェクトトラッカーで Product-Shadowing テンプレートを使用して Issue を作成する;
2. このページへの WIP MR を作成し、以下の表を更新して、自分の名前と Issue リンクを追加する。そして、
3. カウンターパートが Issue にアサインされたら、彼らの名前を追加し、WIP ステータスを削除して、レビューのためにマネージャーにアサインします。

スピードラン

• Labels
  • Scoped Labels
• Issues
  • Description Change History

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