スクラム開発
1. スクラム開発とは
- アジャイル開発プロセスモデルの一種
- 複雑で変化の激しい問題に対応し、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるフレームワーク（スクラムガイドより）
2. スクラム開発における役割
プロダクトオーナー
- プロダクトについて責任を持つ人間
- 開発チームとステークホルダーの間の窓口を担当する
- プロダクトバックログの管理に責任を持つ
スクラムマスター
- スクラム開発の推進と支援に責任を持つ、スクラム開発の伝道師的な役割
開発チーム
- 実際に開発を行うエンジニアあるいは専門家のチーム
- チームの規模は5-7名程度が望ましいとされる
ステークホルダー
- プロダクト/プロジェクトの利害関係者
- システムの利用部門の人間である場合もあれば、企画を専門に行う人々である場合もある
3. スクラム開発におけるイベント
スプリント
- プロダクトの開発を行う1週間〜4週間（期間は開発チームが決定する）程度の期間
- スプリントの期間は固定されていなければならない
- スプリントは以下の要素で構成される
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
スプリントプランニング
- スプリントで行う作業を決定する
- スプリント毎に毎回行う
- スプリントで行う作業と成果物は開発チームが決定し責任を持つ
デイリースクラム
- 毎日行われる進捗状況や問題の共有
- 要するに朝会/夕会のようなもの
- 15分以内に終わることが望まれる（スクラムガイドより）
スプリントレビュー
- スプリントの終了時に成果物の確認とバックログの更新を行う
- プロダクトオーナーによるバックログの更新状況の共有
スプリントレトロスペクティブ
- スプリントの終了時に行うスプリント毎のふりかえり
- 反省点・改善点の議論を行う
4. スクラム開発におけるアウトプット
プロダクトバックログ
- プロダクトが必要とする要求/要件のリスト
- プロダクトオーナーが管理に責任を持つ
- プロジェクトが終了するまでスプリント毎に更新され、「完成」することはない
スプリントバックログ
- スプリントプランニングで選択したスプリントで開発する機能をリストアップしたもの
- 開発チームが作成し、管理の責任を持つ
プロダクト
- プロジェクトで作成するべきプロダクトそのもの
- 毎回のスプリント毎に何かしらが完成（利用可能）になっていることが望まれる
- 開発中であっても常に利用可能な状態（デモ可能な状態）に保たれていることが望まれる
5. スクラム開発のメリット
早い段階で動くプロダクトが得られる
- 前提として要件定義やドキュメントでは完全な認識合わせは困難である
- スクラム開発では、何度かのスプリントで最低限動作する機能が提供されることになる為、実際に動作するプロダクトを見ながら関係者の認識を揃えることができる
- 実際に動くプロダクトが1-2週間程度のスプリントで手に入り、要件定義や設計に膨大な時間を掛ける必要がなくなる為、コストパフォーマンスに優れる
フィードバックに基づきあるべき方向へ微調整を掛けることができる
- 最低限動作する機能に対して、フィードバックを受けることでより精密で具体的な要件・仕様が得られるようになる
プロダクトやチームについての問題早く気付ける
- ウォーターフォール開発:
- 全工程が完了した後でないとプロダクトに触ることができない
- 途中で問題が発生すると全体の進行に影響が生じる為、問題解決よりも「問題を起こさないこと」に力が注がれる
- 結果的にチームの問題はよほどの事でない限り、無視される
- スクラム開発:
- スプリント単位で動作するプロダクトを触ることができる
- スプリント単位でふりかえりを行うことでチームの問題点を共有し、改善に繋げていくことができる
- ウォーターフォールでも定期的なふりかえりをすることはできるが、問題点に気付いた時には工程が進んでいるため、そのプロジェクトでは役に立たないという事態が発生しがち
- 結果的にスクラム開発ではチームの学習効率に優れる
結合のリスクを早めに見つけることができる
- スプリント毎に最低限動作するプロダクトをアウトプットしていくので、結合試験で致命的な不具合が発生する可能性を減らせる
- ウォーターフォール開発では結合試験までモジュールやサブシステムの結合が行われないことが多々あり、結果的に結合試験で大炎上するケースが散見される
参考資料