何をどのように分離する - アジャイル環境での設計 [終了]

Question

アジャイル (スクラム) 環境では、専門ではないすべての設計をプロダクト管理者に行わせることなく、十分に小さなバックログ項目やストーリーを作成できるようにするにはどうすればよいでしょうか?言い換えれば、アジャイル開発において、何を（ビジネス要件）とどのように（設計）をどのように分離するのでしょうか?

Answer 1

スクラムでは、 製品管理 1 人である必要があります:の プロダクトオーナー .

やりたいことはその期間中に実行されます スプリント計画, 、チーム全体 (プロダクトオーナー、スクラムマスター、開発者) が存在する必要があります。

の 何 次のように定義する必要があります ユーザーストーリー によって プロダクトオーナー 。ユーザー ストーリーは高レベルであることが想定されているため、製品所有者がビジネス要件を表現できるのは限られています。 一文のストーリーで十分です.

例えば StackOverflow ユーザーとして、自分の評判を知りたいです

スプリント計画の目標の 1 つは、スプリント中に実行する必要があるストーリーを決定することです。したがって、プロダクトオーナーがストーリーを選択すると、チームはストーリーを細分化し、デザインについて簡単に話し合うことができます (どのように）を推定してください。

一言で言えば、 何 製品所有者が行う必要があります。 どうやって チームによって。このプロセスがプロダクトオーナーに明確に説明されていれば、プロダクトオーナーはすべてを設計しようとすることはありません。とにかく彼がやろうとすると、スクラムマスターが彼を止めるでしょう。

Answer 2

まず最初にやらなければならないこと、そしてそれが多くのスクラムプロジェクトの失敗の原因となっているのは、プロダクト管理者にプロダクトオーナーの役割を果たすよう教えることです。あなたは彼がプロジェクトの ROI に責任を持っていること、そしてそのために、彼はストーリー/アイテム/ビジネス ニーズ/機能など、あなたが製品バックログを構成するために使用しているものに最も優先順位を付ける責任があることを示す必要があります。貴重なアイテムほど優先順位が高くなります。

私は、製品バックログの項目としてユーザー ストーリーを使用し、スプリント計画の際に、ストーリーが選択した小さなタスクに分割してスプリント バックログを構成することに賛成です。

ユーザー ストーリーを作成するとき、または PO の作成を支援するときに常に念頭に置いておく必要があるのは、ストーリーは投資である必要があるということです。 私独立した、 N交渉好きな、 V顧客にとって価値のある、 E推定可能な、 Sモールと T安定している。

最初は以下のテンプレートを使用すると、PO がビジネス目標に集中し続けるのに役立つと思います。

「私は - タイプのユーザー - として、 - 何らかの目標 - が欲しいので、 - 何らかの理由 - を実現します。」

ストーリーの例としては、「stackoverflow ユーザーとして、最も価値のある答えが簡単に見つかるように、回答に投票したいと考えています。」というものがあります。

ストーリーが完全に実装されているかどうかを判断するための基本的な基準として使用できるため、PO にスプリント バックログの各ストーリーの受け入れテストを作成または定義させることを忘れないでください。

上の例では、次の 2 つの受け入れテストが考えられます。

「回答に投票するためのテスト」

「回答に反対票を投じるためのテスト」

このストーリーと 2 つの受け入れテストにより、チームは、stackoverflow ユーザーが回答に投票し、ストーリーのステータスを更新して「Done」を実行できることを認識しました。システムは、ユーザーが例外をスローせずに回答に賛成票を投じたり反対票を投じたりできるようにする必要があります。

Answer 3

製品バックログの項目は、重み付けシステム (素数、フィボナッチなど) を使用して重要度の順に評価する必要があることを忘れないでください。そうすることで、バックログに同様の重要性の項目がある場合 (つまり、ウェイトが 21 の 2 つのアイテム) の場合、理論的には両方とも 13 秒と 8 秒の前にスプリントに挿入されるはずです。

Answer 4

バックログ (再) 見積もり中 (優先順位付け後)、チームはユーザー ストーリーの全範囲を理解し、複雑さを正確に見積もることができるようにモデリングを行う必要があります。これは、行われる可能性のあるモデリングの全範囲ではありません (チームはさらに開発を行う可能性があります) が、開始するのに最適な場所であり、顧客/製品所有者がそこにいて質問に答えられるという利点を活用できます。その後。

この結果として得られるディスカッションは、プロダクトオーナーと協力して要件を意味のある適切な粒度に分割するのに役立ちます。