BT

アジャイル/スクラムプロジェクトにおけるバグへの対応

| 作者: Mark Levison フォローする 0 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2009年7月20日. 推定読書時間: 4 分 |

原文(投稿日:2009/7/15)へのリンク

Bugsよくされる質問がある。スクラムでは、チームがバグをどう処理することを推奨しているのか?プロダクトバックログに入れるべきなのか?それとも、別のバグリストに入れるべきなのか?もしバグがバックログにあるのなら、プロダクトオーナーが優先順位をつけるのか、それとも、自動的に最重要項目になるのか?別のバグ修正スプリントをするべきなのか?

Pascal Maugeri氏のチームでは、完了の定義を改善して、「適切なテスト/ユニットテスト」をした後でさえも、まだスプリントを逃れたバグが見つかるそうだ。どうすればこの問題を解決できるのか、彼は質問を投げかけた。

アジャイルコーチであるGeorge Dinwiddie氏は、ふりかえりでチームにその問題を提起するよう提案している。 – 彼はバグ発生率がほとんどゼロのチームで仕事をしたことがあるそうだ。Mark Levison氏(この記事の報告者)はこう提案する。「なぜバグが発生したスプリントで、そのバグを発見して修正できなかったのか?と問い始めるようにしました。私の関心は、問題を発見する(そして修正する)のにかかる時間を削減することにあります。結局のところ、もしスプリント中にバグが書かれ、ストーリーにバグが発見されたら、PO(プロダクトオーナー)は完了を受け入れるべきではありません。それに、バグを早期発見すると、開発チームの頭にはまだコードが残っているため修正はずっと簡単です」

Artisan Software ConsultingのCST(認定スクラムトレーナー)であるJim Schiel氏は、プロダクトオーナーが優先順位をつけられるよう、バグをプロダクトバックログに入れるだけだと言う。- 「もしスプリント計画中に解決策を決めてそのスプリントで実施できるような、極めて単純な修正でなければね」

Bruce Kantelis氏は、すべては文化を育てることだと言う。「私たちは欠陥を分類しています。優先順位1はユーザの作業をブロックするもので、直ちに対策、すなわち、修正やパッチのための割り込み作業をします。それ以外はすべて、次のスプリントのリストの一番上に、ストーリーとして追加します。時間がたつにつれチームは、品質評価や品質変化が労働時間に実際に影響を与えて、割り込みが最小限になることを実感します」

Mike Cohn氏は、スプリントで見つかったバグはチームルーム中に大声で叫んで、バグを説明することにより処理するのが一番だ、と指摘する。それがダメなら、バグを説明したカードをボードに追加してもよい。しかし、スプリントを逃れるバグもある。彼はそれらをプロダクトバックログに追加して、プロダクトオーナーが優先順位づけするまでそのままにしておくそうだ。既存のチームの多くには、依然として使い続ける必要のあるバグデータベースがある。その場合には、彼は別のバグバックログを管理するよう勧めている。プロダクトオーナーは優先順位がどのキューにあるものかを言うだけでよい。例えば、まずプロダクトバックログから2つ、それからバグが続いて、最後にプロダクトバックログから次の2つ、というように。

Kevlin Henney氏は、このアプローチはバグを負の値をもつ機能として扱うことと同じだと主張する。

もし欠陥を負の値をもつ機能だと考えると、欠陥はまるで機能であるかのように管理されることになります。開発グループは優先順位づけされたバグのリポジトリを蓄え、バグをユーザストーリーとして扱い、バグ修正をアウトソースするのです。これらは過渡期や危機に瀕したプロジェクトに対処するときには、役立つテクニックや考え方になるでしょうが、奨励すべき長期的な考え方ではありません。結局のところ、「アジャイルソフトウェア開発マニフェスト」が言っているように、「動作するソフトウェアこそが進捗の最も重要な尺度」なのです。既知の欠陥のある機能を「ええ、完了してます、少しだけバグはありますが」と言って、完了して動作しているとごまかすのは、少し誠実さに欠けるでしょう。

Ron Jeffries氏は、問題をひっくり返して、完了後に機能にある欠陥を修正するのは、最初から修正するよりも必ずコストがかかると言う。

だからね、間違ったソフトウェアを書いて、後からそれを修正すると、顧客は余分なお金を払うことになるのです。これまでに払ったものに加えて、バグの修正分までね。

本当は、顧客は怒るべきなんです。顧客には、欠陥すべてに優先順位をつけることをお勧めします。そうすれば、チームの不適切なソフトウェアプロセスに対して、顧客は間違いなく苦痛を感じるようになります。顧客がその苦痛を表明することで、チームはものごとをうまくやるアイデアを得る機会がさらに得られるのだと、私は確信しています。

あなたはバグを完全に避けられますか?バグをプロダクトバックログに入れますか?Kevlin氏が述べたような問題を経験したいですか?

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT