XI が Y をしたいので Z がしたいという規定に従って、ユーザー ストーリーを記述します。現在、要件を指定するための BDD とガーキン言語形式が普及しているため、ユーザー ストーリーをゲルキン形式に切り替えた経験がある人はいますか。この形式でビジネスから要件を引き出す方が簡単で直感的だと感じましたか? また、そうすることで何かメリットを経験しましたか?
質問する
1648 次
4 に答える
5
各機能は引き続きAs an X I want a Y so that ZGherkin で開始します。ただし、これは一般的に好転するため、その利点が最も顕著な側面になります。たとえば、https://github.com/cucumber/cucumber/wiki/Gherkin
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value /*Z*/
As an explicit system actor /*X*/
I want to gain some beneficial outcome which furthers the goal /*Y*/
このセクションを完了すると、Gherkin 機能の残りの部分がわかりやすいGiven When Thenセクションになりますが、これらは機能の機能を強調する単なる例です。それらは、機能定義の代わりではなく、機能定義とともに存在します。
詳細については、http://dannorth.net/introducing-bdd/ をよく読んでください。
于 2013-09-16T09:55:11.910 に答える
2
「As a ... I Want ... So That ...」形式でユーザー ストーリーを書き続け、Gherkin を使用して承認基準を書きます。
于 2013-09-15T21:21:14.187 に答える
1
アジャイルの経験を通じて、すべての状況とすべてのチームに有効な固定ルールは存在しないことに気付きました。アジャイルの概念は、不必要な形式主義や変更から離れることであり、これらはむしろ本当のアジャイルの概念から離れてしまいます (私のPOW!)
ユーザーストーリーを書いている間ずっと、それはより進化的なものであり、修正されています。すべての新しいチームで、彼らにとって何がうまくいくかを試してテストする必要があります. 「壊れていないものは直さない」ため、現在のユーザー ストーリーに問題がある場合は、振り返りミーティングで指摘して問題を解決してください。チームが推奨し、同意した変更に従うようにしてください。より良いユーザー ストーリーを得ることができます。
于 2013-09-16T02:47:39.260 に答える