スクラム道フルブーストに参加してきた #scrumdo #nawoto_girls

勉強会 Scrum Agile


(写真：第1ラウンドディスカッション風景の一幕。)

スクラム道では、不定期にスクラム道場というイベントをやっています。

アジャイル開発は、自分の現場で実践してからがスタート地点であり、実際に取り組みはじめると日々、様々な事に悩みます。 
その中で一番悩むのがプラクティスや良く聞くワードを現場で上手く実践し続ける事です。 

スクラム道場では、毎回、プラクティスなどをテーマに自分の現場での工夫や失敗経験などをシェアし、
議論よる深掘りによって上手に実践する事を目指してきました。

この度、祝10回記念という事でバンダイナムコスタジオ様の会場提供により大きな会場での再演イベントをやります!! 

ふだん、なかなか聞けない生々しい話や議論が聞けるチャンスなので、ぜひ奮ってご参加ください。

スクラム関連コミュニティ『スクラム道』は普段は実践者向けの勉強会ですが、昨年に引き続き、この日に『選手・観客参加型イベント』として第2回が開催されたので参加してきました。ちなみに前回はこんな感じ。

『スクラム道』に関する詳細はこちらの公式ページを参照。FaceBookアカウント、TwitterID等もあります。


会場は前回に引き続き-バンダイナムコ未来研究所＠品川シーサイド。建物自体は外装が工事中でした。


開場、受付開始 (18:00 - )

イントロダクション（構成・アンケート・トイレ等について案内）(18:30 - )

開始時間が少々早めだったので、仕事を調整して開場時間に到着。開場時点で既に2〜30人は着席されていました。

ディスカッションテーマ案内、投票 (18:35 - )

  • コンセプト：もっと上手にアジャイル開発をしたい。
  • 不定期に下記のイベントを開催してきました。
    • Scrum Boot Camp(明日から少しでも不安無く実践する)
    • スクラム道場(日々実践する事からより深く探求)
    • ワークショップ大戦(人に伝える事から新しい事を学ぶ)
  • スクラム道場：実験的に見てる前でやってみよう。
    • プラクティス・または類するキーワードについて採り上げて、30分間議論／質疑応答
    • 日々実践する事／すぐに上達しない／背景にあること／本では詳しく学べない。
    • 一番悩むこと：毎日やるべき事が難しい。
    • 探求：悩んだ事、工夫した事などを話す
    • 切磋琢磨する。
    • 本日盛り上がるかどうかは皆さん次第。盛り上げて！

そして今回の『読み手』の投票へ。今回は以下5名の方による再演講演がエントリ。

「良いインセプションデッキとは」

「スプリント計画ミーティング」

「スクラムマスター」

「スプリントバーンダウンチャート虎の巻」

「プロダクトバックログ」


投票については、当初『拍手の大きさ』によって判定を行う予定だったものの、判定アプリの調整不足(拍手が大きすぎて計測しきれなかった)によって厳正なる挙手数による判定で行う事に。

読み手候補が5人居たため、このようなトーナメント方式で勝者を決定していました。

んで、結果はこうなりました。

読み手の発表 (18:45 - )

投票の結果、勝者(読み手)となったのは今給黎隆(@imagire)さんの『プロダクトバックログ』でした！

再演イベントですので、資料(の元となる前回資料)は以下にUPされております。※メモは割愛。

差分的なものについては以下に写真で掲載しておきます。

選手（議論参加者）入場 (19:15 - )


前以て参加を表明していた人、突発的に『出たい！』と申し出た人達が一同前→ステージへ登壇。

･･･とここで、本日選手参加された方々にプレゼントされた『プランニングポーカー』を差し入れして頂いたマイクロソフトさんからのお知らせ(ツイートしようね♪)が！

ディスカッション ラウンド1 (19:20 - ) / 選手（議論参加者）交代 (20:15 - ) / ディスカッション ラウンド２ (20:20 - )

