スクラム フレームワーク: スプリント、役割、儀式
スクラム これは世界で最も人気のあるアジャイル フレームワークであり、チームの 70% が使用しています。 アジャイル手法を採用しています。 1990 年代初頭に Ken Schwaber と Jeff Sutherland によって作成されました。 スクラムが提供するのは、 軽い構造 複雑なプロジェクトを効率的に管理するため 反復的かつ漸進的。
🎯 何を学ぶか
- スクラムの 3 つの役割: プロダクトオーナー、スクラムマスター、開発チーム
- 5つのスクラムセレモニー（イベント）詳細
- 3 つの成果物: プロダクト バックログ、スプリント バックログ、インクリメント
- タイムラインを含む完全なスプリント サイクル
- 完了および合格基準の定義
- よくあるアンチパターンとその回避方法
- 大規模なスクラム: SAFe、LeSS、Nexus
スクラムとは何ですか?
スクラムとは、 経験的枠組み 3つの柱に基づいて：
🏛️ スクラムの 3 本の柱
- 透明度: プロセスのあらゆる側面が誰にでも見えるようになる
- 検査： 目標に向けた進捗状況を頻繁に確認する
- 適応： 結果に基づいたプロセス調整
スクラム構造
SCRUM FRAMEWORK
├── 3 RUOLI
│ ├── Product Owner
│ ├── Scrum Master
│ └── Development Team
├── 5 EVENTI (Cerimonie)
│ ├── Sprint
│ ├── Sprint Planning
│ ├── Daily Scrum
│ ├── Sprint Review
│ └── Sprint Retrospective
└── 3 ARTIFACT
├── Product Backlog
├── Sprint Backlog
└── Incrementスクラムの 3 つの役割
1. プロダクトオーナー (PO)
Il プロダクトオーナー は「プロダクトオーナー」であり、 価値を最大化する チームの仕事の。
🎯 プロダクト所有者の責任
- 製品ビジョン: 製品ビジョンを定義して伝達する
- 製品バックログ管理: バックログの作成、順序付け、維持
- 優先順位付け: 何が最も重要かを決定する (ROI 重視)
- お仕事の受付： 完了したユーザーストーリーを承認/拒否する
- 利害関係者の関与: チームと顧客/ビジネス間のインターフェース
- 意思決定者: (「どのように」ではなく)「何を」構築するかについて最終決定権を持っています
✅ PO が有効です
- チームが毎日利用できる
- 素早い決断
- 製品の鮮明な視界
- ビジネスドメインを知っている
- 権限を与えられている（権限がある）
- チームと協力的
❌ PO は無効です
- 不在/利用不可
- 決断が遅い、または優柔不断である
- PO「委員会による」
- 彼はビジネスを何も知らない
- 代理のみで権限はありません
- チームを細かく管理する
2. スクラムマスター
Lo スクラムマスター です サーバントリーダー それがチームを助ける スクラムを効果的に導入するための組織。
🛡️ スクラムマスターの責任
開発チームへのサービス:
- 自己組織化と機能横断性に関するコーチング
- 障害物（ブロッカー）の除去
- スクラムイベントを促進する
- 外部の気を散らすものからチームを守る
製品所有者へのサービス:
- プロダクト バックログの効果的な管理を支援する
- チームとのコラボレーションを促進する
- アジャイル実践に関するコーチング
組織へのサービス:
- 組織内でのスクラム導入の推進
- チームの生産性を向上させる
- 他のスクラムマスターと協力する
⚠️ スクラムマスターは以下の者ではありません:
- ❌ プロジェクトマネージャー (スクラムには PM がありません!)
- ❌ チームリーダーまたはマネージャー
- ❌ チーム秘書
- ❌ 配送マネージャー
- ❌ テクニカルリード
スクラムマスターは、 ファシリテーター e コーチ、マネージャーではありません チームに対する権限を持っています。
3. 開発チーム
Il 開発チーム のために協力するプロフェッショナル集団です。 各スプリントの終了時に製品の「完了」増分を提供します。
👥 開発チームの特徴
- 自己組織化: 彼は仕事の進め方を自主的に決める
- 部門横断型: 必要なスキルをすべて持っている (開発、テスト、設計など)
- サブチームなし: 個別の「フロントエンド」チームや「バックエンド」チームはありません
- タイトルなし: 誰もが「開発者」です（内部階層はありません）
- チームとしての責任: 成功も失敗も集合体である
- 最適なサイズ: 3～9人（理想は5～7人）
なぜ 3 ～ 9 人なのか?
👥 TEAM SIZE ANALYSIS
< 3 persone
├─ ❌ Troppo piccolo
├─ Mancano skill necessarie
├─ Vulnerabilità (assenze impattano molto)
└─ Poco scambio di conoscenze
3-5 persone
├─ ✅ Comunicazione facile
├─ ✅ Velocità decisionale alta
└─ ⚠️ Skill coverage limitata
6-9 persone
├─ ✅ Balance ottimale
├─ ✅ Competenze diversificate
├─ ✅ Resilienza ad assenze
└─ ⚠️ Comunicazione richiede più effort
> 9 persone
├─ ❌ Troppo grande
├─ Comunicazione complessa (N*(N-1)/2)
├─ Coordinating overhead alto
└─ Considera split in 2 team5つのスクラムセレモニー
1. スプリント (タイムボックスコンテナ)
Lo スプリント スクラムの中心です。タイムボックス化されたサイクルです。 1～4週間 (最も一般的: 2 週間) この期間中に、製品の「完了」増分が作成されます。
📅 スプリントのルール
- 固定期間: すべてのスプリントで常に同じ長さ
- スプリントの目標: 明確で共有された目標
- 変更なし: スプリント中はスコープは変化しません（フォーカス）
- 品質： 完了の定義は損なわれない
- キャンセル： スプリントをキャンセルできるのは PO だけです (まれです!)
2. スプリント計画
タイムボックス: 1 か月のスプリントあたり最大 8 時間 (短いスプリントの場合は日割り計算)。
参加者： スクラム チーム全体 (PO、SM、開発チーム)。
スプリント計画 - 2 部
🔵 PARTE 1: WHAT? (Cosa faremo?)
Durata: ~50% del tempo (es: 2 ore per sprint 2 settimane)
1. Product Owner presenta top priority backlog items
2. Team fa domande per capire requisiti
3. Team seleziona items per lo sprint (pull, non push!)
4. Sprint Goal viene definito
└─ Es: "Implementare checkout flow completo"
Output: Sprint Backlog (lista user stories selezionate)
---
🔵 PARTE 2: HOW? (Come lo realizzeremo?)
Durata: ~50% del tempo
1. Team scompone ogni user story in task tecnici
2. Stima effort in ore per ogni task
3. Identifica dipendenze e rischi
4. Valida capacità (velocity storica)
5. Commitment del team
Output: Sprint Backlog dettagliato con task
---
📊 CAPACITY PLANNING
Team di 5 persone, sprint 2 settimane:
- 5 persone × 10 giorni = 50 giorni-uomo teorici
- -20% per meeting, supporto, imprevisti = 40 giorni effettivi
- Velocity storica: 30 story points
- → Commitment: ~25-30 story points (conservative)3. デイリースクラム（スタンドアップ）
タイムボックス: 15 分 (固定!)。
参加者： 開発チーム (必須)、SM 施設、PO はオプション。
いつ： 毎日、同じ時間、同じ場所。
🗣️ 3 つの典型的な質問
各チームメンバーは次のように答えます。
- 昨日私がしたこと それはチームがスプリント目標を達成するのに役立ちましたか?
- 今日は何をしましょうか スプリント目標に向けてチームを支援するには?
- 障害があります それが私やチームをブロックしますか？
❌ 毎日のスクラムのアンチパターン
- マネージャーへの状況報告: それは階層的なレポートではありません。
- 拡張された問題解決: 毎日は同期のためであり、問題解決のためではありません（会議後）
- 継続時間 > 15 分: タイムボックスは神聖、日常以外の議論は重要
- 発言者のみがスクラム マスターです。 それはチームでの会話でなければなりません
- 立っている人/座っている人: スタンディングミーティングは時間を短縮するのに役立ちます
4. スプリントレビュー
タイムボックス: 1 か月のスプリントでは最大 4 時間 (例: 2 週間のスプリントでは 2 時間)。
参加者： スクラムチーム + 関係者 + 顧客。
🎬 スプリントのアジェンダのレビュー
- オープニング (5 分): PO はスプリント目標と計画内容を覚えています
- デモ (60%): チームは実際に動作するソフトウェアを示します (ライブデモ、スライドなし!)
- 国防総省によると「完了」のみの機能
- ステージング/本番環境に似た環境
- インタラクティブ: 関係者が製品を試す
- フィードバック (30%): 関係者が意見を提供する
- 何がうまくいきますか？
- 何が足りないのか、あるいは何を変更する必要があるのか?
- 新しいアイデアが生まれました
- 製品バックログの更新 (10%): PO は洞察を伴ってバックログを更新します
デモスクリプトの例
Sprint Review - Sprint 14 - E-commerce Checkout
✅ COMPLETED (Demo order):
1. User Story: "Add payment method selection"
└─ Demo: Credit card, PayPal, Apple Pay
2. User Story: "Implement address autocomplete"
└─ Demo: Google Places API integration
3. User Story: "Order confirmation email"
└─ Demo: Email template with order details
❌ NOT COMPLETED (transparenza!):
4. User Story: "Coupon code validation"
└─ Reason: API integrazione more complex, rollover to next sprint
🔄 FEEDBACK RACCOLTO:
- Stakeholder: "Aggiungere shipping estimation prima del checkout"
- PO: Added to backlog, high priority
- Marketing: "Email template needs company branding"
- PO: Created new story for next sprint5. スプリント回顧展
タイムボックス: 1 か月のスプリントでは最大 3 時間 (例: 2 週間のスプリントでは 1.5 時間)。
参加者： スクラム チームのみ (PO、SM、開発チーム)。外部の利害関係者は不要です。
いつ： スプリント レビューの後、次の計画の前。
🔄 遡及的な目標
検査と適応 作業工程 (製品のものではありません)。焦点を当てる：
- 何がうまくいきましたか? (続けてください)
- 何が間違っていたのでしょうか? (やめてください)
- 何を改善できるでしょうか? (やり始める)
遡及的手法
🎯 TECNICA 1: Start-Stop-Continue
┌─────────────┬─────────────┬─────────────┐
│ START │ STOP │ CONTINUE │
├─────────────┼─────────────┼─────────────┤
│ Pair │ Working │ Code │
│ programming │ overtime │ reviews │
│ │ │ │
│ Automated │ Skipping │ Daily │
│ tests │ retrospect. │ standups │
└─────────────┴─────────────┴─────────────┘
🎯 TECNICA 2: Happiness Radar
Team rate (1-5) diverse categorie:
- Collaboration: ⭐⭐⭐⭐⭐ (Excellent!)
- Technical quality: ⭐⭐⭐ (Needs improvement)
- Work-life balance: ⭐⭐ (RED FLAG!)
- Sprint goal clarity: ⭐⭐⭐⭐
🎯 TECNICA 3: Sailboat Retrospective
⛵ Goal (island): Dove vogliamo arrivare?
🌊 Winds: Cosa ci spinge avanti?
⚓ Anchors: Cosa ci trattiene?
🪨 Rocks: Rischi da evitare?
OUTPUT: 1-3 ACTION ITEMS concreti
✅ Action: "Introdurre TDD da prossimo sprint"
Owner: Tutta il team
Due: Sprint 15
Success: 50% new code has tests first🛡️ 遡及ルール
- 安全なスペース: 裏で言ったことは裏に残る
- お咎めなし: 人ではなくプロセスに焦点を当てる
- 正直： 話してください！改善する時期が来ました
- アクション指向: 苦情だけでなく解決策も
- フォローアップ： 前回のスプリントのアクションアイテムを確認する
スクラムの 3 つの成果物
1. 製品バックログ
リスト 秩序正しくダイナミックな 製品に必要なすべての作業。 製品所有者が所有します。
📚 製品バックログの機能
- 注文済み (優先順位なし): 単一シーケンス、先頭 = 次のスプリント
- 緊急: 常に進化し続けるが、決して「完成」しない
- 適切に詳しく説明します: 上部の項目は詳細、下部は曖昧
- 推定： ストーリー ポイントまたはその他の関連指標
- 透明： 誰にでも見える
製品バックログの例
PRODUCT BACKLOG - E-commerce Platform
Ordered by value/priority (top = next)
Pos | ID | User Story | Points | Status
----|-----|---------------------------------------|--------|--------
1 | 123 | Guest checkout without registration | 8 | Ready
2 | 124 | Save payment methods for future | 5 | Ready
3 | 125 | Product recommendations AI | 13 | Ready
4 | 126 | Multi-currency support | 20 | Refining
5 | 127 | Wishlist sharing social | 8 | Refining
6 | 128 | Advanced search filters | 13 | Refining
...
20 | 145 | Dark mode UI | ? | Idea
21 | 146 | Voice search | ? | Idea
READY = Acceptance criteria defined, DoD clear, impedimenti removed
REFINING = In discussion, needs more details
IDEA = High-level, da elaborare in futuro2. スプリントバックログ
現在のスプリントとそれを提供する計画のために選択されたプロダクト バックログのサブセット。 開発チームが所有します。
📋 スプリント バックログのコンテンツ
- 選択されたユーザー ストーリー
- 詳細な技術タスク
- スプリントの目標
- 実施計画
- 各タスクのリアルタイムステータス
🔄アップデート
- チームによって毎日更新される
- 新たな課題が生まれるかもしれない
- チームのみが編集できます
- ボード上で確認可能 (物理/デジタル)
- バーンダウンチャートはそこから来ています
3. インクリメント
スプリント中に完了したすべてのプロダクト バックログ項目の合計 + の値 以前のすべてのスプリントの増分。そうでなければなりません "終わり" 完了の定義によると。
✅ 完了の定義 (国防総省)
作品が完了したとみなされるときの共有された明確な基準。交渉不可！
完了の定義例
📋 DEFINITION OF DONE (Team Level)
Una user story è "DONE" quando:
✅ DEVELOPMENT
├─ Codice scritto seguendo coding standards
├─ Codice committed su feature branch
├─ Code review approvata (2+ reviewers)
└─ Merged su main branch
✅ TESTING
├─ Unit tests scritti (coverage ≥ 80%)
├─ Integration tests passati
├─ Regression tests passati
├─ Manual exploratory testing completato
└─ Nessun bug P0/P1 aperto
✅ DOCUMENTATION
├─ Inline code comments per logica complessa
├─ API documentation aggiornata
├─ README updated (se necessario)
└─ User documentation scritta (se feature user-facing)
✅ QUALITY
├─ Linter passed (zero warnings)
├─ Security scan passed
├─ Performance benchmarks ok
└─ Accessibility checks passed (WCAG 2.1 AA)
✅ DEPLOYMENT
├─ Deployed su staging environment
├─ Smoke tests su staging passati
├─ Product Owner ha accettato (demo)
└─ Ready for production deployment
---
DoD può avere 3 livelli:
1. Task DoD: Singolo task completato
2. Story DoD: User story completata (sopra)
3. Release DoD: Incremento rilasciabile in produzione完全なスプリント フロー
スプリント タイムライン 2 週間 (例)
SPRINT 14 - Goal: "Implement complete checkout flow"
📅 LUNEDÌ SETTIMANA 1 (Giorno 1)
├─ 09:00-13:00: Sprint Planning
│ ├─ Part 1 (WHAT): PO presenta, team seleziona stories (20 pts)
│ └─ Part 2 (HOW): Breakdown in task, capacity planning
└─ 14:00-18:00: Development inizia
📅 MAR-VEN SETTIMANA 1 (Giorni 2-5)
├─ 09:00-09:15: Daily Scrum (ogni giorno)
├─ 09:15-18:00: Development + Testing
└─ Continuous: Code review, pair programming
📅 MERCOLEDÌ SETTIMANA 1 (Mid-Sprint)
└─ 15:00-16:00: Backlog Refinement (opzionale)
└─ Preparare stories per prossimo sprint
📅 LUN-GIO SETTIMANA 2 (Giorni 6-9)
├─ 09:00-09:15: Daily Scrum
├─ Development + Integration
└─ Bug fixing e polish
📅 VENERDÌ SETTIMANA 2 (Giorno 10)
├─ 09:00-09:15: Daily Scrum (ultimo!)
├─ 09:15-13:00: Final testing e demo prep
├─ 14:00-16:00: Sprint Review
│ └─ Demo a stakeholder, raccolta feedback
├─ 16:15-17:45: Sprint Retrospective
│ └─ Inspect & adapt del processo
└─ 17:45-18:00: Celebrazione! 🎉
🔵 LUNEDÌ SETTIMANA 3
└─ Inizia Sprint 15...一般的なスクラムのアンチパターン
🚫 避けるべき間違い
1. スクラムバット (スクラムバット)
症状： 「私たちはスクラムをやっていますが...[例外]」
- 「スクラムはあるけどデイリースクラムは無い」→スクラムではない
- 「スクラムだけど振り返りなし」 → 決して上達しない
- 「スクラムはあるがPOが利用できない」 → チームは継続的にブロックされる
2. ミニウォーターフォールとしてのスプリント
問題： スプリント内のすべてのフェーズが順番に実行される
❌ BAD: Sprint = Design → Dev → Test → Deploy (waterfall!)
✅ GOOD: Sprint = Iterate su features, ogni feature Done completamente3. スプリント目標が存在しないか曖昧である
問題： スプリントは単なる「タスクリスト」であり、一貫した目標はありません
- ❌ BAD: 「ストーリー 45、46、47、48 を完了する」
- ✅ GOOD: 「ユーザーが登録なしで購入を完了できるようにする」
4. 固定コミットメントとしての速度
問題： 経営陣はベロシティを利用してチームに圧力をかける
- ベロシティは計画の指標であり、達成すべき目標ではありません。
- プレッシャーにさらされたチームが見積もりを膨らませる → ベロシティが意味を失う
5. 製品所有者の代理人
問題： POには権限はなく、常に「質問」する必要があります
- 決断が遅い
- チームがブロックされました
- 解決策: PO に権限を与えるか担当者を変更する
大規模なスクラム
組織に多くのスクラム チームがある場合、調整するためのフレームワークが必要になります。 主なものは次の 3 つです。
🏢 SAFe (スケーリングされたアジャイル フレームワーク)
- エンタープライズ向けの最も人気のあるフレームワーク
- 4 つのレベル: チーム、プログラム、大規模ソリューション、ポートフォリオ
- 8～12週間のプログラム増分（PI）
- アジャイル リリース トレイン (ART): 50 ～ 125 名
- 長所: 構造化され、文書化されており、大規模な組織に適しています
- 短所: 重い、純粋なスクラムより機敏性に劣る
🪜 LeSS (大規模スクラム)
- マルチチームスクラム（2～8チーム）
- すべてのチームに 1 人のプロダクトオーナー
- 1 つの共有製品バックログ
- 同期されたスプリント
- 全体的な振り返りクロスチーム
- 長所: スクラムをシンプルに保つ
- 短所: 高いアジャイル成熟度が必要
🔗 ネクサス
- 3 ～ 9 チーム向けの Scrum.org フレームワーク
- Nexus 統合チームの調整
- Nexus スプリントの計画、レビュー、振り返り
- 継続的インテグレーションに焦点を当てる
- Pro: Scrum.org の公式
- 短所: 最大 100 名までに制限される
有用なスクラム指標
📊 プロセスメトリクス
- 速度： ストーリーポイント/スプリント
- スプリント バーンダウン: 残りの作業
- リリースバーンナップ: リリースに向けた進捗状況
- サイクルタイム: タイムストーリー→完了
🎯 品質指標
- 欠陥率: スプリントのバグ
- コードカバレッジ: % コードテスト済み
- 技術的負債: リファクタリング作業
- チームの幸福度: 四半期ごとの調査
結論
スクラムが提供するのは、 シンプルだが強力な構造 アジャイル開発向け。 成功の鍵は厳格な採用 フレームワークの (スクラムはありませんが!) と組み合わせた 継続的な検査と適応.
💡 キーポイント
- スクラムには 3 つの役割、5 つのイベント、3 つの成果物があり、すべて必須です
- プロダクトオーナーは価値を最大化し、スクラムマスターは業務を軽減し、開発チームは成果を提供します
- スプリントは、明確な目標を持つタイムボックス化されたサイクル (1 ～ 4 週間) です
- 完了の定義は品質に関して交渉の余地のない基準です
- 振り返りは継続的改善のエンジンです
- 透明性、検査、適応が三本柱
- 大規模なスクラムには追加のフレームワーク (SAFe、LeSS、Nexus) が必要です
📚 次の記事
次の記事では、詳しく見ていきます カンバン方式: 連続フローシステム WIP 制限、カンバン ボード、フロー メトリクス (リード タイム、サイクル タイム)、およびスクラムとの比較を含みます。