4/16に参加しました。開発者視点、お客様視点の両方で考えることでいろんなことが見えてくるキーワードが多かったです。いうことは、お客様にも開発者にも目に見えてわかるメリットだと思う。結果として「欲しいものに近いものができる」可能性が高まる。<開発者>お客さんの使い方や機能の目的を、文字や言葉ではなくダイレクトに理解する機会が増える修正が困難ではないタイミングで要望を聞くことができる使ってもらうのを目にすることでモチベーション上がる結果として「無駄な作り込みをしない」可能性が高まる。デモで、双方の不安を解消できると思う。Scrumを実践するのが難しい場合でも、「デモ」というイベントはなるべく取り入れていけたらいいと思う。一つ一つを終わらせて次に進むことが大事、この「終わらせる」の認識を合わせておかないといけない。ここを曖昧にすると最終局面で痛い目に遭う....(遠い目。判断する、と書かれている。確かに両方が「完了」とすることで終わったことの信頼性は上がる。実際の現場で、POは完了(デモでユーザーストーリーを満たす機能が出来上がっていることを確認できた)、だけど、開発チームは完了と言えない(ソースコードがぼろぼろ)場合に、どこまで「未完了なので次イテレーションに持ち越し」できるのだろう。信頼貯金の量や今後の見通しを含めた説明の仕方によるのだろうけど、その部分は開発チーム側からの説明が難しそうだなあと思った。タイムボックスは変えないタイムボックスはメジャーの目盛りと同じなので、常に同じでなければ行けない。「後ちょっとでできそうだからタイムボックスを1日延ばす」ことはあり得ない。終わらせるまでにどのくらいの時間が必要か、というのとは逆の考え方。デモと違ってすぐに恩恵が見えないということもあり、理解が難しい部分だと思う...正確には、理解はできているのだけど実践が困難かな。お客様への説明も、デモと異なり見えるメリットが少ないので誤解が生じないよう気をつけなければいけないところだろう。自分だったら、”タイムボックスは変えない”という大前提は崩さないとしても、いつもより頑張ったら間に合いそうなものがある場合、頑張ってそのイテレーションに入るよう残業でなんとかしてしまうんじゃないかなと思った。常にそのペースでできないよね...という場合、ベロシティを狂わせることになるんだよなあ。潔く「できませんでした」とすることが懸命なのだろうか。今回は(自分だったら)実際のところどうなんだろう、うまくいくんだろうか、と思った部分が多かったです。その他、話し合いのログはこちらになります。