バグトラッキングシステムなんて捨ててしまえ？

作者 Mike Bria , 翻訳者 安井 力 - (株)永和システムマネジメント 投稿日 2009年3月26日

セクション

プロセス/プラクティス

トピック

Agile ,

Delivering Quality

タグ

品質 ,

プランニング

"testObsessed"(リンク)(訳注: 「テスト熱中症」の意味)の名で知られるElisabeth Hendricksonが、アジャイルプロジェクトで使うバグトリアージ手法について(リンク)、考えさせられる提案をしている。すなわち、イテレーションの最中に見つかったものは「バグ」ではなく、「バグ」を指摘できるのはプロダクトオーナーだけである。また、健全なアジャイルチームであれば、バグトラッキングシステムを必要としないとも論じている。

Hendricksonの議論は、まず「バグ」とはなにか、その定義から始まっている。

アジャイルにおいて、私の定義はこうです: 完了した("Done"になった)ストーリーの中に、プロダクトオーナーの期待と異なる挙動があれば、それはバグである。

「プロダクトオーナー」の定義をし、「期待」についての説明をしてから、ソフトウェアが完了("DONE")になるまでに「プロダクトオーナーの期待」と異なる部分を発見した場合についての話を続けた。Hendricksonによれば、それは「バグ」と呼ぶべきではない。肝心なのは、そうした発見があったらただちに直す、それ以外の選択肢はないという点である。

ストーリーが完了("Done")になる前に、プロダクトオーナーの期待に反する箇所を見つけたら、直します。期待通りかどうか検討したり、議論したり、トリアージしたりはしません。ただ直すのです。 これが、バグに対して「容赦ない("zero tolerance")」ということです。
...
見つけ次第に直してしまうのですから、そういうものを呼ぶ名前はありません。優先順位はつけません。バグトラッキングシステムでトラッキングする必要もありません。ただちに対応するだけです。

こうした前提を論じた上で、いよいよ本当の「バグ」とはなにか、どう対処すべきか、Hendrickson自身の所見を述べている。

ストーリーが完了("DONE")になり、受け入れも済んだ後で、終わったストーリーがプロダクトオーナーの期待を完全に満たせないとわかる場合があります。このとき初めて、バグが発生したと考えます。

ちゃんとやっていれば、そうした事態が起きることは比較的少ないはずです。高機能なバグトラッキングシステムを使ってバグのトリアージやトラッキングをしたとことで、発生しているバグが常時5個程度しかないのであれば、無意味です。プロダクトオーナーが、プロダクトバックログの中でバグ対応の優先順位を付けて、あとはチームが作業を進めればいいのです。

しかし、もしもちゃんとやっていないのであれば、数多くの虫が逃げ回って収拾がつかないということになるかもしれません。これは、自分たちのプロセスに何か問題があるというサインです。そうなったら、バグを逃さないよう管理することに時間をかけるのではなく、ふりかえってどんな問題があるのか、なぜ数多くのバグが発生しているのか見つけなくてはならないのです。バグは元から絶つ。そもそも、発生したバグを囲い込んで管理するべきではないのです。

この記事でHendricksonは、誰かがソフトウェアにおかしなところがあると指摘し、プロダクトオーナーが「問題ではない」と判断したときどうすべきかについても論じている。そうしたものは記録するべきではないというのが骨子だ。

わたしが仕事で関わったことのある従来型のチームの多くでは(アジャイルチームと働くようになる以前の経験も含みますが)、バグデータベースの中には将来決して対応しないようなバグが大量に記録してありました。こうしたバグは、チームのメンバーやテスターから報告されたものの、「軽微」とか「優先度低」と判断されたものです。

優先度が低い問題を管理しても、決して価値には結びつきません。経験上、そうした情報は決して使われませんでした。データをすべて、リリースからリリースへと引き継いで維持するのも、すべての細かな報告内容を(誰かが重箱の隅をつついて出てきたものですが)管理すればいつか価値を生むと、根拠もなく信じているために過ぎません。ビジネス側が気にしないような課題に価値はないのです。

やがてデータベースはプロジェクトの資産ではなく、セキュリティ的な防護網のようになります。わたしたちは何時間もかけて課題について審議し、課題リストを作り、重大性と緊急性を調整しますが、費やした時間も次に緊急の要望や重大なバグが発生すると無駄になってしまいます。身に覚えがあるなら、認識を改めるべきです。そうした情報はプロジェクトを進める役に立ちません。いつまでも持ち回るのはやめましょう。得る以上に、失うものが多いのですから。

煎じ詰めると、なにを「 バグ」と呼ぶのかもっと鋭敏かつ慎重であるべきではないかと、Hendricksonは挑戦を投げかけているのだ。より具体的に言うと、「後で対応する」と記録するものの量を大幅に減らすべきだというのが、挑戦の内容である。それも、バグトラッキングシステムを使うのが無駄になるほど、少ない数にまで減らしてみろというのだ。そして、「真の」バグの数が多く、きちっとトラッキングする必要が出てきたら、そのときには開発プロセスを見直し、改善して、バグトラッキングシステムが不要な状態に戻すべきだと示唆している。

乱暴なアイデアだと感じる人もいるだろう。いずれにしても、Hendricksonの記事(リンク)全文を読んで(ここではごく一部しか紹介できなかった)、そこに込められたメッセージを真剣に受け止め、自分の考えや経験をもって議論に参加してほしい。

原文はこちらです：http://www.infoq.com/news/2009/03/testobsessed-on-agile-bugs

 

• 次へ >