私の開発チームは100％成長しました（1人の開発者から2人に）。私の新しいコホートは、バグ追跡ソフトウェアに投資したいと考えています。このような小さなチームにとって、このようなソフトウェアには利点がありますか？

すべての「はい」の答えは、アイデアを支持するのに大いに役立つと思います。しかし、私は決定がいくつかの質問に基づいているという考えを捨てるつもりです：

• チームとしてどのようにコミュニケーションを取りたいですか？ 2人の開発者がいるので、チームになりました。どのようにコミュニケーションを取りたいですか？多数のアジャイルチームが直接議論し、ホワイトボードのスケッチを作成します。しかし、特にそれがしばらくの間優先順位リストに載らないバグである場合、彼らは物事を書き留めるまで行きます。
• 顧客とどのようにコミュニケーションを取りたいですか？これに対する答えはわかりませんが、バグ（またはバージョンリリースドキュメントの修正されたバグ）を公開する理由がある場合は、最終的にそれらを書き留めることになります。同様に、低ストレスのバグ管理システムを選択し、それを行うことができます。
• 歴史を保存することに価値はありますか？ 答えは「今はない」かもしれませんが、将来的にはバグの傾向を確認して、ユーザーが最も問題を抱えている場所、またはチェックに時間を費やすことができる場所を確認したいと考えています。メジャーリリースの前にレビューし、バグ追跡システムを入手します。履歴に関することは、記録が必要な日は、記録の保持を開始すべき日ではないということです。

IMO、これらの質問への答えは、製品がどこに行くのか、チームをどのように成長させたいのかについての詳細であり、「2人=バグ追跡システムの理由」についてではありません。より大きな問題は、おそらく「構成および管理する時間と購入コストに見合うバグ追跡システムですか？」です。

1、ただし痛みがない場合のみ。たとえば、GitHubには、小規模なチームに十分な機能を備えた非常にシンプルで使いやすい課題トラッカーがあります。Bugzilla、Tracなどは優れていますが、使用する前にすべてハードウェア、インストール、構成が必要であり、メンテナンスは間違いなく非ゼロの費用です。

バグ追跡ソフトウェアを初めて使用したとき、私たちは非常に小さなチームを持っていましたが、それを修正する必要があると考えていたものがなんとかして修正されなかったことに驚きました。チームの規模に関係なく、まったく価値があります。

はい。千回はい。

バグ追跡の観点からではなく、チケットの追跡と考えてください。

チケットですべてのタスクを見ることができることは大きな利点があります。タスクの履歴を1か所に保存できます。誰がいつ作業したかを知っています。タスクの何日に何が完了したかを言うのと同じくらい詳しく説明できます。

バグ追跡では、すべてのバグを1か所に配置して、完了したバグと進行中のバグを追跡できます。

それは物事をもっと良く管理するのに役立ちます。

1人以上のチームでそれをする価値があります。

正式なソフトウェアソリューションを購入するかどうかに関係なく、バグ/機能追跡システムを使用することになります。メモ帳にある場合もあれば、付箋紙である場合もあれば、コードの上部にあるコメントのブロックにある場合もあります。ただし、ランダムに開発しているのでない限り、To Doリストをどこかに書き留めることになります。チームとともに成長できる、より組織化されたシステムを使用してみませんか？

また、検討する価値があります：バグトラッカーの多くは、非常に小さなチーム（1〜2）が無料で使用できるため、利益のために大きな費用が発生するわけではありません。

チームのすべてのメンバーがいる限り、バグ追跡ソフトウェアは必要ありません。

• 完璧な写真の記憶を持ち、
• チームの他のすべてのメンバーと考えを同期できます。

簡単な答えはイエスです。

いくつかの理由：

1. 特定のバージョンに対して見つかったバグを記録する機能。
2. どの（既知の）バグがまだ修正されていないかを知る能力。
3. 再び発見されたバグを修正した人を追跡します。
4. 開発者の売上高-ことわざのバスにぶつかったとしても、知識の伝達を可能にします。

あなたはおそらくあなたがセットアップ/管理するのにそれほど時間がかからない何かを見たいと思うでしょう。また、ソース管理と統合する機能を含むものを探すことをお勧めします。

この答えは、引数のYES側に重みを追加することです。

私はほとんど1つのチームです。SVN統合と一緒に問題追跡（redmine）を広範囲に使用します。

それは本当に素晴らしいです、私はそれなしで夢中になります。私は物事を忘れてしまうので、私の品質は低下します。

生産性ツール：

• まともなIDE
• 問題追跡
• ソース管理

