2011年11月23日

アジャイルサムライ読書会 BIGLOBE道場に参加しました #biglobedojo #agilesamurai

11月22日、第7回 アジャイルサムライ読書会 BIGLOBE道場に参加してきました。

今回のテーマは第5部 「アジャイルなプログラミング」。「読書会」というタイトルですが、実際にアジャイルを現場で実践してきた方々のLT・講演と、質疑応答を中心に進められました。



わてすさんのLT

まず最初は、ゲーム業界のプログラマーとして勤務されているわてすさんによるLT。アジャイルを実践してきた成果についてお話を伺えました。

  • 仮想環境があると便利。小規模なlaaS、KVM、ESXiを利用している。
  • Redmineを導入した。Tracをさらにシンプルにした感じ。
  • gerritでコードレビューを行えるようにした(gitとの相性がいいらしい)。
  • Makefileの代わりに、CMakeを利用している。
  • ソースコード静的解析ツールとして、coverityを利用している。
  • メンバー間で情報を共有するための工夫として、メンバー全員で見られる大画面、ノートPC(持ち運び可能な開発環境があると便利)を利用している。
  • jenkinsはWebのインターフェースがあるので、テスト用のマシンにログインしてコマンドコマンド打つ用途につかうだけでも、かなり便利。

@kage-yxaさんのLT

開発メンバーが東京-広島の二ヶ所にいる状況で、リモートスクラムを実践してきた成果についてお話を伺えました。

  • コミュニケーションは、Skypeやメッセンジャーが中心。
  • デスクトップ共有ツールSharedViewでファイルの共有を行なっている。
  • 週に平均2〜3回リリース。リリースは細かい単位(1画面のこの部分を直す、等)に分けて、頻繁に行なっている。
  • 「ふりかえり」は、各メンバーがSkypeやメッセンジャーで送って、結果をSMがExcelにまとめる。
  • 「ふりかえり」から生まれた課題や改善策は次週に実践され、それらに対する「ふりかえりのふりかえり」も行なっている。
  • スクラムを実践してみて、以前よりメンバー間で話がしやすい雰囲気になり、東京-広島間の連携がスムーズに行えるようになった。
  • まだ解決していない問題点1:Skype用にヘッドセッドを常時つけていると、耳が痛くなってくる。
  • まだ解決していない問題点2:SharedVIewだと複数ユーザーで同じドキュメントを編集できない。Cacooの導入を検討しているが、セキュリティ上の理由で使えない。

@tsuyokさんの講演「 CIしてるかい?」

受託開発でスクラムを実践し、お客様からの評判も上々とのこと。

今回は、CI(継続的インテグレーション)についてのお話を伺えました。

手動でテスト・ビルドをやると

いろんな人が開発したものを合わせてコンパイルすると、コンパイルエラー。。。

バグが出たらテストのやりなおし、のはずだけど。。。 みんなほんとにやっています?

CIを導入すると

おかしなコードをコミットするとすぐわかる。中途半端なコードをコミットしない。 テストを先に書くことによる安心感がある。

Seleniumのテストで気を付けたこと

各要素の検証を細かくすると、仕様が変わったときに修正が面倒。一連のパスを通すことを目的にテストした。また、レスポンスが早くなるよう、モックを利用した。

CIのメリット

  • 手戻りの削減および品質の維持ができる。
  • いつでも、誰でも、実行可能なソフトウェアが作成できる。
  • ビルド、テスト、結果フィードバック等の作業コストを削減できる。
  • 機械による実行で、作業の正確さ、機密さ曖昧性の排除が可能となる。

@kajipさんの講演「TDDを1年やってみました〜シロート集団がTDDをやってはまったこと〜」

PHP開発でTDDを実践してみて、実際に起った問題や、それらに対する対処についてのお話を伺えました。

テストメソッドが増えすぎて変更の手間がひどい、メソッド名が思いつかない

dataProviderというのを利用するといいらしい。

(ちょっと調べてみると、PHPUnit複数のテストメソッドで呼び出す共通のテストをまとめて短くかける仕組みがあるらしい)

テストの実行速度が遅い

DatabaseTestCaseを利用すると遅いことが分かった。DatabaseTestCaseを使わず代替手段に置き換えることで、テストの実行速度を大幅に短縮させることができた。

Twitter APIを呼ぶテストで、Twitter APIが不調だとテストがこけるケースがある

Twitter APIを呼ぶ箇所にモックを利用するようにした。

PHPのBDDテストFW「Jasmine」

Jasmineというテスティングフレームワークをつかうと、RubyのRSpecみたいなテストコードが書ける。

プロダクトコードの前にテストを先に書くことの意義

「テストコード」は「これから書くプロダクトコードの設計書」でもある。

最後に、勉強会の感想

実際の現場での体験談・失敗談が中心で、これから私の職場でアジャイルを実践する上での参考材料になりそうな話を多く伺うことができました。

結局、勉強会のために購入したアジャイルサムライは一度も手に取ることなく終わりましたが(笑)、まあ書籍より貴重な話を伺えたので、何の問題もないですね。

懇親会にも参加しましたが、アジャイルを現場に導入する難しさはどの職場にもあるようです。アジャイルに抵抗感を持つ人達とどう話し合っていくか… 実績で示すことができればいいけど、みんな手探りでやっている状態ではそれもできないし、これというアイデアは私にもないですね…

ただ、同じ志の社外の人たちと交流を持つということは、何らかの突破口になるのかもしれません。

今回の勉強会に参加して、アジャイルサムライ読書会はアジャイルなら世の中バラ色と夢見ている人たちではなく、現実に起こっている問題を認識つつ、今のままのソフトウェア開発ではいけないという危機感を持った人たちが切磋琢磨している場だと感じました。この一文が、より印象深いものになる勉強会でした。スタッフの皆様、参加者の皆様、ありがとうございました。

「君が質の高いソフトウェアを届けることは誰にも止められない」

アジャイルサムライ304ページより



ryu22e at 19:23コメント(0)トラックバック(0)勉強会 | アジャイル 

トラックバックURL

コメントする

名前
 
  絵文字
 
 
Profile

ryu22e

Recent Comments
  • ライブドアブログ