「スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス」を読んだ¶

2015/12/25

スクラムのキーワードの説明と進め方、各ユースケースに対応する FAQ がまとまっている。重厚な本ではなく、小さくよくまとまった本で読みやすかった。

バックログバックログとよく見たことがあるが、ざっくりと書くと TODO のことだと、やっと意味がわかった。

読んでいて、「スプリントバックログのタイムボックスを厳守するべき」とあって、最初は機能が当初想定していたより大きい場合無理だよな、どうするの？と思った。ただ、これは僕の認識誤りだった。その後の章で次のスプリントに持ち越すか、そもそも取りやめるか、など検討するらしかった。なるほどと。

あと、スクラムは PO 1名スクラムマスター 1名エンジニア 3-8名で構成すると良いらしいが、その場合どうするかと言うことも事例と主に記載されていたので面白かった。分けられる単位で分けるのだ。これは本文中ではスクラム・オブ・スクラムなどと書いてあった。スクラムオブスクラム (外部サイト) では PMBOK/ITIL などでも似たような記載があるらしく、そうなんですねと。

はじめに書いたけど、本文もそこまで量が多くはなく、読みやすかった

このスクラムだが、プロジェクトバックログ (TODO) をいかに消化するかを目的としたフレームワークなんだと読んでいて感じた。5W1H だと What と How を目的としたフレームワークらしい。

最初 What/How が大事と書いてあって、 Why のほうが大事なんじゃないの？と思ったけど、読み進めてプロジェクトバックログを消化するのが大目的かと理解し、腑に落ちた。

読んでいて、属人性の排除、を指向しているかなと思ったんだけど、今読み返すと事例で属人性の排除のためスクラムを導入したとあって、明記されてなかったんだなと。確かに属人性をなるべく排除できれば、チームに参画するメンバーがかわっても開発が進められて経営的にうれしいんだろうなとは思う。

自己組織化が進んだとしたら力量があるメンバーがないメンバーに対して教えると思うけど、その際メンバーによって自分からは学ぼうとしない人がいるとして、わざわざ教えるのかなと思いはした。けど、それも開発よね。