問題追跡システムを使用することの欠点についての調査はありますか？[閉まっている]

次の理由で、問題追跡システムは好きではありません。

• その中で問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。
• バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるようにするためにバグをそこに置くことができます。
• 時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間を費やしています。

ホワイトボードでポストイットを使用して問題を処理したり、顔を見ながら会話したり、重要なバグが現れたらすぐに殺したりすることを好みます。オーバーヘッドに見合うだけの価値はないと思うので、バグの履歴を追跡することはあまり気にしません。

私はここに一人ですか？問題追跡システムを使用することの欠点（または大きな利点）に関する研究（本/記事/何でも）はありますか？

その中で問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。

バグを説明することさえできない場合、どうすれば修正を開始できますか？

バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるようにするためにバグをそこに置くことができます。

これは、ソフトウェアではなくチームの問題です。

時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間がかかります。

もう一度あなたのチームとの問題を説明します。

バグ追跡ソフトウェアの目的は、チームがバグを修正する動機を与えることではなく、記録を残して、バグの原因を追跡し、バグの再発を防ぐことです。良い管理の代わりになるソフトウェアはありません。

IMOあなたの出発点は偏っています。開発者がバグの修正に失敗した場合、適切なバグ追跡ツール、ポストイット、石の彫刻などを使用してバグを追跡するかどうかに関係なく、プロジェクトは失敗する運命にあります。使用しない場合や誤用した場合は、ツールのせいではありません。（とはいえ、そこにはもちろん悪いバグ/問題トラッカーがあります...私はこの仕事にまったく不十分なツールを使用してプロジェクトに取り組んだので、私はそれがどれほど悪いことがあり得るかを知っています。しかし、良いものもあります、最小限のセレモニーとオーバーヘッドを必要とするため、関連情報に集中できます）。

ただし、開発者が注意を払い、プロジェクトのサイズが些細なものよりも大きく、プロジェクトに1人以上の開発者がいて、何らかの管理が関与している場合（これらはすべて、実際のプロジェクトではかなり一般的です） ）、すぐに次のような質問が発生します：

1. 開いているバグのうち、最初に修正する必要があるのはどれですか？（注：正しいプロジェクトでは、これは開発者ではなく、製品の所有者や管理者が決定する必要があります- まず、開発者はすべての未解決のバグを認識しておく必要があります！）
2. 未解決のバグはいくつありますか、またどの程度深刻ですか？
3. これらのどれをリリースする前に修正する必要がありますか？
4. これらの修正を計画するためにどのくらいの時間-多くの場合、以下につながる：バグを修正するために平均してどれくらいの時間がかかるか？
5. 前回のリリースでクライアントからいくつのバグが報告されましたか？
6. 誰がこれとこのバグを修正しましたか、いつ、そして何（コード/構成/データ）の修正に修正が含まれましたか？
7. 公開しようとしているリリースにはどのバグ修正が含まれていますか？
8. ...

付箋に基づいて、このような質問に[更新]を繰り返し、確実かつ効率的に[/更新]回答できますか？

はい、問題トラッカーにバグデータを入力すると、オーバーヘッドが発生します。ただし、保存されたバグデータから上記のようなレポートを検索および作成する際に節約された時間と労力によって、それ以上の効果が得られます。

あなたの方法論は、限られた数のプログラマーがいる非常に小さなプロジェクトでうまくいくかもしれません。プロジェクトが大きくなると、特に異なるコードリリースで修正が行われる場合は、異なるチーム間の調整のために問題追跡システムを持つことが非常に重要になります。複雑なプロジェクトには多くの可動部品/コンポーネントがあり、問題がスケジュールされ、修正されることを確実にすることは、問題追跡の実装の重要な部分です。

ZendのJiraの使用法について論じているこの記事や、バグ追跡システムの使用について論じているこのフランスの研究など、興味深い記事/研究がいくつかあります。

研究があるかもしれませんが、フィールドの人々の苦労して得られた経験はさらに良いです。ほとんどの問題追跡システムは、設計を推進するプロセスの影響を受けます。多くの場合、課題追跡は2つの異なるクラスのユーザーをサポートする必要があります。

