問題追跡システムを使用することの欠点についての研究はありますか？
次の理由により、問題追跡システムは好きではありません。
- 問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。
- バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるように（またはそうではない）、そこにバグを置くことができます。
- 時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間を費やしています。
ホワイトボードでポストイットを使用して問題を処理したり、顔を見ながら会話したり、重要なバグが現れたらすぐに殺したりすることを好みます。オーバーヘッドの価値があるとは思わないので、バグの履歴を追跡することはあまり気にしません。
私はここに一人ですか？問題追跡システムを使用することの欠点（または大きな利点）に関する研究（本/記事/その他）はありますか？
問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。
バグを説明することさえできない場合、どうすれば修正を開始できますか？
バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるように（またはそうではない）、そこにバグを置くことができます。
これは、ソフトウェアではなくチームの問題です。
時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間がかかります。
もう一度あなたのチームとの問題を説明します。
バグ追跡ソフトウェアの要点は、チームがバグを修正する動機を与えることではなく、記録を保持して、バグの原因を追跡し、バグの再発を防ぐことです。良い管理の代わりになるソフトウェアはありません。
IMOあなたの出発点は偏っています。開発者がバグの修正に失敗した場合、適切なバグ追跡ツール、ポストイット、石の彫刻などを使用してバグを追跡するかどうかに関係なく、プロジェクトは失敗する運命にあります。使用されていない、または誤用されている場合は、ツールの責任ではありません。 （とは言っても、そこにはもちろん悪いバグ/問題トラッカーがあります...私はこの仕事に完全に不十分なツールを使用してプロジェクトに取り組んだので、それがどれほど悪い可能性があるか知っています。しかし、良いものもあります、最小限のセレモニーとオーバーヘッドを必要とするため、関連情報に集中できます）。
ただし、開発者が注意を払い、プロジェクトのサイズが些細なものより大きく、開発者が1人以上いて、何らかの管理が関与している場合（これらはすべて、実際のプロジェクトではかなり一般的です） ）、すぐに次のような質問が発生します：
- 開いているバグのうち、最初に修正する必要があるのはどれですか。 （注：正しいプロジェクトでは、これは開発者ではなく、製品の所有者や管理者が決定する必要があります-そのためawareまず、開いているすべてのバグの中で！）
- 未解決のバグはいくつあり、どの程度深刻ですか？
- これらのどれをリリースする前に修正する必要がありますか？
- これらの修正を計画するためにどのくらいの時間-多くの場合、次の原因になります：バグを修正するのに平均してどれくらいの時間がかかりますか？
- 前回のリリースでクライアントからいくつのバグが報告されましたか？
- 誰がこれとこのバグを修正しましたか、いつ、そして何（コード/構成/データ）の修正に修正が含まれましたか？
- 公開しようとしているリリースには、どのようなバグ修正が含まれていますか？
- ...
付箋に基づいて、このような質問に答えることができます[更新]繰り返し可能、確実かつ効率的[/更新]？
はい、問題のトラッカーにバグデータを入力すると、オーバーヘッドが発生します。ただし、保存されたバグデータから上記のようなレポートを検索および作成する際に節約された時間と労力によって、それ以上の効果が得られます。
研究があるかもしれませんが、フィールドの人々の苦労して得られた経験はさらに良いです。ほとんどの問題追跡システムは、設計を推進するプロセスの影響を受けます。多くの場合、課題追跡は2つの異なるクラスのユーザーをサポートする必要があります。
- 開発チーム
- システムのユーザー
Cal Henderson（以前はFlickrのメンバー）は 素晴らしい投稿 を使用して、多くの課題トラッカーの設計と、なぜGitHub課題トラッカーを好むのか（Iと同様）を述べています。また、Garrett Dimonは Sifter の設計をカバーし、さらに 効果的な問題追跡 のプロセスを簡略化する方法を示しました。チームの問題追跡ワークフローを簡素化するために、これらの投稿とこれらの投稿の両方からいくつかのアイデアを採用しました。
そうは言っても、それはプロセスとツールよりも人々にかかっています。私の一般的な考えでは、課題追跡は、管理しなければならないこのバックログを作成する傾向があります。トリアージの間、人々はバグであるかどうかを合理化する可能性が高くなります。私たちのプロセスでは、それが問題であるかどうかについてバグが報告された直後に決定を下します。その決定が行われると、バグはPivotal Trackerに入ります。ここでの違いは、トラッカーを優先順位付けに使用することであり、私たちがやりたくないことを保持するペンとしてではありません。実際、Iceboxが大きくなりすぎたら、バグを含むアイテムを積極的に削除します。問題が処理する必要があるほど大きい場合は、再び発生します。
バグ履歴はほとんど必要ありません。時折、誰かがバグの症状に言及し、それがすでに処理した問題に関連しているかどうかを検索する場合があります。しかし、それはまれです。
TL; DRプロセスに焦点を当て、簡単なツールを選び、問題が発生したら対処します。
重要なバグが現れたらすぐに殺す
ここで開いているドアに侵入しているようです。 重要 Issue Trackerを使用しているかどうかに関係なく、バグはできるだけ早く「kill」されます。
- ああ、そして「彼らが現れるように」という部分はかなり滑りやすいところである。あるプロジェクトでは、製品全体を廃業させる恐れのある重要なバグがありました（何がより重要なのでしょうか？）。これは非常に複雑（アーキテクチャエラー）で、修正に時間がかかることがわかっていました。顧客は私たちに（製品を落とす前に）修正するために1年を与えることを親切に同意してくれました。
課題追跡については、私はこれらをほぼ10年間使用しており、原則として、私の周りのすべてのプログラマーは追跡者にほとんど時間を費やしていません（注私はプログラマについて話している;マネージャーは別の話である）。そうではないときに（まれに）ケースを見たことがあります-これらのすべてのケースで、何かがひどく壊れていました。
対面式の会話と問題の追跡に関する研究に関して、ここでもまた、ここで開かれたドアに侵入しているように感じます。問題追跡は典型的な書かれたコミュニケーションです。物事を議論するためにface2faceコミュニケーションは電話でよりもはるかに効率的であることを示す多くの研究があります---これは順番に書かれたよりはるかに効率的です。
- 実際、f2fについて尋ねると、トラッカーを使用して議論しているように感じます（これはその目的ではありません）。その意図された用途を理解するには、その名前をゆっくりと明確に綴るだけです： issue tracking system 。
バグリストが長くなる
私の経験では、上記は問題ではなく利点です。
長いバグリストを使用すると、開発者はキューを設定して、はるか先に修正を計画できます。これは可能な限り生産的です。私にとっては、このようなキューを操作するためのキューがあるとき、これは基本的にニルヴァーナです。 最初のバグ-修正-完了、2番目のバグ-修正-完了、次のバグ-修正-完了など]愚かな中断なし、非常に効率的なf2f会話による煩わしい気晴らしなし 純粋な流れ 。
- 長いバグリストが問題であった1つのケースのみを思い出します。それは、上級管理職の馬鹿が、ほぼ毎日50〜100の山から次のバグを選択するように開発者に強制するポリシーを決定したときに起こりました。なんて無駄だ。これを彼の頭の上にエスカレートして修正する方法を見つけるまで、数か月の苦痛を要しました。
便利なワークフローを確立できた後、「エンドレスバックログ」が魔法のように空になっていることがわかりました。