受け入れ基準の書き方:例とベストプラクティス

ここMobindustryでは、アジャイルアプローチで運営しています。 これを使用していまアジャイル部品のようなユーザーの話を受け入れ基準とします。 高性能なチームや組織は、製品バックログにこれらのコンポーネントを持っており、それらを作成して効果的に使用する方法を知っています。

プロダクトバックログにユーザーストーリーや受け入れ基準がない場合、または明確に定義されていない場合、期待が現実に収束しない危険があります。, ユーザー物語や合格基準担を表すのにどのようにエンドユーザーが利用アプリは、どのよう開発チームはそれぞれの開発課題です。 新しい製品の作業を開始すると、私たちのチームはクライアントと協力してユーザーストーリーを定義します。

ユーザーストーリーは、その機能を使用したい人の視点からの製品機能の短くて簡単な説明です。 ユーザー語の定義に使用された製品の受注残高は、アジャイル開発ワークフロー.,

プロダクトバックログは、基本的に、特定の製品またはサービスの機能仕様および機能の開発を知らせるユーザーストーリーの集まりです。 ユーザーストーリーは、ストーリーが書かれているユーザーのペルソナ、ユーザーが必要とする機能の説明、および機能が満たす必要性の説明の三つの部分から構成されます。

ユーザーストーリーを書く方法は次のとおりです。

（ユーザー）として（必要を満たす）ことができるように（機能）が必要です。

ユーザーストーリーがどのように見えるかを見てみましょう。, 例としてAirbnbを取り上げてみましょう。 典型的なユーザーストーリーがAirbnbのような製品をどのように探すかを想像してみましょう。

“ユーザーとして、目的地を検索して、外国の都市の宿泊施設を予約できるようにしたい。”

受け入れ基準の定義

今、私たちは、ユーザーストーリーが正しく完了し、クライアントの要求に対応していることを確認する必要があります。

受け入れ基準は、ソフトウェア製品がユーザー、顧客、またはシステムレベルの機能の場合は消費するシステムによって受け入れられるために満たさなければならない条件です。,

受け入れ基準は、ステートメントのセットであり、それぞれが明確な合否結果を持ち、機能要件と非機能要件の両方を測定し、指定できます。

受け入れ基準を書くことは、クライアントが製品に期待するものを確立するだけでなく、開発プロセスにとって重要です。 当然のことながら、異なる人々は異なる角度から同じ問題を見ます。 明確に定義された受け入れ基準は、実装する予定の機能の統一されたビューを提供します。,

誰でも、スクラムボードまで歩き、プロダクトバックログ項目を取得し、受け入れ基準を読み、その特定の項目を完了カラムに移動するために完了する必 受け入れ基準は、製品の特定の部分が終了するために何をする必要があるかを示します。

なぜ受け入れ基準が必要なのですか？,

• 境界を定義します。 受入れ基準の開発チームを定義する境界のユーザーの話です。 などの形態であることの確認アプリとして活躍が期待で、ユーザーの話が完了します。
• コンセンサスに達しました。 受入れ基準の開発チームが同じページとしてクライアント そして、開発チーム約などの条件を満たす必要があるのを知ってお客様から何を期待できる。
• 受け入れテストを合理化します。, 受け入れ条件のユーザーの話を受け入れます。 すべての合格基準は、独立してテストされ、成功または失敗のための明確なシナリオを持
• 計画と見積もり。 受入れ基準を許可するユーザーに配布地の作業なので正しく評価され、予定しています。
• 負のシナリオを記述します。 受け入れ基準にする必要があるかもしれなシステムを特定するのに弱いパスワードをユーザーからの継続を備えています。, 不正なパスワード形式の入力は、ユーザーが不正なデータを入力したり、予期せず動作したりする否定的なシナリオの例です。 受入れ基準をこのシナリオの方法などの説明ができるようになシステムに対応すべきと考えます。

受け入れ基準を持つユーザーストーリーの例

ユーザーストーリーと受け入れ基準が何であるかを明確に理解したので、いくつかの例を見てみましょう。,

例1

ユーザーストーリー：ユーザーとして、オンラインで買い物を始めることができるようにサービスに登録できるようにしたいと考えています。

受け入れ基準：

• ユーザーは、必要なすべてのフィールドに入力することによってのみ、フォームを提出することができます。
• ユーザーが提供する電子メールは、無料の電子メールサービスで提供されてはなりません。
• 同じIPからの提出は、30分以内に三回しか行うことができません。
• ユーザーは正常に登録すると通知メールを受け取ります。,

