それを呼ばないでください、ほとんどのチームにとってこれは難しいです。 主な困難は、そのような会議が構造化されておらず、その結果が理解できないことです。 彼らは時間がかかり、単に退屈です。 その結果、セッションは不規則になるか、完全に放棄されます。
しかし、そのような会議を短く、非常に生産的にする簡単な方法があります。 このメソッドは、サンプルマッピングまたはテストケースのマッピングと呼ばれます。
仕組み
特定のテストケース（例）は、サブジェクトエリアを探索するための優れた方法です。 彼らはあなたの受け入れテストのための良い基礎になることができます。 テストケースについて議論するとき、他の側面についても話し合う必要があります。
- さまざまなケースを一般化するルール 、またはその逆は、テストケースの適用可能性を制限します。
- 実際に何が本当かわからない場合のシナリオに関する質問 。 または、要件の開発を何らかの形で進めるために我々が提唱した仮説 。
- ディスカッション中に明らかになった新しいユーザーストーリー 。
マッピングの例では、4種類の色のカードとボールペンを使用して、話すときに新しい情報を記録します。 ミーティング中、上の写真のように、情報はカードに記録され、ボードに配置されます。
最初に、黄色のステッカーに、ストーリー自体を書き留めて、ボードの上部に配置する必要があります。 次に、青色のステッカーには、以前に開発した各受け入れ基準またはルールが示されています。 黄色の下に青いカードを配置します。
通常、各ルールは複数のテストケースで説明できます。 各テストケースには独自の緑色のステッカーがあり、対応するルールの下に配置されています。
地図を編集して事例を議論している間、出席者が誰も答えられないという疑問が生じるかもしれません。 赤いステッカーにそれらを修正し、議論を続けます。
ストーリーは完全に理解されていると全員が確信するまで、または割り当てられた時間が終了するまで、会議は続きます。
インスタントフィードバック
このような会話の過程で、歴史の現在の理解の視覚的表現が簡単かつ迅速に構築されます。
- 赤いステッカー（質問）で覆われたボードには、まだまだ多くのものが残っています。
- 青いステッカー（ルール）で覆われたボードは、ストーリーが大きく複雑であることを示しています。 おそらくあなたはそれを分解する必要があります。 別の黄色のステッカー（ストーリー）を取り、ストーリーの一部をバックログに入れる必要があるかもしれません。
- ルールに含まれるテストケースが多すぎる場合は、おそらく複雑すぎるため、個別に詳細に説明できるいくつかのルールを強調表示する必要があります。
一部のルールは非常に明白であるため、テストケースを必要としない場合があります。 たとえば、誰もが同じ方法でルールを理解している場合、時間を無駄にして固定数のテストケースを拷問する必要はありません。
限られた時間で考える
いくつかのアミーゴのグループは、 約25分でまともなストーリーを作成するはずです。
割り当てられた時間を満たすことができない場合、いくつかのオプションが可能です。
- あなたはまだこの方法を使うことを学んでいます（これは正常です）。
- あなたの物語が大きすぎる（これは間違いなくもう良くない）;
- あなたのストーリーには不確実性が多すぎます。
何ができますか？ ストーリーをいくつかに分割するか、製品の宿題の所有者に渡して、後で次のセッションでマッピングの例を使ってこのストーリーに戻りますが、答えは返してください。
CucumberのMatt Wynneは、ストーリーが開発のために提出される準備ができているかどうか、25分以内に投票するよう会議の参加者を招待します。 いくつかの問題が未解決のままであっても、チームはあまり不確実性がないと判断する場合があり、その過程でさらに開発することができます。
便益
マッピングの例は、スケールを変更し、履歴動作の最小部分に焦点を当てるのに役立ちます。 マップをコンパイルすることにより、ルールを選択し、目的の動作の本質を見つけて、残りを後で延期することができます。 調査が徹底しているため、サンプルマッピングはフィルターのように機能し、大きな大胆なストーリーがスプリントに入るのを防ぎ、最後に不快な驚きを与えます。 さらに、このアプローチは時間を節約し、プロセスに関心を持つ人々の関与を維持するのに役立ちます。
3人のamigoがこのミーティング中に受け入れテストを作成する必要があるようです（たとえば、Cucumberのスクリプト）。 原則として、これは理にかなっている場合もありますが、多くの場合、このアプローチは会話の真の目的から逸れるだけです。
そのような意見がどこから来たのかは明らかです。明確な目標は、事前に定義された受け入れ基準をすでに持っているユーザーストーリーを取り上げ、受け入れテストに変換できるテストケースを見つけることです。
本当の目標は、ストーリーを作成するために必要なものの共通理解を達成することです。 高度な技術を使用しなくても、この目標に向かって迅速に移行できます。
記録の簡素化
したがって、正式なGherkinスクリプトを使用する代わりに、命名規則を使用してテストケースのリストをすばやくコンパイルしてください。
例：
- 顧客が領収書を忘れた場合。
- 製品は15日前に購入されました。
このケース名の背後に不確実性が隠されている場合、本能的に詳細と詳細が必要です。 しかし、それでも、 Then When Thenの剛体構造に固執する必要はありません。
結果（ "then"）が不明確な場合、この例は機能しませんが、問題は解決します。
既知の不明
会話が循環し始めたら、十分な情報がありません。 ミーティングに適切な人がいないか、調査を行うかSpikeを使用する必要があります。
結果がどうあるべきかについて各参加者の意見を聞く代わりに、レッドカードに質問を書いて先に進んでください。 それで未知は既知の未知に変わるでしょう。 これは大きな進歩です。
経験から、この例のマッピングの例でさえ、3つのAmigo会議を退屈なものから迅速で生産的なものに変えることができます。
誰が参加すべきですか？
開発者、テスター、製品所有者（ビジネスアナリスト）の3人以上が必要です。 これは最低限です。 さらに、操作から誰か、UXの専門家、または議論中のストーリーに関与している他の人を招待できます。 会話中に新しい質問を見つけたり、質問を回答に変えたりできる人は誰でも役に立ちます。
このテクニックを習得している間、ファシリテーターの役割のために誰かを見つけることは便利です。 彼の正式な任務は、言われたすべてがすぐにステッカーに記録されるようにすることです。 テストケースと質問は、セッション中にすばやく議論され、問題のあるものを確認するためにタイムリーにステッカーにそれらを書くには規律が必要です。
Gherkinに書き込むタイミングは？
誤解しないでください。Gherkinを使用することは、特にプロジェクトの初期の段階で共通言語を開発する際に非常に価値があります。 チームの全員がそれを信じるように、シナリオを表現することが重要です。
しかし、このようにテストケースを記述するには、異なる考え方が必要です。 どのケースが問題の分野に該当するかを決定し、それらの一般的なルールを確立するだけでなく、。
かなり成熟したドメイン言語で作業するチームの場合、製品所有者がマッピングに時間とエネルギーを費やし、ガーキンを書く作業を他の2人のアミーゴに任せる方がより有益です。 Gherkin仕様を開発した後、製品所有者はフィードバックを提供できます。 「そのように書けますか？」という質問を自問することで、製品の知識をアミーゴに伝えるという点で、マッピングがどれほど効果的であったかを確認できます。
これはどのくらいの頻度で行われますか？
実際には、 1日おきに会うことをお勧めします。 ユーザーストーリーを1つ選択し、25分間注意を向けてから、仕事に戻ります。 もっとやろうとするなら、エネルギーを無駄にしてください。
しかし、私は分散チームを持っています！
このために、Googleのキープ上のステッカーのリストや、色の付いたステッカー付きのオンライン掲示板など、既に解決策を考え出しています。 マインドマップを使用できます。 主なことは、会話に集中できるように、簡単かつ迅速に作業できることです 。
最後のヒント
サンプルマッピングを使用する前に、 ルールとテストケースを明確に区別することが重要です。 これには楽しい練習があります。
このような会議の最終目標は、 まだ知らないことを発見することです 。 愚かな質問はありません。それらはすべて問題を本当に調査するのに役立ちます。
この手法を使用すると、ルールによってストーリーの自然な発展ラインが作成されることがわかります。 質問に落ち着いて関わり、それらを分離し、脇に置くようにしてください。 その後、主な問題の解決に集中できます。 後で複雑になって理想に近づけることができます。
QualityConfカンファレンスで、要件を解決し、テストケースカードを作成するための3 Amigoの実践について説明します。 さらに、承認されたレポートのリストには、高品質のIT製品を作成するための他の非常に興味深い実用的なアプローチが含まれています。 QualityConfカンファレンスは、5月27日と28日にRIT ++フェスティバルの一環として初めて開催され、参加する時間があります。