ユーザーストーリーはユースケースと互換性がありますか？
アジャイルセージはウェブをグーグルで検索し、ユースケースとユーザーストーリーは2つの異なるものであると考えています。 Mike Cohn： ユーザーストーリーはユースケースではありません Alistair Cockburn： ガゼルが望楼にあるように、ユーザーストーリーはユースケースにあります Extreme Programming.org： ユーザーストーリーはユースケースと同じ目的を果たしますが、同じではありません。 ユースケース主導のアプローチは、要件をキャプチャするための最もホットな手法の1つであり、ユースケースの問題のためにチームが「アジャイル」ではなくなる多くの問題に関連する一種の時代遅れの古いスタイルの手法であると考える人もいます。 ： 前払いの要件–前払いのすべての側面の詳細を定義しようとすると、多くの作業をやり直す必要があるため、多くの無駄な労力と時間が発生します。 機能的分解：ユースケースの機能的性質は、拡張によって関連付けられ、ユースケースの関連付けを含む具体的および抽象的なユースケースの観点から、システムの機能的分解に自然につながります。 「ユースケースとユーザーストーリー」というキーワードでWebを検索すると、ユースケースアプローチの欠点、問題、または落とし穴について示唆する記事の長いリストが見つかりますが、ユーザーストーリーに関連する利点のリストはさらに長くなります。 。興味深いことに、IT業界では物事が急速に変化し、以前は「トレンディ」だったものから現在の「新しいトレンディ」なものに切り替わる人々にとってはさらに速くなります。 興味深いことに、実際に本物の練習をするのではなく、物事をバイナリパターンで認識し、それらを象徴的に関連付けることで流行のものを追いかけることを好む人もいます。一部の人々は、他の人々にまだユースケースを使用していることを知らせたくない、または彼らは時代遅れで古いスタイルであると見なされるかもしれません。 現在、一部の人々は、ユーザーストーリーとユーザーケースに関連する等号を付けています。 アジャイル=ユーザーストーリーまたはアジャイル=ユーザーストーリー+スクラム ユーザーストーリー=ちょうど十分でちょうどいい時間 ユーザーストーリー=ユーザーの期待に応え、満足のいくもの ユースケース=事前の詳細な要件のキャプチャ ユースケース= << include >> + << extends >> =関数分解 ユースケースは「ユーザー入力」->「システム応答」のみのスタイルです ユースケース=古いスタイルと時代遅れ ツールベンダーとして、私たちは方法、ツール、テクニックにかなり中立です。個人的には、私はアジャイル開発、ユーザーストーリー、スクラムプロセスの大ファンであることを明確に強調したいと思います。特に、次のような概念に関連する下線を引く原則とベストプラクティス。 要件の配信ではなく、要件の発見 上記の原則の下で、アジャイル開発プロセスで2つの重要な特性が得られます ジャストインタイム 十分です （私は、1992年から1995年の私の博士課程の研究分野に密接に関連している私自身の意見で上記の原則に関連するより多くの投稿を書きます-メタモデルとスキーマ変換） それでは、「ユースケースとユーザーストーリー」のトピックに戻りましょう。ヘビーウェイトのアジャイルセージはすでにその票を投じていますが、私は彼らの「類似している、あるいは同じでさえあると主張することによって彼らの投票を覆そうとして頑固ですか？ ユーザーストーリーがユーザーケースと「非常に異なる」かどうかを示す例を示しましょう。 例 優れたユーザーストーリーは、単なる発言以上のものです。標準のユーザーストーリーは、一般に3つのCと呼ばれる3つの部分で構成されます。 各ユーザーストーリーの最初の「C」は、次の標準化された形式に従う必要があります。 [役割]として、[何かをしたい]ので、[メリット] これは、カードに入れるユーザーストーリーの最小限のコンテンツです。 会話は、エンドユーザー、プロジェクトオーナー、および開発チーム間のディスカッションを表すユーザーストーリーの2番目の「C」の内容です。これらの変換では、口頭での話し合い、または電子メール、ワイヤーフレーム、その他のプロジェクト関連コンテンツなど、他の多くの有用な情報が記録されます。 ユーザーストーリーの最後の「C」は、ユーザーストーリーが修正されて正常に配信されたことを確認するために使用される受け入れ基準である確認です。 ユーザーストーリーの確認部分を作成する方法についてもう少し詳しく説明します。ここでは、Gherkinと呼ばれる最もよく知られているテンプレートを使用します。これは、Given-When-Then式を採用して、ユーザーストーリーの受け入れテストの作成をガイドします。 （与えられた..そして）いくつかの文脈 （いつ..そして）何らかのアクションが実行されます （次に..および）いくつかのアクションを実行します CucumberやJbehaveテストフレームワークなどのツールは、自動テストを実行するためのGiven / When / Thenテンプレートの使用を推奨しますが、使用するツールに関係なく、純粋にヒューリスティックとして使用することもできます。 「登録コース」のユーザーストーリーのすべての情報を収集し、3C形式で入力してみましょう。 「登録コース」のユーザーストーリーを表すために、一般的に使用される3C形式を採用しました。同様に、ユースケースの説明で作成された同じ「登録コース」のユースケースを説明するために、最も広く使用されている形式を採用しました。ユースケースの説明に記載したステップ番号に関連付けられているユーザーストーリーの確認セクション（最後のC）のステップに番号を付けました。これらは、シナリオの同じ「9ステップ」であり、それぞれのアプローチに異なる順序で配置されます。私は、モデル表現の両方が、対応する賢人と信者にとって受け入れられると信じています。次に、もう一度質問します。ユーザーストーリーはユーザーケースと非常に似ていますが、それらは異なっているのでしょうか、それともステップの順序がユースケースアプローチに対するあらゆる種類の批判を引き起こしているのでしょうか。 異なる意味と意味的に同等ですか？ モデリングドメインに同様のケースがあるかどうかを調べて、ここでの状況と比較してみましょう。または、「ユーザーストーリーとユースケース」に投票するのに役立つかもしれませんが、群衆を盲目的にフォローしたり、何を繰り返したりしないでください。賢人はオウムの話のように言った。 例：意味的に同等 UMLでは、シーケンス図を使用してユースケースシナリオを説明できますが、通常、同じ目的でコラボレーション図を使用することはありません。両方の図を通してさえ、意味的に同等です。つまり、シーケンス図とコラボレーション図の両方で、シナリオに参加している同じ数のオブジェクトがあり、シナリオのタスクを実行するために同じ数のオブジェクトが同じセットのオブジェクトを通過します。ただし、前者は時間重視、後者は空間重視です。シーケンス図はシナリオモデリングで使用する場合により直感的ですが、コラボレーション図はオブジェクト間の構造関係のモデリングに適しています。つまり、参加しているオブジェクトのシナリオをMVCフレームワーク（モデル/ビューおよびコントロールレイヤー）に構造的に表現したいとします。 個人的には、ユーザーストーリーを使用してもチームがアジャイルになるとは思いません。また、ユースケースによってチームが「前向き」になるとは思いません。最も重要なのは、どのような考え方とベストプラクティスを背後に置いて、これらのツールをどのように適用して使用するかです。私が実際にアジャイルで行動するとき、私が「古いスタイル」または時代遅れであると人々が考えることについてあまり心配していません。 構造化分析と設計の時代を思い出します。おそらく、ADAの抽象データ型を使用して、198xのOOPのサポートがなくても、オブジェクト指向の分析と設計の原則を適用できますか？残念ながら、抽象データ型の概念にまったく出くわさないかもしれません。おー！私の神私は誤って開示します–私は年をとっていますか？または、私は前向きに考える必要があります–経験豊富ですか？ どう思いますか？これに対するあなたの投票は何ですか？私が間違っている場合は、私に知らせてください。continue reading →
