ソフトウェア開発に従事しているなら、ユーザーストーリーを聞いたことがあるはずです。 おそらく、マネージャーとしてユーザー ストーリーを書いていることでしょう。 あるいは、あなたはクライアントで、ソフトウェア開発者は機能要求をユーザー ストーリーとしてまとめることを望んでいるかもしれません。

この投稿では、ユーザー ストーリーについて知りたいと思ったことすべてをお伝えします。 ユーザー」の部分が示すように、ユーザー ストーリーは一人称単数形で書かれ、アプリのユーザーによって認識される機能を記述します。

典型的なユーザー ストーリーは、（アジャイル開発プロセスについて話している場合）この構造に従っています。…) は、アプリケーションでのユーザーの役割を指定します。これは通常、そこで何をすることが許可されているかに関連しています。

第 2 部 (機能) は、このケースで使用される機能の一部を指します。

例 1

登録ユーザーとして、
友人が近くのイベントに行くときに通知されるようにしたい
ので、そのニュースに反応するか、イベントに参加することができる。

例 2

ライダーとして、
10 回ごとに 10% 割引を受けたい
そうすれば、サービスに常にお金を使うことで報酬を得ることができる。 製品/プロジェクト マネージャーがさまざまなソースから来るソフトウェア要件を扱うとき、統一性を達成することが困難な場合があります。 また、その機能がどのユーザーのカテゴリをカバーするのか、あるいはビジネス価値がどこにあるのかも不明確な場合があります。

Approaches to Composing User Stories

ユーザー ストーリーは、一緒に仕事をする人に応じて、さまざまな方法で書くことができる。 以下は Gherkin 構文の簡単な例です:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

気付いたかもしれませんが、Gherkin では indent が構造を定義しています。 基本的なパラメーターは Given/When/Then で、これらは必要に応じて複数の And で追加することができます。 しかし、構文はこれらの基本的なパラメータを越えています。 Gherkin をマスターすることを本当に決意しているなら、ここに素晴らしいチュートリアルがあります。

プロジェクトの初期要件を収集しているときは、Gherkin は最良の選択ではないかもしれませんが、ユーザー ストーリーをさらに開発するときに (特に QA チームにとって) 有益であることがあります。

The Agile Way

Many Agile project management applications offers a functionality for entering user stories. たとえば、私たちは社内のいくつかのプロジェクトでTaigaアプリを使用しています。 これは、バックログで個々のタスクに分解することができるユーザー ストーリーを中心に、作業を整理するのに役立ちます。 Taiga.io interface

考えてみると、バックログ項目としてユーザー ストーリーを持ち、1 つのユーザー ストーリーに複数のタスクを追加することは、完全に理にかなっています。 なぜでしょうか。 なぜなら、たとえば、1 つの機能 (=ユーザー ストーリー) があり、3 人の人がそれに取り組んでいるとすると、その人たちのために別々のタスクが必要になるからです。 インターフェイスを設計するデザイナー、インターフェイスをプログラミングする HTML/JavaScript プログラマー、インターフェイスを本番環境にリリースする DevOps が必要です。

Pivotal Tracker (関連するストーリーをまとめる「エピック」の概念を導入) など他のツールでも、異なるタイプのストーリーを作成することができます。

Source: 「機能」、「作業」、「バグ」、または「リリース」です。 PivotalTracker.com

さまざまな企業で使用されているさまざまなアプローチとは別に、ユーザー ストーリーを記述するシンプルで簡単な方法があることを覚えておいてください – この記事の冒頭でその例を示しました。

Who Should Write User Stories? それは人それぞれです。 チームがユーザー ストーリーの形式で機能をキャプチャすることに同意している場合、それは、製品オーナーを通じて株主から来る可能性が高いです。

また、プロジェクト マネージャーまたは QA が機能および要件を議論するためにクライアントと仕事をすることもあります。 あるいは、15人のスタートアップで、あなたがCEO、CTO、CMOかもしれませんね。 この場合、例を示して、ユーザー ストーリーを使用して機能を文書化し始めることができます。

IT 業界の多くは、「ユーザー ストーリー開発」についても話しており、これは、最初に高レベルの詳細を登録し (たとえば、機能の単純なリストから開始する)、次にタスクやシナリオなどを追加してより詳細なストーリーに展開するプロセスを指します。 また、要件を完全なものにするのに役立ちます。 そして、言われたように、使用する正確なテンプレート/フィールドは、状況によって異なる可能性があります。