ちょっと日が空いてしまったのですが、3月19日（水）に開催された、Scrum Boot Camp The Book 読書会 in 札幌 5に参加しました。
今回はプロジェクト計画・スプリント計画ミーティング・デイリースクラム（Scene No. 06,07,08）。
特に前半のプロジェクト計画・スプリント計画ミーティングは議論が盛り上がりました。
スプリントとベロシティの話
個人的に、Scrumをはじめようと思った時一番つまづく部分じゃないかなあと思っています。
つまづくというか、現状の考え方を一番シフトチェンジしなければ歪みが生じてしまうところ。
ベロシティは”測る”物であり、決めるものではない
これに尽きるのだけど、これが一番難しい。
できる量からどこまで出来るかを導き出す、のではなく、できるであろう量の予測をして、それに近づけるように作業をする、となってしまう。
間に合わなくなったら困るから無駄にバッファを詰んだり、予測した数値に近づけるためにデスマになったり、いいことは何もないのだけど、現実として、そうせざるを得ない場面というのは多い。
- 受注前に工数、金額をださないといけない、そしてそれは変えられない
- 最初に要員計画をして、人員を確保しなければいけない
- チームがまだ存在すらしない段階で予測をして提出しなければいけない
- 一旦出した予測は変えられない
このあたりのことを考えると、スクラム開発は内部から推し進めるのに限界があり、まるっとプロセスを変えないといけないよなあと思う。お客さんの理解と同意も含めて。
なので
「こういうことをやりたいのだけど、どうするのがいいかな。うまいやり方を一緒に考えてほしい」
というタイプのプロジェクトだとスクラムを適用しやすく、一緒にものをつくり上げる事ができる気がする。
「これをつくって欲しいのだけど、いつまでに出来る？」
というタイプのプロジェクトだと「計画は変わります」という説明が難しくなる気がする。
“これを作って欲しい”という部分も、突き詰めると”本当にそれが必要なのか？” “もっと他に良い方法があるのでは？” となる余地があるはずなのだけど、そうなるまでには信頼貯金をかなり積み上げないといけない。
これがほしい、と作るものが（上司の命令であれ慣例であれなんであれ）明確になっている場合に「いやいや他のやり方があるよ」といきなりいってもうまくいかないと思うのです。
- 予想や推測は外れる可能性がある
- 実際に終わらせた結果だけが信用できる数値
- 計画を守るためにベロシティをあげようとしてはいけない
- 間違ったままの計画で進んでいけば、いつか大きく計画を見なおさないといけない
- 計画は見なおして変えていくもの
この辺りの言葉が、今まで関わったプロジェクトを思い返すに耳が痛く、一番大きな壁を感じるところ。
その他、話し合いのログはこちらになります。
https://github.com/ScrumBootCampTheBook-Sapporo/reading/wiki/2014-03-19
次回はDoneの定義から。
またよろしくおねがいします。