システムユーザストーリー対タスク

Question

私たちはポータルPを他のサードパーティのWebアプリケーションWと統合しています.Wはポータルのモーダルポップアップ内に表示されます。ボタンBをクリックするとUは、Wがポップアップし、設定し、特定の情報として表示する必要があるユーザーとして明らかユーザーストーリー（のはそれを呼び出すUS1を聞かせて）

の

一つの事前されなければならない「です」私は情報セット 'IS'を見直すことができます。

今

事前移入情報設定することで、我々は、Webアプリケーションに私たちのポータルPからの情報を送信するために、バックエンドでのAPIのセットを作成し、統合する必要がありますW.

私が持っている質問は、APIの作成がシステムのユーザーストーリーまたはタスクであるべきかどうかです。

作業はスプリントで行うことができますが、APIの作成と統合はおそらく私には複数の作業です。また、この統合が完了すると、後続のユーザーストーリーがサードパーティWebアプリケーションでブロックされます。

システムのユーザーストーリー（SUS1と呼ぶことができます）とそのようなタスクを記述する必要がありますか？

ポータルPとして、ユーザUがこの情報を見ることができるように、情報セットISを第三者ウェブアプリケーションWに送信することができるはずである。

これは明らかに、サブタスクTの作成が必要になるなど、

"APIのAの作成"

または私はちょうど、ユーザーストーリーUS1のためのサブタスクTを作成する必要があります。

ここにいるチームは、すべてのストーリーを呼び出すことがより快適で、スプリントバーンダウンでのアクティビティーを簡単に表示し、特にその後のユーザーストーリーUS2がシステムユーザーストーリーSUS1に依存していることを伝えて示します。

Answer 1

User storiesは、エンドユーザーの立場から書かれており、製品からどのようなものを入手したいのかを説明しています。 実装の仕方を説明していません。

説明した内容はユーザーストーリーではなく、複数の実装タスクの組み合わせです。

ユーザーストーリーの例は次のようになります。

私は今日の天気情報を表示したいポータルのユーザーとして、私は天気が、この後は、今日

どのようになるかを知ることができるようにユーザのストーリーがスプリントに割り当てられると、開発チームはいくつかの技術的な作業にそれを打ち破ることができます。これには、ユーザーストーリーを配信するのに十分なAPI の作成が含まれます。

Answer 2

APIの作成は、ステークホルダー（またはエンドユーザー）レベルでは表示しないでください。したがって、ユーザーストーリーUS1を実装する手段としてタスクを作成する必要があります。

しかし！

システムを縦に分割する必要があります。つまり、US1を動作させるために必要以上にAPIを実装する必要がありません。後続のユーザーストーリーの実装に沿って、残りのAPIを実装する必要があります。

当然のことながら、インクリメンタルに構築されたAPIは、最高の設計が可能ではありません。したがって、各ステップでこれまで実装されたすべてのユーザーストーリーを考慮してリファクタリングする必要があります。これはBDUF（Big Design Up Front）よりはるかに優れています。