バグ/問題を追跡するために共有スプレッドシートを使用しないことをどのように支持しますか？

当社では、開発者は適切なバグ追跡ツールを使用して、アプリケーションの問題を管理したいと考えています。ただし、管理者は共有スプレッドシート（​​以前は共有Excelファイルでしたが、現在は同時アクセスを可能にするWebベースソリューションのスプレッドシート）の使用を主張しています。

彼らの主張は、スプレッドシートを使用すると、プロジェクトの状態をより高レベルで把握できるため、開いているバグの数を一目で確認できるためです。また、これにより、各バグに取り組んでいる人を確認し、それらをすべて閉じるのに必要な時間の見積もりを取得できます（開発者は、作業中のバグの時間見積もりを記入する必要があるため）。

理解できるように、これは開発者にとって実際に使用するのは実際的ではありません（バグ追跡ソフトウェアは、ある理由で発明されました）。では、開発者の作業を容易にするためにバグ追跡ソフトウェアをどのように提唱できますか？

ボーナスとして、管理者が高レベルのビューでフィードバック（バグのオープン数、それらに取り組んでいる人、時間の見積もり）を取得できるようにするソフトウェアをお勧めしますか？

では、開発者の作業を容易にするためにバグ追跡ソフトウェアをどのように提唱できますか？

この声明を考えると：

スプレッドシートを使用すると、開いているバグの数を一目で確認できるため、プロジェクトの状態をより高レベルで表示できます。

「リアルタイム」で（またはできる限り近くで）スプレッドシートを効果的に作成できるレポートツールを備えたシステムを検討する必要があります。これらのいずれかを見つけた場合、開発者に「適切な」システムを使用させることは、彼らが興味を持っているデータが（できれば）より正確で最新のものになることを意味することを説明します。

スプレッドシートのどのバージョンが最新ですか？そのスプレッドシートは誰が持っていますか？

まともなバグトラッカーは、スプレッドシートでできることだけを行います：

• 何かが変更された場合、関係者にメールを送信します
• 最新の情報の単一の正規ソースを提供します
• プロジェクトの状態の高レベルのビューを提供するために、要約レポートを許可します

私の個人的なプロジェクトでは、Mantisを使用しています（セットアップが本当に簡単だからです）。WorkはMercurial統合でTracを使用します。

Mantisは、すぐに開いた/閉じた/割り当てられたバグの数などを提供します。ほとんどのバグトラッカーが提供すると思います。私は時間を見積もることについて知りません。Trac（またはここの職場）には時間の見積もりがあり、たとえばマイルストーンごとに見積もりを合計するカスタムレポートを作成するのは簡単です。

他の皆の答えは良いです。私にはもう1つの側面があります。

スプレッドシートのセキュリティについてはどうですか。経営者は、ランダムな開発者が誤ってCTRL + A、DELETEボタンを押して、本当に混乱させることを心配するべきではありませんか？適切なバグ追跡システムは、この種のデータ破損を許可しません。そして、それは悪意さえ説明しません。特定の開発者がより多くのクレジットを必要とし、すべての不具合修正を自分に再割り当てし始めた場合はどうなりますか。実際のシステムには、そのようなことが目立つ監査証跡があります。スプレッドシートはそうしません。

管理者に要件が満たされることを示す必要があります。

彼らの主張は、スプレッドシートを使用すると、プロジェクトの状態をより高レベルで把握できるため、開いているバグの数を一目で確認できるためです。また、これにより、各バグに取り組んでいる人を確認し、それらをすべて閉じるのに必要な時間の見積もりを取得できます（開発者は、作業中のバグの時間見積もりを記入する必要があるため）。

そのため、ダミーシステムをセットアップし、スプレッドシートを使用するよりもこの情報を取得できることをデモで示します。

これまでのところ、誰もが同様の適切な応答を考え出します。まだ話されていない重要な側面が1つあります。バグを追跡し、クラックをすり抜けないようにするには、次の2つが必要です。

• 概要と詳細の両方の優れたレポート-これは後で検索できます
• 誰もが最新のコピーがどこにあるかを知る必要があります。

Excelスプレッドシートを使用することを提唱するほとんどすべての環境では、全員のマシンにこのスプレッドシートの異なるコピーがあり、どれも同じではありません。これにより、進捗状況をレビューするプロセスは非常に難しく、逆効果になります。

Trac、RedMine、JIRA、Mantisなどの集中サーバー、またはこれらの問題の両方を処理するものが必要です。その時点で、それはあなたの会社のニーズに最も適合するものの問題です。環境によっては、これらのツールはバージョン管理システムと同様にIDEに統合できます（Eclipseにはこの機能があります）。これにより、割り当てられたバグを簡単に処理できます。

私はあなたの環境を知りませんが、Visual StudioユーザーにはTFSを強くお勧めします。ソース管理と問題追跡の両方を統合し、完全なレポート機能を備えています。また、権限の層、完全な履歴追跡（つまり、誰がいつバグを更新したか、セットアップした場合はその理由）を提供し、「バグ」と「問題」と「拡張」などを区別できます。 Visual Studio IDEと完全に統合します。バグとチェックインされたコードを結び付け、特定のビルドに結び付けることができます。そしてもっとたくさん。

