0

プロセス レベルでのユーザー ストーリーの受け入れ基準の変更に、人々がどのように対処しているかを知りたいと思っています。

例：

機能 XYZ の受け入れ基準を含むユーザー ストーリーを作成します。そのユーザー ストーリーは、リリース 1.0 のスプリントで実装されます。しばらくして 1.2 リリースの製品所有者は、受け入れ基準を変更することを望んでいます (たとえば、30 秒ではなく 1 分間のタイムアウト)。

この変化をどのように処理しますか? 元のユーザー ストーリーのステータスはどのように変化しますか? 私たちは JIRA/JIRA アジャイルを使用しています。たとえば、閉じたユーザー ストーリーを再開して、新しいスプリントでそれらに取り組んでいるかどうかを聞くことに特に興味があります。

Confluence を使用して製品仕様を記述し、PS のユーザー ストーリーはクエリを介して JIRA から直接読み込まれます。元のユーザー ストーリーの受け入れ基準を変更して再度開く場合、バージョン 1.0 の製品仕様が変更されないようにするにはどうすればよいでしょうか?

編集：

プロセスについてさらに情報を追加する必要があります。すべてのユーザー ストーリーには、受け入れ基準と同様に、これらの基準をテストするために使用できるいくつかの手順があります。これらの手順は、すべての製品仕様が適切に実装されていることを確認するために使用される検証/テスト プロトコルを生成するために使用されます。

つまり、ユーザー ストーリーへの変更は、データが jira クエリを介して読み込まれるため、既にレビューされ、承認された製品仕様とテスト プロトコルに直接影響を与えることを意味します。これは、コンテンツを Confluence にプルする適切な方法ではない可能性があると思います。より永続的な方法をお勧めします。

これらの直接/動的クエリを使用していなかったとしても、この質問は有効です: 要件/承認基準の変更はユーザー ストーリーにどのように影響しますか?

4

5 に答える 5

1

したがって、製品がリリースされた後、製品所有者があなたに戻ってきて、次のことを望んでいると言います。

30 秒ではなく 1 分のタイムアウト

これは問題と見なされる可能性があります。タイムアウト機能は正常に動作するため、これはバグではありません。期間に問題があるだけです。したがって、問題を作成し、それを元のストーリーに関連付けてから、タスクに分割してこの変更を実装できます。

でも：

バージョン 1.0 の製品仕様が変更されないようにするにはどうすればよいでしょうか?

元の製品仕様ではタイムアウトが 30 秒と記載されていたが、現在は 1 分に変更されている場合、仕様が変更されたという事実から逃れることはできません。問題を作成して元のストーリーにリンクすると、元のストーリーを編集する必要がなくなります。

于 2014-07-25T21:55:01.023 に答える
0

一度完了したユーザー ストーリーの承認基準を変更することはできません(はい、完了の定義を参照してください)。

プロダクト オーナーがユーザー ストーリーの承認基準を変更する必要がある場合は、「承認基準」を使用して新しい機能/ユーザー ストーリーを作成する必要があります。

変更がスプリントの途中で発生し、既存の受け入れ基準がプロジェクトに意味をなさない場合は、スプリント バックログからユーザー ストーリーを削除し、これを新しいスプリントに追加します (変更はスプリントの途中で受け入れられるべきではありません)。新しい/変更された受け入れ基準。

于 2015-04-30T09:34:28.547 に答える
0

あなたの元の話は良いままだと思います。タイムアウトの変更に価値があることを考えると、元のストーリーの受け入れ基準を変更する必要があることは明らかです。これは、テストが自動化されている場合に特に当てはまります。新しいストーリーを作成します。

fraggle thrunge ブラケット操作のタイムアウト値を変更したいので、

この新しい物語を書くことは、この変化がもたらす価値に素晴らしく心を集中させます。付加価値がない場合は、実行しないでください。

于 2014-07-24T07:35:33.387 に答える