スクラム実践者が知るべき97のこと

41バグ再考

リッチ・フントハウゼン

問題、インシデント、サービス停止、欠陥、バグ。これらの言葉を口にするだけで、プロダクトオーナーやステークホルダーの背筋が凍ることがある。品質が低いことを暗示しているからだ。そのため私は、このような言葉の利用を減らしたり、チームの言葉から外したりするのに情熱を注ぐ。確かに、プロダクトが望ましくないふるまいをすることはある。以前は動いていたフィーチャーが動かない、例外、予期せぬ停止といったものをみんな経験している。そういったものをバグと呼びたくなるかもしれないが、そうしたところで何の役に立つだろうか？　プロダクトが望まないふるまいをするのにはさまざまな理由がある。私たちは開発者を名指ししたり、非難したり、恥をかかせたりするために蔑称を使っているだけではないだろうか？

スクラムでは、スプリントでする作業をすべて開発と呼ぶ。スプリントゴールに向けて開発を進め、スプリントゴールの達成に必要で、完成できると予想したプロダクトバックログアイテム（PBI）を届ける。作業の種類に関係なく、説明責任はスクラムの開発チームにある。スプリントでの開発中は、開発したインクリメントのなかにバグのようなものはない。コンパイルエラーでビルドが失敗する。コード品質のチェックに通らない。自動テストが失敗する。どれも開発だ。予測できない問題がたくさん起こる大変な仕事である。スプリントでは、その作業がまだ「完成」していないという以上のことは言えないのだ。

開発チームがチーム内で作業を完成させるのに必要なすべてのスキルを持っていない場合には、さらに重大な問題が起きる。たとえば、時差があったり組織が違ったり場所が違ったりするチーム外の人によってテストが行われる場合だ。だが、これはまずは ...