例2

ユーザーストーリー：ユーザーとして、デバイス上の通知を受信した直後にアクセスできます。

受け入れ基準：

• 通知をスワイプ/タップすると、ユーザーはメッセージに直接移動します。
• ビューは会話を表示します—新しいメッセージが返信であった場合、元のメッセージの上に表示されます。
• メッセージ数が更新されます。
• メッセージが表示された後、読み取りとマークされます。

良い合格基準を書く上での7つのヒント

合格基準を書くのは簡単ではありません。, 単純な形式にもかかわらず、テキストを書くことは挑戦です。 ここでは、合格基準を書いている間に一般的な間違いを避けるために、またはあなたのチームのメンバーによって書かれた基準を

• 開発プロセスを開始する前に、ドキュメントの基準。 このようにして、チームは事前にクライアントのニーズをすべてキャッチする可能性が高くなります。 最初は、少数のユーザーストーリーの基準を設定して、二つのスプリントのバックログを完了するだけで十分です。 文書化された受け入れ基準は、開発者が技術プロセスを計画するために使用されます。,
• 受け入れ基準を狭くしすぎないでください。 あまりにも特定の受け入れ基準は、開発者が操縦する余地を残します。 これを避けるために、受け入れ基準は意図の表現であり、最終決定ではないことを忘れないでください。 さらに、狭い受け入れ基準は、すべてのユーザーアクションを考慮に入れ
• あなたの基準を達成可能にしてください。 効果的な受け入れ基準は、提供できる機能の合理的な最小量を定義します。 しかし、あなたがすべての小さな詳細を記述し続ける場合、あなたのチームは小さなタスクの数百に立ち往生するリスクがあります。,
• 受け入れ基準が広すぎないようにします。 幅広く受け入れ基準によるユーザー物語としない。 効果的な受け入れ基準は、開発者が適切に計画し、彼らの努力を推定できるように、作業の範囲を概説する必要があります。
• 技術的な詳細は避けてください。 受け入れ基準は平易な言語で書かれるべきである。 ステークホルダーや経営者が技術的背景をもつので、煩わしい言語の基準を理解できます。
• コンセンサスに達します。, 同じ問題は、チームメンバーとステークホルダーの視点に応じて、さまざまな方法で解決できます。 受け入れ基準を利害関係者やチームメンバーに伝え、相互の合意に達することを確認してください。
• テスト可能な受け入れ基準を書き込みます。 本試験機の機会を確保すべての要件を満たした場合には、できる開発者が知った場合、ユーザーの話が完了します。,

受け入れ基準の書き方

ここでは、受け入れ基準の文言の問題を解決するのに役立ちます五つの一般的なルールがあります。 これらのルールを使用すると、貴重な時間を節約し、製品所有者と開発チームの間の理解を確立できます。

ルール＃1：”not”を避ける

“Not”は”いかなる場合でも”を意味するため、このような条件の遵守を確認するのに十分な時間はありません。, “Not”を使用せずに要件を書き換えると、より明確になり、最も重要なのは検証可能になります。

例:

ユーザーストーリー

しない:ユーザーとして、アカウントにアクセスするたびにパスワードを入力する必要はありません。
Do：ユーザーとして、パスワードを記憶して自動的に入力して、パスワードを再入力せずにアカウントにアクセスできるようにします。

受け入れ基準

しない:システムが失敗してはなりません。
Do：システムは90％以上の可用性を持っている必要があります。,

Exception

受け入れ基準に”not”を使用して、”ログインフォームを赤色にすべきではありません。”ほとんどの場合、これは非機能要件に適用されます。 この例では、赤の色合いの範囲が明確に定義されている場合（例えば、RGB形式で指定されている場合）、簡単に検証できる制約を定式化します。,

ルール#2:アクティブボイスを使用する

アクティブボイスは、文の中の主語がアクションの実行者である アクションを実行する責任のあるエンティティが明確に示されていない場合、誰または何がアクションを実行すべきかが不明確になり、要件が満たされているかどうかを確認することがより困難になります。,

例：

ユーザーストーリー

しない：オンライン買い物客として、私は私が欲しいものを見つけることができるようにフィルタを適用したいです。
Do：ユーザーとして、私は項目を見つけることができるように検索フィルタを適用したいと思います。

受け入れ基準

