[読書] SCRUM BOOTCAMP THE BOOK
スクラム開発 アジャイル開発
読んだ本
| SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 |  |
モチベーション
- 諸事情あって転職することになり、新環境ではスクラム開発をするこということに。
- スクラム開発をやるうえで最初に読む本として、おすすめということで転職先が購入してこちらの本を送ってくれました。
理解メモ(復習)
基礎編：スクラムってなに？
- スクラム開発とは
- 1990年代にKen Schwaber と Jeff Sutherland によってつくられた
- 日本の経営学者（野中郁次郎、竹内弘高）の論文「The New New Product Development Game」をソフトウェア開発に応用したもの
- 要求をリスト化して、価値やリスクや必要性の観点で並べ替え、その順で取り組む手法
- タイムボックス＝固定の短い時間で区切って作業をすすめるための単位
- 透明性＝現在の状況や問題点を常に明らかにする
- 検査＝定期的に進捗状況や成果、仕事の進め方を確認する
- 適応=やり方を変える
- イベント=スプリント、デイリースクラムなど
- ロール=スクラムマスター、プロダクトオーナー、開発者など
- 作成物=プロダクトバックログ、スプリントバックログ、インクリメント
- プロダクトオーナー
- プロダクトのWhatを明確にすることに責任を持つ人
- 1プロダクトにつき1人
- プロダクトバックログを管理する
- プロダクトバックログ項目が完成しているかどうかを確認
- 開発チームには相談はできるが干渉はしない
- ステークホルダーと協業する
- 開発チーム
- プロダクトのHowを担当
- 3人〜9人で構成する
- 3人以下だと、個人のスキルに依存するため適切でない
- 10人以上だとコミュニケーションコストが増えるため適切でない
- 要求分析チームとかテストチームとしてわけず、機能横断的
- 開発チームでの進め方は、外部からの指示されず自ら決めていく＝自己組織化
- スプリント
- 最大1ヶ月以内の一定の期間
- 期間の長さは決まっていないが、固定の長さとして、途中から変わってはいけない
- スプリントの最終日に作業が残っていても、スプリントは終了し、延長しない
- 状況の変化によって、現在のスプリント意味がなくなった場合はプロダクトオーナーの権限でスプリントを途中で中止することが可能
- スプリントプランニング
- スプリント期間が最大1ヶ月の場合は、8時間。スプリントが短ければ、それよりも短くするのが普通
- トピック１：Whatを決める
- プロダクトオーナーが今回のスプリントで達成したい目的：スプリントゴールをあきらかにする
- それを達成するために必要なプロダクトバックログ項目を選ぶ
- ベロシティとキャパシティ（今回のスプリントで、作業に使える時間)を参考にする
- 事前準備：プロダクトバックログリファインメント
- ユーザーストーリーの何ができたら完成とするのかを明確にする
- 自分たちが扱えるサイズに分割する
- 項目を見積もる
- この時間はスプリントの10%以内に収めるのが一般的
- トピック２：計画をたてる
- 必要な作業項目をリストアップして計画を立てる
- スプリント内で達成すべきプロダクトバックログと、上記の作業項目をあわせてスプリントバックログとよぶ
- スプリントバックログは、開発チームで自由に作業を追加したり、削除できる
- 個々の作業は1日以内で終わるように分割するのが一般的
- スプリントプランニングできめたプロダクトバックログ項目を完成させるのが難しい場合は、プロダクトオーナーと相談して、削るなどして作業量を調整する
- プロダクトバックログ項目は、かならず達成することを約束したものではないので、作業を簡易化したり、長時間残業するものではない
- インクリメント
- スプリントでの成果（プロダクトバックログ項目）をインクリメントと呼ぶ
- インクリメントは、動作しているソフトウェアとして提供される必要があるため、検査可能でなければならない。
- プロダクトオーナーと開発チームが指す完成の形=完成の定義
- 以下のようなものが完成の定義の具体例
- コードレビュー
- ユニットテスト
- カバレッジ85%
- 性能
- デイリースクラム
- 朝会でスプリントバックログの項目を確認
- 15分のタイムボックスでおこない、延長はしない
- 問題解決の場ではないので、簡潔に進捗を確認できるようにする
- スプリントレビュー
- プロダクトオーナーが主体で、ステークホルダーを招待しておこなう
- できあがったものをデモする。できあがったものなのかそうでないのかは、プロダクトオーナーと開発チームで事前に明確にしておく
- スプリントレトロスペクティブ
- スプリント内の開発方法を自分たちでふりかえる
- スプリントレトロスペクティブで出た改善項目の１つは次のスプリントバックログにふくめることがスクラムガイドに書かれている
- 1ヶ月のスプリントであれば、3時間。それよりも短いスプリントであれば、それよりも短く。
- スクラムマスター
- スクラムがうまくまわるようにする
- まとめ：スクラムの５つの価値基準
- 確約：それぞれの人がゴールの達成に全力を尽くすことを確約する
- 勇気：正しいことをする勇気を持ち、困難な問題に取り組む
- 集中：全員がスプリントでの作業やゴールの達成に集中する
- 公開：すべての仕事や問題を公開することに合意する
- 尊敬：お互いを能力ある個人として尊敬する
実践編：どうやればうまくいくの？
- 半分マンガの物語形式でスクラムの実践が説明されていました。ここでは、私が気になったポイントのみをリストアップします。
- Scene No.02 どこを目指すのかを理解する
- インセプションデッキ：明らかにすべき10個の問い
- 一方的にスライドをつくって説明するのではなく、チームで考えることが大事
- Scene No.03 プロダクトバックログをつくる
- 優先順位は、スクラムチームが自分できめること
- Scene No.06 この先の計画を立てる
- 初回のリリースがいつになるのか、決められた期限までにリリースできるのか、予算がおさまるのかはどうしても知りたいもの。アジャイル開発をやっているかどうかは関係ない。
- プロダクトバックログ項目のポイント数と1スプリント内のベロシティから計画を見積もる
- ベロシティは計測値なので、目標値にはしない
- Scene No.07 詳細な計画を立てる
- なにが「完成した」状態なのかを明確にしておくことがポイント
- 確実に達成できる詳細な計画を立てる
- スプリントプランニングがうまくいかなかったとしても次のスプリントに活かす。隠蔽しない
- Scene No.10 何が完成したかを明らかにする
- フィードバックによって、プロダクトバックログの見直しなど、本質的なところに気づくきっかけになる
- 完成の定義をきちんと用意するのと同時に、進行ともに完成の定義もブラッシュアップする
- 事前に開発チーム、POの両方が完成と思えるものができているか確認してからレビューする
- Scene No.11 先を予測しやすくしておく
- スプリント期間など、タイムボックスをきっちり守るべきなのは、今後の予測をしやすくするため
- タイムボックスを守ることであつかうものを小さくできるので、見通しがたてやすくなり、実力にあわせた取り組みがしやすくなる。
- タイムボックスが守れているか、はスクラムチームが成長できているかの指標になる
- Scene No.13 みんなの自律を促していく
- スクラムは、最低限守ってほしいものだけが書かれており、足りないことがある。ルールがたくさん増えることで形骸化するため、シンプルにつくられている
- 自分たちで自分たちのルールをつくって、メンテナンスしていく＝自律したチーム
- Scene No.16 意図を明確にしておく
- レビューで起きそうな問題=意図が伝わっていない
- ユーザーの立場で表現する=ユビキタス言語
- ユーザーストーリーのフォーマット
- <どういったユーザーや顧客>として
- <どんな機能や性能>がほしい
- それは<どんなことが達成したい>ためだ
- とくにwhyの部分を伝える
- 文で書くのは限界なので、直接会話できるならそうする
- オフショアで開発チームが海外にいるなど、状況に応じて、ドキュメントを作るなど
- Scene No.17 スクラムチームを支援していく
- 技術的負債（扱いにくいコードが増えている）によりスプリントで進められる量が減ってしまうことがある。情報の非対称性により、スプリントプランニングに上手く反映されないことも
- スクラムマスターはよくないことの予兆を感じとったり、インジケータとして測ったりしたいところ。残業時間、テストケースの数
- 問いかけを開発チームにして、チーム自身での解決を促す
- Scene No.18 より良い状態にしていく
- 抱えている問題はチームに包み隠さずに公開する。
- 問題の一覧にまとめ、原因を探り、管理する=スクラムマスター
- Scene No.22 さまざまな状況に対応する
- さまざまな状況に対応するには、開発チームのメンバーが機能横断的に自己組織化しながら進められる必要がある
- スキルマップでメンバーの得意不得意を可視化
- ドラッカー風エクササイズで、メンバーの期待、得意、不得意を認識
- スウォーミング=モブプロなどで手戻りを減らしたり知識の移転をしながら進める方法もある
感想
- 以前スクラムガイドを読んだことはありましたが、実際にどうやるのかあまりわからずだったので、こちらの本は導入本としてさらに噛み砕いて説明されていて良かったです。
- カイゼン・ジャーニー を読んだときはまだ自分がアジャイル開発をやる状況になったわけではなかったので、今回スクラムを実践することを想定しながらこちらを読んでまたアジャイル開発の解像度をあげることができた気がします。
今後の展望
- XPやリーンソフトウェア開発との違いも気になるところです。
- とくにリーンソフトウェア開発はDevOpsとの関連が深いので、そちらもすこし覗いてみたいなと思いました。
最終更新日: May 11, 2024