4

私の組織は現在スクラムを実装しています。一部のビジネス ロジックの処理方法を変更するために製品のバックログ アイテムに取り組んでいるときに、一部のビジネス ロジックに欠陥があることに気付きました。PBI とその受け入れ基準は、現在、既存のビジネス ロジックの実装を変更することを目的としています。PO は、ビジネス ロジック自体に対するこの変更は優先度が高く、何らかの方法でスプリントに取り組まなければならないと感じており、特に開発の観点から両方を一緒に行うことが非常に理にかなっているため、開発チームは同意しています。

ただし、受け入れ基準を変更したり、新しい PBI を作成してすぐにスプリントに取り入れたりする方が理にかなっているのかどうかはわかりません。これは元の PBI とは別の話であり、受け入れ基準のセットであると感じているため、私は個人的に新しい PBI に傾倒しており、一般的にスプリントの途中で受け入れ基準を変更することに懐疑的です。PO は、この新しい要件と元の PBI の両方が同時に実装されることを指摘しました。元の PBI は、新しい要件に対処しなければ意味がありません。したがって、PO は、最終的に同じ実装を反映する 2 つの別個の PBI を作成するのではなく、元の PBI の受け入れ基準を調整する方が適切であると感じています。

これらのアプローチの 1 つは、他のアプローチよりもスクラムに適していますか?

4

5 に答える 5

4

スクラムには理解すべき微妙な違いがいくつかあります。

スプリント計画では、プロダクト オーナーは、チームのベロシティに基づいて、次に高い価値のある要件をチームに提供します。PO は要件を説明し、チームは詳細について PO に質問します。

注: チームが要件を確認するのはこれが初めてではありません。チームはグルーミング セッションで以前に確認したはずです。

チームはアプローチについて話し合い、設計を行い、実行するタスクの山を作成し、予測に同意します。チームはスプリント バックログ、スプリント ゴールを作成し、作業を開始します。

チームが取り組んでいるコア要件を変更することはできません。チームでさえありません。PO だけが、継続することに価値がないと判断した場合、作業を終了する権利を有します。ここで、PO 側の不適切な計画と要件の明確化の間には微妙な境界線があります。

要件は契約ではなく、チームは何をしなければならないかという核心を持っている必要があります。詳細を収集し、要件を達成するためにわずかに変更する必要があります。チームは、作業中のタスクを完全に変更したり、タスクを追加したり、タスクを削除したりして、コミュニケーションとコラボレーションを支援できます。要求された要件を提供する限り。詳細の明確化は完全に受け入れられます。

ほとんどのチームが抱えている課題は、明確化によって要件の意味が変わってしまうことです。これが発生した場合は、ふりかえりで問題の芽を摘み取り、要件の記述方法に適応する必要があります。したがって、あいまいさを取り除きます。それは単に、グルーミングにより多くの時間を費やす必要があることを意味します.

あなたの質問に答えるために。 PO とチームが何かを変更することが理にかなっている場合は、変更してください。ただし、これは規則よりも例外である必要があります。常に発生している場合。あなたの身だしなみは悪いです。スプリントで受入基準を明確にし、品質を高めることは悪いことではありません。

于 2013-02-20T12:27:12.713 に答える
4

チームは一連の基準を提供することを約束しているため、チームの同意を得てのみストーリーを変更する必要があります。チームの全会一致の同意なしに基準を変更する場合、そもそもなぜわざわざそれを取得したのですか?

スプリントのバックログをいじるのは大したことではありません。なぜなら、スプリント中に特定の一連のストーリーを提供するというチームのコミットメントの価値を下げることになるからです。

チームが変更を受け入れたくない場合、PO は元のストーリーを撤回し、新しいストーリーをバックログの一番上に置くことができます。現在のスプリントに含まれる場合と含まれない場合があります。

POがスプリント中にスプリントのバックログをいじることができるという考えに、あなたのすべての繊維で抵抗してください. 私の PO は、最近のスプリントの終わり近くに (非常にでたらめな推論に基づいて) 非常に小さなストーリーをドロップしようとしました。

http://www.scrum.org/scrum-guides/から:

スプリント中にスプリント バックログを変更できるのは、開発チームだけです。

それは良いアドバイスだと思います。

于 2013-02-14T05:33:54.243 に答える
1

一般に、特にスプリント内で、チケットが見積もられた後は、チケット (PBI) の AC を変更することは大したことではありません。そうは言っても、そうすることがどのような問題を引き起こす可能性があるかを尋ねる必要があります。

つまり、AC を変更すると、推定値が不正確になる可能性があります。つまり、低すぎます。だから何？そうなると、チームはスプリントからコミットされたチケットを完了できなくなる可能性があります。良くないね。

この場合の新しいチケットは、 INVESTストーリーの「独立した」基準に適合しないように聞こえるため、おそらく悪い考えです。

現在のチケットを変更すると、スプリントに追加されたストーリー/ポイントを追跡しようとするときに会計上の問題が発生する可能性がありますが、それ以外の問題はありません。ここで重要なのは、再見積もりして、これがより多くの作業であることを全員が理解できるようにすることです。

「スクラムに適した」ものに行き詰まらないようにしてください。何がうまくいくか、さまざまなことがあなたにどのような問題を引き起こすかを考え、それに基づいて決定を下してください.

最後に、この問題がふりかえりで取り上げられることを確認してください。これにより、このケースで AC が正しくない、または不完全であった理由を話し合い、チームが今後そのようなことが起こらないようにするための実行可能な措置を講じることができるかどうかを確認できます。

PS pm.stackexchange.com で、このような質問に対するヘルプを見つけることができます。

于 2013-02-14T04:06:40.073 に答える
0

私はあなたの質問を非常に迅速に解決しました。これが事です。同様の状況がありました。デルタ ストーリーを作成し、現在のスプリントから何かを取り出して別のスプリントに移動しました。それを DELTA US と呼び、バージョン 1.1 を与えてください。

それは役に立ちますか？

ありがとう、クリス。

于 2013-02-22T16:14:33.687 に答える