スクラム開発って何？『SCRUM BOOT CAMP』を読んだのでまとめてみる
なぜこの記事を書くのか
とある面接で「普段はスクラムで開発をしているの？」と質問されたのだが、スクラムについてほとんど知識のなかった私は、「(多分)そうです」というあいまいな回答しかできなかった...。
そこで、入門書として読みやすい『SCRUM BOOT CAMP THE BOOK』(株式会社翔泳社)を読んでみた。
普段の開発はスクラムなんだろうと思っていたが、この本を読んで、私が経験してきた開発はスクラムではないということに気づいてしまった。
今後、スクラムでの開発に困らないようにアウトプットする。
参考文献
『SCRUM BOOT CAMP THE BOOK』(株式会社翔泳社)
3つの作成物
【作成物１】プロダクトバックログ
実現したいことが並べられたリスト。機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたもの。誰でも(スクラムチーム外の人でも)リストに項目を追加できるが、順番や必要性など最終的な判断はプロダクトオーナーが行う。プロジェクトにつき１つ。
【作成物２】スプリントバックログ
プロダクトバックログは項目ごとに、具体的な作業を洗い出すなどして作業計画を立てるが、その選択したプロダクトバックログ項目と作業の一覧のこと。個々の作業は１日以内で終わるように分割するのが一般的。
【作成物３】インクリメント
過去のスプリントと今回のスプリントの成果を合わせた動作するプロダクト。
５つのイベント
【イベント1】スプリント
スクラムでは1週間〜１ヶ月ほどの単位で、プロジェクトの期間を同じ期間に区切って繰り返す。
１つの区切りをスプリントと呼ぶ。
期間の長さは、作業が終わらなかったとしても、スプリントごとに変えてはいけない。(変えないことで、今後の予測を具体的に行うことができるようになる)
【イベント2】スプリントプランニング
スプリントを始める前に、スプリントで何を作るのか(What)、どのように作るのか(How)を計画する。その計画を決定する場。使える時間は、２週間スプリントなら４時間ほど。
【イベント3】デイリースクラム
ゴールの達成に向けて進んでいるか毎日検査する。１日15分ほどで行い、延長はしない。開発メンバーが以下の３つの質問に答える形で進める
- スプリントゴールの達成のために、自分が昨日やったことは何か？
- スプリントゴールの達成のために、自分が今日やることは何か？
- スプリントゴールの達成するうえで、障害となるものがあるか？
デイリースクラムは問題解決の場ではない。開発メンバーから問題が報告された場合は、デイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定する。(15分を死守するため)
【イベント4】スプリントレビュー
スプリントの最後に、プロダクトオーナーの主催で行う、スプリントの成果をレビューするイベント。開発チームのスプリントでの成果物(完成したもの)を関係者にデモする。デモすることができるのは完成した項目だけ。
フィードバックを得て、プロダクトバックログを見直す。
また、以下のようなことについて報告・議論を行う。
- スプリントで完成しなかったプロダクトバックログの項目について説明する。
- スプリントでうまくいかなかったことや直面した問題点、解決した方法について議論する。
- プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する。
- プロダクトバックログに追加すべき項目の有無について議論する。
- プロダクトの開発を進めるうえで問題となる事項について議論する。
- 現在の進捗を踏まえて、リリース日や完了日を予測する。
スプリントレビューに使える時間は、２週間スプリントであれば、２時間ほど。
【イベント5】スプリントレトロスペクティブ
直近のスプリントでプロダクトの開発に関わる活動において問題がなかったか、もっと成果を出すためにできることがないか検査を行い、次回のスプリント以降のアクションアイテムを決める。もっと成果を出せるように自分たちの仕事のやり方を変えていく。
ただし、一度にたくさんのことを変更しようとしない。
ふりかえりでは、問題を100%解決しようとするのではなく、1%でも前に進めるアイデアがあればどんどん出していくようにする。またふりかえりのアクションも「小さくやってみる」ことを意識する。
スプリントレトロスペクティブに使える時間は、２週間スプリントであれば、１時間半ほど。
3つのロール
【ロール１】 プロダクトオーナー
プロダクトの責任者。１プロダクトにつき１人。そのプロダクトが生み出す価値を最大化する責任がある。プロダクトバックログの管理者。
【ロール2】 開発チーム
プロダクトオーナーが順位づけしたプロダクトバックログの項目を順番にスプリント単位で開発していく。３〜９人で構成される。プロダクトを作るために必要な全ての作業ができなければならない。そのため、作業を進めていく過程でなるべく個人が複数のことをできるようになることが望まれる。
【ロール3】 スクラムマスター
プロセスを円滑にまわして、プロダクトをうまく作れるようにプロダクトオーナーや開発チームを支える。スクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、スクラムの外にる人からの妨害や割り込みからプロダクトオーナーや開発チームを守る。
プロダクトオーナーとの兼任は不可。(開発チームに対する利害が一致しない場合があるため)
スクラムと私が経験した開発の比較
１. 開発の前のスプリントプランニング(作業準備)を行っていなかった
機能追加のチケットがあった場合、事前にチームみんなでどのくらい時間がかかるのか、どのような作業が必要なのか検討する機会がなかった。それらは、チケットの担当者が自身で行うこととなっていた。そのため、スクラムでの１日単位でタスクを切り分けるというのが、あまりイメージできなかった。
以前に、受託開発の見積もりをした際、工数を検討する場があったが、「みんなで行う」ということの意義を分かっていなかった私は、先輩方の意見をただ聞いているだけだった。
2. スプリントを意識していなかった
事前に作業にかかる時間を想定しないため、スプリントを意識することもなく、だらだらと開発を行ってしまっていた。
３. デイリースクラムでの問題報告をしていなかった
上記のように、スプリントを意識しないため、時間がかかりそうな問題があっても、毎日の会議で報告をしっかり行うということをしていなかった。
４. 次のチケットに移行する際のふりかえりがなかった
上記のように、問題を抱えたとしても自己解決をしていたため、みんなでふりかえりをする場がなかった。
コードレビューがチームからもらえる唯一のフィードバックだと思っていたが、スクラムではスプリントごとにフィードバックのための会議があるということを知って驚いた。
感想
これまで経験してきた開発現場では思っていることを常に口にできないまま作業をしていたなと反省するきっかけになった。
開発をしていて課題だと思ったことは自分の意見として伝える努力をしていきたい。
Discussion