10

私の職場の数人が集まり、アジャイル ソフトウェア開発/プロジェクト管理の原則を実装する利点を分析することを目的としたグループを結成しました。

開発者として、ユーザー ストーリーには大きなメリットがあります。現在のリリースの段階を監視し、将来のリリースを計画するために使用できる情報ラジエーターをまとめることを検討しています。このプロセスにユーザー ストーリーを使用したいと考えています。

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

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

1 つのユーザー ストーリーに対して複数の報告されたバグがあるシナリオでは、ストーリーを詳しく説明し、そのストーリーを構成する子バグへの依存関係を設定するユーザー ストーリー バグを作成するという 1 つのアイデアがあります。これが複雑になりすぎて、利害関係者、開発、および QA の間で混乱が生じるのではないかと心配しています。また、Bugzilla をかなり混乱させます。

誰かがすでにこの道を進んでいますか？もしそうなら、あなたは何をしましたか？Bugzilla でのユーザー ストーリーのアイデアを放棄するようプッシュする必要がありますか? もっと簡単な解決策はありますか？

任意の考えをいただければ幸いです。

4

3 に答える 3

3

以前、Bugzilla で同様のことを行ったことがありますが、私が見つけた解決策は、階層的な「ストーリー バグ」などを実装しないことでした。それは混乱を招き、私たちが望んでいたものには単純に複雑すぎると判断しました。私が以前に使用した解決策は、単純にバグの説明にユーザー ストーリー番号を入れることでした。逆参照を容易にするために、そこにリンクを投げることもできます。少しパッチワーク的ですが、うまく機能します。

于 2009-06-08T18:49:22.710 に答える
2

Bugzilla での依存リンクの使用がストーリーの追跡に使用されるかどうかに関係なく、ストーリーにキーワードを使用することを強くお勧めします。「物語」を使っています。キーワードを使用すると、製品ツリー内のストーリーとバグを簡単に追跡できます。また、Bugzilla のインストールでタイム トラッキングを使用することをお勧めします。時間がストーリーでのみ追跡されている場合でも。

于 2011-02-26T04:29:27.330 に答える
2

ユーザー ストーリーに複数のバグ ケースが必要な場合、それらは大きすぎます。必要な機能を適切に抽象化することで、ユーザー ストーリーをより小さなストーリーに分割し、ストーリーごとに 1 つのケースのみを必要とし、そのように計画して進めることができます。

ケースからユーザーストーリーの公式（wiki）ドキュメントへのリンクを使用して、 @McWaffflestixが説明するアプローチを使用しようとしましたが、しばらくして、ユーザーストーリーを小さくする方が良いことがわかりました-それはより良いアプリケーションにもつながりますこれは、各ユーザー ストーリーが可能な限り抽象化されて実装され、コードのテスト容易性と保守容易性が向上するためです。

于 2009-06-08T18:59:26.373 に答える