アジャイルな開発をチームでやってみている(2010年)のですが、いざやってみると結構ハマリどころがありました。やってみたことを共有しておこうと思います。
かたちから入ろう
朝会
アジャイルな開発と言えば朝会なので、朝会から始めました。開始時刻をメンバーで決めて、それぞれが昨日やったこと、今日やること、おしらせ、困っていること、を共有しました。
さらに、朝会前に社内wikiにメモ書き程度の項目を書いておきます。これにあらかじめ目を通すことで、一番の課題に時間を集中することができました。
アンチパターン・決めた時刻を守らない
11時から朝会始めようと決めたのに、11時過ぎに汗だくで飛び込んできて「遅れてすみません」「wiki書いてません」「wiki読んでません」というのは、チームの空気を悪くするだけでなく、単純に全員の時間を無駄にしてしまいます。時刻を守るか、守れるルールに変えましょう。ごめんなさい。
できることからやろう
組み込めそうなものからとりいれてみました。具体的には、『達人プログラマー』で言う三本柱（テスト・自動化・早期デプロイ）、朝会、継続的な統合(CI)、テスト駆動開発(TDD)、テスト用データベースの独立、分散VCSを使う、などです。
CI, git, TDDは一気に導入しました。テスト用データベースの独立は必要になってから取り入れました。
アンチパターン・あれもこれも
一個一個見ればそれはあったほうがいいんだろうなと思いますが、きりがありません。多すぎて身構えてしまうし、開発が乗ってくるまでにどれだけかかるんだよと。かといって完全マスターしないと増やさないポリシーも意味がありません。要はバランスです。
今思えばgitの導入がかなり説明不足でした。その時はsubversionをフル活用した社内ライブラリとの接合をとるのでいっぱいいっぱいでした。
チームでやろう
今までもタスクが個人レベルまで分解されたあとは、アジャイルというかXPというか"ぼくのかんがえたTDD"でやってみてました。これが結構できるようになったなーと思ってチームでやるようになったのですが、ひとりxpとチームxpのあいだの一歩は思ったより大きかったです。逆説的ですが、ひとりxpが完璧にできるようになるのを待つ必要はないと思います。最終的にチームでやらない意味がわからないので、できることからさっさとチームで始めるのが良いと思います。
アンチパターン・チームで決めた方針は変えない
合わなかったら、そして合理的な理由があればさっさと方針を変えましょう。はじめのルールのままテストがどんどん遅くなっていっているのでどうにかしたいです。
テスト駆動で開発しよう
テストコードを先に書く事で、テスト可能な設計になります。むしろテスト可能な設計でしか書けません。テストコードが存在することで、テストコードの範囲内で正しく動くっぽいことが確認できます。テストコードがなければ、正しく動くっぽいことの確認すらできません。また、テストを壊してしまったら、CIサーバのhudsonが容赦なく "Build faild in Hudson" なるメールをガッシュガッシュ投げつけてくるので、想定の範囲内でデグレードを防ぐことができます。
アンチパターン・テストを書かなければ失敗しない
テストを書かなければ失敗しないのですが、それでは意味がありません。また、通らなくなったテストをコメントアウトしたり、消したりしてテストを通してはいけません。さらに「いけません」とチームに言ってるのに「他の作業するところで影響でるから」と実装だけ修正したりすると、「なんであいつだけ」となるので以後気をつけます。
ただし"たまに落ちるテスト"はどうしていいかいまだによくわかりません。
イディオムに従う
symfonyのイディオムはjobeetなので、jobeetに従っておくと共通認識をつくりやすいです。php, symfony, lime, jobeetのイディオムから外れるときは明確に意図を持って外れるようにしましょう。「正しいunit testでは」みたいな話ばかりをしていても仕方がないので。しましたけど。
そんなこんなやってみた構成
- php5.3, symfony1.4, mysql5.1, memcache, flashlite1.1
- テスティングフレームワーク lime
- BTS trac
- VCS git
- CI hudson
- デプロイ capistrano
やってみてのハマりどころ
アジャイルな開発のスイートスポットは新規開発?
不慣れなチームだったので別にスイートスポットではありませんでした。ケータイ向けアプリのflash
flashが重要な役割を占めるけど、limeでテスト駆動開発...そこは割り切って開発することにしました。デプロイするcapistranoのレシピは早々に書いて動かしてたのですが、flashとphpが出来上がってきたところでがっちゃんこになりました。そして、がっちゃんこしたら結局わりきった接合面でなんでか動きません。TDDでmodelを厚く作ったのに...
だいたい原因は、symfony にも不慣れな人ばかりだったので、そんなに厚くないcontroller部分の値の受け渡し部分なことが多かったです。
ケータイ向けopensocialに特有の部分
テスト用擬似ブラウザsfBrowserのclickとかredirectとか(NDAかもしれないので省略されました)
fixtureの硬直化がDBのschemaの硬直化を呼ぶ
fixtureをyamlで書いてそれを毎回DBにロードしてるので、スキーマ変更するたびにyamlの編集が必要になりました。テスト書き換えるだけでもしんどいとおもうひとばかりなのに、yamlをえんえん編集してるのはもっとひどくてかなりダメージを受けてました。赤→緑→リファクタリングのサイクルで脳汁が出る人ばかりではありません。自然と、 DBのschemaが硬直してしまいました。factory_girlはやくきてくれー。
全体的に
やりたいやりたい言ってる私がコーチになるどころかそんなに役に立ててないのが割と原因の一つです。でも私もわかんないよ。手探り手探りです。あわせてよみたい
- mixi Engineers' Blog » いまからでも間に合う開発者テスト
- デブサミのアンケートに感動したので全部返事書いてみた 2010
このバーンダウンチャートいいなー - 達人プログラマー 黒い方 4-89471-274-1
- Head First ソフトウェア開発 978-4-87311-392-0
これから
問題にぶつかったなかで、今一番多い解決策は"とりあえずわりきって前に進む"であることがおおいので、もうちょっとましな解決tipsのエントリを挙げられるといいなあと思います。以上デース