Iteration 0 の基本

チームの立ち上げ

1. チームの規範と作業合意について整合させる。
2. 役割と責任についてチームを方向付ける。
3. 作業のケイデンスについて合意する。
4. 自分のチーム固有のビジョン、スコープ、ゴールについて整合させる。

作業合意

PMO 組織として、私たちは GitLab 内部および外部の GitLab パートナーの両方とともに、継続的にマイクロチームを編成しています。

新しいプロジェクトのためにデリバリーチームが集まると、作業規範に合意するための短い儀式を行います。最終的にこれは、プロジェクトの成功裏のデリバリーと対人関係の良好な作業関係に結びつく、ポジティブな作業関係を育むものです。

これは私たちの GitLab バリューのいくつかと一致し、心理的安全性を促進します。次のリンクは GitLab の心理的安全性に関する見解 をドキュメント化しています。

なぜ作業合意なのか？

作業合意はオーナーシップとエージェンシーを醸成し、次に貢献します。

• より強いチームの結束とコラボレーション。
• 生産性の向上。
• 定期的なコミュニケーションを通じたプロジェクト課題の早期特定。
• より良いコミュニケーションと透明性。
• より良いワークライフバランス。

プロジェクトチームは Professional Services Engineer、Technical Architect、Program/Project Manager で構成されます。 暗黙的なものを明示化することで、チームメンバー間でつながりのある体験を促進し、心理的安全性を構築します。

作業合意はパフォーマンスを評価するためのツールでは ありません。チームが共に働くのを助けるためだけのものです。

作業合意の例

• プロジェクト全体を通して、各チームメンバーが経験レベルと視点に基づいて最善を尽くすという肯定的な意図を仮定し、認識する。
• GitLab Collaboration Project やコラボレーションツールを使い、自分の仕事を同僚や顧客に対して透明にすることに合意する。
• 対応不可能なときは「不在」とマークし、復帰予定時刻を示す。
• Issue のステータスと時間追跡を毎日更新する。
• コアコラボレーション時間: 10:00 AM - 4:00 PM EST。勤務時間外の対応は期待されない。
• GitLab の 非同期コミュニケーション への嗜好を認識する。これは勤務時間を定義する指示ではなく、チームメイトへの共有事項にすぎない。
• チームメイトおよび顧客への約束を尊重する。何かを行うことを約束したら、期待される時間内にやり遂げる。
• 作業合意は権威的なものではなく、必要に応じて流動的に変更可能であると理解する。

エンゲージメント計画

EM>PS デリバリー移管から始まり、Stakeholder Planning Meeting と Customer Kickoff まで続きます。Iteration 0 全体を通して、継続的に取り組みます…

1. プロジェクトバックログ（ユーザーストーリーと受け入れ基準 - 2 イテレーション）を洗練し優先順位付けする。
2. 初期リリース計画（初期計画と設計）に Issue を割り当てる。
3. Definition of Done (DoD) を定義し、必要であれば Definition of Ready (DoR) も定義する。
4. 自分のチーム固有の制約、阻害要因、リスクを理解する。

技術的・ビジネス的基盤の構築

1. 初期バックログとツールに基づいて、主要なリスクと依存関係を特定する。
2. 望ましい機能性をサポートするデータおよびビジネスアーキテクチャと CI/CD パイプラインを設計する。
3. DevSecOps を可能にするためのエンジニアリングのベストプラクティスを定義し実装する。

本番リリースに向けた準備

1. 初期バックログとツールに基づいて、主要なリスクと依存関係を特定する。
2. 望ましい機能性をサポートするデータおよびビジネスアーキテクチャと CI/CD パイプラインを設計する。

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