SCRUMはただの柔軟なソフトウェア開発の手法だと思っていた
特にSCRUMの開発経験はないので、SCRUMという名前は知っていてもそこまで具体的には知らなかった。
だから、ソフトウェア開発をアジャイルに進めていくための手法、という程度の認識しかしていなかったのだけど、SCRUMの本を読んでみると、もちろんそうなんだけど、それだけではない、というふうに自分は感じた。
むしろ、アジャイル開発の中で、チームというものをどう成長させていくのか、どうやってチームが強くなっていくのかという点に重きをおいているように思えた。
SCRUMの基本をまとめてみる
一旦自分の整理のためにSCRUMの基本をまとめてみる。
3つのロール
SCRUMには3つのロールが存在する。
- プロダクトオーナー
- 開発チーム
- スクラムマスター
そして、この3つのロールがプロダクトバックログという一つの柱を軸に、それぞれが役割を発揮していく。
プロダクトバックログとはプロダクトの実現したいことを、実現したい順に並べたもののこと。
プロダクトオーナーは、プロダクトバックログの順番に責任を持つ。
プロダクトバックログの順番を並べ替えられる権限を持つのは、プロダクトオーナーだけである。
開発チームは、プロダクトバックログの項目をどうやって実現するのかということに責任を持つ。
スクラムマスターは、プロダクトオーナーと開発チームがうまくSCRUMのフレームワークにのれるようにサポートすることに責任を持つ。
開発の流れ
実際の開発は、スプリントと呼ばれる期間で区切った単位で進めていく。
- スプリントが始まる際に、プロダクトバックログから今回のスプリントで開発を進める項目を決めて、タスクに落とし込んでいく。これを、スプリントプランニングと呼ぶ。
- スプリント中は毎日、今やっていること、昨日やったこと、困っていることを共有する。これを、デイリースクラムと呼ぶ。
- 開発チームは過去のスプリントと、現在のスプリントで開発したものを合わせて、動作して検査可能なものを作成する。この成果物を、インクリメントと呼ぶ。
- スプリントの終盤でインクリメントのデモを行い、フィードバックを得る。これを、スプリントレビューと呼ぶ。
- 最後に、次のスプリントに向けてもっと改善したほうが良いことなどを話し合う。これを、スプリントレトロスペクティブと呼ぶ。
この一連の流れを1スプリントごとにまわしていき、開発を進めていく。
見通しを立てるために
1スプリントを終えたとき、開発チームが1スプリントでどれだけのことができるのかということが見えてくる。
この1スプリント単位の作業量のことをベロシティと呼ぶ。
そして、同じようにプロダクトバックログの各項目にも、どれだけの作業量が必要そうかを、開発チームは見積もる。これを、ストーリーポイントと呼ぶ。
プロダクトバックログの各項目のストーリーポイントがわかり、開発チームのベロシティがわかると、バックログのどこまでが何スプリントで終わりそうなのか、という見通しが立てやすくなる。
プロダクトバックログの見直し
スプリントをまわしていくためには、プロダクトバックログから項目を選択し、タスクに落とし込んでいく必要がある。
プロダクトバックログの項目をタスクに落とし込むためには、バックログの項目をある程度詳細に詰めておく必要がある。
また、項目は本当にこれでいいのか、並び順は本当にこれでいいのか、といったような見直しも常にする必要がある。
このプロダクトバックログの見直しのことをプロダクトバックログリファインメントと呼ぶ。
プロダクトバックログリファインメントは特にこのタイミングで必ずやらないといけない、というようなルールは定められていない。ただ、プロダクトバックログの更新が止まってしまうのは絶対によくない。
と、ものすごくざっくりまとめてみると、こんな感じだと思う。
この理解をもとに、自分の感想をまとめてみる。
ロールの明確さ
まず、3つのロールについて。
ロールが少ない。そして、それぞれの責任範囲が明確になっていることが、素晴らしい。
特に、プロダクトオーナーだけがバックログの順番を並び替える権限を持つ、という点。
よくある「で、誰がこれを決めるんでしょうか？」ということを聞かなくてもよくなりそう。それだけでだいぶ嬉しい。
徹底したタイムボックス
SCRUMでは、各イベントに対してタイムボックスが設けられている。
スプリントは、1週間から1ヶ月の間で定める。
そして、スプリントの長さに応じて、スプリントプランニングにかけられる時間などが定められている。（1ヶ月スプリントであれば8時間など）
デイリースクラムは必ず15分以内に終わらせる。
時間をフレームワークによって定められることで、「この時間ってどれぐらい使っていいんだっけ？」という無駄な脳のリソースを使わなくてもすむ。これもでかい。
名前がつけられることのやりやすさ
SCRUMというフレームワークにのっからずとも、SCRUMの中のイベントのようなことは、よくやっているはずである。
次になにするかを話し合ったり、タスクばらしをしたりなど。
だけど、それに対して「プロダクトバックログリファインメント」だったり「スプリントプランニング」という名前がはっきりとつけられることで、途端にやりやすくなる。
目的がはっきりするし、今何をやっているか迷わなくなるからだと思う。
自分たちの力を知り、自分たちで解決し、自分たちで強くなっていく
ここまでの感想は、SCRUMだからというよりも、フレームワークに乗っかるってそういうメリットがあるよね、という部分が強い気がする。
でも、タイトルに書いたように、SCRUMはチームとして成長するためのフレームワークなんだなと感じた。
ベロシティというのは、まさに、今の開発チームの開発力の見える化であって、スプリントを繰り返していくときっと上がっていく値なんだと思う。
それはスプリントというものが、前回のスプリントよりも今回のスプリントを少しでも良いスプリントにするという信念のもとに組まれているように見えたからである。
そして、この信念を実行するのは、開発チームそのものなのだ。
そのためのスプリントプランニングであり、そのためのデイリースクラムであり、そのためのスプリントレトロスペクティブなのだ。
本の中で、デイリースクラムは進捗報告の場ではなく、自分たちで問題を見つけるための場であると説明されていた。
毎スプリント、自分たちで計画を立て、自分たちで問題を見つけ解決し、自分たちで振り返って次に活かしていく。
SCRUMはそんなフレームワークだからこそ、うまく使えれば強いチームに成長していけるのかなと思った。
読んでみて
とてもよかった。今の自分に必要だと思える内容だった。
