最初に実行する必要があるのは、ユースケースとユーザーストーリーのどちらですか。
ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。
私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。
ユーザーストーリーは、製品のバックログの作成に使用されているようです。これには、開発で実行する必要があるすべてのものが含まれています。
一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用の流れの説明を提供します。
1つのユースケースに複数のユーザーストーリーがあるように思えます。
これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、どういうわけか「同時に」行う必要がありますか？
私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？
ユースケースとユーザーストーリーは、どちらも要件を収集して表現するためのツールです。
すでにおわかりのように、単一のユースケースは通常、エラーや通常のパスからの逸脱を含むユーザーインタラクションを完全に記述しようとするため、単一のユーザーストーリーよりも広い範囲を持ちます。ユーザーストーリーは、ユースケースの1つのフローと大まかに比較できます。
すべてのツールと同様に、特定の状況で必要と思われるツールを使用するかどうかは、あなた次第です。つまり、ユースケースのみ、ユーザーストーリーのみ、またはユースケースとユーザーストーリーの組み合わせを必要に応じて使用できます。
1回の反復/スプリントで開発および配信できるものの作業単位としてユーザーストーリーを使用することがますます一般的になっています。
それを念頭に置いて、利害関係者と話し合うときにユースケースが自然に来ない限り、ユースケースとしての要件の収集にあまり力を入れません。
私の場合、フルユースケースに必要な詳細のレベルは、最初にユーザーストーリーを最初に考えることで得られることにいつも気づきました。私が最初に尋ねる質問は、「人々が何ができるようになる必要があるのか？」です。シナリオが分かれば、システムのフローのすべてのユースケースとバリアントを確認するのが簡単になります。
とはいえ、単独で作業する1人の開発者にとって、ユースケース、ユーザーストーリー、または「 'x'を忘れないでください」と書かれた壁に貼られた付箋など、本当に気にする必要はありません。必要なのは、ユーザーが達成しようとしていることについて考えさせ、ユーザーが実行できるようにする必要があるさまざまなことを追跡するのに役立つプロセスです。それ以外のすべては、開発を計画するために書き留める必要がある詳細のレベルに関してはあなた次第です。
たとえば、ソロのサイドプロジェクトで作業している場合、私の作業タスクは次のようになります。
- ログインする
- 'foo'のリストを表示
- リストから選択を保存
- 探す
正直なところ、それらのそれぞれは、推定値以上のものを持っていません。どうして？私はユーザーに何をする必要があるかを思い出させるためにそれらを使用しているだけなので、その部分に取り掛かったときに詳細を理解します。一人のチームでは、すべてが頭の中にある可能性があり、それを他の人に伝える必要がないため、それは問題ありません。
今、注意点があります...
他の専門家と協力する単一の開発者
進捗状況を別のチームに報告する必要がありますか？作業を検証する必要があるテスターはいますか？あなたが何をしたか知りたい経営陣はいますか？タイムラインを予測する必要があるプロジェクトマネージャーはいますか？必要な機能を決定している製品所有者はいますか？
これらの人々があなたのプロジェクトの一部であるなら、あなたはあなたの仕事の仕事が彼らが彼らの仕事をすることを可能にするのに十分な情報を彼らに持っていることを確認する必要があります。 PMおそらく、物事の相対的なサイズを確認し、その作業を進める方法が必要です。テスターは、物事の流れ方（使用例）に関する詳細が必要であり、質問することもできますあなたがそれらを書くのを助けるために。経営陣はあなたが何に取り組んでいるのかを知りたいので、あなたが提供しようとしている機能を彼らが理解できるように十分なビジネスの説明が必要になります。
これらすべての質問に「はい」と答えた場合は、チームの他のメンバーとの通信に使用するため、バックログをより厳密に文書化する必要がある可能性があります。
- 管理者や製品の所有者に報告するために使用できる高レベルの機能となる「エピック」または「機能」の概念が必要になる可能性があります。
- これらのエピック/機能内にネストされたユーザーストーリーがあり、プロジェクトマネージャーとの進捗状況の伝達、スプリント内の作業タスクの定義、およびビジネス目標の伝達に使用される機能の小さなブロックを定義します。テストチーム。
- ストーリーに対して定義されたユースケースまたはテストケースを使用して、お客様、ビジネス、およびテストチームが連携し、何が「正しい」として受け入れられるかを確認するために必要なさまざまな低レベルのフロー決定をキャプチャします。
あなたが作業を定義し、進行状況を管理し、ソフトウェアをテストし、何かが「正しい」かどうかを判断するのであれば、上記のすべてを無視できます。余分な労力を省き、重要なことを実行していることを確認してください：実用的なソフトウェアの構築！
ある種のアジャイルをしているなら、独断的な答えはあなたのために働くことをしてください。
プロセスはあなたの回顧の一部であるべきです。ボトルネック、冗長性、コミュニケーションの問題、誰も読んだことのないドキュメントなどについて話している必要があります。そして、それはプロセスの変更が合意され、理想的には実行に移されるべき設定です。
私の経験では、プロジェクトマネージャー、アナリスト、および「ビジネスパーソン」は、プロセスを「裏返しに」実行するように訓練されています。それらは、多くの場合口頭である要件を収集し、ユーザーストーリー形式で利害関係者から与えられます。彼らは明確にするために質問をするので、詳細な「ユースケース」ドキュメントを作成できます。開発チームは、これを反復可能なユーザーストーリーに変換しようとします...
私の経験に基づいた私の推奨：チームまたはアナリストに依頼するか、またはwhoeverを使用して、最小限の詳細でユーザーストーリーをバックログに入れます。優先順位の情報を含め、ストーリーが解決しようとしている「問題」を説明します。可能性のある解決策をいくつか挙げてください...しかし、それ以上に、開発者が反復するときに「ユースケース」が出現するようにしますQAおよび/または利害関係者とともにストーリーについて。
ストーリーの解決時に、着手したユースケースをドキュメントに記録します。システムの理解に役立つ形式で記録してください。
ユーザーストーリーとユースケースは相互に排他的ではなく、「推奨」はありません。
これらは、プロセスをある程度まで強化するために役立つ場合とそうでない場合がある単なるツールです。可能な方法はたくさんありますが、ユースケースとストーリーの両方を一緒に使用する方法を提案します。
- バックログと計画については、高レベルの機能プレースホルダーとしてユーザーストーリーを試してください。 （もちろん、ユーザーの目標レベルまでのユースケースも役立ちます。）
- すでに実装されている要件を文書化するには、ユースケースが最適です。
以前は、ユースケースはウォーターフォールアプローチ向けであると考えていましたが、ユーザーストーリーにはアジャイルプロセスが含まれていました。それらが排他的ではないことに気づくのにしばらく時間がかかりました。
あなたはこれらを共有する必要がないので、それはあなた自身を除いて、コミュニケーションについてではありません。 1週間ほど後にノートを理解できる限り、問題ありません。それ以外の場合は、要件をメモするときに詳細を追加します。
進捗状況を追跡し、優先順位を設定するための視覚的で柔軟な方法が必要ですか？もしそうなら、ユーザーストーリーは、ほとんどのアジャイル方法論（todo、done、現在のスプリント）で見られる進捗ボードと一緒に役立ちます。
純粋な要件については、何をどのように解決する必要があるかがわかっているので、ユーザーストーリーは簡単に作成できるので（1文）、アクターと高レベルのアクションのみをリストしたユースケース図から始めることをお勧めします。
詳細が必要な場合は、より多くのユーザーストーリーでドリルダウンします。複雑なプロセス（分岐、多くの条件、前提条件）が発生した場合、図を使用するか、テキストテンプレートバージョンを使用するかに関係なく、ユーザーストーリーをユースケースにリンクできます。そして、それらもさまざまなレベルの詳細で作成できることを覚えておいてください。 Karl Wiegers＆Joy Beattyによるソフトウェア要件の本では、理解に必要な詳細レベルのみを保持することをお勧めしています。何かがまったく明白な場合は、ドリルダウンする必要はありません。
上記は私が最初に個人的に理解しなかったものです。ユーザーストーリーは出発点、つまり「要約」ですが、必要に応じて詳細なユースケースを含め、意味と必要性をさらに定義するために追加のドキュメントで補足することができます。
状況による。一人で作業している場合は、さまざまなアプローチを試して、自分に最適な方法を試してください。
免責事項：それらを記述する方法はたくさんあります。 「ユーザーストーリー」の定義は非常に一般的ですが、「ユースケース」の意味は大きく異なります。私は、非常に一般的な古典的なUMLダイアグラムを参照します。
ユーザーストーリーまたはユースケース
私の経験では、どちらの方法を理解するのが良いかについて、さまざまな考え方があります。そのため、新しいプロジェクトチームごとに、要件を文書化する方法を決定します。通常は組み合わせが一般的で、概要にはユースケースを、詳細にはユーザーストーリーを使用します。
- 使用例、特に図としては、視覚的に考える人に適しています
- ユーザーストーリーは、非常にしゃべりやすいディスカッションで考える人に好まれます。
（これは意見に基づくものであり、科学的根拠はありません）
最初に何をすべきか？
プロジェクトの要件を記述する際、私は非常に抽象的なレベルから始めます。ユースケースを使用して、プロジェクトのグローバルな目標を（UML-）ダイアグラムにペイントします。ユーザーストーリーを使用して、主な目標を説明する「エピックストーリー」をいくつか書き留めます。
2番目のステップは、詳細を確認することです。これを行うには、「エピックストーリー」またはグローバルな目標への参照を維持するようにしてください。これは、要件の構造化に大きく役立ちます。
逆に見ていきます。最後に何が必要ですか？
最後のステップは、あなた（または他の誰か）が要件をバックログに入力することです。要件は、記述するコードの動作を知っている必要があり、テスターがコードの動作を検証できるようにする必要があります。
これらの要件は、明確に定義されたユーザーストーリーの形式で非常によく記録できます。したがって、ユーザーストーリーは最後のステップになる可能性があります。ユースケースは通常、複数のユーザーストーリーに変わるため、ユーザーストーリーの前に配置する必要があります。