独立コンサルタント、アジャイルトレーナー。 2002年以降のIT業界。 彼は、プロジェクトおよびプログラムマネージャー、アウトソーシング会社のセールスマネージャー、シリコンバレーのスタートアップの開発ディレクターとして働いていました。 2007年から2008年にかけて、彼はトレーニングセンターLuxoftと協力しました。
注釈：
この記事では、ユーザーストーリーの起源と用途の概要を説明します。これは、柔軟な開発方法の重要なメカニズムであり、価値の流れを通じて顧客の要求を導く役割を果たします。 同様に、ユーザーストーリーは、 柔軟な企業向けのリーンでスケーラブルな情報要件モデル と企業の柔軟性の大局に関する記事の重要な要素であり、どちらもブログに掲載されています。 現在の記事は、2010年に公開予定の、将来の書籍、柔軟な要件：チーム、プログラム、および企業向けのリーン要件管理プラクティスから抜粋したものです。 本への貢献に対してジェニファー・フォーセットとドン・ウィドリッグに感謝します。
用語について （翻訳の著者のメモ）：
読者がすでに推測できるように、記事の中心的なオブジェクトはユーザーストーリーであり、元々はユーザーストーリーのように聞こえます。 この用語のかなり贅沢な翻訳（「希望」など）を含む、いくつかの異なるものがあります。 ただし、翻訳では、実用的な動機のみを使用することにしました。そのため、「ユーザーストーリー」という用語を多少公式な意味で使用し、直接計算に使用するのは「ストーリー」です。 事実は、英語を話す顧客と仕事をするとき、最も柔軟なチームの生活に広く使われているのはこの用語であり、したがって正当化されるということです。
カスタムストーリーの基本
彼らは言語の大宴会でしたが、パン粉に満足していました。
-Page Moth to Kostard、「The Vain Work of Love」、ウィリアム・シェークスピア
はじめに
アジャイル開発では、ユーザーストーリーは、機能仕様、ユースケースの説明など、要件を記述する従来の手段に代わる軽量で活発な代替手段です。実際、ユーザーストーリー（ストーリー）は、これはアジャイル開発です。これは、値のフローをユーザーに転送するのに役立つコンテナであり、アジャイル開発の本質は、正確な価値のある結果の迅速な配信であるためです。
また、Storyは、値の増分配信に基づいた、アプローチ全体のメタファーとしても機能します。
有用なストーリーを定義します-短い反復の一部として実装およびテストします-それをユーザーに実証および/または配信します-フィードバックを受け取ります-情報を学びます-ループで繰り返します！
幅広い記事のコンテキストでユーザーストーリーについて既に簡単に説明しました。 「柔軟な企業の要件に関するリーンでスケーラブルな情報モデル」と「テーマ、叙事詩、機能とともに、ストーリーが最高の成果物である企業の柔軟性の概要」（1）柔軟なチームが使用する要件。
この記事では、ユーザーストーリーをより詳細に説明します。これは、ソリューションをユーザーのニーズに直接向けることができ、同時に製品の品質を検証できるようにする重要な柔軟なプラクティスの1つを明らかにするためです。
ユーザーストーリー：概要
前述の記事および関連するブログ投稿で、企業のアジャイルプラクティスへのスクラムモデルの貢献の重要性を強調しました。たとえば、要件の処理に不可欠な製品所有者の役割の定義そのものに注目しました。 しかし、私たちはユーザーストーリーの発明そのものをXPに負っており、この成果物の幅と深さを開発したのはXPの支持者です。 これは、見た目よりもはるかに重要性の低い「方法論の交差点」ですが、ユーザーストーリーは通常、バックログを構築してスプリントの構成を決定する手段としてスクラムコースのフレームワークに含まれているためです。 彼はUser Stories Appliedの本でユーザーストーリーに幅広く取り組んでいるので、この統合の多くについてMike Cohnに感謝すべきです。 Cohn 2004]、およびスクラムアライアンスコミュニティで非常に活発に活動しています。
この目的のために、ユーザーストーリーを次のように定義します。
ユーザーストーリーとは、システムがユーザーに対して行うべきことを説明する意図の短い声明です。
XPでは、ストーリーは通常顧客が作成するため、顧客を開発プロセスに直接統合します。 スクラムでは、製品は多くの場合、顧客、利害関係者、およびチームからの情報に基づいてストーリーを作成します。 ただし、実際には、ビジネス分野で十分な知識を持つチームメンバーはユーザーストーリーを作成できますが、最終的には、製品所有者が製品バックログの潜在的なストーリーの採用と優先順位を決定します。
ユーザーストーリーは、システムの動作を定義する手段であるため、開発者とユーザーの両方が理解できます。 Storeyは、伝統的に行うように構造的にタスクに分割するのではなく、ユーザー定義の値に作業を集中させます。 システムの要件を管理するための軽量で効率的なアプローチを提供します。
ユーザーストーリーは、カード上の機能の短い文言をキャプチャするか、オンラインツールを使用することもできます。
例：
- エネルギー監視ポータルにログイン
- 毎日の摂取量を見る
- 現在のレートを確認する
システムの動作の詳細は、この短い文言には表示されませんが、後で残され、チームと製品所有者による対話と受け入れ基準を通じて開発されます。
ユーザーストーリーは、開発者とユーザーのギャップを埋めるのに役立ちます
アジャイル開発では、開発者はユーザーではなくユーザーの言語で通信できる必要があります-技術的な言語を話す必要があります。 効果的なコミュニケーションはすべての鍵であり、したがって共通言語が必要です。 Storeyは、ユーザーと技術チームの間で理解するための共通言語を提供するだけです。
XPの作成者の1人であるビルウェイクは、これについて次のように説明しています（2）。
Pidginは、商取引で一般的に使用される単純化された言語であり、母国語でコミュニケーションできない人々がそれでも協力できるようにします。 ユーザーストーリーも同様に機能します。 顧客やユーザーに、開発者とまったく同じシステムのビジョンを期待していません。 ストーリーはピジンのように機能し、両者は常に効果的に協力することに同意できます。
ユーザーストーリーの場合、ソネットを書くために必要なスキルのレベルで互いの言語を理解する必要はありません。 合意に達したことを知るのに十分なだけお互いを理解する必要があります！
ユーザーストーリーは要件ではありません
以前は要件仕様（SRS）やユースケースなどに属していた役割でストーリーが大きな役割を果たしているという事実にもかかわらず、それにもかかわらず、それらはいくつかの微妙ではあるが重要なニュアンスが著しく異なります。
- それらは要件の詳細な説明（つまり、システムが行うべきこと）ではなく、むしろ意図の議論を表します（このようなことを行う必要があります）
- これらは短くて読みやすく、開発者、利害関係者、ユーザーにとって理解しやすいものです。
- これらは、数日または数週間以内に実装できる貴重な機能の小さな増分を表します。
- 比較的簡単に見積もることができるため、実装に必要な労力をすばやく決定できます。
- 巨大でかさばるドキュメントを使用するのではなく、新しい情報が到着したときに整理および順序変更しやすいリストに編成されます。
- これらはプロジェクトの最初の段階では詳しく説明されていませんが、「オンタイム」でより詳細に開発されているため、早すぎる確実性、開発の遅れ、要件の積み上げ、決定の過度に限定された表現を回避します
- 彼らは最小限を必要とするか、伴奏をまったく必要とせず、実装後に安全にキャンセルすることができます（3）
[継続する]
文学
コーン、マイク。 2004.適用されるユーザーストーリー：アジャイルソフトウェア開発用。 マサチューセッツ州ボストン：Addison-Wesley。
参考文献：
- www.scalingsoftwareagility.wordpress.com
- xp123.com/xplor/xp0308/index.shtml
- これは、回帰テストに必要な詳細でシステムの動作を決定する受け入れテストを開発およびサポートするタスクです。
