ユーザーストーリーと受け入れ基準とは何か（例）

実際のシナリオを持つユーザーストーリー受け入れ基準へのパーフェクトガイド：

ソフトウェア開発業界では、”要件”という言葉は、私たちの目標が何であるか、顧客が正確に必要とするもの、そして私たちのビジネスを増やすために私たちの会社を作るものを定義します。

それはソフトウェア製品を作る製品会社または様々なソフトウェア分野でサービスを提供するサービス会社であれば、それらのすべてのための主なベースは、要件であり、成功は要件がどれだけうまく満たされているかによって定義されます。,

“要件”という用語は、異なるプロジェクト方法論で異なる名前を持っています。

ウォーターフォールでは”要件/仕様文書”と呼ばれ、アジャイルやスクラムでは”Epic”、”ユーザーストーリー”と呼ばれます。

Waterfallモデルでは、製品全体が一段階で実装されているため、要件ドキュメントは200ページ以上の巨大なドキュメントです。 しかし、これらの方法論では、製品が段階的に準備されているため、小さな機能や機能に対する要件が与えられているため、アジャイル/スクラムではそうではありません。,

この記事では、ユーザーストーリーとそれに関連する受け入れ基準を扱うことに関する私の4年間の経験と、より良い理解のための簡単でシンプルな実

私たちは最初の基礎を再訪してみましょう。

ユーザーストーリーとは何ですか？

ユーザーストーリーは、一つまたは二つの行で書き留められ、最大5行までの機能または機能の要件です。 ユーザーストーリーは通常、可能な限り最も単純な要件であり、唯一の機能（または一つの機能）についてです。,

ユーザーストーリー作成に最も一般的に使用される標準形式は以下のとおりです。

<ユーザーロール/顧客として、<達成する目標>できるように<目標の理由<486e8bad93″>.

例：

WhatsAppユーザーとして、チャット書き込みボックスのカメラアイコンをキャプチャして写真を送信して、すべての友人と同時に写真をクリックして

受け入れ基準とは何ですか？,

受け入れ基準とは、製品所有者/利害関係者が受け入れるために、機能または機能が満たし、満たすべき受け入れられた条件またはビジネスルール

これはユーザーストーリーの完成の非常に重要な部分であり、単一の基準を欠くと多くのコストがかかるため、製品所有者とビジネスアナリストによって非常に細心の注意を払って検討する必要があります。 これは単純な番号付きリストまたは箇条書きリストです。

そのフォーマットは次のとおりです。

“何らかのアクションを実行するときに前提条件がある場合、結果が期待されます”。

例(w.r.,p>

• 私は友人とチャットしていると私は写真をキャプチャすることができるはずであることを考えてみましょう。
• 画像をクリックすると、画像を送信する前に画像にキャプションを追加できるはずです。私の携帯電話のカメラの起動に何らかの問題がある場合は、”カメラを起動できませんでした”のようなエラーメッセージが表示されます。 など。 に示されるべきである。

したがって、ユーザーストーリーは任意の機能または機能の要件を定義し、受け入れ基準はユーザーストーリーまたは要件の”完了の定義”を定義します。,

QAとして、ユーザーストーリーとその受け入れ基準を深く理解することは非常に重要であり、”テストの開始”には一つの疑いさえ残っていません。 今後は、ユーザーストーリーと受け入れ基準を”深く”掘り下げることが非常に重要である理由を理解しましょう。

ユーザーストーリーを深く掘り下げる

まず、基本的かつ基本的なもの、すなわちユーザーストーリーの”詳細な”研究の重要性を理解しましょう。

以下のケースは私自身の実際の経験です。,

ケース#1:

3年前、私はモバイルアプリケーションプロジェクトに取り組んでいましたが、製品は配信者向けに設計されたアプリケーションでした。

あなたは配達人が配達のためにあなたの場所に来るのを見たでしょう。 そして、彼らは配達の後にあなたの署名を与えるように頼む携帯電話を持っています。 この署名は、DTDC、FedExなどの宅配便サービスプロバイダーのポータルに反映されています。

モバイルアプリが起動したばかりで、そのポータルがすでに存在していると想像してみましょう。,

問題：スプリントの場合、製品所有者には、このモバイルアプリのユーザーストーリーがあり、”ポータル管理者として、配達時に配達者が撮影した署名を表示できる ここで、ポータル（webアプリ）が変更され、それに応じて更新され、署名が反映されます。

QAとして、モバイルアプリでキャプチャされた署名がポータルで期待どおりに反映されているかどうかを確認する必要があります。,

このユーザーストーリーを見ると、シンプルに見えますが、ここでは”履歴配信の場合、署名リフレクション機能がなかったため、ポータル担当者が履歴配信を表示した場合はどうなるでしょうか？”履歴データを消去する必要がありますか？ うすることを許可していますクラッシュやエラーなどのデータはもらえますか？

もちろん、これは優雅に処理されるべきではありません。,解決策：それぞれのDBテーブルが更新されて署名の場所の新しい列が追加されると、古いデータにはNULLまたは0の値がチェックされ、”no signature exists”というメッセージ

これは、製品所有者またはビジネスアナリストからミスとして呼び出すことができますが、これを行う必要があります。 実施の機能が破れのものでは望ましくないよおります。 これは、同じユーザーストーリーと同じスプリントで行う必要があります。,

Case#2

6年前、私は退職計画金融アプリケーションに取り組んでいました（BAなし）これは、CA、財務アドバイザーのような金融の人々が投資計画、貯蓄などを投影するために異なる通貨のためにそれを使用することができるグローバルなアプリケーションでした。、彼らの顧客に大きい期間にわたって。

問題：製品所有者は、”アドバイザーとして、提供された財務詳細に基づいて顧客のレポートを表示したい”というユーザーストーリーを提供します。,

ここでは2つの隠された要件があり、私は不完全な話としてそれを呼び出すだろう：

a]レポートは、最後に表示されたレポートのように歴史的なものではなく、日次の通貨換算レートを考慮する必要があります。

