私、スクラムを分かってませんでした〜Jim Coplien氏のScrum Master 研修を受けて 1〜

社内で、Jim Coplien氏による、2日間のスクラムマスターの研修を受けさせてもらう機会をいただきました。先週のJavaOneに続いて、会社からすごいお金と時間を出してもらってるなぁ…自分。

なかなかショッキングな内容も多く、整理するのに時間がかかりましたが、まとめと、今後のアクションを書いていきたいと思います。

用語：PBIとSBI

初めに今回覚えた用語を二つ。PBIはProduct Backlog Item, SBIはSprint Backlog Itemの略です。

概念的にはすでに馴染みのあるものですが、PBI、SBIという呼称は今回始めて知りました。

私は「スクラム」を理解していなかった

さて、本題です。研修の一番冒頭で、Jimから、スクラムのたった一つの約束が紹介されました。

"It promises only that the team will work on the most important things first"「約束は一つだけ。チームが最も重要な作業から手をつけること」

そんなの知ってるよ！とこの時は思っていたのですが、やがて、この言葉の意味をまるで理解していなかったことに気づきました。

チームは「群がる」

仮にスプリントチームのメンバー数が4人で、あるスプリントでPBI#1〜PBI#3の3つのPBIがあり、それぞれ、複数のSBIに分割されているとします。このとき、スプリント内でどのような順番で進めて行くのが良いのでしょうか。答えは

全員でPBI#1をやる

です。

PBI#1にみんなで「群がる」んです。

これを聞いた時に、これまでスクラムで何と無く腑に落ちなかった点が一気にクリアになってきました。

なぜ「スクラム」というのか。

なぜ個人のベロシティには意味がなく「チームのベロシティ」が大事なのか。

なぜ時間では見積もらずに「ストーリーポイントで見積もる」のか。

なぜ誰かがタスクをアサインするのではなく、「Pull型」でおこなうのか。

なぜ「特定のロールはない」のか。

なぜ「小さな単位でリリース」が可能なのか。

それは、チーム全員が、一つ一つのPBIに対してスクラムを組み、開発・テストが終わった、リリース可能な状態の小さなプロダクトを順に作っていくからなんですね。

なお、PBIのサイズによっては、「PBI#1は4人でやるには小さすぎるから、PBI#1は1人でやって、PBI#2を3人で」ということはあるそうです。

だから受け入れテストの自動化が重要なんだ

これは、Copeの研修では言及されていなかったのですが、上記のことを踏まえて、受け入れテストの自動化（または結合テストの自動化。自分の中では同じ意味で使ってます）が重要であると感じました。

マニュアルのテストは、コーディング終了後にしか行えません。ですので、プログラマが実装を終えた後、時間差でテストが始まり、テスト中、プログラマはまた別のPBIの実装（もしくは別のPBIのテスト）へ移ることになります。

ここでもしバグが出ると、すでに他のPBIに移ってるプログラマが戻ってきて直す（か、他の人が直す）まで、テストが進められないのでそのPBI自体が止まってしまうんですね。

ですが、もし自動テストだったらどうでしょうか。あるPBIの、実装の開始と同時にテストの作成を始めることができ、実装終了後、即座にテストを実施することができます。そこでバグがあれば、そのまま実装していたプログラマが修正に入ることができるわけです。一方のテスター（ここではテストを書いた人）は、すでにテストを書き終わってますから、修正を手伝うなり、次のPBIにかかるなりすることが可能です。

実際には、そこまでタイミング良く実装とテストが同時に終わることはなかなかないかもしれませんが、マニュアルテストに比べて、かなり効率良く進められることができ、一つ一つのPBIに「群がった」開発ができるようになるのだと思います。

そして、修正のテストが完了し、CIも完了したら、自動でみんなが見られる環境へ（もちろん自動で）デプロイ。
これで、QAや、POへのデモ用の環境が整います。

※続きます