ユーザーストーリーの書き方: 完全ガイド

ユーザー ストーリーは、適切なアジャイル ソフトウェア開発の重要な部分です。ユーザー ストーリーの役割を見て、ユーザー ストーリーの書き方を学びましょう。

アジャイル フレームワークは、ソフトウェア開発を構築し、タスクを委任するための一般的で効果的な方法です。 ユーザー ストーリーの作成 (証言の作成方法と混同しないでください) は、アジャイル開発のツールであり、開発者が何をする必要があるか、要件を満たす方法を理解できるようにします。 そのため、非常に重要な出発点となりますが、慎重に構築する必要があることも意味します。 知っておくべきことは次のとおりです。

ユーザーストーリーとは？

これは、アジャイル フレームワーク内でのソフトウェア開発で使用される用語です。 ユーザー ストーリーは通常、アジャイル プロジェクトの最小単位、または要件を満たすための最初のステップと見なされます。 それらは、プロジェクトが完全に計画されたときに作成されます。

それで、それは正確にどういう意味ですか？ すべてのソフトウェア機能は、プロジェクトに追加されるときに特定の目的を持っています (または持つべきです)。 その目的は、その開発全体と、それが全体的なフレームワークにどのように組み込まれるかに影響するはずです。 開発者は、特に目標をどのように分類し、何を優先するかについて、決定を下す必要があるときはいつでもこの目的を参照できます。 「ユーザー ストーリー」は、単に機能の目的を説明する方法です。

ユーザー ストーリーは、ユーザーの視点から、通常は 1 ～ 2 文で記述されます。 ユーザーの視点とユーザーが何をしたいのかを捉えます。 完成した優れたユーザー ストーリーは、戦略的な目標、どの機能を安全に破棄できるか、または追加する必要があるかなどを簡単に説明できます。

ユーザーストーリーの書き方

ステップ 1. 入力を取得する

所有者、見込みユーザー、およびプロジェクト マネージャーから情報を入手します。 強力なユーザー ストーリーを正確に作成するには、多くのインプットが必要です。 彼らが何をしたいのかについて、これらのグループから明確な説明を受けてください。 これはユーザー ストーリーに直接変換されるべきではありませんが、必要な情報が提供されることを忘れないでください。 所有者は、「私のアプリで PayPal で支払いができるようにする必要があります」と言うかもしれません。これは非常に便利ですが、ユーザー ストーリーそのものではありません。

ステップ 2.ユーザー ストーリーの作成方法を決定する

これは、ワークフローによって異なります。 初期段階では、全体的なフレームワークを計画しながら、ユーザー ストーリーをインデックス カードまたはポストイットに取り込みます。 その後、それらはプロジェクト管理ソフトウェアに組み込まれます。 チーム メンバーの中には付箋の段階を飛ばす人もいれば、それに依存する人もいます。どちらでも構いません。

ステップ 3. 定義、定義、定義

ユーザーの定義: 入力を使用して、ユーザーを定義できるようになりました。 これは必ずしも製品機能のエンド ユーザーではないことに注意してください。 ユーザーのタイプによって異なります。 必要に応じてユーザー ペルソナを作成します。 ユーザーが実行しているアクションを定義し、このアクションを実行する際のユーザーの目標を定義します。 ユーザー ストーリーを作成してターゲット ユーザーにアピールする際は、この重要な情報を含めてください。

ステップ 4. ストーリーを書く

ユーザー ストーリーを書き始めます。読者の注意を引くために、1 文か 2 文で十分です。 ここでは正確で技術的なことを言いたくなるかもしれませんが、ミッション ステートメントのような幅広い言葉が役立つ場合があります。 ストーリーを明確にし、それが解決または完了できることを確認して、振り返って「はい、ユーザーはこれを実行できるようになりました!」と確認できるようにします。

ステップ 5. さらにステップに分割する

ユーザー ストーリーは、最終目標に到達するために複数のステップを必要とする場合があり、使用しているアジャイル フレームワークによっては、多少の再構築が必要になる場合があります。 ユーザー ストーリーは常にフレームワークの最小単位であることを忘れないでください。 この詳細なレベルでは、ユーザー ストーリーの実装には数日かかるはずです。

大幅に時間がかかると思われる場合は、再検討して、ユーザー エクスペリエンスをさらに分解して再構築する必要があるかどうかを確認する兆候です。 新しい要件が追加された場合は、それらもユーザー ストーリーに分割する必要があります。 これらのいくつかの文は効果的なユーザー ストーリーの核心ですが、開発が進むにつれて拡張することもできます。 それを詳しく見てみましょう。

ユーザーストーリーの 3 つの C とは?

