Story–Splitting-b-agile

だから、グラフィカルなユースケース図や（テキストの）ユーザーストーリーのリストを好むかどうかは、多かれ少なかれ好みの問題です。

大規模な要件の構造化についての議論を要約してみましょう：表記法とは無関係に、大きな問題を外部トリガされたプロセスに分解することは、この内訳を達成するための最も中立的な方法です。 それはシステムの内部構造に基づいていません（その機能ではなく、サブシステムでもなく、オブジェクトでもありません。,,)しかし、純粋に環境からのニーズに。

これは、上記の他の分解戦略が機能しないと言うことではなく、内部構造の議論に固執しないための提案に過ぎません。

このプロセスの上のナビゲーションシステムの簡単な例でわかるように、小さな

分割は、（あなたが好む表記法とは無関係に）まだ複雑すぎて、1回のイテレーションで実装することはできません。 あなたは間違いなくそれを小さな塊に分解する必要があります。 Lawrence(https://agileforall.com/resources/how-to-split-a-user-story/)は、より大きなチャンクに取り組み、それらを1回の反復に十分に小さいストーリーに分割する多くの方法を提案しました。

古典的な方法では、主に複雑なプロセスをステップのシーケンスを見ることによってよりよく理解することが提案されていましたが、アジャイルの世界では追加の問題に直面しています。 それをよりよく理解するために、大きなプロセス（ユースケースや大きなストーリー）を分解するだけでは十分ではありません。 分解後、各部品は、他の部品とは無関係に、ユーザーに何らかの価値を提供する必要があります。

これは、永続層を最初に実装する(つまり、いくつかのデータベーステーブルを作成する)ことは、それらを埋めて表示するまでビジネス価値を提供しないため、ユー 複雑なプロセスの単一のステップ7だけを実装することは、先行ステップと後続ステップが存在しない限り、価値を提供しない可能性があります。

（方法論者間の用語戦争についての興味深い歴史的側面の発言：Mike Cohnは、ユーザーストーリーは単に引数を使用することによってユースケースではないと訴えた。 Ivar Jacobsonはサイズについてその議論を受け入れましたが、ユースケーススライスはエンドツーエンドの価値を提供するので、”ユースケーススライス”は十分に小さ)