バックエンド システムを設計するとき、通常、ストーリーとタスクにどの程度の粒度を与えますか?
ストーリーとタスクを作成するほとんどの例は、通常、ユーザーが実行できるもの (ISBN で本を検索するなど) であるストーリーと、この GUI 機能を有効にすることを中心とした各タスクを含む GUI アプリケーションを中心にしています。
バックエンド システム、つまりユーザー インターフェイスを持たず、データベースやミドルウェアなどと通信する一連のサービスを設計する場合、どのようにタスクやストーリーを思いつきますか?
基本的に、ユーザー ストーリーのサイズを 1 ～ 10 人日で完成させるようにしています。そのため、Mike Cohn が「エピック」または「テーマ」と呼んでいるものをユーザー ストーリーとして開発者に渡すことができず、逆に言えば、私のユーザー ストーリーが解決策を示唆するほど具体的になるのを防いでいます (ユーザー ストーリーは問題を説明する必要があります)。どのように解決すべきかではありません）。
コンテンツに関する限り、私のストーリーにはビジネス価値のみが含まれていることを確認します。需要をどのように満たすか (すべきか) を説明したり、理解するためにユーザードメイン以外の知識を「要求」したりすることは決してありません。
良い例:私はコンテンツ管理者として、すべてのユーザーがトークバックを書く前にログインしなければならないようにしたいと考えています。
悪い例: Web サイトにキャプチャを追加します。
一方、タスクはソリューションを解決するためのステップであり、追加/変更する必要があるコンポーネントと機能を記述します。ここで、「キャプチャの追加」ソリューションの出番です。サイズに関しては、各タスクのサイズを 1 日 1/2 から 2 ～ 3 日間の作業にしようとしています。
タスクには、次のようなすべての機能/要件/問題/バグに適用される一連の標準タスクも含まれます。
これが役に立てば幸いです、アサフ。
ユーザーがいる限り、ユーザーストーリーはユーザーができることに関するものです。他の開発者に API を提供している場合、彼らはあなたのユーザーです。その時点で物事はより技術的になります（つまり、ユーザーは従業員レコードを更新できます）