2011/05/28

すくすくスクラム第23回にいってきた #suc3rum

皆様おつかれさまでした。

海江田@Qooh0さん、講師お疲れ様です。スタッフの皆様、すばらしい勉強会をありがとうございます、参加者のみなさまに出会えて、とても有意義な時間をすごさせていただきました。

今回のすくすくスクラムは、初学者向けってことで、スクラムって何?ってところから、お話していただけました。
そんなこともあって、「今回初めて!」って方がいっぱいいらっしゃって、スクラムってやっぱり注目されてるなぁと思ったり。

後日談ツイートで見かけたところによると、1/3ぐらいゲーム業界からいらっしゃっていたようで、懇親会でも話を聞けたんですが、ゲーム開発にぴたっとはまる瞬間があるみたい。(実際は、いろんなプロセスを混合する感じのほうが、上手くいくかもしれないとか、いろいろと意見はあるようです)

勉強会の内容的には、いままで教えてもらったことの再認識って感じだったけど、地味に勘違いしてるとことか、分かってなかったところが見えて、とってもうれしかった。そして、紙飛行機飛ばしは、意見をまとめて、「これでいこう!」っていうFixが、ものすごい難しかった気がする。

ロール

  • プロダクトオーナー
    • リリースとかの権限を持ってる
    • 製品の行く末を決める
  • チーム
    • チームは、長いスパンで成長させていく
  • スクラムマスター
    • サーバントリーダーシップ(よいしょ係)

昔会社で、一番難しい命令は「うまくやっといて」だとか話をしたのを思い出したけど、スクラムマスターは、まさしく「うまくやる人」なんだなと思った。

