私はちょうどその本のScrum and XP from the Trenchesの途中で、 How we do testingの章、特に Acceptance Testing Phase (私はATPと呼びます) について読んでいます。著者は、1 つのアプローチを提案しています。
アプローチ 2: 「新しいものの構築を開始しても問題ありませんが、古いものを本番環境に移行することを優先します」</p>
しかし（私の意見では、または私は何も得られません）そのアプローチはATPをまったく参照していません. 1 つのスプリントがあり、次に別のスプリントがありますが、ATP はどこにありますか。あるいは、最初のスプリントには ATP が含まれていることを著者が念頭に置いているのかもしれません。もしそうなら、それはステートメントフォームのサブチャプターをどのように参照するか? 受け入れテストはスプリントの一部であるべきか? 数ページ前:
私たちはここでよく迷います。一部のチームは、スプリントに受け入れテストを含めています。しかし、私たちのチームのほとんどは、次の 2 つの理由からそうしません。 スプリントにはタイムボックスがあります。受け入れテスト (デバッグと再リリースを含む私の定義を使用) は、タイムボックス化が非常に困難です。時間がなくなっても重大なバグが残っている場合はどうなりますか? 重大なバグがある状態で本番環境にリリースするつもりですか? 次のスプリントまで待つつもりですか？ほとんどの場合、どちらのソリューションも受け入れられません。そのため、手作業による受け入れテストは外部に任せています。複数のスクラム チームが同じ製品に取り組んでいる場合、手動の受け入れテストは、両方のチームの作業を組み合わせた結果に対して行う必要があります。両方のチームがスプリント内で手動で承認した場合でも、最終リリースをテストするチームが必要になります。
皆さん、（ここに質問があります）：その章をどのように理解していますか？
それとは別に、ここに私の考えがあります。著者は、重大なバグの問題があるため、ATP はスプリントの一部であってはならないと述べていますか? では、スプリントで ATP がなければ、このような問題が発生することはありませんか? はい、できます。いずれにせよ (Sptint に ATP があるかどうかに関係なく) 問題が発生します。結論 : スプリント タイムボックスが十分に長い場合 (おそらくそれはアプローチ 2の著者のアイデアでした)、ATP も処理できます。これにより、リリース後に大量のエラーが到着することがなくなります。
ありがとう、パヴェル
PS 本の著者と積極的にチャットできるように変更されたページをご存知ですか?
PS 2質問を投稿する前に読んだときに、おそらく次のように言って、啓発されました。
アプローチ 2: 「新しいものの構築を開始しても問題ありませんが、古いものを本番環境に移行することを優先します」</p>
著者: スプリント 1 が終了し、コードベース (バージョン 1.0.0) が ATP に入ります。同時に、リリース 1.1.0 の Sprint 2 を開始し、同時に 1.0.0 バージョンで発見されたバグを修正します。スプリント 1 で準備されたコードベースに問題がなければ、それは公開されます。ここに、オーバーラップの王様がいます。しかし、それが作者の意図であった場合 (そうではなかったと確信しています)、基本原則を破っています。
- スプリントの後、新しいソフトウェアが利用可能になります (ATP が終了するのを待っているわけではありません)。
- スプリントをスプリント + ATP :) と見なすと、スプリントはタイムボックス化されません。
全体として、その本は素晴らしい読み物ですが、その章は少しあいまいですが（私がその読書中に拾った素敵なクールな言葉でもあります）.