Bugzillaでユーザーストーリーを実装する方法は？

Question

私の仕事では、いくつかの人が集まり、Agileのソフトウェア開発/プロジェクト管理の原則を実装することのメリットを分析することを目標としています。

開発者として、私はユーザーストーリーで大きな利益を得ています。現在のリリースの段階を監視し、将来のリリースを計画するために使用できる情報ラジエータを組み込むことを検討しています。私はこのプロセスにユーザーストーリーを使用したいと思います。

現在、問題追跡にBugzillaを使用しています。ほとんどのリリース計画は、このシステムのバグを使用して行われます。おそらくBugzillaの使用は変更されません。適切なコスト（$ 0）で必要なもののほとんどを提供します。

懸念事項の1つは、ユーザーストーリーとバグのマッピングです。リリース管理は現在、バグ番号を使用して行われています。問題は、1つのユーザーストーリーに3つのバグが含まれている可能性があります。

1つのユーザーストーリーに複数のバグが報告されているシナリオでは、ユーザーストーリーバグを作成し、そのストーリーを構成する子バグの依存関係を設定します。私はこれが複雑すぎて、ステークホルダー、開発、QAの間で混乱を招く恐れがあります。また、Bugzillaをかなり混乱させます。

誰もが既にこの道を下っていますか？もしそうなら、あなたは何をしましたか？私はBugzillaのユーザーストーリーのアイディアを放棄するべきでしょうか？よりシンプルなソリューションはありますか？

どのような考えにも感謝します。

Answer 1

以前はBugzillaで同様のことをしていましたが、私が見つけた解決策は階層的な「ストーリーバグ」などを実装することではありませんでした。私たちは混乱の原因となるだけでなく、私たちが望んでいたほど複雑すぎると決めました。私が以前に使った解決策は、バグの説明にUser Story番号を入れるだけでした。参照を簡単にするために、そこにリンクを投げることもできます。ちょっとしたパッチワークですが、うまくいきます。

Answer 2

あなたのユーザーストーリーが複数のバグケースを必要とする場合は、大きすぎます。必要な機能を十分に抽象化すれば、ユーザーストーリーを小さなストーリーに分割することができ、ストーリーごとに1つのケースしか必要とせずに、その方法を計画して進めることができます。

私たちは、ケースからユーザーストーリーの公式（wiki）ドキュメントへのリンクを使用して、@McWafflestixというアプローチを使用しようとしましたが、小さなユーザーストーリーの作成が優れていることがわかりました。できるだけ抽象的に実装されているため、優れたテスト容易性とコードの保守性を提供するため、より優れたアプリケーション設計です。

Answer 3

Bugzillaでの依存リンクの使用がストーリートラッキングに使用されているかどうかにかかわらず、ストーリーにキーワードを使用することを強くおすすめします。私たちは「物語」を使用します。キーワードを使用すると、製品ツリーの不具合対バグを簡単に追跡できる柔軟性が得られます。私はまた、Bugzillaインストールで時間トラッキングの使用をお勧めします。たとえ時間が物語にしか追跡されないとしても。