b]顧客の財務詳細を提供した後に通貨が変更された場合、レポートは変更された通貨で表示される必要があります。

解決策：私は製品所有者と直接この懸念を提起し、これらの両方ができるだけ早く行われなければならないことを彼に認識させました。 彼は私に同意し、次のスプリントのために2つの異なる物語を優先して作成しました。,

奪う：私たちはすべての製品、そのデザイン、構造などを非常によく知っていたので、これらはキャッチされました。 このような知識は、製品を完全に理解し、モジュールの操作性を理解し、2ライナーであってもユーザーストーリーを徹底的に研究することによってのみ達成でき

物事をより簡単にし、BAや開発者と彼らの思考について話し合うためにメモを作成します。,

受け入れ基準の詳細な外観

受け入れ基準と他のすべての条件を理解する&ルールを徹底的に理解することは、ユーザーストーリーを控えめに 要件が不完全または曖昧な場合は、次のスプリントで取り上げることができますが、受け入れ基準が見逃された場合、ユーザーストーリー自体をリリースすることはできないためです。

私たちは皆、ある時点でネットバンキングを使用していると思いますし、私たちのほとんどは毎日それを使用し、私は私の歴史的な声明をたくさん, 注意深く観察すると、ダウンロードできる特定のオプションがあります。

ステートメントをダウンロードするためのファイルの種類を選択するオプションがあります。 クレジット/デビット/両方のみをダウンロードする場合は、選択するオプションがあります。

プロダクトオーナーが”顧客として、特定の期間に行われたすべての取引を表示できるように、口座明細書をダウンロードしたい”というユーザーストーリーを与えることを想像してみてください。,

以下の受け入れ基準で：

• 私は過去の声明のダウンロードページにいることを考慮して、声明をダウンロードする期間を選択する必要があります。
• 私がダウンロード履歴声明ページにいることを考慮して、私は声明をダウンロードしたいアカウントを選択する必要があります。
• 私がダウンロード履歴声明ページにいることを考慮すると、将来の’To’日付の声明をダウンロードすることは許可されるべきではありません。,
• 私がダウンロード履歴ステートメントページにいることを考慮すると、過去10年以降の”From”日付を選択することは許可されるべきではありません。私は私の文をダウンロードすることを考えると、私はダウンロードしたファイルを表示することができるはずです。私がダウンロード履歴声明ページにいることを考えると、私はdoc、excel、およびpdf形式で自分の声明をダウンロードできるはずです。

この受け入れを通過すると、ここに欠けている3つのものがあります：

• ダウンロードされるファイル名の名前と形式。,
• ファイルに表示される情報（列名）。
• 顧客が望む取引の種類、つまり借方のみ、貸方のみ、またはその両方を選択するためのオプションリスト。

このようなケースはたまに起こるかもしれませんが、各受け入れ基準についてよく勉強し、ユーザーストーリーを参照して視覚化しようとします。 条件やビジネスルールについて深く勉強すればするほど、その機能についての知識が増えます。

初期段階で見つかったバグは、”テスト”段階でコストがかかる可能性があるものと比較して何もコストがかかりません。,

ユーザーストーリー/受け入れ基準の不一致を見つけることの重要性

開発またはテストが開始される前であっても、ユーザーストーリーと受け入れ基準を早い段階で深く掘り下げることは常に重要です。

以下が含まれるため、

#1)時間の浪費:

開発が進行中またはテストが進行中のときにユーザーストーリー/受け入れ基準の不一致または間違いが見つかった場合、残りのスプリント時間に多くのリワークを行う必要があるかもしれません。,

プロダクトオーナーがいくつかのことを逃したとしても、ユーザーストーリーを今後のスプリントに移動することはありません。 95%の確率で、必要な実装をチームに依頼し、同じスプリントでリリースすることができます。

したがって、余分な時間を費やしたり、週末に来たり、深夜に仕事をしなければならないので、チームにとっては悪夢になります。 このすることを確認することにより、研究と討議を、ユーザー物語/受入れ基準をできるだけ早期段階にある。

#2）努力の無駄：

開発者とQAは、実装されたコードとテストケースを再訪する必要があります。, 要件ごとに更新、追加、削除は簡単な作業ではありません。 それは時間通りに提供する圧力が既にあるので余りに苦痛になる。

このような状況では、開発段階またはテスト段階で間違いが発生する可能性があります。 このような状況に遭遇した場合は、”DevQAペアリング”に行きます。 ケーキの上のアイシングとして、あなたは余分な仕事のための補償を得ることはできません。

結論

ユーザーストーリーと受け入れ基準の深い理解は、それを勉強するのに膨大な時間を費やすことによってのみ達成することができます。,

これはすべての論理的思考、経験、および製品についての知識についてであるとして、あなたのためにこれを行うには、市場で利用可能な特定のツール

事前計画ミーティングに積極的に参加し、BAと話し、自分で勉強することは、これを達成するのに役立ちます。 あなたが置くより多くの努力は、より多くのあなたが学び、成長。

QAであれ開発者であれ、ユーザーストーリーとその受け入れ基準について誰もが同じページにいなければなりません。,

あなたはユーザーストーリーでの作業に関するあなたの経験について私たちと共有する新しい何かを持ってい 以下にご感想をお書きくださいませ！!