最初に実行する必要があるのは、ユースケースとユーザーストーリーのどちらですか。

ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。

私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。

私が製品バックログを作成するために使用されているように見えるユーザーストーリーには、開発で実行する必要があるすべてのものが含まれています。

一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用のフローの説明を提供します。

1つのユースケースに複数のユーザーストーリーがあるように思えます。

これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、何とかして「同時に」行う必要がありますか？

私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？

ユースケースとユーザーストーリーは、どちらも要件を収集して表現するためのツールです。
すでにおわかりのように、単一のユースケースは通常、エラーや通常のパスからの逸脱を含むユーザーインタラクションを完全に記述しようとするため、単一のユーザーストーリーよりも広い範囲を持ちます。ユーザーストーリーは、ユースケースの1つのフローと大まかに比較できます。

すべてのツールと同様に、特定の状況で必要だと思われるツールを使用するのはあなた次第です。つまり、ユースケースのみ、ユーザーストーリーのみ、または適切と思われるユースケースとユーザーストーリーの組み合わせを使用できます。

1回の反復/スプリントで開発および配信できるものの作業単位としてユーザーストーリーを使用することがますます一般的になっています。
それを念頭に置いて、利害関係者と話し合うときにユースケースが自然に来ない限り、ユースケースとしての要件の収集にあまり力を入れません。

私の場合、フルユースケースに必要な詳細レベルは、まずユーザーストーリーを最初に考えることで得られることに常に気づきました。私が最初に尋ねる質問は、「人々が何ができるようになる必要があるのか​​？」です。シナリオを取得したら、システムのフローのすべてのユースケースとバリアントを確認する方が簡単です。

とはいえ、単独で作業する1人の開発者にとって、ユースケース、ユーザーストーリー、または「xを忘れないでください」と書かれた壁に貼られた付箋など、本当に気にする必要はありません。必要なのは、ユーザーが達成しようとしていることを考えさせ、ユーザーが実行できるようにする必要があるさまざまなことを追跡するのに役立つプロセスです。それ以外のすべては、開発を計画するために書き留める必要がある詳細のレベルに関してはあなた次第です。

たとえば、ソロのサイドプロジェクトで作業している場合、私の作業タスクは次のようになります。

1. ログインする
2. 'foo'のリストを表示
3. リストから選択を保存
4. 探す

正直なところ、それらのそれぞれは、推定値以上のものは何もありません。どうして？私はユーザーに何をする必要があるかを思い出させるためにそれらを使用しているだけなので、その部分に移動したときに詳細を理解します。一人のチームでは、すべてが頭の中にある可能性があり、それを他の人に伝える必要がないため、それは問題ありません。

今、注意点があります...

他の専門家と協力する単一の開発者

進行状況を別のチームに報告する必要がありますか？作業を検証する必要があるテスターはいますか？あなたがしたことを知りたい経営陣はいますか？タイムラインを予測する必要があるプロジェクトマネージャーはいますか？必要な機能を決定している製品所有者はいますか？

これらの人々があなたのプロジェクトの一部であるならば、あなたはあなたの仕事の仕事が彼らが彼らの仕事をすることを可能にするのに十分な情報を彼らに持っていることを確認する必要があります。首相はおそらく、物事の相対的なサイズを確認し、その作業を進める方法が必要です。テスターは、物事がどのように流れることが期待されるか（ユースケース）に関する詳細が必要です。また、テスターに​​作成の手伝いを依頼することもできます。管理者は自分が何に取り組んでいるのかを知りたいと思うかもしれないので、提供する予定の機能を理解できるように、十分なビジネスの説明が必要になります。

これらすべての質問に「はい」と答えた場合、チームの他のメンバーとの通信に使用するため、バックログをより厳密に文書化する必要がある可能性があります。

• おそらく、管理者または製品の所有者に報告するために使用できる高レベルの機能となる「エピック」または「機能」の概念が必要になります。
• これらのEpics / Features内にネストされたユーザーストーリーがあり、プロジェクトマネージャーとの進捗状況の伝達、スプリント内での作業タスクの定義、およびビジネス目標の伝達に使用される機能の小さなブロックを定義します。テストチーム。
• ストーリーに対して定義されたユースケースまたはテストケースを使用して、お客様、ビジネス、およびテストチームが連携し、何が「正しい」として受け入れられるかを確認するために必要なさまざまな低レベルのフロー決定をキャプチャします。

あなたが作業を定義し、進行状況を管理し、ソフトウェアをテストし、何かが「正しい」かどうかを判断するのがあなたである場合、上記のすべてを無視できます。余分な労力を省き、重要なことを実行していることを確認してください：実用的なソフトウェアの構築！

ある種のアジャイルをしているなら、独断的な答えは、「あなたのために働くことをしてください」です。

プロセスはあなたの回顧の一部であるべきです。ボトルネック、冗長性、コミュニケーションの問題、誰も読んだことがないドキュメントなどについて話している必要があります。そして、それはプロセスの変更が合意され、理想的には実行に移されるべき設定です。

