勤めている会社で、スクラムで開発を進めているプロジェクトに初めて入ることになったので、先輩におすすめいただいた スクラムブートキャンプ（SCRUM BOOT CAMP THE BOOK） を読みました。
この本の紹介に書いてある「はじめて『スクラム』をやることになったら読む本」という言葉通り、マンガをはさんだストーリー仕立ての説明はとても分かりやすかったです。
後から見返せるように、ポイントをまとめてみました。このブログを読むだけでもスクラムの雰囲気は分かると思います。
ソフトウェアをつくる上で大事なこと
- できたものを使って利用者が便利になる等の成果をあげること。何かを作ることは目的ではなく、あくまで手段である。当初作ろうと思っていたものよりも良いアイデアが出れば、目的を達成するためにそれを受け入れながら、作るものを変えていく。そうすることで成果を最大化できる
- このような考え方で、成果を最大化するために考案された開発の進め方がアジャイル開発である
アジャイル開発とは
-
次のような開発の進め方をアジャイル開発と言う
-
-
関係者は目的の達成のためにお互いに協力し合いながら進める
-
-
-
利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する
-
-
-
一度にまとめてではなく、少しずつ作る。そして実際にできあがったものが求めているものと合っているかを頻繁に確認する
-
- あらかじめおおよその全体像を明らかにしたうえで、どのくらいの期間と人数で仕事をするかを決めて、その範囲の中で大事な要求から順にプロダクトを作っていく
スクラムとは
- 目的を達成できるプロダクトをつくるために、常に進む方向を調整しながら全員が一丸となって行うべき作業、会議、成果物を定めたものをスクラムと言う
スクラムの進め方
- スクラムではプロダクトオーナー（後述）が要求を並べ替えて、開発チームがスプリント単位でプロダクトをつくっていく
- 「プロダクトバックログ」（プロダクトへの要求を抽出して順番に並べ替えたリスト）を作成し、常にメンテナンスして最新に保つ
- スプリント（1週間〜4週間）の固定の期間内で、計画、設計、開発、テストなどプロダクトのリリースに必要なすべてのことを行う
スクラムのチーム編成
プロダクトオーナー
開発チーム
-
通常3~9人で構成される。3人未満だと個人のスキルに依存してしまい、10人以上だとコミュニケーションコストが増えてしまう
- 開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとに決められ、外部から仕事の進め方を指示されることはない
スクラムマスター
- スクラムのプロセスを円滑を回して、プロダクトオーナーや開発チームを支える
スクラムで実施するミーティング
スプリントプランニング
- スプリントの開始時に行う
- 2つのトピックを扱う
- 2週間スプリントであれば、4時間程度を使う
プロダクトバックログリファインメント
- 準備する内容の一例
-
- 中身を具体的にする
- 疑問点を解決する
- 何ができたら完成なのか（受け入れ基準）を明確にする（デモ手順まで決めておくと認識が揃いやすい）
- 自分たちが扱えるサイズに分割する（具体的な分割方法はこちらの記事が参考になりました）
- 見積もる
- いつどのように行うかはスクラムでは定義していないが、使う時間はスプリントの10%以内にするのが一般的
デイリースクラム
- スプリント期間中、毎日、同じ場所、同じ時間に行う
- スプリントバックログの残作業を確認し、このまま進めてスプリントゴールが達成できるのかを確認する
- 開発チームのメンバーが以下の3つを話す形で進めることが多い
-
- スプリントゴールの達成のために、自分が昨日やったことは何か
- スプリントゴールの達成のために、自分が今日やることは何か
- スプリントゴールを達成する上で、障害となるものがあるか
- 問題解決の場ではないことに注意する。開発チームのメンバーが問題を報告した場合は、デイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定する
- 開発チームの人数に関係なく 15分間で行う
スプリントレビュー
-
スプリントの終わりに行う
- ステークホルダーに参加してもらう
- 開発チームのスプリントでの成果物を関係者にデモを行い、フィードバックを得てプロダクトバックログを見直す
- デモができるのは完成したものだけである
- 2週間スプリントであれば、2時間程度を使う
スプリントレトロスペクティブ
- スプリントレビューの後に行う
- スプリントの振り返りを行う。うまくいったこと、今後改善すべき点を整理し、今後のアクションプランをつくる。アクションプランのうち少なくとも1つは次のスプリントのスプリントバックログに含めると良い
- アクションを検討するときは、アイデアを具体化するために便利な指標であるSMARTを意識すると効果が高まる
-
- Specific（具体的な）
- Measurable（計測可能な）
- Achievable（達成可能な）
- Relevant（問題に関連のある）
- Timely / Time-bounded（すぐできる / 期日のある）
- 2週間スプリントであれば、1.5時間程度を使う
スクラムを行う上で知っておいた方がいいこと
- プロダクトバックログは詳細なフォーマットは定められていないが、以下のどちらかの形式で書かれることが多い
-
- 機能・目的・詳細でまとめて一覧にした形式
- 実際に使うユーザーに何を提供してその目的は何かを簡潔に書く、ユーザーストーリーという形式
- プロダクトバックログに重要な項目が漏れないようにするためのやり方：スクラムチームみんなで、プロダクトバックログに含めたほうがいいと思う項目を付箋などに書き出していく。様々な人のいろんな観点で洗い出すことで、致命的な漏れをなくすことができる
-
スプリントごとに終わらせられるポイント数は、ベロシティと呼ばれている。ベロシティはスクラムチームのスピードのようなものである。ベロシティは決めるものではなく測るものであり、実際に行った数字を使うのが一番確実である
-
プロジェクトで調整できるものは次の4つしかない。品質、予算、期間、スコープ である
おわりに
本書は、最初にスクラムについてのポイントをまとめ、その後は実践編としてマンガをはさみながらのストーリー仕立てで解説していくという構成でした。
サクサク読めてとても分かりやすかったので、ご興味ある方は是非お手に取ってみてください。
次は、会社の方におすすめいただいた カイゼン・ジャーニー （アジャイル開発の実例を書いた有名な本です）を読む予定です。
以下の記事を合わせて読むことでスクラムのベースとなるアジャイル開発についての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。
