ユーザーストーリーに取り組む
機能リクエストに取り組むためのプロセスを強化しようとしています。現在、カードを使用して機能リクエストを管理するためにtrelloを使用しています。それらは通常このように見えます。
Card Title: Invite a friend
Card Description: Allow the user to send an invite.
次に、機能を解釈し、要求を満たすためのコードの記述を開始します。コーディングの途中で停止して、クライアントまたはプロジェクトマネージャーに「これは通常のユーザー専用ですか？そのメールが既に存在する場合はどうなりますか？招待ページのリンクはどこに移動する必要がありますか？」などのメッセージを送信する必要があります。
ユーザーストーリーの作成に取り掛かっていますが、会話の内容が前面に出てきて、機能の計画段階に役立っているようですが、コードを書く前に、少なくとももう1つのステップがあるはずです。
例として、教師と生徒がコミュニケーションできるWebアプリケーションに取り組んでいるとしましょう。ユーザーが招待を送信できるようにする機能リクエストを受け取ります。この機能には3つのシナリオがあります。
シナリオ1ユーザーストーリー
As a：生徒I want：クラスメートを招待するSo that：彼らは私たちの教師と通信できます。
シナリオ2ユーザーストーリー
As a：学生欲しい：先生を招待するだから：アプリケーション内で通信できます。
シナリオ2ユーザーストーリー
as a：先生欲しい：同僚を招待するそうする：彼らは生徒とコミュニケーションをとることができる。
コードを書く前に計画段階の一部としてこれを打ち破るプログラマー/開発者としての最良の方法は何ですか？このユーザーストーリーを開発者関連のものに分割するにはどうすればよいですか。実際にコードを記述しているときに参照できます。私はTDDを使用しているので、通常は存在したいコードでテストを書き始め、テストを満たすためにクラスとメソッドを書き始めます。ユーザーストーリーで同様のことを行うことはできますか？
BDDとGherkin仕様言語を探しているようです。ガーキン言語は、コードレベルのテストをスタブ化するために使用できるビジネスシナリオを表現する方法です。テストスタブを入手したら、従来のTDDの赤/緑/リファクタリングスタイルの方法を使用してソリューションの実装を開始できます。
これに関するブログ投稿は次のとおりです： https://medium.com/@SteelKiwiDev/how-to-describe-user-stories-using-gherkin-language-8cffc6b888df
ガーキンシナリオを複数の言語で読み取ることができるBDDフレームワークがあるため、開発者が使い慣れているものから始めることができる可能性があります。
うーん。私はあなたの3つのシナリオを見て、私が心配している依存関係を見つけました。シナリオ1は、シナリオ2がすでに提供されていると想定しているようです。これにより、少なくとも、「これらの3つのシナリオの実際の違いは何ですか？」多分何も。たぶん私は1つのシナリオだけが必要です。
あるいは、ここに非対称性があるかもしれません。他の人を招待するには、特別な許可（承認？）が必要ですか？これは、ドメインとシステムの意図された動作を知っている誰かと一緒に探索するもののように聞こえます。
システムが特別な許可ルールを必要としているとしましょう。問題ない。最初のストーリーは、誰もが他のすべての人を招待できるようにすること（名誉システム）として記述し、次に「興味深い」種類の承認ルールごとにさらにストーリーを追加します。誰かが他の誰かを招待できるようになると、関連する各ストーリーは、許可されるべきではない招待リクエストを禁止することによって機能を改良します。これはいくつかの理由で良いのですが、システムに深刻なセキュリティ/プライバシーの懸念がある場合は、「誰も誰も招待できない」から始めて、一度に1ストーリーずつ権限を追加するように、それを裏返す必要があるかもしれません。大きなストーリーを小さなストーリーに分割しようとすると、潜在的な暗黙の仮定について質問する傾向があります。 「まあもちろん承認ポリシーがあります...誰がそれを持っていないのですか？！」と聞くのを待ちすぎたくありません。
私にとって、キラーテクニックは「例で話す」です。誰かと話をするとき、私はその話の現在の理解を説明する例を執拗に説明します。このようにして、他の人は私の例を聞いて、私がどのように間違っているかを教えてくれる機会があります。その瞬間は、適切なシステムを構築するために必要な詳細を学ぶことにつながります。私はこれを何度も繰り返し、これらの詳細を収集します。私はもっと単純な例を説明しようとし続け、それは他の人に重要なバリエーションを追加するために「戦う」ように促します。数分以内に私は多くのことを知っています。 15分以内に、完全に間違った方向に向かわずに始めるのに十分なことをほぼ確実に知っています。それから私はもの（TDDかどうか、あなたのために働くものは何でも）を構築し、それらの前に何かを置き、そしてより多くのフィードバックを得ます。例では。何回も何回も。それはうまくいきます。
ちなみに、これらの例は、システムの動作を駆動するための自動テストになる可能性があります。お客様がこれらの例の作成と改良にどれだけ積極的に参加するかに応じて、好きなようにそれらを自動化します。これらの例の価値の90％は、自動化ではなく会話から得られることを覚えておいてください。