ユーザーストーリーと要件
ユーザーストーリーは、ユーザーがシステムで何をしたいかを高レベルでキャプチャします。ユーザーストーリーがさらに多くの低レベルの要件を促進することを理解しています。ユーザーストーリーはシステムの高レベルの要件と同じですか？
正直に言うと、アジャイル開発に没頭して2年近く過ごした後も、「ユーザーストーリー」は「機能要件」の空想的な用語にすぎないと私は思います。
表面的なレベルでは異なります。それは常に特定の形式（ "Xとして、私はYがZになるようにしたい..."）をとりますが、重要な要素-利害関係者の識別と根拠-よく書かれた機能要件にも固有です。悪い要件（ "を[会社名]として書くのと同じくらい簡単に、悪いユーザーストーリーを書くのは簡単です。[あいまいな機能]を使用して、 「顧客にもっと販売する」など、私の仕事の一部であることは明らかです]] "）。
私の経験では、ほとんどのユーザーストーリーは決してキャプチャしません非機能的ですパフォーマンスやセキュリティなどの要件。これらの種類の要件は、適切に記述することが非常に困難であり、ユーザーストーリーの形式は、特定のユーザーの要件を満たすことではなく、一般的な製品品質とリスクの軽減（ただし排除ではない）に関するものであるため、それらをキャプチャするのにあまり適していません。必要。
したがって、ユーザーストーリーは、特定の式を使用した要件のサブセットであると実際に考え、用語をほとんど同じ意味で使用しています。
ユーザーストーリーの要件に対する主な利点の1つは、Wordの "要件"によって、機能が必須であることが示唆され、多くの場合、望ましい。理論的には、ユーザーストーリーに優先順位を付けて、どのリリースでも組み込むことができますが、要件はeveryリリースの前提条件のようです。
もちろん、前述の区別が問題となるためには、顧客や上級管理職がそれを採用する必要があります。すべてが同時に完了する必要のある「プロジェクト」にグループ化された30のユーザーストーリーがある場合、それはまったく役に立ちません。それらは実際に必要なので、その場合は「要件」と呼ぶこともできます。
Ron Jeffriesは、ユーザーストーリーの3C（ http://xprogramming.com/articles/expcardconversationconfirmation/ ）について、カード（短い説明）、顧客とユーザーストーリーが実行可能になると、配信チーム、およびその会話の後に合意されたストーリーの確認。
基本的に、会話の前は、ユーザーストーリーは計画された範囲であり、私たちが何をするかについての大まかなアイデアです。会話の後で、ストーリーが完了したことを確認する方法が必要です。したがって、このタイムラインでストーリーを見る時間に応じて、ストーリーはスコープに関する広範なアイデア、または詳細な要件になる場合があります。
最近では、「ユーザーストーリー」の意味は、ジェフリーズの3Cの「カード」部分だけに絞られているようです。その場合、ユーザーストーリーは必須ではありませんが、要件について会話することを約束します。
C2ウィキ（ http://xp.c2.com/UserStory.html ）で、ユーザーストーリーについての知恵の金塊を見つけることができます。
ユーザーストーリーと要件はまったく異なります。
必要条件
要件は、アプリケーションの設計が事前に行われ、開発がその設計の実装であることを前提としています。したがって、機能はhowに重点を置いて機能を実装します。
要件の例：
- 次のフィールドを使用して、ユーザーの連絡先フォームを作成します：名前、姓、電子メール、フリーテキスト、および送信ボタン。送信ボタンを押すと、サポートチームにメールが送信されます。
ユーザーストーリー
ユーザーストーリーはwhatに重点を置いており、製品の設計は土壇場で行われ、製品担当者と開発者の共同作業であると主張します。詳細は、機会に基づいて実装時に決定されます。
ストーリーの例：
- Jimmyのユーザーとして、サイトを適切に使用できない場合にサポートチームに連絡して支援を求めたいと考えています。
違いはなんですか？
ご覧のように、提供される詳細の量には確かに違いがありますが、ストーリーでのみ利用できる多くの情報、つまり目的が試みているものもありますこの機能を使用して実現します。
目的は比較的重要ではないように見えるかもしれませんが、これはアジャイル開発では間違った仮定です。通常、目的を知ることが非常に重要である2つのケースがあります。機会のコストを削減し、俊敏性を有効にすることです。
機会費用
要件に隠された仮定がある場合、それを達成することは非常に困難です。例：利用可能なメールサーバーはありますか？そうでない場合、要件の開発にはさらに長い時間がかかる可能性があります。他のいくつかのケースでは、同じ目標を達成するためのより簡単な方法は、設計のために見落とされる可能性があります。
対照的に、ユーザーストーリーとは、ユーザーがサポート部門に連絡することです。メールの送信が不可能または高すぎる場合は、その場で別の解決策を考案できます。たとえば、データベースに書き込むか、Googleドキュメント経由でフォームを使用するか、フォームの代わりにメールアドレスを入力します。これは要件で簡単に行うことはできませんが、ストーリーと製品担当者が存在することで簡単に行うことができます。
機敏
このため、要件では一般に、これらの隠された仮定を事前に考え、問題がないことを確認する傾向があります。そのため、この場合、事前にスケジュールされた別の要件があり、メールサーバーが存在することを確認しました。
これにより、ストーリーと要件の間に別の大きな違いが生じます階層。上記で例示したように、依存関係が満たされるように、要件はそれ自体の性質により、いくつかの自然な階層で順序付けられる必要があります。一方、ストーリーは目的に焦点を当てており、そのような制約はありません。
これは設計によるものです。アジャイルでは、プロジェクトの実行中に必要に応じてストーリーを追加、削除、再スケジュール、および変更することが基本的に重要です。要件は通常、追加したり、場合によっては変更または削除したりできますが、すべての依存関係のため、要件を移動することは一般に非常に困難です。あまり頻繁には行われません。要件に取り組んでいる場合、アジャイル実装は、変化を受け入れることができるという意味で、影響を受けるか、まったくアジャイルにならない可能性があります。
私にとって、ユーザーストーリーの重要な要素は、ユーザーがシステムを使用する理由と方法をキャプチャすることです。これは、システムが必要な機能を提供する方法をあまり指定しないため、特に役立ちます。 UIとユーザビリティのテストが必要な場合、ユーザーストーリーが最も重要なドキュメントになる可能性があります。
もちろん、Seleniumで特定のノードがHTMLに存在することを確認したり、スクリーンショットを撮ったり、特定のピクセルが希望どおりの場所にあることを確認したりできます。しかし、誤解を招くようなテキストがある場合、またはユーザーがシステムをどのように使用する必要があるかが明確でない場合、またはユーザーが目標を達成する方法を理解するのが難しい場合、突然、完全なシステムがなくなります。このシステムを使用するには、トレーニングが必要です。完成したシステムをユーザーシナリオに照らしてレビューすることは、手動テストの重要なコンポーネントです。
ユーザーストーリー/シナリオには、実装に関する多くの詳細な設計決定に影響を与えるマインドセットがあります。開発者がユーザーと直接話をしたり、システムの使用を監視したりしない限り、ユーザーのシナリオは、ユーザーのニーズを理解するための唯一のリンクになる可能性があります。
最後に、ビジネス人々は、それがどのように達成されるべきかを示唆することなく、必要なものを指定することを可能にします。ソリューションはニーズよりもはるかに簡単に説明できます。ユーザーシナリオは、特定のソリューションを提案することなく、ニーズを説明するためのフレームワークを提供します。私が聞いた最も一般的なビジネス要件は、「Excelのようになりたいが、Web上にありたい」というもので、これはまだ実際に必要なものではありませんでした。
したがって、良いストーリーには、システムの実装方法に関する具体的な詳細を含めないでください。 「1か月に1回、システムAをシステムBからの新しいデータで更新する必要があります。そのデータには修正が必要な場合があります。クライアントには無効なデータを入力し、何週間も問題を認識していない履歴があります。」 「列3が数値でない場合、システムは少なくとも月に1回はlatin1 CSVファイルを受け入れ、NumberFormatExceptionをスローする必要があります。」違いがわかりますか？シナリオでは、具体的なソリューションではなく、ニーズについて説明します。次に、テストでシナリオに戻り、ソリューションがニーズに合っていることを確認します。要件によっては、一部のニーズと一部のソリューションが混在する場合や、完全にソリューションに集中する場合もあります。
グーグル検索の最中にこれに遭遇し、私は自分の意見を投げ入れようと思いました。
要件とユーザーストーリーの間に違いはありません。どちらも、ユーザーの観点から望ましい結果または目標を述べています。
唯一の違いは、この目標または結果がビジネスアナリストによってキャプチャされる方法です。この場合、それは言い回しの中にあります。
例：
チームリーダーとして、どのチームが住宅ローンの案件に取り組んでいるかを確認して、彼らのパフォーマンスを監視できるようにしたいと考えています。
ソリューションは、住宅ローンのケースに取り組んでいるチームメンバーを表示します。
上記はどちらも同じように解釈できますが、どちらにも曖昧さがたくさんあります。ここでのポイントは、スタイルの違いです。私たちが主に目にする問題は、要件の世界から機能設計の世界に移る前に、ソリューションを定義するためにどこまで進むかです。 「ログインしているユーザーをメインアプリケーションメニューにファーストネームとセカンドネームでリストする」というのはビジネスアナリストの責任ですか、それとも情報が多すぎますか？利害関係者と話し合って、誰もがソリューションを知っていて、それがどのように見えるかを解釈できるとき、その上に構築される可能性のあるコード言語とそれが展開される方法でさえ、私たちは本当に純粋なゲームをプレイする必要がありますか？解決策ではなく目的を定義しましょう。」これは私が本当に混乱を感じるところです。
多くの場合、要件は、ソリューションについて何も知らないという前提に基づいており、望ましい結果だけを求めています。はい、これはすべてのソリューションにとらわれませんが、開発サイクルで本当に役立ちますか？何かを早期に正確に定義できるのであれば、なぜそれをしないのですか？
全体として、ユーザーストーリーや要件の違いについては心配しません。最終的には、誰かがソリューションを開発するのに十分な情報を定義する必要があります。高すぎるユーザーストーリーは単にノックバックされ、より小さなユーザーストーリーに分割するように要求されます。 「システムが必要」スタイルと同じです。十分な詳細がない場合、要件は多分あいまいであるため、おそらくノックバックされます。
最終的には、開発者や利害関係者がそれから見て、そこから作業したいものを選びます。
古典的な教科書であっても、Wordの要件が何を意味するかについては多くの不整合があると思います。同じ矛盾がユーザーストーリーにも当てはまります。組織や教科書によって、これらの用語の扱いは異なります。たとえば、Roger Pressmanの古典的なソフトウェアエンジニアリングのテキストが要件について語る方法は、Dean Leffingwellのアジャイルソフトウェア要件の本とはかなり異なります。私はそれらを両方尊重し、それらは両方とも有効である場合もあります。
要件とは、想像力にほとんど委ねられていない、非常に特殊なコードをコーディングするものです。一方、要件はビジネスの問題が何であるかを指定し、解決策を指定するべきではないと主張することができます。私はそれはより微妙であると思います、そして答えはそれぞれの会社や業界に固有のスペクトルのどこかにあります（すべてのソフトウェア開発がITで行われるわけではありません）。
要件elicitationは分析につながり、設計につながり、要件につながるアーキテクチャにつながると教えられました- elaborationまたは仕様。これは、コード化できるものにつながります。これがアジャイルでなくなるとは思いません。これらのことが起こるタイミングは変わりますが、それが最も重要な違いです。ウォーターフォールモデルでは、顕在化と精巧化は早期に行われます。リーンとスクラムでは、スプリントでの実装に近づくにつれて、より多くの精緻化が発生するさまざまな段階で、顕在化と精緻化が行われます。創発的な設計作業もそうです。
私たちの組織では、要件ではなく、作業の内訳と優先順位付けとして、エピック、機能、およびストーリーのレフィンウェルモデルに依存しています。要件は別のものです。規制当局に対して必要となるため、要件は個別に管理されます。それでも、一部のチームは、プログラムの増分とスプリントの計画中にユーザーストーリー内の要件を確実に開発しています。
誰もが過去の経験に応じてすべてを異なる方法で実装し、ラベルを付けることになると思います。そして仕事を成し遂げるその会社のためにどんな言語が機能しても、議論する価値はありません。
ただし、IMO、ユーザーストーリーは、「建物内の顧客または顧客がすぐに利用できる」というアジャイルのアプローチに従います。詳細は顧客の頭にあり、正式なSRSがすぐに利用できるため、ドキュメントは必ずしも必要ありません。必要ありません。これで、「ユーザーストーリー」の「タスク」は、開発者がユーザーストーリーを消化可能に構築する方法です。
ユーザーストーリーの例は次のとおりです。
管理者ユーザーとして、グリッドにリストされたクライアントデータを表示したい
「タスク」は次のようになります。
表示するデータをリストするグリッドを作成します
選択した列をソートするグリッドでソートを有効にします
これで、各タスクがそれぞれのスプリントで見積もり、完了しました。
「顧客が把握するのが難しい」という「伝統的な」観点から、これを書き留めて、計画/コーディングを開始する前にそれが正しいことを確認できるようにする必要があります。ソフトウェア要件仕様はお客様の頭に浮かんだアイデアを引き出し、書き留めて形式化し、ベースライン化して管理します。
この場合、「機能要件」は、そのSRSの細部に至るまで詳細であり、より大きなアイデアの一部です。したがって、私の意見では、ユーザーストーリーは正式な "要件"（の一部）と見なすことができ、そのユーザーストーリーのタスクは機能要件（または多くの機能要件の1つ）です。
ユーザーストーリーの例では、正式な「要件」はフローチャートを含む長いドキュメントであり、顧客中心の「アジャイル」アプローチとは対照的に、一般にドキュメント中心になります。
違いは、正式な「要件」は、いくつかのリストが必要になること、いくつかの役割ベースのセキュリティなどが示されることを示す、アプリの管理セクションを概説する約10ページのドキュメントの行に沿っていることになります。要件は、「リストグリッドが並べ替えを有効にする」、「ユーザー情報がグリッドにリストされる」などです。
そして、私は最近、これらの用語がすべて混合され、混じっていると信じています。
機能要件は通常、ソフトウェアが機能するかどうかを正確に知ることができる正式な仕様です。ユーザーストーリーは、通常、ユーザーストーリーの必要性を説明するより非公式な方法です。ソフトウェアが「有効」か「無効」かを判断する厳密な仕様は指定していません。あなたはそれの一部をテストすることができますが、ユーザーストーリーの本当の完成は（あなたがそれらを正しく行うなら）、ユーザーが「うん、それで私の問題は解決します！」と言うときです。アジャイルマニフェストを覚えておいてください。
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
マイクコーンは彼の著書「User Story Applied」で、一部のものがユーザーストーリーにマッピングされず、onlyを使用する必要がないと具体的に述べていますそれ。
私自身のチームでは、以下を使用しています。
- ユーザーストーリー：ある種のユーザーのビジネスニーズ。ここで強調しているのはneedであり、whyはそれが必要なのです。他の人が言ったように、ここで重要なことは、それがどのように行われるかを指定することではなく、ユーザーの本当の必要性に深く踏み込むことです（例：彼はしませんneedテーブルのデータを表示するには、データの正確な値を確認する必要があり、それを行うにはテーブルに精通しています）。
- バグ：通常の使用を損なうソフトウェアの予期しない動作。通常、「重要度」（開発の優先度に関係なく）が付いており、ユーザーのワークフローにどの程度影響するかを評価します。
- 技術的な負債。ソフトウェアの使用を妨げるものではないが、将来的に開発者を損なうものus 。例：一部のクラスが読みにくい、ビルドが遅い、一部のコードが単体テストされていない、IDE奇妙な警告を表示...
- 改善：新しいシナリオを許可しないが、より良いエクスペリエンスを実現するソフトウェアへの変更。例：フォントの変更、フォームを再設計して明確にする、アプリケーションに適切なデフォルトを追加するなど.
機能要件では、キュウリのテストに合格し、書かれたすべてのWordを実装したとしても、実装した機能がユーザーのニーズを解決しないことを認識できません。ストーリーは議論であり、非公式です。問題は、実装担当者が何が問題なのかを理解することです。それらは契約ツールではありません。 "スクラムbut ..."を実行し、ストーリーがソフトウェアの要件を記述する面白い方法である場合、はい、no違い。
重要なのはユーザーストーリーではありません。重要なのは、実行する作業にアプローチする方法におけるパラダイムの大幅な変化です。契約を結んでおらず、ユーザーが問題を解決するのを手伝っています。ユーザーストーリーがrealユーザーのディスカッションツールとして表示されない場合、ユーザーはユーザーを使用していませんストーリー、ファンキーな要件構文を使用しています。
ここでの残りは私の意見です。ユーザーストーリーは一方的に成功することはありません。あなたはそれを扱う顧客を必要としています。ウォータースクラムフォールは、奇妙な要件ですが、要件ではありません。特定の要件を持つ固定入札契約を結んでいる場合は、反復やユーザーストーリーを使用しないでください。ポイントはありません。アジャイルツールキットの残りの部分を使用する：自動化されたユニット/機能テスト、コードレビュー、継続的インテグレーション、リファクタリングなど。ソフトウェアが継続的に機能しており、すぐに出荷できることを確認してください。できる限り多くのフィードバックを提供できるように、未完成の形でお客様に提供します。もしあなたが「ユーザーストーリー」と「スクラム」をしなかったとしても、私の友人がそうするなら、あなたは多くのいわゆる「アジャイル」ショップよりも俊敏であったでしょう。