スクラム-ユーザーストーリー

ご存じのとおり、ユーザーストーリーは一般に製品の機能を説明するために使用され、スクラムアーティファクトの一部を形成します-製品バックログ*および*スプリントバックログ。

ユーザーストーリー

ソフトウェア開発では、製品の機能が重要な役割を果たします。これは、ユーザーが最終製品で最終的に使用したい機能です。これらは、一般用語では要件として知られています。ソフトウェア開発プロジェクトの成功は、ユーザーの要件を正確かつ適切に理解し、最終製品に実装することにあります。したがって、要件または製品の機能は、開発プロジェクトチームに完全に知られている必要があります。

1999年に、Kent Beckは製品機能の用語User Storiesを考案しました。彼は、ユーザーストーリーはユーザーの観点から、システムが彼のために何ができるかというよりも、彼または彼女が持ちたいものに関してナレーションされると説明しました。したがって、ビューは製品からユーザーに完全に変わり、ユーザーストーリーはすべてのアジャイルフレームワークの要件の事実上の標準になりました。

スクラムプロジェクトでは、製品バックログはユーザーストーリーのリストです。これらのユーザーストーリーは優先順位が付けられ、スプリントプランニングミーティングのスプリントバックログに取り込まれます。

推定はユーザーストーリーにも基づいており、製品のサイズはユーザーストーリーポイントで推定されます。

ユーザーストーリー構造

ユーザーストーリーの構造は次のとおりです-

_ <ユーザーのタイプ> _として、

_ <タスクを実行するには> _が必要です。

_ <私はいくつかの目標/利益/価値を達成できるように> _。

銀行の顧客がATMから現金を引き出すシナリオで、ユーザーストーリーがどのように構成されているかを見てみましょう。

ユーザーストーリー：顧客の現金引き出し

顧客*として、

ATMから現金を引き出す*、

銀行で並んで待つ必要はありません

ユーザーストーリーの受け入れ基準

各ユーザーストーリーには承認基準も定義されているため、ユーザーストーリーの実装の正確性は、承認基準に基づいた承認テストに合格することで確認されます。

以下は、ユーザーストーリーの顧客による現金の引き出しの例の承認基準のサンプルです。

合格基準1：

与えられた*アカウントは信用できる

そして、カードは有効です
ディスペンサーには現金が入っています

いつ*顧客が現金を要求する

その後*口座から引き落とされることを確認する

そして、現金が分配されるようにします
そして、カードが返されることを確認します。

合格基準2：

与えられた*アカウントがオーバードローされた

そして、カードは有効です

いつ*顧客が現金を要求する

次に*拒否メッセージが表示されることを確認します

現金が出されないようにします
そして、カードが返されることを確認します。

ユーザーストーリーを書く

製品所有者は、製品バックログ、したがってユーザーストーリーの責任を負います。ただし、製品の所有者だけがユーザーストーリーを作成するわけではありません。スクラムチームの誰もがユーザーストーリーを作成でき、要件が洗練され、新しい機能が追加されると、アクティビティをプロジェクト全体に広げることができます。

ユーザーストーリーの非機能要件

ユーザーストーリーにも非機能要件を組み込むことができます。所定のATMの例では、365日24時間365日利用可能なATMは非機能要件であり、ユースケースで説明できます。

ユーザーストーリーの管理

ユーザーストーリーは製品バックログで管理されます。ユーザーストーリーは優先度に従って並べられます。最も優先順位の高いユーザーストーリーはより詳細なレベルに維持され、最も優先順位の低いユーザーストーリーはより詳細なレベルに維持されます。すべてのスプリントについて、最も優先順位が高いため、より詳細なユーザーストーリーがスプリントバックログに取り込まれます。ユーザーストーリーを製品バックログに追加する場合、優先度が最初に決定され、優先度に従ってその場所に従って配置されます。ユーザーストーリーはいつでも優先順位を変更できます。必要に応じて、ユーザーストーリーを削除することもできます。

ユーザーストーリーの利点

ユーザーストーリーの主な利点は、ユーザー中心の定義自体にあります。これは、最終的に、関連するユーザーシナリオで製品を使用するのはユーザーであるためです。エンドユーザーをチームメンバーに接続します。
ユーザーストーリー自体の構文により、ユーザーが達成したい目標、利益、または価値を確実に取り込むことができます。
受け入れ基準はユーザーストーリー自体の一部を構成するため、スクラムチームにとっては追加の利点になります。
プロジェクトの実行中に、ユーザーストーリーに変更を加えることができます。ユーザーストーリーの範囲が大きくなった場合、より小さなユーザーストーリーに分割する必要があります。受け入れ基準の条件も変更できます。
作業中の製品の増分が各スプリントの終わりにユーザーに配信されるため、スクラムチームはスプリントレビュー会議でユーザーからフィードバックを得ることができます。これにより、製品にフィードバックを継続的に組み込むことができます。

結論

スクラムのユーザーストーリーは、ユーザーをスクラムチームに近づけ、土壇場での驚きを防ぎます。

Scrum-user-stories

目次