スクラム/カンバンボードを使用する場合の従来の課題追跡の役割は何ですか？
非常に高いレベルで見ると、私には、一般的に2種類のプロジェクト管理ツールがあるように見えます。
- Fogbugz、JIRA、BugZilla、Trac、Redmineなどの従来の問題トラッカー.
- 仮想カードボード/ Pivotal Tracker、GreenHopper、AgileZen、Trelloなどのアジャイルプロジェクト管理ツール.
もちろん、それらは何らかの方法で重複しています。 Pivotal TrackerタスクはJIRAにインポートできます。GreenHopper自体はJIRA課題ベースの上に実装されます。しかし、これら2つのタイプのツールの方向の違いはまだ見られると思います。
従来の課題追跡は、アジャイルプロジェクト管理を行う企業でも使用されているようです。私の質問は、なぜ彼らはそれをするのですか？また、会社では課題追跡を使用する必要があると感じていますが、それについて考えているとき、なぜそれが必要なのかわかりません。
たとえば、Trelloの開発は、Trello自体（ this virtual wall を参照）を使用して管理されているようですが、Fogbugzにアクセスできます。したがって、アジャイルPM？のツールの1つを使用してアジャイルな方法で作業を100％実行する場合、従来の課題追跡は必要ないかもしれません。
チームが機能する方法は（少なくとも）3つあります。チームに適したものを選択してください。
1。詳細とハイレベルの概要
課題トラッカーを使用して、個々のタスクを追跡します。カードボードを使用して、主要な機能の全体像を、課題追跡のタスクの概要として維持します。
2。バグと機能
課題トラッカーを使用して、個々のバグとカスタマーサービスのリクエストを追跡します。カードボードを使用して、開発中の新機能を追跡します。
。マイルストーンソフトウェア配信と継続的ソフトウェア配信
新しい機能の大きなブロックを不定期に提供する場合（たとえば、Windowsチームで数年ごとに新しいバージョンがある場合）は、課題追跡を使用してください。これは、大規模な完成したプロジェクトが顧客に一度に配信される開発プロセスに理想的です（ゲーム、組み込みソフトウェア、および年次または半年ごとのリリースに基づく従来のソフトウェアが含まれます）。
たとえば、顧客に価値を継続的または非常に頻繁に提供するWebチームで開発されている新機能を顧客に継続的に提供する場合は、カードボードを使用します。このシナリオでは、ソフトウェア開発プロセスはほとんど組み立てラインのようなものであり、最初と最後のプロジェクトのようなものではありません。
簡単な答えは、従来の問題追跡ソフトウェアはバックログの管理に役立ち、スクラムボードは現在のスプリントとリリースの追跡に役立つということです。
もちろん、どちらのタイプのツールを使用して両方を行うことも可能ですが、最終的には妥協する必要があります。
完全な開示：私はアトラシアンのGreenHopperプロダクトマネージャーなので少し偏見がありますが、アトラシアン以外でもアジャイル開発に長い間関わってきました
アジャイル計画ツールまたは問題トラッカーのみを使用することは、確実に実行可能です。問題は、それが次善であるということです。私の経験では、それは次の理由で最適ではありません：
- 製品計画は通常、バックログのエピックおよびストーリーレベルで行われます。アジャイル計画ツールはここで素晴らしいです
- しかし、古いことわざが言うように、最初の敵との接触に生き残る計画はありません。この場合、最初の数回のリリース後、あなたはboundになり、QA、顧客、サポートなどによってログに記録されるバグ（およびその他のフィードバック）が発生します。これらは、計画にフィードバックする必要がありますが、それを圧倒する
そのため、アジャイル計画ツールだけを使用することは素晴らしいことですが、製品が成熟して外部入力が増えると、その入力を効果的に管理することがますます難しくなります。これらの外部コントリビューターの一部は、「管理されたアジャイルバックログ」タイプの方法でコントリビュートできず、問題を送信して次に進みたいだけです。そこで問題トラッカーを使用すると、これらのコントリビューターを関与させて、製品開発を継続するという進行中のビジネスを正常に管理できます。
両方のツールが必要だと思います。それらを統合することも本当に必要です。そうしないと、2つを同期させるためにすべての時間を費やすことになります。
一部の製品は、ストーリーとタスクに対して欠陥よりも少し最適化されていますが、実際には大きな違いはありません。優れたアジャイルPM強制された構造または必須フィールドの点であまりオーバーヘッドをかけないツールは、欠陥追跡に簡単に使用できます。現在のプロジェクトでは両方のタスクに単一のツールを使用していますそして欠陥そしてそれはPOSである製品を除いて大丈夫です:)
DoneDone と呼ばれる課題追跡を実行します。これは、＃ Joelの回答 に適合する＃3-バグ追跡のより伝統的な役割です。確かに、私たちのコンサルタントが歴史的に多くのコード（ウェブサイトの形で）を不定期に配信しているので、私たちはそれを構築しました。
1か月前にDoneDoneのユーザーベースに少し手を差し伸べましたが、かなりの数のユーザーがTrelloやSprint.lyと同様のフロントエンドを要求して、コード/リリースサイクルを継続しています。もう1つの有用な洞察は、QAが始まる前にこれらの人々の多くがDoneDoneを使用しているため、プロジェクト（または機能）がサイクル間を移動するときに、すべてのデータを1か所に集めたいということです。
私の2セントは、少しのワークフローが適用されたすべてのデータです。違いは、実際にはUIであり、それがどのようにチームに対応するか、およびその時点での方法論やプロジェクトの段階に応じて異なります。
多くのツールは両方を実行できるように設計されていますが、問題の追跡はプロジェクト管理ではありません。したがって、一方のシステムがもう一方のシステムを実際に置き換えるわけではありません。
カンバンボードは、現在の優れた作業の素敵な概要を提供し、優先順位が一目でわかるようにします。一方、課題トラッカーを使用すると、問題をバージョン管理システムに結び付けることができ、より効果的に機能します。かんばんバックログにあるべきすべてのものをログに記録する手段として。ただし、それ以外の場合は、かんばんボードを読むのが本当の混乱になります。
重要なのは、2つの概念が連携して機能し、お互いを適切にサポートすることです。もちろん、1つのきちんとしたアプリケーションの内部で両方の世界のベストを提供できるシステムがある場合は、少し線がぼやけるかもしれませんが、概念はまだ合理的に分離されたままです。
明確な答えがあるかどうかわからないので、私の経験を報告しています...
何年もの間、私はFogBugz、Jira、Tracなどの真のバグ追跡システムで完全に売られていました。しかし、最近、doingアジャイル）。バグの履歴リストや、持っていくべきアイテムはありません。
そのようなツールを使用するだけでは意味がありません。重要なことは何でもすぐにできるようになります。それほど重要ではない何か、まあ、ポイントは何ですか？
私たちには、実行する時間がないことがわかっているものの膨大なバックログがないと同時に、毎日最高の価値を提供していることを知っていることは、かなり解放されます。