まだあった・Agileでうまくいかないとき
Allan: Agile failure modes - again
まだあった・Agileでうまくいかないとき
Agileでうまくいかないときと続・Agileでうまくいかないときの続編だよ。まだ他にも見つけた。Agile開発がうまくいかなくなる事がある、他のパターンだ。最初にこれを見つけたときはよくわからなかったけど、二回目に遭遇したらだいぶわかってきた。ま、ありがちな事のように見えるんだけどね。
リーン開発やAgileの考え方の基本は、コードの品質を上げていく事だ。コードの品質を上げると、様々な波及効果がでてくる。品質向上はバグの減少につながる。バグが減るという事は、将来的にバグ対策で無駄な時間が取られなくなるということだ。また、品質を上げる事は開発終盤においてテストにかける時間を減らす事につながる。つまり、イタレーション周期を短くできる事になる。また、品質を上げる事で製品の投入(あるいはデモ)をいつでも可能にできる。いずれにせよ、品質向上は大切な事だ。
品質向上のためにまず試すのは、自動化された単体テストだ。テスト駆動型開発(TDD)とかテストファーストとかいうやつでは基本だね。この自動かテストが難しさにつながるかもしれないそもそもの理由なんだけど、その説明は他のブログに任せよう。いい感じの粒度で単体テストを自動化する事で、回帰テストを高速化できる。そして、安心して新たなコードを追加できるようになる。
でも、ここが問題の入り口なんだな。
何か修正を加えたら、まずテストが失敗する事を期待するよね。じゃないと、バグを埋め込んじゃう事になる。なので、まず新しいコードのためのテストを書き、対象のコードを書き、そのうちテストを通るようにする。でも、新規コードではなく既存コードを変更する場合には、まずテストは失敗するはずだ。つまり、(コード変更による問題を検知するため)テストが不安定な状態になる事を期待しているわけだ。
このテストが不安定な状態が間違った方向に走ってしまう事で、問題が生じてくる。自分が見た例では、データベースの中のテストデータが変更された事でテストが不安定になってしまった。その前に見たときはCOMモジュール周りのテストが不安定になっていた。つまり、単体テストが必要とする環境だけ切り出せていなかった、ということになる。
筋金入りのAgile/TDD開発者なら、「あ〜それはだね、やり方がまずいよ。」と直ちに問題点を指摘する事であろう。そのとおり。テストが不安定にならないように工夫する必要がある。スタブコードを使うとか、モックオブジェクトを使うとか、データベースならデータ戻しをかけるとか。
本来のテスト自動化は、コードが正しい事を保証し、より素早く前進できるようにするためのものなんだけど、誤った使い方をすると開発の足を引っ張るだけになってしまう。頻繁にテストを書き換えるという事は、作業の負荷と複雑さを増すだけだからね。全てオッケーということを確認するためのテストのはずなのに、保守作業が増大してしまう。明らかに目的とは異なる結果になっている。
問題の根っ子は、Agile/TDDをやろう！ としている人達の間にAgile/TDDの経験がない、というところにある。でも、やったことがないのにどうやって経験をつめるっての？
対策は三つある。一つは、Agile/TDDをしたがっている人達を訓練するため、企業はきちんと投資する事だ。二つ目は、Agileを教える人を雇う事。正規職として雇ってもいいし、外部から臨時で招聘してもいいだろう。三つ目は、経営側がAgile/TDDしたがっているチームを支援し、彼らが挑戦している事に対して元気づけてやる事だ。
Agileは現場主導で開始され、そこにみんな勢いでついてくる、ということが多い。仮に経営側の判断で始めるにしても、研修のための費用は高くなってしまうかもしれない。そもそも、Agile研修をしてくれる人達がいる事を、経営者達はわかってないかもしれない。(Agile研修・訓練をしてくれる人を知らなかったら私にメールしてくれ。いいのを紹介するから。)
ということで、「とにかくやろうぜ！」「いいからやれ！」という形でAgileが始まると、そのプロジェクトでは将来問題が発生する可能性がある。プロジェクトで発生する問題点を見つけたら(見つけられればの話だが)、正しい対応をとる事だ。さもなければ、「Agileが悪い」といわれることになりかねない。
補足
- これは自分も経験したし、他の事例も見てきたからよくわかる。
- Unit Test爆発現象。
- 理由は様々。
- Unitと呼ぶ単位がそもそもデカすぎる場合。
- (ほぼ同義だが)他のUnitや部品への依存度を断ち切れず、それらのUnit/部品の状態分だけテストケースが増えていく。
- 汚いコードを放置している場合。
- 確かに最初の頃は泣く思いでテストケースを追加し、あるいは保守した記憶がある。
- このあたり、確かに研修も大事だけど、「演習プロジェクト」みたいなのがあってもいいかもしれない。
