4月16日（水）に開催された、Scrum Boot Camp The Book 読書会 in 札幌 4/16に参加しました。
完了の定義、状況の見える化、タイムボックスについてのセクションを読み合いました（Scene No. 09,10,11）。
開発者視点、お客様視点の両方で考えることでいろんなことが見えてくるキーワードが多かったです。
デモの良いところ
動くものを早く見せることができる ということは、お客様にも開発者にも目に見えてわかるメリットだと思う。
＜お客様＞
- 実際に触ってみて改善点を早く挙げることができる
- 現物が目の前にあることで欲しいものの方向性がはっきりしてくる
- 修正可能なタイミングで問題点に気がつくことができる
- プロダクトが出来上がっていっていることが目に見える安心感
結果として「欲しいものに近いものができる」可能性が高まる。
＜開発者＞
- お客さんの使い方や機能の目的を、文字や言葉ではなくダイレクトに理解する機会が増える
- 修正が困難ではないタイミングで要望を聞くことができる
- 使ってもらうのを目にすることでモチベーション上がる
結果として「無駄な作り込みをしない」可能性が高まる。
デモで、双方の不安を解消できると思う。
Scrumを実践するのが難しい場合でも、「デモ」というイベントはなるべく取り入れていけたらいいと思う。
（準備は少し大変になるけれど、それ以上に得るものがある）
完了の定義
一つ一つを終わらせて次に進むことが大事、この「終わらせる」の認識を合わせておかないといけない。
ここを曖昧にすると最終局面で痛い目に遭う….（遠い目。
この本では「プロジェクトオーナーの視点」と「開発チームの視点」の両方で “終わった” かどうかを判断する、と書かれている。確かに両方が「完了」とすることで終わったことの信頼性は上がる。
でも、実際の現場で、POは完了（デモでユーザーストーリーを満たす機能が出来上がっていることを確認できた）、だけど、開発チームは完了と言えない（ソースコードがぼろぼろ）場合に、どこまで「未完了なので次イテレーションに持ち越し」できるのだろう。
信頼貯金の量や今後の見通しを含めた説明の仕方によるのだろうけど、その部分は開発チーム側からの説明が難しそうだなあと思った。
タイムボックスは変えない
タイムボックスはメジャーの目盛りと同じなので、常に同じでなければ行けない。
だから「後ちょっとでできそうだからタイムボックスを1日延ばす」ことはあり得ない。
終わらせるまでにどのくらいの時間が必要か、というのとは逆の考え方。
デモと違ってすぐに恩恵が見えないということもあり、理解が難しい部分だと思う…正確には、理解はできているのだけど実践が困難かな。
お客様への説明も、デモと異なり見えるメリットが少ないので誤解が生じないよう気をつけなければいけないところだろう。
また、自分だったら、”タイムボックスは変えない”という大前提は崩さないとしても、いつもより頑張ったら間に合いそうなものがある場合、頑張ってそのイテレーションに入るよう残業でなんとかしてしまうんじゃないかなと思った。
でも常にそのペースでできないよね…という場合、ベロシティを狂わせることになるんだよなあ。
潔く「できませんでした」とすることが懸命なのだろうか。
今回は（自分だったら）実際のところどうなんだろう、うまくいくんだろうか、と思った部分が多かったです。
その他、話し合いのログはこちらになります。
https://github.com/ScrumBootCampTheBook-Sapporo/reading/wiki/2014-04-16
次回は Scene No.12 から。
またよろしくおねがいします。