ディスカッションは、今回の読み手となった今給黎さんの『プロダクトバックログ』にちなんだテーマで始まりました。計2ラウンド、休憩を挟みつつの熱い議論。以下メモ。(※議論を負いつつも状況把握に努めていた部分(自分も選手の皆さんも)があるので、若干メモの内容も把握しづらいかも知れませんがその辺はご了承下さい。^^; 各種御指摘などありましたら宜しければご連絡頂けると幸いです)


※文中略語について
PBL･･･プロダクトバックログ
PO･･･プロダクトオーナー
  • Q：「パーキンソンの法則」（バッファを積んで、それを食い潰す）を、「ストーリーポイント」で防ぐ事はできるのか？
    • 一人でやるとパーキンソンの法則は効いてしまう。チームでなら（同じ意識なら）しょうがない？致し方無い？
    • でも一人でやるよりかは間違いなく少なくなる。
    • 振り返り、改善などが出来ているかが大事かも。
  • Q：PBLの見積もりの話：PBLは開発者の意志とPO、ステークホルダーの認識を合わせることが目的。開発者は見積もりに余裕を持ちがち？どういう数字が欲しい？
    • 単一の数値、危なくない所の数値。
    • なるべく正しく、状況を知ることが出来る数値
    • 両方出してもらって見てみる？
    • 過大に見積もっちゃう？
      • ストーリーポイントを使うと、その問題は割と解決しやすい。
      • ストーリーポイントは個人個人のスキルから切り離されている。
      • 自然と正確に見積もった方が得、という力学が働くのでは。
    • アジャイル、スクラムは『チーム』でやる事が重要。なるべく個人によらないように。
    • 1回のスプリントでは見積もり違いもあるが、何回も繰り返せば改善点が見えてくる。
    • 個人でやるのではなく、チームでやる。目標をシェアする。段々精度が上がってくる。
    • まとめ：パーキンソンの法則をどうやって防げるのか？
      • チームの問題として取り組む
      • ふりかえり毎にベロシティを計測し、改善する
  • PBLでストーリーを見積もっている。基準のストーリーを出しています(※質問では2ポイント・5ポイントという数字を例に出した)。スプリント見積もりの基準は変えるべきではないと思うが、一番最初に2と5だと思ってたのが異なってしまった(2と5が、当初基準になりえないようなものに後程かわっていた)場合、どうするか？
    • 感覚的に合意が得られていれば、どの2，どの5でもあまりこだわらなくても良いんでは？
    • 何で基準について、変わって行くことにこだわりを持ったか
    • ベロシティを計測している時に、スプリントの基準となってるものが違ってしまうと比較が出来なくなるのでは？
    • チームの成長をベロシティから観察する場合、推移しやすいのではないか？
      • →基準（に対してポイント）が変わるのはどういう時か？
        • 例えば・・・スプリントが終わって、前のスプリントでの2と5
        • 実際にやってみたらもっと難しかったとか。他との整合性が取れなくなる？

        • 2と5だったんだけど、後程そういった相対的な形にならなかった場合、どうするか？
          • 他のストーリーに変えれば良いんじゃないか？
          • 2点で見積もる事の利点：大きいモノが何倍か分からなくなる。どっちもデカイ。
          • ポイントが合ってない：もう一回見積もり直しても、そのスプリントくらいしか影響を受けないのでは。
          • 見積もりポイントがフィボナッチであることの意味を考えよう。
    • 基準：ある程度合った方が、チームとしても心強いのではないか？
    • ベロシティを人事評価に使う？→使うべきではない。でもチームの状態を表す、数値的なものがベロシティではないか？
    • ベロシティが上がっている＝良い方向に行っている、と思うか？
      • 個人的にはyes。
      • 意図：何スプリントかやって、傾向を見るべきものではないのか。
      • ベロシティが増えて加速している：：：逆に危険なのでは？
        • 初期的には良いかも、でもそれで良いのか？という意見も
          • チームの安定が第一
          • リスクを取って上げていく、というチームがあってもいい。
  • Q.今給黎さんの発表の中で、慣れないチームについて『良いもの』を提供しているとあった。どういう基準で『良いもの』を判断しているのか？
    • チームに似たシチュエーションのモノを探す。
    • 完了条件の例とかは？
  • Q.PBLを作る際に、技術的に未体験、トライしたい要求がある場合、ある程度スパイクをするのは分かるが、幾つか増えてきた場合どうするか？優先順位を付けるのか、絞ってガチッと対応するのか？その辺の見積もり度合など。
    • 基本的にリスクのあるモノを早く。
    • 価値とのバランス。
    • 1人分の量で抑える
    • リスクの高い項目は、それをリストアップしておいて締め切りを設ける。目処を立てて取り組む、トラックする。
    • ちょっとならトライ項目、でも3つあった場合は？
      • そこはPBI項目の中に混ぜておく方が良いのでは？
  • (お悩み).私今困ってるんです...結構大きな規模の初期開発をするためにPBLを作っている。粗い粒度で洗い出したが、沢山出て来てしまった。決済するために見積もりだしてるのだが生産的では無い状態で、辛い...初期の見積もりについて、どのように行っているのか？
    • 1項目1点でやっている。
    • プランニングポーカーを使っているのは何故？
      • 設計作業を行っているのと同様の効果、認識の違いはあるので、なるべく正確な見積もりをしたいので。
    • PBLの項目が膨大に・・・全部でお幾ら？を知りたい。
      • 作りたいモノが凄いデカイ、というお話。
      • 一発で出すのは無理。数回に分けて見積もる。
        • 全部でどれ位なん？これを見積もる場合のコツ。
      • 出した後、削る作業はやる。まずはトータルを知りたい。
        • 多いって分かった時点で辞めた方が・・・w
        • 結局相対値なので、ピックアップ、サンプリングして倍掛けすれば？
    • プランニングポーカー：ポイントに行かず、カード一覧として洗い出す。
      • そして、カードを順位付けでソートしちゃう。計算しなくて済む。
      • 「実は私も一ヶ月前に同じ悩みを...」
        • 長い期間と多い項目
          • ざっくりスプリントを切って、ゴールを設ける
          • 今から1時間掛けて、ざっくり見積もりをしよう
          • タイムボックスを設けてざっくり区切っちゃう
          • 最初の数スプリントのみ対処（今給黎さんの資料にあったように）
          • 優先度は決まってない、出した時に付けている
          • 優先度が低いモノを雑にしてるけど、それでも辛い
          • 環境・基盤的な部分はある程度決まっている。技術的な部分については見積もりしやすい形。
            • チームとしてやるのは初めて。短いスプリントを幾つかは経験している。
            • 明日から1つ、小さい機能をリリースして、そこから見積もり始めると良いかも知れない。


  • (お悩み).POがスクラム初めてです･･･という時、POがPBLを作るのは難しい。んでチームで作って上げた。けどPOには分かりづらかったみたい。(POが作ったものだとストーリーが大きくなり過ぎちゃたようです…)。POがスクラム初心者の場合のコツや方法等があればご意見聞かせてください。
    • 同じような境遇があった。一緒にPBLを作った。
    • 理解出来なかった理由、思い当たる節とかはあったのか？
      • (チームが）実装寄りに記述してしまった。量的に沢山、細かく出してしまった。
        • チームがストーリーを書いてしまった、のが問題なのでは？
        • チーム側が分割スキル足りなかった、と言う面もあるのでは。
        • 大きなストーリーが来て困った点：価値のあるストーリーにしづらかった。
        • 全員そんなに慣れて無かった・・・最初はぶれたりするけど、回して見て、後から改善していくので良いのでは？
          • 最初から一気にやろうとしても無理。
    • 開発側・ビジネス側が同じ言葉で話せるように。
      • 元のタスク出しはムダでは無いかも。マッピングなり整理をして理解しやすくすれば...
      • 喋る言葉を変えるだけで、割とスムーズに行くのではないか。
      • 計画ミーティングの時点で上手く出来てなかったのではないか。
  • Q.今給黎さんの資料にあった『自転車操業』とは逆の話しで、すごい勢いでPBLが積み上げられていく。やる／やらないの切り分けに、『価値』だけでは判断出来ない状況。全部見積もっちゃいたい。そんな時どうすれば良いのか？
    • 判断基準：ROIが高いかどうか。
    • S/M/Lで見積もっちゃってしまえば、割に合う合わないが分かるのでは。
    • PO側が価値を見積もってしまう方が良いのでは。
  • Q.POの付けた価値がおかしい。チームに『？』が付くような状況、これってホントに正しい優先順位なの？
    • その責任をチームが取る事は無いと思う。
    • そのことをPOに伝えるべきでは。言った後POが判断すればそれはPOの責任。
    • POも神じゃない。
    • 話せば良いじゃない？
    • PO＝一人称と捉えがち。POチーム、という形で集めて最終決定を下すという方法も。
    • POのさきにお客さんは居るのか、居ないのか？
    • 最終的なゴールはあるのか？
    • 『ビジネス価値』をポーカーで見積もる、喋り合う。
  • Q.チームコミュニケーションを改善する際のコツなどあれば。
    • 飲み会。
    • バックログ改善ミーティング
    • POを1箇所に集める。これが一番てっとり早い。
    • 夜時間取れない場合、昼一緒に食べる。
  • Q.PBLのチーム向けの表現／列、お客向けの表現／列あると思うが、同じものを使ってるか？(※自分は都度別々のものを作っています)
    • バックログを元に通訳するような人を置いている。
    • お客さんがPBLを見たい理由は？何故見せてるのか？
      • →PBLを見てもお客さんが知りたい情報がわからない場合もある。
      • →現状からストーリーを説明する方が
    • お客さんにPBLを見せ続けて馴染ませる方が良いのでは。
      • →次こうなりますよ、で口頭説明してしまえば。
    • 一緒にして説明を付ける方式にしちゃえば？
    • PBL＝外に出すモノ。
    • PBL→SBLなら、お客さんようにリバースするのはおかしい？
    • PBLを使って報告している・・・のがおかしい？
      • それ相応の資料を作るのが自然。

…とここでTIME UP!熱い議論はあっという間に時間を迎えてしまいました。

クロージング、解散 (20:45 - )

まずは、開催会場を利用させて頂いたバンダイナムコゲーム様に感謝！ありがとうございました。

そして関連イベントの宣伝などが続きます。興味深いイベントが続々と待ち構えているようです。

2012/05/26 Scrum Boot Camp 名古屋 開催！


こちらの会場については、まだ十分に空きがあるようです。興味のある方は是非とも参加エントリしてみてはいかがでしょうか。

2012/06/16 Scrum Boot Camp 東京＆大阪 同時多発で開催！


こちらは東京・大阪共に既に定員達成となってしまっております！(2012/05/12現在) 参加したいという方はキャンセル待ち等状況を要ウォッチですね。

7月に何かやりたい…

  • nawotoさん談。Scrum Boot Camp Premiumに関しても言及されてました。

そして最後にスクラム道について再告知し、拍手の元に終了。

会場ご提供頂いたバンダイナムコゲーム様、スクラム道スタッフの皆様、そして選手及び観客として参加された皆様。今回もエキサイティングな場をありがとうございました！

おまけ：#nawoto_girls

イベント途中で和服女性の方を目撃された方も多いと思いますが、こちらの御方、今回仙台からお越し頂いたMako Karube(TwitterID:@cousacu)さんでした。『レッツゴーデベロッパー』に参加されていたそうで、今回の和服はこういう経緯のようでした^^; (※#nawoto_girls関係者の方々に了承を得ましたので、ブログでも言及してみました)

写真もナイスビアの人に『UP!』と言われたのでこちらにUPしてみます。nawoto_girlsによる2ショット＋3ショット(？)写真です。

#nawoto_girls については現在も絶賛団員募集中だそうです。興味のある方は名乗りを上げてみてはいかがでしょうか。


その他関連：