ここで思考プロセスを変更する必要があります。
ユーザー ストーリーは、ユーザーが達成したいことを捉えた、エンド ユーザーの日常言語またはビジネス言語の 1 つまたは複数の文です。例えば
フロント担当者として、早急に部屋の予約をしたいと思います。
ご覧のとおり、
- ユーザー・役割（フロント担当者）の視点から
- 目的志向（部屋の予約を早くする）
しかし、さまざまなフロー (支払いなど)、受け入れ基準、非機能要件の特定などの詳細が欠けています (例の話ですぐに意味することは何ですか?)。サブストーリーを作成して、詳細を提供します。
良いストーリーとは？
INVEST :独立、交渉可能、価値あり、評価可能、モール、テスト可能
Web アプリ (またはモバイル アプリ) のアイデアをストーリー/イテレーションのリストにうまく変換する方法をガイドできるツールはありますか?
Rally や JIRA などのツールを使用すると、ストーリー、サブストーリー、スプリント/イテレーションなどを整理できます。
状態、機能、または機能 (およびその関係) のある種の視覚的表現で、機能的、非機能的、および技術的な仕様を指定できるので、その後でストーリーを作成できますか?
これらのツールは、ストーリーを書くのに役立つリッチ テキスト エディターを提供します。場合によっては、ストーリーに合わない要件がある場合があります
- ユースケース
- ユーザー インターフェイスのガイドライン
- 業務ルール等の一覧
それから別のことを書きます。JIRA などのツールは、添付ファイルを提供します。
その後、ストーリーを作成できますか？
** ストーリーは最初に行うべき活動です。それが要点です。後付けではありません。ストーリーは、ユーザーと目標の観点から考えるよう強制する方法であり、ユーザーの目標を達成するためのソフトウェアを作成します。**
ストーリーは要件を表すものであり、文書化するものではありません。- レイチェル・デイビス
アジャイル アプローチは、継続的なリファクタリングで十分なアーキテクチャを促進します。
通常、スプリント デリバリ チームには、ビジネス アナリスト、テスター、アーキテクト、データベース管理者、開発者など、必要な利害関係者がすべて含まれます。彼らは集合的にストーリー/スプリントを完成させる責任があり、春の終わりには、本番環境でデプロイ可能なアプリケーションが完成します。アイデアは、機能を段階的に追加することです。
チーム構成からわかるように、アーキテクト/リードも各スプリントに関与しています。彼は、チームの助けを借りて、現在のスプリント/イテレーションの一部であるストーリーのためだけに設計および設計します (ちょうど十分なアーキテクチャ、緊急設計)。彼らが最初のスプリントで選ぶストーリーは、リスクが高いか、アーキテクチャ上重要なものです。
デザインに関しては、ほとんどがブレインストーミングと紙または黒板ベースです。コードを可能な限りリファレンス ドキュメントとして使用し、ペア プログラミングなどによってチーム全体で集合的な知識を構築することが考えられます。
そのため、品質の低いソフトウェアになってしまうことはありません。実際には、ストーリーを実行できる最小限のコード ベースが用意されています (将来の要件や機能があれば便利なコード ベースを蓄積するわけではありません)。どこかで、構築された機能の 40% だけが顧客によって使用されていると読んだことがあります。