デブサミ２日目

Posted by kenchan 2009-02-14 22:19:00

2日目は、セッション２つを聞いて、デブサミふりかえりのお手伝いをしてました。

アート・オブ・アジャイル デベロップメント

木下将軍もとい、ダークナイトのセッション。

会場で先行発売していたアート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミングの中から、テストと顧客のビジネス、価値についてのお話。

  • アジャイル開発で重要なのは続けること
  • アジャイルとテスト
    • ディベロッパーテスト
      • ペアプロで効率が落ちるのはナビゲータがサボってるから
      • Think->Red->Green->Refactor
      • 5行以下で実現可能かThinkするのがナビゲータ
      • ピンポンペアリング
        • Think->Redの時点で交代
    • QAテスト
      • プラクティス「バグなし」ができないなら必要

アーキテクトってなんですか

マイクロソフト認定アーキテクトを取得した際の経験から、アーキテクトとは何なのか、PMとは何が違うのか、そのあたりをお酒っぽい何かを呑みながら熱く語ってらっしゃいました。

  • アーキテクトの仕事
    • 何でも
    • 技術的な責任を持つ人
  • アーキテクトとPM
    • アーキテクトは父
      • システムとビジネスをつなぐ
      • 先頭を走る
      • 技術で引っ張る
    • PMは母
      • お金
      • 裏方でどっしり
      • リソースを管理
    • PMとアーキテクトの視点を合わせることで最大になるように
      • 兼任では1人分の視点しか
  • アジャイルとアーキテクト
    • アジャイル開発者がいると心強い
    • アジャイルの導入は失敗できない
      • 「やっぱりだめじゃん」と言われる

デブサミふりかえり

デブサミの最後に、2日間での気付きをふりかえり、そして共有しようという企画でした。

裏番組が強力すぎたので、正直思ったより人がすくなかったのですが、参加した方々に「こうしてふりかえれてよかった」と言ってもらえたときはとてもうれしかったです。(準備などまったく手伝えなかった人が言うことじゃないですが)

途中からスタッフも中に入ったんですが、皆さんの熱気がすごかった！そして、4人中2人が帰って社内勉強会を立ち上げると！すごいパワー！

俺も負けてられない、というか、もっとがんばらなきゃ！そんな風に思ったふりかえりでした。

 

さて、デブサミを終えて強く思ったことが一つあります。

「俺もいつかあの壇上に立ちたい！」

今はまだ無理だけど、いつか、近い将来、あそこに立つためにがんばろう。

 

(ここから心の声)

やばい！書いちゃった！書いたら後戻りはできない！突き進むのみ！

デブサミ１日目 1

Posted by kenchan 2009-02-14 21:22:00

1日目に参加したセッションは次の4つ。

  • iPhone開発者座談会
  • カードゲームでプロマネ疑似体験
  • Eclipse-way
  • オブジェクト指向エクササイズのススメ
  • LT大会

iPhone開発者座談会

iPhoneどころか、touchも持ってないけど、興味本位で聞いてきました。

  • 審査がかなり厳しい
    • UIがいけてないとだめ
    • 文言が悪いとだめ
    • あらかじめ、軽いアプリでアカウントを作っておくのがオススメ
  • iPhoneに向いている、向いていない
    • 80%の人が使う機能だけを入れる
    • 単機能
    • 最初は細かい機能をごっそり落とす
    • 何かを見るアプリが向いてる
  • 開発する上での注意など
    • タッチポジションは大きめに。指は1ドットではない。
    • アップルのアプリをよく見る
      • なぜここにボタンがないのか
    • コードの美しさ vs パフォーマンス
    • ドキュメントのないAPIが肝
    • Twitterで情報共有しよう

カードゲームでプロマネ疑似体験

yattomの手作りカードゲーム面白かったです！

  • プロジェクト開始時点で、実は勝負が決まっている!?
  • 手札が多い序盤に、リスクのあるカードを処理するのが正解？

相手の方から「ゲームが進むにつれて、リスクが上昇するのはどうなんだろう。開発が進むにつれてリスクは減っていくのでは？」というところが気になったようです。

Eclipse-way

ついこの前、codezineにも記事が載ったJazz（とRationalのツール)のお話。

分散開発におけるリポジトリの考え方はよくまとまってて面白かったです。改めて分散バージョン管理に移ろうと心に決めたのでした。

  • IBMの開発プロセスウォーターフォールからRUP、そしてAgileに
  • 分散Agileやってます
  • Jazzのサイト自体が分散Agileの実例となっている
    • 何を作るのか
    • 何を決めるのか
    • どういう粒度の成果物を作るのか
  • Eclipse-wayとは、Eclipseの開発プラクティス
    • OSSならではのプラクティス
    • 大規模開発のプラクティス
    • 分散開発のプラクティス
  • ドッグフード重要
  • 分散開発のポイント
    • リポジトリの管理
      • コードをコミットするための明確な完了基準
      • SVNを分散っぽく使う
      • メインリポジトリと個人のワークスペースとローカルスペース
      • 個人のワークスペースはサーバ上、ローカルリポジトリはローカルマシン
      • ちょっとした変更でも共有やレビューができるように、サーバ上にワークスペースをおいている
      • ワークスペースとローカルリポジトリは常に同期されている

 

オブジェクト指向エクササイズの進め

ThoughtWorksアンソロジーのエッセイの一つを紹介してました。

かなり厳しい制限を加えることで、普段思いつかないようなクラスが抽出できたり、チームのメンバーに眠っている知識を引き出したり、責務の再分配ができたりと、かなりの効果があるとのことでした。

何よりも、実際にこの制限化でアプリケーションを開発しているチームがThoughtWorksにはあるというが一番の驚きでした。

  • 9つ制約の効果
    • 責務の再配分
    • 新しいクラスの発見
    • 設計がゆれる（いい意味で）
    • 議論を引き出す

 

LT大会

終始ドラ娘専属カメラマンになってました。

まったく知らないコミュニティの方々のLTを見れて、かなり新鮮でした。職人系が少なかったのもよかったです。

 

2日目に続く。