しないでください：顧客の身元を確認する必要があります。 （お客様の身元を確認するために誰または何の責任があるかは不明です。)
Do:Accounting_SystemはCustomer_Indentityを確認する必要があります。 （用語”Accounting_System”と”Customer_Indentity”の定義は、用語集に追加する必要があることに注意してください。,)

ルール＃3：代名詞（特に未定義のもの）を使用しないでください

他の要件で参照されている項目を参照するときは、代名詞の代わりに名詞 代名詞はあいまいさをもたらす可能性があるため、避けるべきです。,

これは、受け入れ基準がjiraなどの要件管理ツールに、必ずしも編成されていない個別の文として格納されている場合に特に重要です。 常に代名詞の代わりに名詞を使用し、あなたはこの問題を避けるでしょう。

例：

ユーザーストーリー

しない：サイトメンバーとして、私は他の人がそれを見ることができるように自分自身についての情報を共有したいと思います。
Do：サイトのメンバーとして、私は他の人が私について学ぶことができるようにプロファイルの説明を追加したい。

受け入れ基準

しないでください：コントローラは、ドライバーにその日の旅程を送信する必要があります。, それはシフトの少なくとも8時間前に配信する必要があります。
Do：コントローラは、Driver_Shiftの少なくとも8時間前にドライバにその日のDriver_Itineraryを送信する必要があります。

ルール#4:接続詞を避ける

接続詞は、単純な文章を複雑なものに組み合わせた”and”、”or”、”but”、”and”などの単語やフレーズです。, 要件におけるそれらの使用は、通常、要件をいくつかの別々の要件に分割できるという兆候です。

例：

ユーザーストーリー

しない：UIデザイナーとして、私はテストするものを知っているように、問題を作成して表示したいと思います。
Do：UIデザイナーとして、私は何をテストすべきかを知るために問題を作成したいと思っています。 UIデザイナーとして、私は何をテストするかを知るために問題を表示したいと思います。

受け入れ基準

しない:ユーザーは信頼されているか、信頼されていない必要があります。
Do:Security_Systemは、各ユーザーをTrustedまたはNot_Trustedとして分類する必要があります。,

Exception

“And”、”or”、および”not”は、論理条件を記述し、修飾子を追加するために使用できます。

ルール#5:達成できない絶対を避ける

絶対(100%の可用性など)は達成できません。 指標を確認する方法を考えてみましょう：システム可用性のレベルが正確に100％であることを証明することは可能でしょうか？, としない場合でもシステムを作成しまいですか？

このような絶対的な要件をチェックするには無限の数のテストが必要になるため、”all”、”always”、および”never”という単語は避けてください。

例：

ユーザーストーリー

しないでください：旅行者として、私は迷子にならないように、リアルタイムで更新された正確な場所を知りたいです。 （”リアルタイム”は異なる方法で解釈することができます。 たとえば、それは達成できず、検証可能ではない絶対的な（遅延がない）ものと見なすことができます。,)
Do：旅行者として、私は私が迷子にならないように、毎秒updatedされた私の正確な場所を知りたいです。

受け入れ基準

しない:システムの可用性は100%である必要があります。 （100％は到達できず、検証できない絶対的なものです。)
Do：システムは、少なくとも98％の可用性を持っている必要があります。

受け入れ基準のクイックサマリー

この記事が受け入れ基準とユーザーストーリーの世界に光を当てることを願っています。, 受け入れ基準は、ユーザー、顧客、またはシステムレベルの機能の場合、消費するシステムが受け入れるためにソフトウェア製品が満たさなければならない条件です。

• 受け入れ基準は、チームと顧客がクライアントの要件を満たす結果に同意しなければならないため、プロジェクトの開始前に文書化され、完了する必
• 受け入れ基準は、最終的な決定ではなく、意図の表現でなければならないことを忘れないでください。
• 有効な受け入れ基準は、合理的な最小量の機能を定義します。,
• 適切な受け入れ基準は、開発者が適切に計画し、彼らの努力を推定することができるように、作業の範囲を概説する必要があります。
• 受け入れ基準は平易な言語で記述する必要があります。
• 受け入れ基準を利害関係者とチームメンバーに伝え、相互の合意に達するようにしてください。
• 受け入れ基準を書いている間は、”not”、接続詞、および達成不可能な絶対を使用しないでください。 アクティブな声を使用して文章を策定。,

モバイルアプリの受け入れ基準とユーザーストーリーを作成する場合、またはこのトピックに関する質問がある場合は、Mobindustryにお問い合わせください。