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

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

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

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

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

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

ユーザー ストーリーはユーザーの視点から、通常はわずか 1 ～ 2 文で書かれます。 ユーザーの視点とユーザーが何をしたいのかを捉えます。 優れたユーザー ストーリーが完成すると、戦略的目標、どの機能を削除しても安全か、または追加する必要があるかなどについて話すのが簡単になります。 なぜユーザーストーリーを書くのか疑問に思っているかもしれません。

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

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

所有者、将来のユーザー、プロジェクト マネージャーから意見を得ることができます。 強力なユーザー ストーリーを正確にするには、多くのインプットが必要です。 これらのグループから、自分たちが何をしたいのかについて明確な説明を受けてください。 これはユーザー ストーリーに直接反映されるべきではありませんが、必要な情報が提供されることに注意してください。 オーナーは、「人々が私のアプリで PayPal で支払えるようにしてほしい」と言うかもしれません。これは非常に便利ですが、ユーザー ストーリーそのものではありません。

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

これはワークフローによって異なります。 初期段階では、全体的なフレームワークを計画しながら、ユーザー ストーリーをインデックス カードやポストイットに記録します。 その後、それらはプロジェクト管理ソフトウェアに組み込まれます。 チームメンバーの中にはポストイットの段階を省略する人もいますが、他のメンバーはポストイットに依存します。どちらでも、自分に合った方法で行うことができます。 また、序文をどのように書けばよいのか迷っている方もいるかもしれません。

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

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

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

ユーザー ストーリーを書き始めます。読者の注意を引くために、長さは 1 ～ 2 文にする必要があります。 ここでは正確で専門的なことを言いたくなる傾向がありますが、ミッション ステートメントのような広範な表現が役立つ場合があります。 ストーリーを明確にして、解決・完了できることを確認して、「そう、ユーザーはこれができるようになった！」と振り返って確認できるようにします。

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

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

大幅に時間がかかりそうな場合は、ユーザー エクスペリエンスをさらに細分化して再構築する必要があるかどうかを再検討する必要があるというサインです。 新しい要件が追加された場合は、それをユーザー ストーリーに分割する必要もあります。 これらのいくつかの文は効果的なユーザー ストーリーの中核ですが、開発が進むにつれて拡張することもできます。 それについて詳しく見てみましょう。 UX ライティングとは何かを学ぶことに興味があるかもしれません。

ユーザーストーリーにおける 3 つの C とは何ですか?

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

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

ユーザー ストーリーをこのように綿密に調査すると、プロジェクト マネージャーや製品所有者に尋ねるべき追加の質問が生じる可能性があり、必要に応じて会話に参加させる必要があります。 会話が続くにつれて、全員が同じ認識になるまで、ユーザー ストーリーが変更、洗練、統合、または削除される場合があります。 ユーザー ストーリーが完成すると、実装に移行します。これは、会話が実質的に終了したことを示します。

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

受け入れテストは製品所有者の意見をもとに作成し、ユーザー ストーリーに直接結び付ける必要があります。 最良のシナリオでは、ユーザーはユーザー ストーリーが示すことを実行しようとして、それができるかどうかを確認するだけです。 しかし、受け入れテストはさまざまな場合があり、常にユーザー ストーリーを想定して作成されているわけではありません。 これによって問題が発生する場合は、受け入れテストとユーザー ストーリーが適切に調整されるまで、会話のステップに戻ります。 すべての受け入れテストが完了すると、ユーザー ストーリーは大喜びします。 ここで、製品開発の次のステップに進むか、機能をリリースするかのどちらかになります。

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

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

ユーザー ストーリーに適した形式とは何ですか?

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

【ユーザーが誰なのか】として、【ユーザーが何を望んでいるのか】（つまり【なぜユーザーがそれを望んでいるのか】）をしていきたいと思っています。

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

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

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

ユーザーストーリーの書き方に関するよくある質問

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