3

ユーザーストーリーの使用が適切な場合を理解しようとしています。常にかどうか？

たとえば、映画のチケット予約サービスなど、チームが何かをゼロから始めたとします。「エンドユーザーとして、シアター X で上映中の映画を閲覧できるようにしたい」など、機能のユーザー ストーリーを思いつくのは簡単です。

しかし、それらを実装する前に、システムを設計する必要があります。アーキテクチャを設計し、データベースを設計し、GUI とビジネス ロジックのテクノロジを選択する必要があります。

これらのタスクはバックログにどのように表示されますか? それらもユーザーストーリーであるべきですか？もしそうなら、彼らはどのようにINVESTニーモニックに準拠していますか? それらだけではエンドユーザーに何も提供しませんが、何らかの機能を実装する前に必要になります。

4

2 に答える 2

4

しかし、それらを実装する前に、システムを設計する必要があります。アーキテクチャを設計し、データベースを設計し、GUI とビジネス ロジックのテクノロジを選択する必要があります。

あまり同意できません。ストーリーは、アーキテクチャのほぼすべてのレイヤーを使用する機能であるため、ストーリーを実装すると、同時にアーキテクチャが構築されます。Alistair Cockburn のWalking Skeletonの定義を確認してください。

質問について

「ユーザーとして...」として定義できるストーリーのほとんどは、ストーリーに UI 機能も含まれている場合があります。明確にするために、ストーリーをサブタスクに分割することができます。INVEST のユーザー ストーリーで紹介するのが難しい作業もありますが。たとえば、バグ、技術。部門など。それらは、特別なタイプのストーリー (バグ、技術ストーリー) として表示されます。デモではそれらを表示できませんでしたが、言及することはできます。

于 2012-11-02T10:10:46.903 に答える
1

(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)

ではない正確に。たとえば、スプリント、特定のリリース、または任意の時点の機能を実装するために設計されたデータベース全体を取得する必要はありません。必要になるのは、いくつかの共通点です。

これは、変化を歓迎するアジャイルの美しさの 1 つ (対ウォーターフォール) が存在する場所です。

ここで、あなたの質問に答えます。ユーザー ストーリーでの役割は、エンド カスタマーの役割である必要はありません。開発者、システム管理者などである可能性があります。

AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption

そのため、PO に、将来の開発のための土台を築くために、ユーザー ストーリー (または複数) をバックログに追加するか優先順位を付けるように説得することができます。しかし、繰り返しになりますが、そのようなストーリーを作成するときは、変化への対応のアジャイルの価値を思い出してください。

PS

また、製品バックログを明確でアクセスしやすい状態に保ち、PO と開発チームの間で適切に対話できるようにすることも重要です。これは、スクラム マスターによってガイドされる必要があります。

このようにして、チームは、技術的な観点から、あるストーリーが互いにどのように影響するか、ストーリー X をストーリー Y の前に行う必要がある理由について、より良いフィードバックを PO に提供したり、PO に警告したりできます。

于 2012-11-07T16:06:09.667 に答える