ユーザーストーリー-テクノロジーを含める方法は？
過去数か月間、私はユーザーストーリーを作成する際の技術的な考慮事項の役割について議論することに多くの時間を費やしました。私の見解では、ソリューションが開発されている技術的な境界を理解し、尊重しなければ、多くの話は実際には議論の余地がありません。他の人々は、機能的な側面だけを議論し、技術的な考慮事項を無視するべきだと指摘します。後者のアイデアは、テクノロジーについて考えずに機能を実行できる場合にうまく機能すると思います。 「ユーザーとして、自分のWebサイトに赤いボタンを表示したい」。
しかし、多くの場合、特定のテクノロジーが採用されているためにのみ機能が可能になります。新しいアドオン機能を開発するときに、Dockerを大幅に解放し、アドオンを開発したいプログラミング言語をユーザーに提供できるようにしました。 Dockerテクノロジーがなければ、機能はまったく異なって見えます（おそらく、単一の言語しかサポートしていなかったでしょう）。
私の考えでは、テクノロジーには2種類あります。有効化テクノロジー（機能がそのようなテクノロジーが使用されている領域に触れる場合は、テクノロジーについて話し合う必要があります。議論には問題があります）とサポートテクノロジー（自由に置き換えることができるもの、たとえば、jsonまたはxmlを使用する場合）。
このトピックについてどう思いますか？重要な技術的アイデアを無視せずに、スクラムユーザーストーリーを可能な限りオープンに保つ方法は？
ここで、ユースケースとユーザーストーリーを区別することが重要です。ユーザーストーリーとは、プログラムにおけるユーザーのニーズを説明する、ユーザーが判読できるドキュメントです。それは、他の技術者以外の人がそれが何を参照しているかを読んで理解できるものでなければなりません。私は違いを説明するまともな記事 here を見つけました。
ユースケースは、ユーザーストーリーの技術バージョンです。最初に真でなければならない条件を説明し、ユーザーが実行する正確な手順を説明し、最終効果とは何かを説明し、それを実現するために必要なすべてのテクノロジーを強調します。
つまり、ユーザーストーリーはユーザーが作成し、ユースケースは技術者が作成します。
これはユーザーストーリーの範囲であってはならないため、ユーザーストーリーが特定のテクノロジーについて言及することは正しくありません。ユーザーストーリーのポイントは、素人の視点からプログラムに必要な要件を強調することです。したがって、「私はウィンドウに入り、bashプロンプトを入力して資格情報を入力する」のようなユーザーストーリーは表示されません。
「ユーザー名とパスワードが要求され、彼はログインします。」のようになります。これにより、プロンプトだけでなくGUIインターフェイスも可能になることに注意してください。これから得られるべきことは、JavaFXを使用したり、Windowsコンピューターにインストールしたりするのではなく、プログラムがユーザーを認証する必要があるということです。
ユーザーストーリーが互いに互換性のないテクノロジーの組み合わせを実現する必要があるというありそうもないケースでは、それとこの問題の可能な解決策を後で評価する必要があります。ただし、ユーザーストーリーの性質上、それが技術を可能にするものであろうと、技術をサポートするものであろうと、技術要件を直接参照するべきではありません。
これはオールオアナッシングではありません。ストーリーで果たす役割に応じて、さまざまな技術プラットフォームを異なる方法で処理する必要があります。
あなたの例では、ユーザーはそれを使用するだけでなく、Webサイトを操作したいと考えています。つまり、定義上、彼らはWebページとは何か、そしてWebページの作成方法について何かを知っているということです。また、サイトをさらに発展させるためにさまざまなプログラミング言語を使用したいかもしれません。つまり、プログラミング言語の概念はユーザーの概念でもあり、ユーザーが理解できないようにすることなく、ストーリーで自由に話しても大丈夫です。
一方、これを可能にするために仮想化を使用していること、特に特定のテクノロジーを使用して物事を仮想化しているという事実は、ユーザーの頭に浮かぶかもしれません。 HTML/CSSを記述できる人、またはRuby/C/Python/what-haveを記述できる人もたくさんいます。仮想化についてはほとんどまたはまったく知りません。 （たとえば、私です。）したがって、これらの概念はどちらもユーザーストーリーに属していません。実装で実際に行っていることについて話し合い、文書化するドキュメントの種類は他にもたくさんあります。
@ Christian-Sauer理論的な答えは、これに従って、非機能要件はユーザーストーリーの制約としてモデル化されるということです Scaled Agile Framework Webサイトからのガイダンス 。
Mike Cohnは、User Stories Appliedの第16章でこれをカバーしており、紙ベースのストーリーカードに制約を追加する方法を説明しています。
残念ながら、ほとんどのアジャイル要件管理ツールでは制約を簡単に追跡できないため、これは大規模なチームでは実際にはうまく機能しません。
実際には、ストーリーのユーザーとして要求システムを使用して、これらのタイプの要件のユーザーストーリーと受け入れ基準を作成するのが好きです。どうして？このアプローチにより、技術チームは、適切に形成された受け入れ基準を介して完全にテスト可能な方法で、「良い」ものがどのように見えるかを説明する必要があります。
非機能的なユーザーストーリーは、私が「アーキテクチャ上重要なユーザーストーリー」と呼んでいるものにリンクし、優先順位を付けて、1つ以上のスプリント中に実装するように割り当てることができます。
更新：ストーリーをアーキテクチャ的に重要にするものは何ですか？
必要なビジネス動作の実装がシステムの1つ以上の非機能的制約に影響を与えたり、ストレスを与えたりする場合、ストーリーはアーキテクチャ的に重要です。
例：トップ20 インターネット小売業者 ビジネス顧客向けのWebサイトでは、検索中に顧客固有の価格を表示することは、アーキテクチャ的に重要なユーザーストーリーです。
ユーザーストーリー：購買エージェントとして、検索中に割引価格を確認して、ショッピングカートに商品を追加する前に最低契約価格を取得していることを確認したいと思います。
B2B Webサイトの顧客固有の価格設定は非常に複雑です。これは、特定の顧客が複数の契約に同時に参加する可能性があるためです。これらの契約は、製品カテゴリ全体で割引レベルが異なります。したがって、エンドユーザーが検索中に「最低契約価格」を確認する機能は、構造的に困難です。大規模なB2BWebサイトには、何億もの顧客固有の価格が含まれている場合があります。
検索結果が1秒未満で買い物客のブラウザに返される場合、これらの価格は200ミリ秒未満でアクセス可能でなければなりません。プロジェクトの早い段階でこのユーザーストーリーを実装すると、プロジェクトチームは、アプリケーションのアーキテクチャが200ミリ秒の制約を実現できるかどうかを確認できます。
NFRストーリー：Webサイトプレゼンテーションレイヤーとして、Webをレンダリングできるように、200ミリ秒以内に検索結果のページのカタログおよび/または顧客固有の価格を返す価格設定コンポーネントが必要です500ミリ秒以内の製品の検索結果のページ。
受け入れ基準：ユーザーストーリーの受け入れ基準は、開発チームにストーリーに関する追加の詳細を提供し、ストーリーが持っていることに製品所有者が同意するために存在しなければならない条件を説明します完全に実装されました。
非機能要件の場合、受け入れ基準は、さまざまな実際の使用シナリオの下で要件の達成をどのように観察するかを説明する必要があります。価格サービスの応答時間のユーザーストーリーに戻りますが、このストーリーの受け入れ基準をいくつか示します。
- 16個の製品のリストの価格を設定するための平均応答時間が200ミリ秒以下であることを確認します。
- 50、100、および200製品を含むより大きな製品グループの価格を設定する場合は、平均応答時間が5％以上低下しないことを確認してください。
- 応答時間の95％-ileが平均から20ミリ秒以内であることを確認します。
- 価格設定サービスが次のボリュームでリクエストを処理するときに、平均および95％-ileの応答時間の目標が満たされていることを確認します：100リクエスト/秒、500リクエスト/秒、1,000リクエスト/秒。
- 価格設定サービスが、10,000,000、50,000,000、100,000,000、および150,000,000の顧客固有の価格およびプログラム価格を含む製品データから価格設定する必要がある場合、平均および95％ile応答時間の目標が満たされていることを確認します。
- 価格設定サービスが、カタログ価格設定、標準割引価格設定、および顧客が複数の契約の価格設定の対象となる顧客固有の価格設定（例：コロラド、コロラド大学システム、および西側諸国契約同盟）。
私のエンジニアリングリードは、アーキテクチャの重要なストーリーをプロジェクトの早い段階でスケジュールすることをお勧めします。これにより、ハードパーツがプログラムの増分/スプリントに据え置かれるときよりもチームが問題を解決するための時間が増えるため、アーキテクチャの潜在的な問題をできるだけ早く見つけることができます。配送サイクルの後半。
技術的な考慮事項は、どの分野のユーザーストーリーにも関与してはならないことに同意します。
それでも、ここで関係することはほとんどなく、そのうちの1つはコストです。
コストをユーザーストーリーに直接比例させる場合は、はい、技術的な考慮事項を検討する必要があります。スコープごとにそれぞれの視点をとる必要があります。
場合によって異なりますが、手順を正確に定義することはできません。