Agile関係５つの誤解

リファラから辿って色々な人のブログを見ているのだけど、Agile（あるいはTDD）で誤解をしている人が少なくないと感じたので自分の思うことを書いてみる。なお、本日自転車でコケて頭を打っているので変な内容になるかもしれないがそこは笑って見逃して。あと、対象として考えているのはビジネス系のアプリケーション。ゲームや組み込みは自分の範疇外なので...

TDDはテストコードを書く分生産性が落ちる

自分がAgileの営業（？）をしていても良く帰ってくる反応のひとつ。確かにテストコードを書くのは手間と時間がかかる。でも、書いてしまったテストコードを実行するのは比較的短時間で済む。一件あたり１秒かかったとしても、１０００件のテストをするのに１０００秒（１７分弱）しかかからない。これを人間が手でテストしていたら、この１０倍（３時間弱）〜１００倍（２８時間）はかかるはず。

テストコードを書く分生産性が落ちる、と思っている人は「何度もテストをする」という発想が欠けている可能性がある。ある程度品質が固まったらその部分のソースコードは変更しない主義でもあるはず。根っからのウォーターフォール主義者だと仕方ないのかも。

テストコードを書くのは難しい

何を持って難しいというのかは難しい問題だけど、テストコードを書くのが困難なコードというのはおそらく手でテストするのも難しいはず。

テストコードを書きやすいような形にリファクタリングすることが大事。テスト自動化とリファクタリングは切っても切れない関係にあって、リファクタリングのないテストコード記述はどこかで壁にぶつかるはず。この状態を「難しい」と思う人は多いのでは。

(XP等)Agile開発はプロセスとして定義できる

参考書などをもとに「こうすればうまくいくはず」とプロセスを定義して、その通りにAgileするというのはなかなかうまくいかないはず。人間は、やらなければならないことの予想は苦手ではないけど、やらなければならないかもしれないことの予想は苦手。そしてAgile開発（に限らず、日常生活のほとんどは）、計画時点では「やらなければならなかったかもしれないと思わざるを得ない」ことばかり。そういう事象に対して柔軟に対応できるのが人間だし、その特性を活かせるのがAgile開発。家から会社に行くまでの間のプロセスをこまごまと定義する人はいないでしょ。いたとしても、それらのプロセスはことごとく想定外の邪魔がはいってうまくいかないでしょ。想定外のことに柔軟に対処するのがAgileであって、これは決してプロセス定義にはならんわけ。

設計書に書かれている内容さえテストすればよい・設計書から導出されるテストケースだけテストすればよい

これは「設計書に抜けや誤りがない」「設計書の通りにコードが書かれている」という前提が成立すれば確かにその通りなんだけど、そうじゃないからみんな苦労するわけよ。

あー、疲れた。頭がぐるぐるする〜。

５つめはなんだっけ？

ああ、やっぱり頭が変かも。明日は会社休むなり。