６月２４日のスクラム道バーストに参加してきました。
初めて参加させていただいたので感想を書いておく。
意外と多くの会社がスクラムを組んでいて驚いた。
議論自体も活発に行われており現場の生の声が聞けて非常に勉強になった。
２週間から１ヶ月でスプリントを繰り返していくというスピード感を実現させるために重要なのは、プロダクトオーナーとスクラムマスタ、チームでゴールの認識をあわせるというフェーズだと個人的には解釈した。ゴールに向けて作業を分解していくためにも、やはりゴールの認識をあわせることは重要だと思う。
また、見積もりをチーム全員で行い、見積もりが合わない場合にその原因について話し合うことで、チームの認識の違いを埋めていくというのは非常にいいなと感じた。
実際に会社の中で作業を行う際にはスケジュールは上から降りてきているので、その根拠とかを説明された覚えがあまりない。そういった見積もりの根拠などを全体で共有していくことで、ベテランから若手への見積もり技術などが伝わっていくんではないかなと感じた。（KKDで見積もりが許されるのは個人作業までだよねー）
今回は作業計画の話を聞いたので、今度は作業後の「振り返り」についての話を聞いてみたいなと思った。
できれば、７月に行われるScrum Boot Campにも参加してみたい！
以下まとめ
開催日時：2011年6月24日（金）18：30〜20：50
会場 ：バンダイナムコ未来研究所
主催 ：スクラム道(協賛:株式会社バンダイナムコゲームス)
プログラム
１．テーマ決め、選手入場
２．読み手の発表
３．ディスカッション ラウンド1
４．ディスカッション ラウンド2
５．クロージング
内容
テーマ決定
・以下からディスカッションテーマを会場の多数決で決定。
・「ふりかえり」KPT is harmful
・「スプリントバーンダウン」スプリントバーンダウン虎の巻
・「スプリント計画ミーティング」
・「スクラムマスター」
「スプリント計画ミーティング」読み手発表
・スプリント計画ミーティングはスプリントの目標と機能を決める会議
・スプリント計画ミーティングには「プロダクトオーナー」、「スクラムマスター」、「チーム」が参加
・プロダクトオーナー：ゴールと目的を説明する
・スクラムマスター ：会議を設定する
・チーム ：チームのキャパシティ計算、タスク詳細化、受諾を行う
・スプリント計画ミーティングは2回に分けて開催する
１．オーナーの要求を理解することに焦点を置く会議（Whatの洗い出し）
２．どのように要求を実現するかに焦点を置く会議（Howの洗い出し）
・前回の開発状況と成果をインプットとして、目的とゴール、スケジュールを決める
(前回開発効率などからチームの作業を見積もり、無理なスケジュールは組まない)
・ミーティングに時間制限を設ける
（開発期間が1ヶ月の場合、1回のミーティングを4時間が目安）
・見積もりにはプランニングポーカーを用いる
（カードを使った全員参加型の作業時間見積もり）
・見積もりが合わなければチームで話し合う
（合うまで話し合わなくてもよく、話し合うことが重要）
ディスカッション ラウンド1
・ミーティングで誰も喋らない or 1人が喋りっぱなし
→ 放っておくと誰かが喋りだす
→ 喋りすぎの人が気付いて黙る
・会議がけんか腰（ex.俺の見積もりに文句あるのか！）
→ 年功序列や上下関係が残った職場だと起きやすい
→ 放っておくとなんとかなる
・ゴールが曖昧で作業が見積もれない
→ プロダクトオーナーに「このPJが終わるとどうなる？」を説明してもらう
→ ゴールが曖昧なまま2回目の会議をしてはいけない
・プロダクトオーナーは明確か
→ プロダクトオーナーが本当のプロダクトオーナーでない場合がある
（ex.プロダクトオーナーとその上司の認識が違ってる）
→ 本当のオーナーが誰かは最初話し合う
・メンバ構成によっては計画を立てない方がよい場合があるのでは
→ 短期スプリントに限っては計画を立てない方が早く終わることがあった
→ 早く終わるかもしれないが計画を立てる立てないでチームの安心感が違う
（相手の作業進捗が見えているか見えていないかで安心感が違う）
・計画を立てたくないという人がいる
→ 理由は作業の分解がめんどくさい
→ 計画を立てないとチーム作業が不透明で進捗管理が難しいいうことを理解してもらう
・タスクを分解していると話が膨らむことがある
→ 細分化の中で漏れていた項目が見つかり話が膨らむケースがある
→ ゴールが膨らんでいくケースもある
→ その膨らんだ部分のゴールが本当に必要か聞く
・タスクの最小粒度は
→ 30分〜2時間程度が多数
→ 1日単位という人もちらほら
ディスカッション ラウンド2
・Doneの定義の変更
→ やる派 ：必要に応じてその都度 or 振り返りで行う
→ やらない派：最初の計画と違うことをはっきりさせた方がよい
→ タスクが終わらないから変更するのはおかしい
・プロダクトオーナーがいない
→ 社内システム開発を放り投げられてオーナーがいない
→ スクラムマスターかチームの中の誰かがオーナーになれば？
→ ダメなシステムができるケースが多い
→ 作業分野ごとにプロダクトオーナーを分けて実施しているが問題なく進んでいる
（あくまで１選手の意見なのでそれが最適かは不明）
・スクラムを社内でどうやってはじめた
→ 社長を説得してセミナー参加や資格取得から始めたら社長が乗り気になった
→ 自チームではじめたら残業がなくなったことをきっかけに、周りが真似を始めた
→ ゲリラ的に内部でスクラムを実施して、上層部に報告するときはウォーターフォールで説明
(ex.報告の際にスクラムの用語は使わない、お客さんには定期的に『試作品』を使ってもらう)
・チームに新入社員が来るんだけどどうすれば？
案１．上位のチームメンバとペアにする
案２．新入社員用の見積もりと作業を与える
案３．別作業をさせる
クロージング
・7月にScrum Boot Camp開催
資料
スプリント計画ミーティング
http://www.slideshare.net/MihoNagase/ss-6492194#