問題追跡; それなしで家を出ないでください

3未満の場合は、おそらくgoogle docsスプレッドシートでうまくいくでしょう。しかし実際には、Bugzillaなどをどこかにインストールするコストはプログラマーのコストに比べてささいなものなので、それを実行する方がましです。（プラス7に成長すると、既にそこにあります）

1つのチームでさえ、メモのテキストファイルであれ、本格的なソフトウェアであれ、何らかのバグトラッカーの恩恵を受けることができます。2人の開発者には、お金ではなく、バグ追跡システムのセットアップに時間をかけることをお勧めします。プロジェクトによっては、バグを紙に書き留めたり、共有オンラインドキュメントでリストを維持したり、TracやBugzillaなどの無料のバグ追跡ソフトウェアを使用したりすることで問題なく取得できます。Fogbugzは、45日間の無料トライアルとしても利用できます。

はい。

どうにか追跡する必要があります！

問題は、開発者の数ではなく、バグの数です。いくつかのバグを処理する場合、Excelシートで管理できますが、それでも最適ではありません。

define benifetがあります-個人プロジェクトでもバグ追跡ソフトウェアを使用しています。バグの追跡だけでなく、「TODO」や機能要求の追跡にも役立ちます。

自分で作業するときはどこでもバグを使いました。ソースと一緒にバグ情報を保持することにより、DVCSで機能します。中央サーバーを必要としないため、オーバーヘッドが非常に低くなります。欠点は、新しいバグをタイムリーに伝播させるために、どのブランチに入力するかを注意する必要があることです。チーム全体のステータスを追跡するよりも。

使い始める

使用し始めたばかりであれば、バージョン管理ソフトウェア、あるいは分散バージョン管理のように、練習の便利さを実感し始めるでしょう。

開発の成熟度

あなたが100人または1人のチームを持っているかどうかは関係ありません。私は自分と自分だけのためにバグ追跡と分散バージョン管理（ローカルコミットのために非常に理にかなっています）を使い始めましたが、すでに別のレベルで感じましたが、それだけで、私は自分の仕事を別のレベルで管理することができました...それ以上の労力をかけずにスケールできるレベルまで。

トラッカーを使用すると、問題を予測して作業の優先順位を設定できます。バグ/問題トラッカーは、バグ/問題だけでなく、プロジェクト管理用でもあります。

私にとっては、それはソフトウェアだけでなく、それを回るプロセスです。テストマネージャーとしての日々の仕事では、私は基本的に1つに住んでおり、次のような利点があります。

これは、2人以上のテスターと3人以上の開発者で非常にうまく機能します。

開発者のバグ修正作業の管理

開発者の「バグキュー」を積極的に管理して、割り当てられた作業量を管理し、チーム全体でバグ修正作業のレベルを割り当てます。

何が修正され、何が修正されないかを決定する

毎日のプロセスで新しいバグをトリアージすることは、あなたが何を修正し、何を修正しないかだけでなく、いつ修正するかに集中するのに役立つ素晴らしい方法です。プロジェクトの初期段階では、すべてを修正する必要があります。最後に、ショーストッパーのみを修正します。バグ追跡ツールはそのために最適です

メトリックが必要な場合

私にとって大きなことはメトリクスです。つまり、バグの発見と修正の傾向、コードのバグのある領域、テスターがバグを見つけて再テストする速さを表示できるようにする場合です。バグ追跡システムの時間です。

1人のチームメンバーでバグトラッカーが必要になるという一般的な意見に同意します。1人または2人の実際のユーザーがいる場合は必須と見なしますが、最初のリリースのかなり前に重要です。

個人的には、ソース管理とバグ追跡の両方で化石が好きです。これは、バグトラッカーとWikiにうまく統合された完全な低セレモニー分散SCMです。また、単一の実行可能なインストールであり、広く移植可能で、内部WebアプリケーションをGUIとして使用します。そのホームページは、実際にはほぼ完全に化石のコピーによって提供されています。

リビジョン管理と密接に統合されたトラッカーを使用すると、変更をチケットに簡単にリンクし、リビジョンと同じタイムラインビューでチケットの更新を確認できます（およびWikiページの編集）。

はい、はい、はい、はい！問題を追跡、優先順位付け、管理できることが、ソフトウェア開発を成功させるための鍵です。1人で、スプレッドシートを使用して（ほとんど）古いソースツリーを圧縮できます。1人の開発者をプロジェクトに追加すると、物事が劇的に変わります。突然、問題の追跡とソースコード管理が必要になります。

