【読んでみた】スクラムブートキャンプ

前にこんな本を読んで勉強していました。

nogawanogawa.hatenablog.com

この前はアジャイル開発の基礎の基礎について勉強しましたが、今回はメジャーなアジャイル開発手法であるスクラムについて勉強してみたので、その備忘録です。

今回参考にしたのはこちら。

SCRUM BOOT CAMP THE BOOK

アジャイルとスクラム

アジャイルと一口に言っても、人によって受け取り方が違ったりします。 スクラムだったり、XPだったり、リーンソフトウェアだったり、意外とアジャイルにもいろいろあるようです。 根っこにあるコンセプトは変わりないのですが、視点がいろいろ違ったりするので、今回はスクラムについて見ていきます。

スクラムとそれ以外のアジャイル開発の違い

state of agile report というレポートによれば、"アジャイル"と言われて実践する取り組みはこんなイメージです。

半分以上はアジャイル=スクラムという感じですね。 マネジメントの文脈でアジャイルという場合には、ほぼスクラムと同義だと思っていて問題ないでしょう。

スクラムとは

プロジェクトマネジメントに関する文脈でアジャイルと言われたら、まず間違いなくスクラムのことでしょう。 スクラムはアジャイル的にプロジェクトマネジメントの指針だと言えます。

本書の説明を借りれば、

常に進む方向を調整しながら目的を達成できるプロダクトをつくるために、全員が一丸となって行う作業・会議・成果物を定めたものです。

がスクラムの意味するところと言えます。

スクラムにおける登場人物

スクラムプロジェクトにおける代表的な登場人物には、大まかに下記の3つがあります。

• プロダクトオーナー
• スクラムマスター
• 開発チーム

プロダクトオーナーは、プロジェクトの成果物に対してすべての責任を持つ役割を担っています。 言い換えるとプロダクトがどうあるべきか、完成図を知っているのはプロダクトオーナーだけだという考えに基づいています。

開発チームは、その名の通りプロダクトの開発を実際に行う実行部隊です。 人数はまちまちですが、通常3〜9人であることが多いそうです。

スクラムマスターは、場合によっていたりいなかったりしますが、スクラムになれていないプロダクトオーナーや開発チームに対してアドバイスや支援を行う、開発チーム側の役になります。

成果物

アジャイル開発では、作成するソフトウェアがもっとも価値があるとされており、プロダクトと読んだりします。 基本的には成果物だけだと思っていただければ問題ありませんが、必要に応じて仕様書をつくることもあるので、設計書等もないわけではないです。

また、中間生成物という観点では、プロダクトバックログとその完了の定義が重要な役割を果たします。 プロダクトバックログは前回作り方を紹介したユーザーストーリーを作成し、そのときに洗い出された各ユーザーストーリーの集合がプロダクトバックログとなることが多いようです。 また、このプロダクトバックログに対してポイントの見積もりを行い、プロダクトの難易度を見積もります。 さらに、各ユーザーストーリーには完了の定義を決める必要があります。 この完了の定義をすべて満たすことがプロダクトの完成を意味するように、完了の定義をストーリーごとに判断可能な形で決めることが求められます。

スクラムの進め方

スクラムプロジェクトの進め方には、マクロな視点とミクロな視点の２つの話があります。

マクロ的な視点

マクロな視点でのスクラムの進め方のイメージはこんな感じです。

プロジェクトの初めから終わりまで、ウォーターフォール型とはちょっと違う感じで進んでいきます。 ウォーターフォールで言う要件定義に親しいものとして、リリースプランニングを実施します。 ここでは、プロダクトが必要とする機能（ストーリー）を洗い出し、プロダクトオーナーにとって価値のあるものから順に開発が行われます。

実際の開発はスプリントと呼ばれる期間に区切って行われます。 スプリントの特徴として、スプリントの長さを表すタイムボックスは固定する必要があります。 アジャイルでは開発の速度や当初のプロダクトの見積もりはあくまで見積もりであって、実際にやって行くうちにプロダクトの開発工数や開発チームの能力がはっきりしていくということを許容しています。 タイムボックスが均等に区切られていることで、不確定要素を次第に明確にすることが可能であり、その進捗を見てスクラムチームは柔軟に軌道を修正していくのです。

そして、プロダクトオーナーにとって必要最小限のプロダクトはMVP (Minimum Variable Product)と呼ばれ、これを満たすのが最初の目標になります。その後も優先順位の高いストーリーから順に開発を行い、リリース１、リリース2と段階的に付加価値が高くなったプロダクトがリリースされていきます。

ミクロ的な視点

一方、各スプリントの中というミクロな視点で見ると、こんな感じで流れていくようになります。

各スプリントの初めに、スプリントプランニングが実施されます。 ここでは、プロダクトバックログの中からこのスプリント内に開発に着手するストーリーを重要なものから順に選定したスプリントバックログを作成します。

その後は開発に着手していきます。 特に決まりがあるわけではありませんが、スクラムにおいてはデイリースクラムというミーティングがよくやられています。 これは、開発チーム全員で短時間で前日の進捗と今日の予定、そしてその時の問題を表明し合うものです。 これにより、チーム内での進捗がクリアになり、問題が隠れていくことを防ぎます。

各スプリントの成果物はリリース可能なプロダクトです。 そのため、スプリント内でテストを実施し、スプリント終了時にはテストが全てパスしたリリース可能な状態のプロダクトを作成する必要があります。

スプリントの最後にはプロダクトのリリース可否の判定を行うスプリントレビューが行われ、プロダクトのその時断面のものが確認されます。 この時、完了の定義に即しているかが判断され、ストーリーを満たす機能が実装されているかが確認されます。

最後に、こちらも特に決まりがあるわけではありませんが、レトロスペクティブ（ふりかえり）を行う場合が多いです。 これは、開発そのものにおいても、不確実性に対応すべく、スプリント内で気づいたことを言い合って、開発そのものを改善する場となっています。

感想

今回はアジャイルのうちスクラムの概要について勉強しました。 このご時世アジャイル開発は当たり前ですので、あまり詳しく知らなかった自分を反省しました。

大まかな流れについて見ていきましたので、今度はスクラムにおけるポイントをまとめていきたいと思います。そのうち。。。