私の現在のプロジェクトでは、ビヘイビア駆動開発 (BDD) を、ビジネス要件アプリケーション レベルのタスクの両方のレベルで使用したいと考えています。
クライアントがビジネス要件が完了したこと (その要件のすべての内部仕様が合格したこと) を確認できるように、内部 BDD 仕様を高レベルの仕様にラップ (グループ化) しても問題ありませんが、実際には内部仕様は表示されませんか?
私の現在のプロジェクトでは、ビヘイビア駆動開発 (BDD) を、ビジネス要件アプリケーション レベルのタスクの両方のレベルで使用したいと考えています。
クライアントがビジネス要件が完了したこと (その要件のすべての内部仕様が合格したこと) を確認できるように、内部 BDD 仕様を高レベルの仕様にラップ (グループ化) しても問題ありませんが、実際には内部仕様は表示されませんか?
「仕様にテストケースのソースコードをたくさん入れるべきか」という意味ですか?(BDDは本質的にTDDのリフレーミングです)
そうすれば、答えはほぼ間違いなくNOです。あなたのクライアントはおそらく彼女が望むことをするシステムを手に入れることを気にかけています、そして彼女が望むことは彼女が最初に求めたものではないことはほぼ間違いありません。
フィードバックを得るには、できるだけ早くソフトウェアをクライアントの手に渡してください。アジャイルソフトウェア開発の実践は、クライアントが早期にフィードバックを提供し、要件を迅速に反復することです。
仕様は 2 つのことだけに役立ちます: 要件を議論するためのサポート (それが完了する前) と、責任を追及するためのツール (クライアントが、ソフトウェアは彼女が必要とすることをしないと言ったとき) です。前者は建設的ですが、後者はそうではありません。