キックオフミーティング

  • プロダクトバックログ(PBI:プロダクトバックログアイテム)
    • 優先度、価値を決める
    • 見積もる
      • Tシャツのサイズ見積もり(SML)
      • プランニングポーカー
    • 誰のために、何が出来たらいいの?を決める
    • 顧客が見えないんですけど。
      • ペルソナ
      • ログ
      • さまざまな情報を収集した結果を持って、ある程度の値を決めると、話がしやすいのではないか?(「値」の重要性?

懇親会でも話しにあがったけど、優先度がつくことで、必須機能やオプション機能、実現性とかのからみを上手く紐解ける感じになるのかなって思った。

このあたり、実体験から話しを聞けたのは、とても良かった。

余談だけど、プロダクトバックログの書き方の話で「ユーザーは」じゃなくて「僕は」だったり、それらしい口調のほうがしっくりくるって話をゲーム関連の方がおっしゃってて、おもしろいなぁと思ったり。

あと、勉強会後に、記念と義援金ってことで、すくすくプランニングポーカーを買ってきたw

NEC_1759

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

    • スプリントで何をする(タスク)
      • タスク粒度
        • 1~16 時間派
        • 1~8 時間派
    • 完了の定義の重要性
      • 大体の目安で、チームとプロダクトオーナーが完了に同意できれば完了
      • リリース可能(昨日が使える状態=プロダクトバックログの完了って感じ?)
      • C.I.とかと連携させてリリースできるようなものを作っていく

スプリントで何するかってのを決めるのが、コレですよね。

完了の定義を決める っていっても、実は「定義」のイメージが沸きません。
完了するってことは開発であれば、「xxxのように動くこと」とか、当たり前のことを定義とするんだろうか。バグであれば、直ってること?再現しないこと?何を持って再現しないとする?
実際、そこらへんを実例で見てみたい気がするなと思った。

スプリントが始まったら

  • デイリースクラム(毎日やろう、朝会)
    • 昨日やったこと
    • 今日やること
    • 困ってること
    • 障害リストのUpodate
    • バーンダウンチャート
      • 必ずやっとけ、マジで。やれ

朝会の3項目は、最近一人朝回が開催されてます。ちなみに、やった日とやらない日では、仕事の進み具合が違います。一人でもやっとく価値がある。

んで、僕、バーンダウンチャートがどーも苦手で、なんかアレを書けといわれてかけないんですけど、やらんでいいですか?って先生に聞いたら、
ダメですd(´∀`)bって言われた。

バーンダウンチャートの重要性って、タスクの消化具合からプロジェクトの健康状態、お客さんとの交渉材料と、多岐にわたってあるんで、コレがあるのと無いのではずいぶん違う模様。

都合上、ノートとかにこそっと作っておくぐらいにすべきか、もしくは、Tracでバーンダウンを吐き出せるようにするか。どっちにしても準備がいるなぁ

スプリントが終わったら

  • スプリントレビュー
    • Demo or Die
  • ふりかえり(レトロスペクティブ)
    • チームをよりよくするための改善
    • スプリントミーティングから、スプリントレビューまで

この2つは、参加者が違うんですね。

スプリントレビューのほうは、そのスプリントの成果を発表する場で、こんなもんができましたよ!ってやつ。

で、ふりかえりは、チームでやる。良かったところとか悪かったところを確認して、改善していくのが目的。

懇親会にて、「ふりかえりやらないと、改善するタイミングないよ」とのこと。
そりゃそうですよねぇ・・・

ちなみに、ふりかえりは学級会みたいでプライドが許さない!っていう感じでとっつきづらいという話をきいて、あーなるほどwと思いつつ、でも、そこのチームでは、繰り返すうちに、それが普通になっていったそうで。やっぱり継続は大切だし、もう一個、その方法が身にしみていく慣れがいるのかなとか。

全然関係ないけど、Demo or Die はいつも、House of the Dead のあの声で再生されます。(バイオハザードの声でも良いですよ)

紙飛行機飛ばし(ワークショップ)

紙飛行機とばしまくってきたw

  • スプリントミーティング:2分
  • スプリント:3分
  • 振り返り:1分

成功品の数は、10 → 21 → 20 だったかな。

見積もりは 無し → 15 → 25 だったかな。

第一スプリント(計画)
  • 飛行機を折るのは、ペアプロならぬペア折り紙w
  • 折る人4人 飛ばす人1人 飛行機の先を丸める1人
    飛行機輸送1人
第一スプリント(ふりかえり)
  • 我がチームは、いっぱい飛んだ!
  • 輸送と先を丸めるロスが意外と
  • 飛行機の品質がバラバラで飛ぶのと飛ばないのがあるよ
  • ペア折り紙より、ライン作業のほうがいいのでは?
    (工程を分離することで、作るものが安定する?)
第二スプリント(計画)
  • とりあえず、折る人いっぱいにしよう
  • 7手かかる飛行機をおるので、7人必要
  • 丸める係りは、最後の一手を折った人
  • 飛ばす係、輸送係は、同様で。
第二スプリント(ふりかえり)
  • すごい、飛ばした数が倍になったぞ!
  • 終盤、仕掛け品がたまってきててもったいなかった
  • タイムキーパー的な何かが居るのでは?
第三スプリント(計画)
  • 最後は、作るだけ作って数人で飛ばしにいこう
  • 最後30秒でまとめて投げに行こう
  • タイムキーパーは、iPhoneの時計を机に。
第三スプリント(ふりかえり)
  • 数増えなかったねぇ。
  • あせって飛ばしきれなかったのがあった
  • 最後30秒じゃちょっと短かったかな

と、試行錯誤しながらも、次にチャレンジすることが、どんどん出てきた。

会社でKPTとかやっても、大して出ないんだけど、違いは何だw

というわけで、本日のすくすくスクラム初潜入は完了しました。

実際、めっちゃたのしかった。会場も近場だったのでさらっと参加できたけど、遠くなるとちょっと難しいんだよなぁ。でも楽しかったし次も出たいし・・・

まとめらしいまとめはしないです、適度に混ぜ込んであるのでw

では、皆様おつかれさまでした。

2 件のコメント:

  1. おお、まとめありがとうございます♪
    KPT とか、最初はハードルが高いかもです。
    私も、最初のKPT とかは無理してだしてもらっていましたが、正直微妙。
    よかったことはなんですか?だけとか、
    問題って何かあったっけ?だけでもいいと思っています。

    返信削除
  2. コメントありがとうございます!

    僕も、今回の紙飛行機とかの振り返りみたいに言いたいことを言ってしまうのが最初はいいのかなと思いました。
    意見を出すことに「慣れる」っていうのが大事かなと感じましたw
    ルールは少ないほうが、入りやすいんですね

    返信削除