カード: カード フェーズでは、開発チーム向けのユーザー ストーリーを 1 ～ 2 文で書くことを指します。 ユーザー ストーリーはもともとインデックス カードに書かれていたため、カードと呼ばれ、多くのチームは今でもそのようにすることを好みます。 カードは、特定のソフトウェア要件の中核であり、すべての議論の出発点です。 ユーザー ストーリーが長すぎるかどうかを確認するのも簡単です。誰もが読めるインデックス カードに収まらない場合は、短くする必要があります。

会話: カードの文章が作成されたら、詳細を打ち込みます。 これは通常、開発者間の一連の質問から始まります。たとえば、「これを実装するにはどれくらいの時間がかかりますか?」などです。 または「このアクションをどのように組み込むことができますか?」 または「このユーザー ストーリーはここで不可欠ですか?」 等々。

このユーザー ストーリーの綿密な調査により、必要に応じて会話に参加する必要があるプロジェクト マネージャーやプロダクト オーナーに尋ねる追加の質問が得られる可能性があります。 会話が続くにつれて、全員が同じページに到達するまで、ユーザー ストーリーは変更、改良、統合、または削除される可能性があります。 ユーザー ストーリーが完成すると、それらは実装に移されます。これは、会話が実質的に終了したことを示しています。

確認: 確認とは、受け入れテスト、つまり受け入れ基準に関するものです。 変更が実装され、開発者が準備が整ったこと、つまりユーザー ストーリーが満足されたことを報告したら、それをテストします。

受け入れテストは、プロダクト オーナーの意見を取り入れて作成し、ユーザー ストーリーに直接結びつける必要があります。 最良のシナリオでは、ユーザー ストーリーが示すことを実行しようとして、それが可能かどうかを確認するだけのユーザーです。 ただし、受け入れテストはさまざまであり、常にユーザー ストーリーを念頭に置いて作成されているとは限りません。 これで問題が発生した場合は、受け入れテストとユーザー ストーリーが適切に調整されるまで、会話のステップに戻ります。 すべての受け入れテストが完了した場合、ユーザー ストーリーは大喜びです。 製品開発の次のステップに進むか、機能をリリースするときです。

4番目のC？ : 興味深いことに、重要な 4th C: Context があると主張する人もいます。 この場合、ユーザー ストーリーは、プロジェクトのより大きなフレームワークで他のユーザー ストーリーと一緒に表示されます。 ここで、開発者は、ユーザー ストーリーが他のユーザー ストーリーをスムーズに補完するかどうか、またはユーザー ストーリー間で見落とされている、ユーザーが行う必要があることや理解する必要のあるギャップがあるかどうかを尋ねます。

理想的には、これは会話フェーズで発見されますが、常にそうなるとは限りません。 一部の開発チームは、完成したユーザー ストーリーがより大きな全体にどのように適合するか、さらに作業を行う必要があるかどうかの最終レビューを必要とする場合があります。

ユーザー ストーリーに適した形式とは?

ユーザー ストーリーの文章を作成するときに非常に役立つ 2 つの書式設定テクニックを見ていきましょう。 1 つ目は非常にシンプルです。「誰が、何を、なぜ？」 文のテンプレートでは、次のように記述できます。

【ユーザーとは】として、【ユーザーが何を求めているか】（なぜ【ユーザーがそれを求めているか】）をしたい。

このテンプレートは、簡略化された用語で、「[役割] として [アクション] を行いたい ([利益] になるように)」のように組み立てることもできます。 この基本的な形式に従うだけで、ほとんどのユーザー ストーリーを作成できます。 通常はこれだけで十分であり、各ユーザー ストーリーに使用すると多くの時間を節約できます。

ただし、より複雑なプロジェクトでは、ユーザー ストーリーを定義するのが難しい場合があります。 この場合、2 つ目のユーザー ストーリー テンプレート手法が役立つ場合があります。 これは INVEST と呼ばれ、次の頭字語です。

• 独立: ストーリーは互いに完全に独立している必要があり、結果としてストーリーは順不同で作業できる必要があります。
• 交渉可能: ストーリーは、プロセスの会話部分で変更できるように設計する必要があります。
• 価値がある : ユーザー ストーリーは、プロジェクトにとって明確な価値を示す必要があります。 それができない場合は、リソースの浪費になる可能性があります。
• 推定可能: ユーザー ストーリーは、重要度の高い順に何に取り組むかを決定するのに役立つように、価値と優先順位付けで測定する必要があります。
• Small : ユーザー ストーリーは機能の最小単位である必要があり、それ以外の場合はさらに細分化する必要があります。
• テスト可能: ユーザー ストーリーは、確認プロセス中にテスト可能な方法で記述される必要があります。

ユーザーストーリーの書き方に関するFAQ

また、ゲーム レビューの書き方に関するガイドにも興味があるかもしれません。