TDDチーム間でのテストの重複を回避する方法

Question

私たちのチームは、本来あるべきアジャイルチームになるために、BDD/TDDを使用して開発することを決定しました。垂直スライスは、アジャイル作業と必要な迅速なフィードバックを得るための重要な部分のようですが、PBIタスクを私たちの間で分割し始めると問題が発生すると思います。

複数のWebサービスと1つのページアプリを備えた分散システムを作成しています。次の2つのユーザーストーリーの例を見てください。それぞれがPBIを表しています。

問題は、これらのPBI /ユーザーストーリーのいくつかが共有されるため、完了するために必要なタスクに起因します。

たとえば、私たちの組織のビジネス要件は、すべての要求をログに記録する必要があることです。したがって、これらのPBI（および私たちが所有する他のほぼすべて）の受け入れ基準には、監査サービスの呼び出しが含まれている必要があります。

したがって、垂直スライシングの使用を計画している場合、2人の開発者がどちらも、実装を促進するテストを含む、ログ記録を実行する監査サービスの同じ部分を書き込み、1人の開発者の時間を効果的に無駄にすることを想像できます。

また、どのPBIに他の機能で必要となるいくつかの機能が含まれているかを覚えておくという要素もあります。

これを避けるためにどのように整理しますか？これは垂直スライスに固有の問題ですか？これは、水平方向のスライスでは問題が少ないようです。

Daniel · Answer

この方法で開発を行った私の経験では、これが捕らえられるべきいくつかの場所があります：

1）計画や毎日のスクラムに巻き込まれるはずです。「Xの作業をするつもりです」「ああ、Xの作業もするつもりだったので、話しましょう」といった会話が起こりそうです。

2）それが何らかの理由で失敗した場合でも、TDD（またはBDD）のステップ1は、失敗したテストを作成することです。私がこれをするとき、誰かがすでに仕事をしているなら、それは予期せず合格するはずです。

3）最後に、定期的なコードレビューを行っている場合、遅くともそこに表示されるはずです。この時点で、私たちはせいぜい数時間を浪費しましたが、これは不幸なことですが、壊滅的ではありません。

これがステップ2または3に頻繁に到達する場合、レトロのトピックが、なぜそれが起こっているのか、そしてそれがどのように前進しないようにするかであることを願っています。

Greg Burghardt · Answer

監査サービスへの呼び出しの場合、私は彼らを彼ら自身の物語にスピンオフします：

ストーリーの主題は「ユーザー」から「監査人」に変わります。

開発者がストーリー＃1に取り組むとき、彼らは監査サービスへの呼び出しについて心配しません。ストーリー3はストーリー1に依存しています。

ストーリー2はストーリー1にも依存しているため、ストーリー1を完了するとストーリー2と3が開きます。

最後に、ストーリー4はストーリー3に依存しているため、最後に開発する必要があります。

 .----->[Story 2] / \ [Story 1]-----> >---->[Story 4]--->(Done) \ / .----->[Story 3]

肝心なのは、ユーザーが監査についてのがらくたを与えないことですが、監査人は確かにそうします！エンドユーザーの受け入れ基準は監査人の受け入れ基準とは異なるため、それらは異なる（ただし関連する）ストーリーである必要があります。