私の経験では、プロジェクトマネージャー、アナリスト、および「ビジネスパーソン」は、プロセスを「裏返しに」実行するように訓練されています。これらは要件を収集します。要件は、ユーザーストーリー形式で関係者によって口頭でしばしば与えられます。彼らは明確にするために質問をするので、詳細な「ユースケース」ドキュメントを作成できます。開発チームは、これを反復可能なユーザーストーリーに変換しようとします...

私自身の経験に基づく私の推奨：チームまたはアナリスト、あるいは誰でも、最小限の詳細でユーザーストーリーをバックログに入れるようにしてください。優先順位の情報を含め、ストーリーが解決しようとしている「問題」を説明します。可能性のある解決策をいくつか挙げてください...しかし、それを超えて、開発者がQAやストーリーの利害関係者と反復するときに「ユースケース」が出現するようにします。

ストーリーの解決時に、着手したユースケースをドキュメントに記録します。システムの理解に役立つ形式で記録します。

ユーザーストーリーとユースケースは相互に排他的ではなく、「推奨」はありません。

これらは、プロセスをある程度まで強化するのに役立つ場合とそうでない場合がある単なるツールです。可能な方法はたくさんありますが、ユースケースとストーリーの両方を一緒に使用する方法を提案します。

• バックログと計画については、高レベルの機能プレースホルダーとしてユーザーストーリーを試してください。（もちろん、ユーザーの目標レベルまでのユースケースも役立ちます。）
• すでに実装されている要件を文書化するには、ユースケースが最善の方法として機能します。

場合によります。一人で作業している場合は、別の方法を試して、自分に最適な方法を試してください。

免責事項：それらを書く方法はたくさんあります。「ユーザーストーリー」には非常に一般的な定義がありますが、「ユースケース」には非常に異なる意味があります。私は、非常に一般的な古典的なUMLダイアグラムを参照します。

ユーザーストーリーまたはユースケース

私の経験では、どちらの方法を理解する方が良いかについて、さまざまな考え方があります。そのため、新しいプロジェクトチームごとに、要件を文書化する方法を決定します。通常は組み合わせが一般的で、概要にはユースケースを使用し、詳細にはユーザーストーリーを使用します。

• 特に図としての使用例は、視覚的に考える人により適しています
• ユーザーストーリーは、非常にしゃべりやすいディスカッションで考える人に好まれます

（これは意見に基づくものであり、科学的根拠はありません）

最初に何をしますか？

プロジェクトの要件を記述する際、私は非常に抽象的なレベルから始めます。ユースケースを使用して、プロジェクトのグローバルな目標を（UML-）ダイアグラムに描画します。ユーザーストーリーを使用して、主な目標を説明する「エピックストーリー」をいくつか書き留めます。

2番目のステップは、詳細を確認することです。これを行うには、「エピックストーリー」またはグローバルな目標への参照を維持するようにしてください。これは、要件の構造化に大きく役立ちます。

逆に見ていきます。最後に何が必要ですか？

最後のステップは、あなた（または他の誰か）が要件をバックログに入力することです。要件は、記述するコードの動作を知っている必要があり、テスターがコードの動作を確認できるようにする必要があります。

これらの要件は、明確に定義されたユーザーストーリーの形で非常によく記録できます。したがって、ユーザーストーリーは最後のステップになる可能性があります。ユースケースは通常複数のユーザーストーリーに変わるため、ユーザーストーリーの前に配置する必要があります。

以前は、ユースケースはウォーターフォールアプローチ用であると考えていましたが、ユーザーストーリーにはアジャイルプロセスが付属しています。それらが排他的ではないことに気づくのにしばらく時間がかかりました。

あなたはこれらを共有する必要がないので、それはあなた自身を除いて、コミュニケーションについてではありません。1週間ほど後にノートを理解できる限り、問題ありません。それ以外の場合は、要件をメモするときに詳細を追加します。

進捗状況を追跡し、優先順位を設定するための視覚的で柔軟な方法が必要ですか？もしそうなら、ユーザーストーリーは、ほとんどのアジャイル方法論（todo、done、現在のスプリント）で見られる進捗ボードと一緒に役立ちます。

純粋な要件については、何をどのように解決する必要があるかがわかっているので、ユーザーストーリーは簡単に作成できる（1文）か、アクターと高レベルのアクションのみをリストしたユースケース図から始めることをお勧めします。

詳細が必要な場合は、より多くのユーザーストーリーでドリルダウンします。複雑なプロセス（分岐、多数の条件、前提条件）が発生した場合、図を使用するか、テキストテンプレートバージョンを使用するかに関係なく、ユーザーストーリーをユースケースにリンクできます。そして、それらでさえもさまざまなレベルの詳細で作成できることを覚えておいてください。ソフトウェア要件のカール・ウィーガーズ＆ジョイ・ビーティの本は理解するために必要な詳細のレベルのみを保つことをお勧めします。何かがまったく明白な場合は、ドリルダウンする必要はありません。

上記は、私が最初に個人的に得たものではありません。ユーザーストーリーは出発点、つまり「要約」ですが、それぞれに追加のドキュメントを追加して、必要に応じて詳細なユースケースを含め、意味と必要性をさらに定義できます。