認定スクラムマスターになり、社内でも実践したり勉強会を開催したりするなかで気になって調べたこと、勘違いしていたことなどを整理して備忘録として残しておくことにした。
スプリントレビューについて
プロダクトオーナーにお披露目するのではない。プロダクトオーナーがステークホルダーにお披露目する場。
受入条件（Acceptance Criteria）の確認はすでに終わっていて、Doneの定義を満たしているものをお披露目することになる。
プロダクトオーナーによる確認は、スクラムチームの一員として、随時行っているべきもの。
（スクラムガイドにちゃんと書いてありました。よく読まないといけないですね、、）
品質について
社内でよく聞かれるのが、｢品質はどう確保するのか？」ということです。
アジャイル開発は品質が悪くて、ウォーターフォールなどの重量プロセスは品質が良いモノができる、というのは誤りです。これは、Doneの定義を明確にして、ちゃんと運用しておけばよい。
とりあえず動くレベルのものをスプリントのインクリメンタル（成果物）としてしまうと、この問題が起こる。もちろん、プロダクトのフェーズや特性によっては、とりあえず動くレベルをスプリントのインクリメンタルとすることもあり得るが。
受入条件と完成（Done）の定義について
受入条件は、個々のバックログアイテムの満たすべき要件（主に仕様面）。完成の定義は、プロダクトバックログやインクリメンタルが、何を持って「完成」とするかプロジェクトルールとして定めたもの。つまり、バックログに関していうと、“受入条件を満たしていること”とか、“受入条件を満たしていることをプロダクトオーナーが確認済みであること”とかが含まれる。それに加えて、“ソースコードと、対になるテストコードがコミットされていること”だったり、“〇〇仕様書に仕様が反映されていること”なんかを完成の定義に含めることもある。
つまり、完成の定義をどう定めるか、がスプリントのインクリメンタル（および付帯するドキュメントなど）の品質に大きく影響する。
単に作るだけ、を考えたときと、完成の定義を満たすレベルを考えたときとでは、スプリントで実装できるバックログの量が大きく違ってくるので注意が必要。
スクラムのはじめ方
プロジェクトでスクラムを採用した場合、実はいきなりスプリントが開始することはない。なぜかというと、初期のプロダクトバックログがまだ無いはずだし、完成の定義も定まっていないから。
まずは、準備期間やスプリントゼロ、という位置づけで、これらを整える必要がある。
こちらのブログエントリでも少し触れました。アジャイル開発における初期設計について - jiigのREDOブログ
最低限やっておくべきことには、以下のようなものがある。
- プロジェクトの目的の明確化
- 開発言語や開発環境の選定
- プロダクトバックログ作成
- 完成の定義を決める
- ステークホルダーの洗い出しやスプリントレビューへの参加要請
- システム全体のアーキテクチャの設計
- 使用するミドルウェアやライブラリ選定
- 概念データモデリング
- スクラム未経験メンバーの教育
他にも出てきたら書き足していきたいと思います。
