スクラム/かんばんボードを使用する場合、従来の課題追跡の役割は何ですか？

非常に高いレベルの観点から見ると、私には一般に2種類のプロジェクト管理ツールがあるようです。

1. Fogbugz、JIRA、BugZilla、Trac、Redmineなどの従来の課題トラッカー
2. 仮想カードボード / Pivotal Tracker、GreenHopper、AgileZen、Trelloなどのアジャイルプロジェクト管理ツール

確かに、それらは何らかの方法で重なります。たとえば、Pivo​​tal TrackerタスクをJIRAにインポートできます。GreenHopper自体はJIRA課題ベースの上に実装されます。

従来の問題追跡ツールは、アジャイルプロジェクト管理を行う企業でも使用されているようです。私の質問は、なぜ彼らはそれをするのですか？また、会社で課題追跡を使用する必要があると思いますが、それについて考えているとき、なぜそれを必要とするのか実際にはわかりません。

たとえば、Trelloの開発は、最高の課題追跡ツールの1つであるFogbugzにアクセスできる場合でも、Trello自体（この仮想ウォールを参照）を使用して管理されているようです。したがって、アジャイルPMツールの1つを使用して作業の100％をアジャイルな方法で行う場合、従来の課題トラッカーは必要ないでしょうか？

チームが（少なくとも）3つの異なる方法で作業できます。チームに適したものを選択してください。

1.詳細と高レベルの概要

課題追跡を使用して、個々のタスクを追跡します。課題追跡のタスクの要約として、カードボードを使用して、主要な機能の全体像を維持します。

2.バグと機能

課題追跡を使用して、個々のバグと顧客サービス要求を追跡します。カードボードを使用して、開発中の新機能を追跡します。

3.マイルストーンソフトウェア配信と継続的なソフトウェア配信

新しい機能の大きなブロックを不規則に提供する場合（たとえば、あなたがWindowsチームで、数年ごとに新しいバージョンがある場合）、問題追跡ツールを使用します。大規模で完成したプロジェクトを一度に顧客に提供する開発プロセスに最適です（ゲーム、組み込みソフトウェア、および年次または半年ごとのリリースに基づく従来のソフトウェアを含む）。

たとえば、継続的または非常に頻繁に価値を顧客に提供するWebチームで、開発中に顧客に新機能を継続的に提供する場合は、カードボードを使用します。このシナリオでは、ソフトウェア開発プロセスはほとんど組立ラインのようであり、開始と終了のあるプロジェクトのようではありません。

簡単な答えは、従来の問題追跡ソフトウェアがバックログの管理に役立ち、スクラムボードが現在のスプリントとリリースの追跡に役立つということだと思います。

もちろん、どちらのツールを使用して両方を実行することもできますが、最終的には妥協が必要になります。

完全な開示：私はアトラシアンのGreenHopperプロダクトマネージャーであるため、少し偏見がありますが、アトラシアン以外のアジャイル開発にも長い間関わってきました。

アジャイル計画ツールまたは問題追跡ツールのみを使用することは、間違いなく実行可能です。問題は、それが準最適であるということです。私の経験では、次の理由で最適ではありません。

• 製品計画は通常、バックログのエピックおよびストーリーレベルで行われます。アジャイル計画ツールはここで素晴らしいです
• しかし、古いことわざにあるように、敵との最初の接触から生き残る計画はありません。この場合、あなたの最初のいくつかのリリースの後にあなたがしている拘束計画にフィードバックにバグ（および他のフィードバック）QAによってログに記録され、顧客、サポートなどでこれらの必要性を終わるためにそれを圧倒しません

そのため、アジャイルプランニングツールだけで十分ですが、製品が成熟し、外部からの入力が増えるにつれて、その入力を効果的に管理することがますます難しくなります。これらの外部コントリビューターの一部は、単に「管理されたアジャイルバックログ」タイプの方法でコントリビュートできません。問題を送信して先に進みたいだけです。そこで問題トラッカーを使用すると、これらの貢献者を引き込み、製品開発を継続するという継続的なビジネスをうまく管理できます。

両方のツールが必要だと思います。また、それらを統合する必要があります。そうしないと、2つの同期を維持するためにすべての時間を費やすことになります。

一部の製品は、ストーリーとタスクよりも欠陥に対してより最適化されていますが、実際には大きな違いはありません。実施された構造または必須フィールドに関してあまりにも多くのオーバーヘッドを課さない優れたアジャイルPMツールは、欠陥の追跡に簡単に使用できます。私の現在のプロジェクトでは、タスクと欠陥の両方に単一のツールを使用していますが、製品がPOSであることは別としても問題なく動作します:)

Joelの答えの 3 番目に当てはまるDoneDoneという課題トラッカーを実行します。これはバグトラッカーのより伝統的な役割です。確かに、私たちのコンサルタント会社はこれまで多くのコードを（Webサイトの形式で）不規則な間隔で配信するため、これを構築しました。

しかし、1か月前にDoneDoneユーザーベースに少しアウトリーチしましたが、かなりの数のユーザーが、より継続的なコード/リリースサイクルのためにTrelloやSprint.lyに類似したフロントエンドを要求しました。別の有用な洞察として、これらの人々の多くはQAが始まる前にDoneDoneを使用しているため、プロジェクト（または機能）がサイクル間を移動するときにすべてのデータを1か所に集めたいと考えています。

私の2セントは、すべてのデータに少しのワークフローが適用されていることです。違いは実際にはUIであり、それがチームにどのように対応するか、どの方法論および/またはプロジェクト段階にあるかです。

多くのツールは両方を実行できるように設計されていますが、問題追跡はプロジェクト管理ではありません。そのため、一方のシステムが実際に他方を置き換えることはありません。

かんばんボードは、現在の傑出した作業の素敵な概要を提供し、優先順位が一目でわかるようにします。一方、課題トラッカーを使用すると、課題をバージョン管理システムに関連付けて、より適切に機能します。かんばんバックログにあるべきすべてを記録する手段として、しかしそうでなければかんばんボードを読むのが本当に面倒になるような追加の詳細があります。

問題は、2つの概念がうまく連携し、お互いをうまくサポートしていることです。もちろん、1つのきちんとしたアプリケーション内に両方の長所を提供できるシステムがある場合、それは少し線をぼやけさせるかもしれませんが、概念はまだ合理的に分離されたままです。

明確な答えがあるかどうかわからないので、自分の経験を報告しています...

年間、私は完全などFogBugzの、Jiraの、Tracの、のように、真のバグ管理システム上で販売されていたしかし、私は最近、我々はアジャイル（本当にだけではない、アジャイルされました仕事やってアジャイルを）。バグや便利なアイテムの長い歴史的なリストはありません。

このようなツールはまったく使用できません。重要なことはすべて、私たちが非常に迅速に行うことです。それほど重要ではない何か、まあ、何がポイントですか？

毎日最高の価値を提供していることを知っている一方で、時間がないとわかっているものの膨大なバックログがないことは非常に自由です。