私たちのチームは、新しいプロジェクトの開始のために TFS 2015 に移動したばかりで、バックログ項目用のかんばんボードをセットアップしました。
私が聞きたかったのは、ユーザー ストーリーの (ガーキン) 仕様を記述するための別のタスクボードを作成することに意味があるかどうかということでした。これは一般的な方法ですか?
記述されたユーザー ストーリーの仕様の記述を追跡し、各仕様が QA 担当者などによるレビューを受けるようにしたいと考えています。
私たちのチームは、新しいプロジェクトの開始のために TFS 2015 に移動したばかりで、バックログ項目用のかんばんボードをセットアップしました。
私が聞きたかったのは、ユーザー ストーリーの (ガーキン) 仕様を記述するための別のタスクボードを作成することに意味があるかどうかということでした。これは一般的な方法ですか?
記述されたユーザー ストーリーの仕様の記述を追跡し、各仕様が QA 担当者などによるレビューを受けるようにしたいと考えています。
いいえ、それは一般的な方法ではないと思います。基本的に、仕様を書くことは、ストーリーの受け入れ基準の一部であるタスクです。
いくつかのオプション:
「コミット」から「完了」への移行の一環として、ストーリーが仕様レビューを確実に通過できるように、「仕様レビュー」のバックログに列を追加します。仕様を記述し、それらが合格することを確認するためのタスク (または複数のタスク) があります。タスクがまだ開いている場合、スペックは書き込まれません。
ユーザー ストーリーごとに、Gherkin 仕様を記述するためのタスクを作成します。Git を使用している場合は、プル リクエストを開いて仕様をトランクにマージすることを要求するブランチ ポリシーを使用して、仕様をブランチにコミットできます。マージが許可される前に必要なレビューが必要です。