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

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

2011/05/10

モテる組込み女子力を磨くための4つの心得

こんにちは、組込みシステムを作っているriskです。私は学歴も知識もありませんしカスプログラマですが、組込みに関してはプロフェッショナル。今回は、モテる組込み女子力を磨くための4つの心得を皆さんにお教えしたいと思います。

 

1. あえて2~3世代前のOSを使っておく

あえて2~3世代前の組込みOSを使っておきましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくOSの性能について悩んでみましょう。そして「あ~ん! このOS本当にマジでチョー使いづらいんですけどぉぉお~!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「OSとか詳しくなくてぇ~! ずっとコレ使ってるんですけどぉ~! リソースっていってもタスク管理ぐらいしかしてくれないし、例外起こったらそこでシステム止まっちゃうし、使いにくいんですぅ~! ぷんぷくり~ん(怒)」と言いましょう。だいたいの男は新しいOSを使いたがる習性があるので、古かったとしても1世代前のOSを使っているはずです。

そこで男が「新しいOSにしないの?」と言ってくるはず(言ってこない空気が読めない男はその時点でガン無視OK)。そう言われたらあなたは「なんかなんかぁ~! 最近iOSが人気なんでしょー!? あれってどうなんですかぁ? 新しいの使いたいんですけどわかんなぁぁああい!! 私かわいそーなコ★」と返します。すると男は「iPhoneとかでしか使えないでしょ? 本当に良くわからないみたいだね。どんなOSが使いたいの?」という話になって、次の休みの日にふたりでiTRONのポートマッピングができるというわけです。あなたの組み込み女子力が高ければ、男が自作OSを作ってくれるかも!?

 

2. LCDに><を表示するとモテる

「キャー!」とか「悲しい!」などを表現する「><」をLCDに表示すると、組込み男性ユーザーは「なんかこの子カワイイなぁ」や「支えてあげたいかも」と思ってくれます。LCD上では現実世界よりも簡素化された8x16のアスキー文字列でイメージが増幅されて相手に伝わるので 「><」 を多用することによって、男性はあなたを可憐で女の子らしいと勘違いしてくれるのです。そういうキャラクター(文字列ではない)にするとほぼ絶対に同性に嫌われますが気にしないようにしましょう。

 

3. とりあえず男には「えー! なにそれ!?  知りたい知りたーい♪」と言っておく

飲み会などで男が女性に話すことといえばCPU占有時間やリソース削減の話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ~?」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女ダメだな」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー! なにそれ!?  知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。

いろいろと話を聞いたあと、「CPU占有時間は、基本的に常に動き続けるスレッドを作ってることがミスであって、割り込みなどをつかったリアルタイム性重視のシステムにすべきなんですね。メモリ使用量の削減も、もともと確保されるスレッドのスタックサイズや、不必要なグローバル変数の削除、共有リソースをシングルトンにすることで単一プロセス内の無駄なメモリ確保をしないようにとか、覚えたぞぉ! メモメモ!」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「00110010110101011011010101010101! 10101010101010111101111111111111!」と言って、「どうしたの?」と男に言わせるのもアリ。そこで「私の物理メモリに記録しているのでありますっ☆」と言えば組込み女子力アップ! そこでまた男は「この子まじでハードウェアかも!?」と思ってくれます。私は学歴も知識もありませんしカスプログラマですが、こういうテクニックを使えば知識がない私のようなヘタレプログラマのほうがモテたりするのです。男は優越感に浸りたいですからね。

4. 新規ハードウェアではレジスタをいじれない女をアピールせよ

男と新規ハードウェアの検証作業に入ったら、真っ先にデータシートのなどのレジスタマップを探し出して「あーん! 私レジスタたたけないんですよねぇ~(悲)」と言いましょう。するとほぼ100パーセント「どうして?アドレスとポインタ分からないの?」と聞かれるので、「嫌いじゃないし叩きたいけど、叩けないんですっ><」と返答しましょう。ここでまた100パーセント「嫌いじゃないのにどうして叩けないの?」と聞かれるので、うつむいて3~5msecほど間をおいてからボソッとこう言います。「……だって、……だって、レジスタ叩いたら、レジスタ値がかわっちゃうじゃないですかぁっ! ハードウェアさんかわいそうですぅ!まだ動作検証もしてないのにぃぃ~(悲)。電気ながれちゃうんですよ……」と身を震わせて言うのです。

その瞬間、あなたの組込み女子力がアップします。きっと男は「なんて優しい天使のようなコなんだろう! 絶対に動かしてやるぞ! コイツは俺の製品だ!」と心のなかで誓い、ハードウェアに惚れ込むはずです。意中の男と付き合うことになったら、そんなことは忘れて好きなだけレジスタを叩いて大丈夫です。「叩けないんじゃなかったっけ?」と言われたら「大丈夫になった」とか「慣れた」、「そんなこと言ってない」「いま検証中だろ」と言っておけばOKです。