StackExchangeの親会社であるFogCreekについて誰も言及していないことに驚いています-彼らのFogBugzソフトウェアは私が今まで使った中で最高の問題追跡アプリです。特に、ホストされたソリューションを使用する場合、高速、低抵抗、および手頃な価格。以前は無料のホストトライアル版を使用していましたが、これには2つのユーザーライセンスが無料で使用されていたと思います。

こちらが私の2セントです。

バグ追跡のためにgoogle-docスプレッドシートを使用するだけで、編集または表示したい人を招待できます。無料なので、あまり投資はしません。私はただバグにそこにすべてのタスクを追跡します。

また、WebホストでSVNを実行しますが、これはWebホスティングに追加コストを追加しません。

一部のクライアントは、混乱のない、または他のそのようなプロジェクト管理/バグ追跡ソフトウェアの使用を必要としましたが、私は上記の無料のソリューションを好むでしょう。

ミニマルなバグトラッカーをお持ちの場合は、1つのチームでも有用だと思います。友達のプロジェクトサイトQuokForgeの1つで、基本的に各プロジェクトにRed Mineインスタンスを提供しています。私の意見では、Red Mineには優れたバグトラッカーがあります（少し奇妙な場合もあります）。つまり、1つのフィールドにテキストを入力するだけでバグを報告できるためです。FogBugzも使用したことがあります。2人以下の場合は無料です。そして、それは同じ単純さを可能にし、1つのテキストフィールドのみに記入することによりバグを提出します。（また、非常に有用なグラフやその他のものも提供します）

基本的に、バグ報告を記入するために30分の時間を確保する必要がある厳密で正式なプロセスをバグ報告にしないでください（BugZilla、私はあなたを見ています）。これは、人々がそれを使用しないことを意味します。

最後に、バグリストがある（各バグに含まれるテキストがすべて約50文字であっても）ことは非常に価値があります。「うーん、リリース1.0になりました。最後のバグを修正したと思います。」また、マネージャーが実際に何かをしているのを見るのも素晴らしいです:)。チームでは、両方の頭の中で精神的なTo Doリストのセットを保持しようとしているわけではないので、より価値があります。そして、それは「あなたはそれを修正しましたか（本当に悪いセキュリティバグ）？ええと、そうだと思います。では、1.0をリリースしましょう。」

また、機能を追跡することも大好きです。これはもう少しオプションですが、頭の中にtodoリストを保持するという精神的なタスクをオフロードできるという利点があります。

また、ジョエルがそれについて言っていたことを参照してください

その数に達しました... 2！あなたが唯一の開発者であっても、バグ追跡ソフトウェアを使用する利点を見ることができます...開発者の総数が1の場合、バグ追跡ソフトウェアを使用しなくても問題ありません。

ただし、開発者が2人以上いるとすぐに、バグ追跡ソフトウェアを使用しない理由は1つではなく、1つではありません。

はい。また、推奨事項はbitbucket http://www.bitbucket.orgです。これらは、無料のバグトラッキングとMercurialの無料のプライベートリポジトリを提供します。

1。その場合は、To Doリストのようなものです。

投資するということは時間を意味すると思います。無料のバグ追跡システムはたくさんありますが、2人のチームにとっては問題ないはずです。より大きなチームができるまで、私は商用製品を検討しませんでした。

あなたの質問はあなたの誤解を浮き彫りにしたと思います。バグ追跡が必要なのはチームではなく、製品です。

それでは、バグ追跡はソフトウェアで行う必要がありますか？まあ、それは助けになると思いますか？

次の2つの条件が存在する場合、価値がない場合があります。

1. 問題の寿命は短いです。この場合、単純なタスクボードで十分です（他の多くの理由でワークフローを視覚化するのが賢明だからです）。ただし、問題をすぐに解決できない場合は、f.ex。バグをすばやく修正すると、問題を追跡するのに役立ちます。
2. コードの変更は、自動化されたテストとともに生きたドキュメントとして文書化されます。つまり、バグと修正は、それらが表示されたときに失敗したテストで文書化され、修正後は合格したテストが回帰テストになります。-機能の変更は、自動化された受け入れテストで記録されます（f.ex. FitNesseやCucumberなどのBDDツールを使用）。このようなドキュメントは、JenkinsなどのCIサーバーから簡単に入手できるはずです。

1または2が存在しない場合、問題追跡の恩恵を受けます。

番号

バグを追跡せず、修正します。

重要なのはチームの規模ではなく、バグを修正する前にリスト上のバグをどれだけ確認するかです。

Agile / TDDを使用している場合、バグリストは短くなり、リストにバグが長く残ることはありません。その場合、追跡システムで十分です。