2012年8月13日月曜日

アジャイルサムライ読書会 横浜道場 「ストーリー収集ワークショップを開催しよう」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場
「ストーリー収集ワークショップを開催しよう」
http://connpass.com/event/834/

アジャイルサムライ読書会 横浜道場 「ストーリー収集ワークショップを開催しよう」 #agilesamurai #横浜道場
http://togetter.com/li/353184

今回は、久しぶりの通常回です。
「6.4 ストーリー収集ワークショップを開催しよう」からでした。

ストーリー収集ワークショップ

DSC_0369.JPG

実際にスクラムを実践されている方がテーブルにいらっしゃったので、実際にやっている内容を聞いて意見を出し合ったりしました。
特に文房具の使い方は、頷ける内容が多いように思いました。
例えば
  • ホワイトボードは議論用に使ってあとで見直せるように印刷できるものやデジカメで保存するようにする。
  • ストーリーカードは紙のサイズを制約として扱い、その一枚で表現する。
といった内容でした。
文章の限界ということを認識して絵や図を多用することで、お互いに共通認識を深めていくのが目的なのではないかなと感じました。

その他もろもろをブレインストーミング

DSC_0370.JPG
「ご近所さんを探せ」などで出てきた、政治的プロセスの把握や、開発環境や運用に関する項目もこの場所で出すことで、そのストーリーがどこと関係しているのかや、どれくらいの規模なのかが見えてくるのではないかと思います。
あまり細かくしてしまうとストーリーが膨大になってしまいますし、粗いと漠然としすぎてしまって本当にやりたいことが隠れてしまうといような印象を受けました。
細かくするのは後のプラクティスでやるのはいいのですが、どの程度までの「粗さ」がこの段階で求められているのか疑問に思いました。

見積り

DSC_0368.JPG

ここから第7章の「見積り:当てずっぽうの奥義」に入りました。

ここで出てきたのが「見積りの根拠」でした。
前回のスプリントから見積もることで相対的に見積もれるというのは分かるのですが、スプリントゼロの見積りはどれを基準にして相対的に見積もるのかなと思いました。
ただ、いわゆる「不確実性のコーン」に基づけば最初の見積りはどんなに頑張っても当てずっぽうなので、今までの経験から推測される根拠であればいいのかなとも思いました。

現状の契約ですとこれがコミットメントとして扱われてしまうから、無駄なものを作ってしまったり、デスマーチに陥ってしまったり、赤字なのにどんどんリソース突っ込んでしまったりといった不幸なことが起きてしまっていると思います。

スクラムやその他のアジャイル手法に適切な日本の商習慣にでも使える契約モデルとかどこかで公開してないでしょうかね。

最後に

今回も初参加の方がいらっしゃいました。だんだん参加される方も増えてきてディスカッションも毎回新鮮な感じを受けています。
次回もまた初参加の方とお話できればいいなと思います。

横浜道場のスタッフの皆様、参加者の方々、会場を提供して下さった株式会社アットウェア様、ありがとうございました。

2012年8月5日日曜日

Twitter 勉強会に参加してきました #twtr_hack

8月1日(水) - Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
http://www.zusaar.com/event/331056

2012/08/01_Twitter 勉強会 #twtr_hack @デジタルハリウッド東京本校(@dh_tokyo)
http://togetter.com/li/348584

今回は、第3回Playframework勉強会 に参加してきました #play_jaで発表されたattaccaの@i2keyさんがクライアント側について発表されるとの事なので、参加してきました。



Railsの環境さえ整えてしまえば、こんなにも簡単にできてしまうのかと思うほど、面白い内容でした。
個人的には、playframeworkでおんなじようにscaffold作ってくれる機能があればなぁと思いました。
この資料を参考にしてやってみようと思います。



テキストマイニングを手動で行われたそうで、とても頭の下がる内容でした。
日本とその他の地域だと使われ方が違うそうなので、コミュニケーションのとり方の違いがそのまま現れているのかなと思いました。
日本語のテキストマイニングに強いフレームワークを利用してみたら、面白そうな企画だと思いました。



今回の勉強会で一番楽しみにしていた内容でした。
外部サービスのAPIが頻繁に変わりやすい場合、非依存にせざるを得ないというのはわかりますが、ここまで大変だと自分たちでラッパーのようなフレームワークを導入していそうなプロダクトが有りそうな気もします。
困ったときにさっそうと現れるTwitterのなんでも屋ことイケメン(@yusuke)さんがカッコ良かった。
OAuth2.0周りでTwitterはお世話になると思うので、よろしくお願いいたします。



チャーハン諸島を初めて知ったきっかけは、ミュ~コミプラスのアカウント(@mc1242)が使ってるクライアントだったということです。
TwitterのAPIと付き合っていくと、クライアントとサーバーとのやり取り、ストリーミングの制御、UI/UX等プログラミングの実践的な部分と向き合うことが出来るということが、印象的でした。
自分が本当に使いたいのかとか、どうやったら出来るのかとかいろいろ悩むのも楽しいので、やってみたいと思いました。

最後に

Paypalの不具合にも関わらず丁寧に対応して下さった主催者である@yusukeさん、講演者の皆様、とても素晴らしいネットワーク環境と会場を提供して下さったデジタルハリウッド東京本校様、ありがとうございました。