私はたくさんの異なるソース管理システム（VSS、SVN、TFS ...）とたくさんのバグ追跡システム（カスタムプロプライエタリシステム、トラッカー、SharePoint、そしてはい、Excelも）を使用しましたが、お金のためです（そしてそれは変更のかなりの部分）、TFSはお金と時間に投資する価値があります。

はい、Excelにエクスポート（およびExcelからインポート）できます。

適切な課題トラッカーへの移行を販売するために、現在のシステムで管理者が抱えている課題を見つけて（「それなら...」と思われます）、かゆみを掻くことができないかどうかを確認する必要があります彼らのために。

経営陣の議論を読む

彼らの主張は、スプレッドシートを使用すると、プロジェクトの状態をより高レベルで把握できるため、開いているバグの数を一目で確認できるためです。また、これにより、各バグに取り組んでいる人を確認し、それらをすべて閉じるのに必要な時間の見積もりを取得できます（開発者は、作業中のバグの時間見積もりを記入する必要があるため）。

私はそれらのすべてのとで合意したすべての単一の1がで満たされJIRA（私はそれが私が使用するものですので、私は他の価値のある候補があると確信しているだけJIRAに言及します）

JIRAのようなツールを使用すると、現在のセットアップのすべての利点が保持されるだけでなく、多くの新しい利点も得られることを強調する必要があります。

ストーリータイム。

数ヶ月前、私は一週間の休暇から戻ってきて、会社全体が首をかしげるようになりました。開発部門の別のセクションが数か月にわたって取り組んでいたプロジェクトは、急を要する急務の優先事項であり、チーム全体が作業を解き放ちました。その日の会議で、会社の所有者は、その日のいくつかのピースをノックアウトし、翌日は残りの部分をノックアウトするように頼みました。

6週間後、ほぼノンストップの仕事と睡眠のサイクルを経て、ようやくその物を届けました。

「終了」の測定基準は、クライアントからのフィードバックがなくなったことです。新しいエキサイティングなことは、これまでになかったフィードバックの各バージョン（電子メールで配信されます）で発生し、彼らが言ったすべての言葉はすぐに仕様の一部でした"）。

ある夜遅くに、電子メールやチェックマーク付きの印刷物によるバグレポートの管理で、HAD ITがまったくおかしくなりました。テストサーバーにMantisをインストールし、セクション用に受け取ったばかりのフィードバックドキュメントをロードしました。私はマネージャーをユーザーとして設定し、問題を解決したときにマネージャーからメールを受信できるようにしました。

約6時間以内にチーム全体が参加しました。PMはクライアントのメールをMantisにフィルタリングし、開発者は課題リストを主張して作業していました。さらに良いことに、彼らはシステム内で明確化とコミュニケーションを要求することができ、その結果、各アイテムに関する詳細のペーパーレスの紙の証跡ができました。

翌日、彼らは私にプロジェクトの残りの部分をTech Leadに依頼しました。ライブ手g弾を渡されるようなものでしたが、私はそれを受け取って走りました。2週間後、私たちはようやくクライアントの鼻輪を引っ張る能力を使い果たし、サイトを実稼働状態にしました。Mantisは現在、バグを管理する方法であり、プロジェクトの最初から機能要求を処理する方法になる可能性があります。

TL; DR：自分でインストールして、自分のものに使い始めましょう。それだけで価値を証明しましょう。

ところで、これは私がバージョン管理に関して従っているのと同じポリシーです。私のマネージャーはファイルのマージを信頼していないため、ロックが必要なポリシーの下でSubversionを使用しています。それは問題ありませんが、SVNプロジェクトをチェックアウトした後、開発用に自分で使用するために、すぐにローカルgitリポジトリを作成します。

Atlassian Jiraを使用しています。

このような多くのレポートが利用可能です：

管理者がスプレッドシートを開くと、必要なすべてのレポートデータが選択したアプリから更新されるスプレッドシートを作成する必要があります。動作させる場合、引数はありません。

ネットワーク共有上のバグ追跡スプレッドシートで問題が発生する可能性があるもの：

• 誰かがそれを開いたままにして、ワークステーションをロックして昼食に行くとき、他の誰もそれを編集できません。
  • 「明らかな」回避策は、書き込み用に新しいバージョンを保存することです。これはブランチを作成します-そして、Excelはマージが苦手です。誰かの仕事は失われます。
• ドキュメントは非表示の行で保存される可能性があり、問題は数週間見落とされます。
• 何でも削除でき、履歴の追跡はわずかです。「先週入力した詳細な問題分析はどうなりましたか？」
• 「制限付き」フィールドに値を追加するのは簡単です。「このバグの重大度はどのようにして「Epic Fail」とマークされましたか？」
• カットアンドペーストは式を上書きします。計算は簡単に定数になります。

私はこれをすべて経験しました。そして、私たちはまだ何とか配達しました...それはたった3か月遅れで、予定外の残業時間が何千もかかりました。

"それは無料です！" 通常、かなり良い議論です。Pivotal Trackerは無料で、インストールの必要はありません。また、低スプレッドシートで可能なものよりも簡単に、マネージャーに物事の優れた高レベルのビューを提供できます。

編集：

私の悩みの種は、Pivo​​tal Trackerがこれ以上長く無料ではないということです。:(