ユーザー ストーリーとは何ですか?
アジャイル運動の開始者の一人、アリスター・コックバーンによると、「ストーリー カードは会話の約束です」と言います。具体的には、ソフトウェア機能をその視点から説明する顧客との会話です。これはユーザー ストーリーの基礎であり、アジャイルおよびリーン ソフトウェア開発のライフサイクルに不可欠な部分です。テーマ、イニシアチブ、エピック、ストーリーはすべて、大小を含む構成要素であり、ユーザー中心のソフトウェア ソリューションを構築するために必要な機能を整理するのに役立ちます。この用語は、文学的な角度から見るとよく知られているように見えるかもしれませんが、正しいものです。ユーザー ストーリーはシンプルなストーリーであり、関連するストーリーはエピックを構成します。これらの用語がどのように連携するかは次のとおりです。
-
テーマ: 野心的な目的または大まかな目標。
-
イニシアチブ: 主な目標を達成するのに役立つエピックのコレクション。
-
エピック: 大まかなビジネス ニーズや大規模なユーザー ストーリー。これらは単一のイテレーションで実装するのが難しいため、小さなストーリーに分割されます。エピック全体は通常、単一のリリースに含まれます。
-
ユーザー ストーリー: ある程度の価値を提供し、ユーザーの視点から書かれた短い要件やユーザー シナリオ。各ストーリーはスプリントまたはイテレーションによって制限されます。
この例は次のとおりです。
テーマ (左端) は、関連するイニシアチブ、それらのイニシアチブをサポートするエピック、詳細な要件を説明するストーリー (右端) で構成される大まかなビジネス目標です。
ソフトウェア開発組織は、ソリューションを近代化するという高い目標を持っているかもしれません。このタスクを達成するには、忘れられないユーザー エクスペリエンスを提供する必要があります。たとえば、そのユーザー エクスペリエンスは、最新の Web インターフェイスを提供し、迅速に実行し、さまざまなユーザー デバイスで作業する必要があります。このシナリオでは、これらのエピックのそれぞれが特定のユーザー ストーリーに分割されます。
エピック ユーザー ストーリーとは?
エピックは、高レベルのビジネス ニーズまたは大規模なユーザー ストーリーです。エピックは複雑すぎて 1 回のスプリントまたはイテレーションで実装できないため、いくつかの小さなユーザー ストーリーに分割されます。エピックのメリットは、多数のユーザー ストーリーを作成する前に、より大きなアイデアを開発し、協力できることです。エピックは当初のアイデアとして維持され、将来の参照ポイントを作成できます。
ユーザーストーリーの目的は何ですか?
ユーザー ストーリーは、ソフトウェア ソリューションの開発を支援することを目的としています。残念ながら、単に意図した顧客ベースに訴えないソフトウェア ソリューションを開発することは珍しくありません。ユーザー ストーリーは、ソフトウェア機能が期待に確実に応えられるよう、エンド ユーザーの要件を明確かつ徹底的に理解することで、このリスクを軽減することを目的としています。
企業はユーザー ストーリーをどのように使用していますか?
ユーザー ストーリーは、アジャイル開発で使用される主なアーティファクトの 1 つです。これらは、機能的および非機能的な機能と要件を説明し、開発を目的とした機能の優先順位付けされたリストを構成するために作成されます。このリストは製品バックログと呼ばれています。
ユーザー ストーリーは、ユーザー ストーリーを水平軸と垂直軸に沿って並べ、さまざまなレベルの使いやすさを表すために使用されるユーザー ストーリー マップの一部になります。水平軸は、ユーザーがシステムとどのように相互作用して機能を実行するかを説明するアクティビティを示します。垂直軸は、複雑さのレベルの増加を表します。最初の行は、関数の基本的な描写です。次の行では、もう少し機能が追加されます。各ユーザー ストーリーには、ストーリー ポイントまたは機能の開発に必要な工数や難易度の理論的な見積もりが割り当てられます。多くの組織では、自動化されたストーリー マッピング ツールを使用しています。最も人気のあるツールは、Jira、Ca によるラリー、ストーリー オンボード、フィーチャー マップです。
ユーザー ストーリー マップ テンプレート
また、このテンプレートを使用して独自のストーリー マップを構築することもできます。Microsoft Word を使用してテンプレートを完成するか、壁に貼り付けるポスト it ノートを使用してテンプレートを再作成できます。組織の開発ニーズに基づいてボックス化の数を調整します。
ユーザー ストーリーの特徴は何ですか?
使用されるアジャイル フレームワーク、エクストリーム プログラミング (XP)、カンバン、DAD (規律アジャイル デリバリー)、AMDD、スクラムにかかわらず、ユーザー ストーリーは同じです。ユーザー ストーリーには、ペルソナ、必要な機能、機能から得られるメリットなど、ユーザーのタイプが記述されています。強力なユーザー ストーリーは、役割特徴理由 (RGB) 構造に従って書かれています。
ユーザー ストーリーには次の資質が必要です。
-
ユーザー価値を示すのに十分な完成度があります。
-
ユーザー中心です。
-
エピックから始めます。
-
短く、シンプルで、明確です。
-
必要に応じて、関連ファイルとドキュメントを含めます。
-
価値を示すのに十分な包括的でありながら、1 回のイテレーションで開発できるほどシンプルです。
-
すべての関係者の意見に基づいて書き込みます。
-
他のストーリーや機能に影響を与えることなく、柔軟で交渉可能です。
-
テストが簡単です。
-
テスターの受け入れ基準 (満足度条件) を含めます。
ユーザー ストーリーとシステム要件という用語が同じ意味で使用されているのを聞くかもしれません。従来、 Waterfall 開発ではシステム要件を使用してソフトウェア ソリューションの機能を定義していました。リスク、範囲、その他の開発固有のガイドラインを含む広範な詳細に説明します。一方、ユーザー ストーリーはシンプルで、議論を促進し、コラボレーションと変化を受け入れるアジャイル開発手法をサポートします。
前述のとおり、ユーザー ストーリーはシンプルでありながら完成している必要があります。たとえば、優れたユーザー ストーリーは次のようになります。
銀行の顧客として、銀行を訪問する必要がないように、小切手をオンラインで入金できるようにしたいと考えています。
ここでは、詳細すぎるユーザー ストーリーの例を示します。
銀行の顧客として、オンラインで小切手を入金し、過去の入金レポートを表示および印刷できるようにしたいので、銀行に行く必要はありません。
ストーリーポイントとは?
各ユーザー ストーリーには、ストーリー ポイント (ストーリー ポイントの開発と実装に必要な工数や難易度の測定) が割り当てられます。チームでは、1 桁の数字 (1、2、3)、複数の数字 (100、200、300)、または選択したその他の数字形式を使用できます。比率が重要な要因です。たとえば、200 のストーリー ポイントが割り当てられたストーリーには、100 のストーリー ポイントを割り当てられた 1 つのストーリー ポイントの 2 倍の工数が必要です。
ユーザー受け入れ基準とは?
満足条件とも呼ばれる受け入れ基準は、ソフトウェア ソリューションがエンド ユーザーや関係者のニーズを満たしていることを保証します。この基準には、パフォーマンス要件、標準、シナリオ、システム動作ルールが含まれます。テスト チームは、受け入れ基準を使用して開発が完了したことを確認します。これらのパラメータが満たされると、ストーリーや機能は「完了」とみなされます。
効果的なユーザー ストーリーの書き方
特に製品の機能の基礎であるため、最初のユーザー ストーリーの作成は難しい場合があります。ユーザー ストーリーは開発の初期段階で最も一般的に開発され、イテレーションとスプリントの計画で使用されますが、いつでも作成できます(開始時に、プロジェクト/ソリューション全体のスコープを提供し、建設、新しいストーリーを特定し、不要なストーリーを削除し、ストーリーをより小さな部分に分割し、移行) し、次のイテレーションのバックログに追加します。
以下の 10 のヒントは、効果的なユーザー ストーリーの作成に役立ちます。
-
ユーザーを第一に考える: ユーザー ストーリーの目的は、ユーザーの視点から機能を実証することです。必ずユーザーにインタビューまたはアンケートを行い、ユーザー定義の事実に基づく情報を含めます。場合によっては、ユーザーは人ではなく、システムである場合があります。
-
ペルソナの定義: ユーザーを理解することは、ユーザー ストーリーを作成する上で不可欠な要素です。ターゲットとなるエンド ユーザーを表す架空のキャラクターを作成します (これには、消費者、バイヤー、頻繁な買い物客、会計士、人事の専門家が含まれます)。購買行動、解決しようとしている問題、全体的な目標はすべて、理想的な顧客に関する重要な情報です。ストーリーを作成する際には、一般的なユーザーの役割ではなく、これらのペルソナ名を使用します。
-
共同作業: ユーザー ストーリーの作成中に、関連するすべての関係者を部屋に入れて共同作業を行います。製品管理、エンジニア/開発者、テスター、カスタマー サポート、セールス、顧客はすべて表現する必要があります。
-
シンプルさを維持する: ストーリーをシンプルで明確に保ちます。積極的な声を使い、重要な事実だけに焦点を当てます。
-
エピックとリファインから始める:より大きなユーザー ストーリーから始めて全体的な機能を完全に理解し、実際の機能の詳細を掘り下げる。大規模なプロセスの各ステップは、ユニークなストーリーにする必要があります。このプロセスを使用すると、ストーリーを単一のスプリントまたはイテレーションに適合させることができます。
-
受け入れ基準を含める: 特定のストーリーの「完了」を定義する受け入れ基準を書きます。受け入れ基準は、テスト チームがユーザーの準備が整っていることを確認するためにテスト ケースに最適な貢献者です。
-
ポスト it ノートまたはインデックス カードから始める:ユーザー ストーリーがエクストリーム プログラミング (XP) の一部として初めて登場したとき、それらはシンプルなインデックス カードでキャプチャされました。この方法を使用すると、共同作業やディスカッション、可視性、透明性が促進され、共同作業環境で物事を動かし、ストーリー ボードを簡単に移動できます。
-
アクセス可能な領域にユーザーストーリーを表示する:ユーザー ストーリーを壁やホワイトボードなどのオープンな領域に表示することで、開発プロジェクト全体の共同作業が促進されます。ストーリー表示は、図、モックアップ、ワークフロー図、ストーリー マップ、スケッチで強化される場合があります。
-
フィードバックを受け入れる:アジャイル開発は柔軟性を受け入れます。フィードバックを使用すると、機能を改良して、製品がユーザーに価値を提供していることを確認できます。
-
時間見積もりを含める: ユーザー ストーリーに基づいて開発を完了するのにかかる時間は、イテレーションとリリースを計画する上で重要です。時間の見積もりは、チーム メンバーにタスクやサブタスクを割り当てるのに役立ちます。
ユーザー ストーリーの作成に役立つ主なテクニックは 2 つあります。
-
3 つの Cs: 2001 年にロン・ジェフリーズによって開拓された 3 つの Cs の公式には、カードまたはポスト it のメモ、ユーザー、開発者、テスター、製品所有者間の会話が含まれており、目標が達成されたことを確認します。
-
INVEST: 2003 年にビル・ウェイクによって導入され、Mark Cohn の著書『アジャイル・ソフトウェア開発に適用されたユーザー ストーリー』によって普及したこの基準では、ユーザー ストーリーが独立し (任意の順序で開発可能)、交渉可能で価値のある (ユーザーまたはビジネスにとって)、評価可能 (完了用)、小さな (設計、テスト、コードを 1 回のイテレーションで)、 テスト可能であることに関して、ユーザー ストーリーの価値を評価します。
ユーザー ストーリーの作成の詳細や、開始に役立つヒントやテンプレートについては、「実際にユーザーに焦点を当てたソフトウェア開発でユーザー ストーリーを作成する方法」をご覧ください。
ユーザー ストーリーを書くのは誰か?
必ずしも誰がユーザー ストーリーを書くのかではなく、誰がユーザー ストーリーの開発プロセスに関与しているかについてです。目標は、ユーザー ストーリーを生み出す共同作業のディスカッションです。製品管理、エンジニア/開発、テスター、顧客サポート、販売、そして最も重要なこととして、顧客がプロセスに参加する必要があります。製品マネージャーまたは製品所有者は、通常、開発ライフサイクルを通じてユーザー ストーリーを所有します。
アジャイルで完了の定義は何ですか?
アジャイル開発では、各チーム独自の完了または完了の定義があり、この定義は、ユーザー ストーリー、スプリント、完全リリースなど、完全性について評価される内容によって異なる場合があります。機能や機能が真に完成していることを確認するために、基準を定めることができます。基準のチェックリストには、以下が含まれます。
-
コードは書かれていますか?
-
コードはテストされましたか?
-
この機能は受け入れ基準を満たしていますか?
-
この機能は既存のソリューションと統合して機能しますか?
-
製品技術仕様書が更新されましたか?
-
製品ドキュメントは更新されましたか?
ユース ケースとユーザー ストーリーは同じですか?
ユーザー ストーリーとユース ケースという用語は似ていますが、ユース ケースにはユーザー ストーリーと比較してはるかに詳細な詳細が含まれています。ユーザー ストーリーは共同作業の際に書かれ、ユーザーの視点、ユーザーの目標、受け入れ基準を表します。
ユース ケースとユーザー ストーリーは同じですか?
ユーザー ストーリーとユース ケースという用語は似ていますが、ユース ケースにはユーザー ストーリーと比較してはるかに詳細な詳細が含まれています。ユーザー ストーリーは共同作業の際に書かれ、ユーザーの視点、ユーザーの目標、受け入れ基準を表します。
この同じ情報がユース ケースに含まれますが、ユースケースはさらに深く行き、ユーザー/システムのやり取りのすべての手段や考えられるリスクを含む、ソリューションの機能要件を概説します。多くの開発プロジェクトでは、ユーザー ストーリーの作成、ストーリー マッピング、ユース ケースを統合して、完全で徹底的な製品を構築します。
ユーザー ストーリーの例、メリット、課題
ユーザー ストーリーは通常、機能属性に基づいて作成されます。たとえば、「顧客として、銀行や ATM への運転を避けるために、小切手を電子的に入金したい」とします。しかし、重要な機能以外の特徴や技術的な制約もあります。この同じ銀行の例を使用すると、「顧客として、1 つの電子取引に 12 の小切手を入金したい」という技術的な制約が書き込まれます。具体的な詳細 (より技術的に思えるかもしれませんが) を理解することで、開発チームは、それを実現するためにオープンエンドのユーザー ストーリーに取り組む必要がある制約について考えることができます。
ユーザー ストーリー テンプレートやその他のアジャイル テンプレートは、こちらからダウンロードできます。
ユーザー ストーリーのメリット
ユーザー ストーリーはアジャイル開発の一般的な要素であり、適切に使用することで、ソリューションを開発する人やソフトウェアを使用している顧客に広範なメリットをもたらします。
ユーザー ストーリーの課題
ソフトウェア開発用の Smartsheet でユーザー ストーリーの可視性を向上させる
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。