プロジェクトの初期段階では、どのようなユーザーストーリーを作成する必要がありますか？

プロジェクトを開始するだけでは、UI、データレイヤー、中間に何もありません。したがって、「ユーザーは自分のfooを表示できるはずです」のような単一のストーリーには多くの作業が必要になります。そのストーリーが得られたら、「ユーザーはfooを編集できるはずです」のようなものがより現実的ですが、最初のストーリーにはUIレイヤー、プレゼンテーションロジックレイヤー、ドメインロジックレイヤー、データアクセスレイヤーの設定が含まれます。

これは、私の「タスク」の概念には合いません。私にとっては、次のような「タスク」のようなものが欲しいです。

• JavaScriptオブジェクトから派生したHTMLでユーザーのfooのダミーデータを表示します。
• プレゼンテーションロジックレイヤーを設定し、JavaScriptオブジェクトをそれに接続します。
• ドメインロジックレイヤーをセットアップし、プレゼンテーションロジックレイヤーをそれに接続します。
• データアクセスレイヤーを設定し、ドメインロジックレイヤーをそれに接続します。

これらはすべて上記の単一の「ストーリー」に該当しますか？もしそうなら、ストーリーはプロジェクトの初期段階で非常に有用なフレームワークではないと感じます。もしそうなら、それは大丈夫です---私はこのアジャイルな方法論をできる限り最善の方法で学ぼうとしているので、何かを逃さないようにしたいだけです。

これは良い質問であり、おそらくいくつかの良い答えがあります。私の意見はこれです：

ストーリーはユーザーストーリーであるため、ユーザーにとってのメリットを説明する用語で定義する必要があります。

アジャイルとストーリーがあなたのために機能するなら、それらは初期段階でも機能するはずです。最初の箇条書きは単一のユーザーストーリーです（ただし、少し技術的な言葉遣い）が、他の3つは技術的なタスクの説明です。

あなたが作るために代わりに適切なフレームワークを持っていないときに、プロジェクトの初期段階では、CRUD（C reate、R EAD、U pdate、Dの迅速かつ簡単にelete）の開発を、あなたの話ははるかに小さく、増分である必要が個。

「ユーザーはfooを表示できるはずです」の代わりに、次のようになります。

1. ユーザーはサンプルデータのあるページを表示できるはずです。
2. ユーザーは、インタラクティブなサンプルデータを含むページを表示できるはずです。
3. ユーザーは、ライブのインタラクティブなサンプルデータを含むページを表示できるはずです。

1回のスプリントで開発するには大きすぎると思われるほとんどのユーザーストーリー（約8ストーリーポイントまたは開発の日数よりも大きいものは大きすぎることがわかった）は、おそらく、ユーザー。

ストーリー/機能は市場性がある必要はなく、製品所有者にとって意味のあるものでなければなりません。上記の場合、いくつかの簡単なデモ作品を入れて、何が変更され、そのストーリーがどのように行われたかを示すことができます。たとえば、＃3の場合、データベースにデータが事前入力された2人のユーザーのページを表示できます。ステージ2では、すべてのユーザーに同じデータが表示されます。

あなたが求めているのは、それを理にかなった断片に分解するために「問題空間をどう考えるか」であり、そこからデザインをすることができます。

これをユーザーストーリー、分析、分解、仕様、または要件収集と呼んでも、最終的には、通常いくつかの反復が行われるいくつかのことになります。

ユーザーの頭から欲しいものを取得する必要があります。（彼らはおそらく彼らが望むもののいくつかを知っていて、矛盾しているがまだそれを見ることができないものを望んでいます。）

これを何らかの形でキャプチャする必要があります。実際には、単語または写真の2つの選択肢しかありません。両方ともパワーがあり、可能であれば両方を使用します。言葉は、後で契約上の紛争の観点から最終的により強力です。

これを提示して同意を求める必要があります。

一部の人々は、ビジネスや他のロジックを背後に持たずに初期のビジュアルプロトタイプを作成します。これは強力なテクニックになる可能性があります-ある程度の手を振る必要があるためです。

一部はストーリーボードになります-そして提示し説明します。

厳密で慎重に分析された文書を書く人もいます。

各手法には長所と短所があります。

私が与える唯一のカウンセルについては、次のとおりです。ソリューションのコーディングを早すぎる段階に進めることは、通常、悪い動きです。WHOにとって何をすべきかを理解してから、それを行う前に、一般的にやり直しが少なくなり、開発が速くなります。

「タスク」について話すとき、これは仕事のある種の内訳のように思われ、上記の何、誰、なぜを理解しました。ユーザーストーリーをドキュメントで理解し、顧客がこれから行う作業の範囲として承認するまで、タスクをうまく把握することはできません。何を達成する必要があるか（出力）を知ることにより、タスク（そこに到達するまでのステップ）を把握できます。

フロントエンドの分析とドキュメントを軽視しないでください。

不足しているのは、ユーザーストーリーは、ユーザーがシステムをどのように使用するかを説明しているということです。これは、ビジネス要件を決定する方法です。それらは、技術的に何をすべきかを直接指示するようには設計されていません。

これは間違いなくプロジェクトの最も重要な部分の1つです。ビジネス要件が正しくないと、システムはユーザーにとって役に立たなくなります。