エンジニアリングデモプロセス
クロスファンクショナルな段階的な整合性を確保するために、定期的なペースでデモを設定することが有用な場合があります。 これは複数の機能チームにわたる統合が必要な高インパクトな成果物に役立ちます。これはアジャイルマニフェストの7番目の原則と一致しています：「動くソフトウェアが進捗の最良の尺度です」。
デモスクリプト
複数人のグループや重要なプロジェクトには、より重みのある採点プロセスを使用します:
- デモオーナーはビジネス基準に基づいてデモの成果を特定します。これはエンジニアリングマネージャー、プロダクトマネージャー、または成果のビジネスステークホルダーである人が担当できます。
- デモオーナーは成果を小さな部分に分解し、機能エリア（トラック）に沿って手順のフローとして構造化します。これは後でデモステップとして記録されます。
- 暗黙的な依存関係を明らかにするために、どんなに小さく見えても各ステップをリストアップしてください。
- デモオーナーは各デモトラックの DRI として機能チームリーダーを特定します。各トラックの DRI はそのトラックを完成させるまでデモする責任があります。
- デモオーナーは機能チームリーダーと協力してスコアカードにデモステップを記入します。デモスコアカードテンプレートはこちらです。このテンプレートを使用するには:
- テンプレートをコピーしてイニシアティブ/成果物にリネームする。
- スコアカードシートのスコアをクリアする。
- デモトラックとデモステップを記入する。
- 注意: 記入済みのデモスコアカードの例はこちらです。
- デモオーナーは採点の説明責任を保持するデモ採点者を特定します。これはデモオーナー本人か、製品ドメインとお客様のユースケースに精通した人が担当できます。デモ採点者はエンドユーザーの成功を擁護できる人であることが重要です。
デモのスケジューリング
- スクリプトが確定したら、デモオーナーは終了目標日を設定して定期的に記録されるミーティングをスケジュールします。
- デモオーナーとデモ採点者は説明責任を確保するためすべてのデモに出席する必要があります。一時的な欠席には適切に代理を指定してください。
- スコアカードに加えて各参加者がメモを取れるアジェンダドキュメントを作成します。
- 参加者はデモの成果物の主要なビジネスステークホルダーとプロダクトグループチーム（開発、UX、Quality、プロダクト）です。
- ミーティングは30分以内に収めてください。製品要件と受け入れ基準に重点を置いてください。
- デモがキックオフされ、各デモトラックは完成まで毎週進捗をイテレーションします。
- GitLab Unfiltered チャンネルへのライブストリームまたはアップロードはオプションです。実施する場合は SAFE ガイドラインに従ってください。
デモの採点
デモマスターはデモミーティング中に各ステップを採点します。主観性を減らすために、広く理解・コミュニケートされているスケールを使用します。 採点の定義は以下の通りです:
| スコア | 定義 |
|---|---|
| 5 | すべてのステークホルダーからサインオフ済み |
| 4 | 「完了の定義」に従ってデモ済み |
| 3 | デモ済みだが不完全および/またはバグあり |
| 2 | 初歩的な状態でデモ済み、作業は開始済み |
| 1 | まだ開始されていないまたはデモできない |
シングルエンジニアグループのデモ
シングルエンジニアグループでは異なるデモプロセスが使用され、デモスコアカードは必要ありません。
- コンピューターまたは Zoom ライブストリームで動くソフトウェアのビデオを録画する
- GitLab Unfiltered チャンネル にアップロードする
- 適切な Slack チャンネルに YouTube リンクを投稿する
- 定期的に繰り返す