1. 開発チーム
2. システムのユーザー

Cal Henderson（以前はFlickrのメンバー）は、多くの課題トラッカーのデザインと、なぜ彼がGitHub課題トラッカーを好むのかについて素晴らしい記事を投稿しています（私もそうです）。また、Garrett DimonはSifterの設計をカバーし、より効果的な問題追跡のためにプロセスを簡略化する方法を示しました。チームの問題追跡ワークフローを簡素化するために、これらの投稿またはこれらの投稿の両方からいくつかのアイデアを採用しました。

そうは言っても、それはプロセスやツールよりも人々にかかっています。私の一般的な考えは、課題追跡は、管理しなければならないこのバックログを作成する傾向があるということです。トリアージの間、人々はバグであるかどうかを合理化する可能性が高くなります。私たちのプロセスでは、それが問題であるかどうかについてバグが報告された直後に、私たちは決定を下します。その決定が行われると、バグはPivotal Trackerに入ります。ここでの違いは、優先順位付けにTrackerを使用することであり、私たちがやりたくないことを保留するペンとしてではありません。実際、Iceboxが大きくなりすぎたら、バグを含むアイテムを積極的に削除します。問題が処理する必要があるほど大きい場合は、再び発生します。

バグ履歴はほとんど必要ありません。時折、誰かがバグの症状に言及し、それがすでに処理した問題に関連しているかどうかを検索する場合があります。しかし、それはまれです。

TL; DRプロセスに焦点を当て、シンプルなツールを選び、問題が発生したらそれに対処します。

重要なバグが現れたらすぐに殺す

ここで開いているドアに侵入しているようです。重要なバグは、Issue Trackerを使用しているかどうかに関係なく、できるだけ早く「kill」されます。

• ああ、「見たとおり」の部分はかなり滑りやすいところである。あるプロジェクトでは、製品全体を廃業させる恐れのある重要なバグがありました（何がより重要なのでしょうか？）。これは非常に複雑（アーキテクチャエラー）で、修正に時間がかかることがわかっていました。顧客には、製品を落とす前に1年間の修正に同意していただき、約1年で完成しました。

課題追跡については、私はこれらをほぼ10年間使用しており、原則として、私の周りのすべてのプログラマーは追跡者とほとんど時間を費やしていません（プログラマーについて話していることに注意してください。マネージャーは別の話です）。そうではないときに（まれに）ケースを見たことがあります。これらのケースではすべて、何かがひどく壊れていました。

対面式の会話と問題の追跡に関する研究に関して、ここでもまた、ここで開かれたドアに侵入しているように感じます。課題追跡は典型的な書面によるコミュニケーションです。物事を議論するために、face2faceコミュニケーションは電話よりもはるかに効率的であることを示す多くの研究があります。電話は書面よりもはるかに効率的です。

• 実際、f2fについて尋ねると、トラッカーを使用して話し合っているように感じます（これはその目的ではありません）。その使用目的を理解するには、その名前をゆっくりと明確に綴るだけです。問題追跡システム。

バグリストが長くなる

私の経験では、上記は問題ではなく利点です。

長いバグリスト開発者は、はるか先キューと計画の修正を設定することができます。これは、可能な限り生産的です。私にとって、このようなキューを操作する場合、これは基本的にニルヴァーナです。最初のバグ-修正-行われ、第二のバグ-修正-行われ、次のバグ-修正-に行わなどなどありません愚かな中断、オハイオ州、それほど効率的F2Fでの会話、とノー痛い気晴らし純粋な流れ。

• 長いバグリストが問題であった1つのケースだけを思い出します。それは、上級管理職の馬鹿が、ほぼ毎日50〜100の山から次のバグを選択することを開発者に強制するポリシーを決定したときに起こりました。なんて無駄だ。これを彼の頭の上でエスカレーションして修正する方法を理解するまで、数か月の苦痛を要しました。
  便利なワークフローを確立できたしばらくして、「無限のバックログ」が魔法のように空になったことがわかりました。