TL; DR：必要に応じてリリース
リリースに価値がある場合はいつでもリリースを行います。場合によっては、単一の機能またはバグ修正が完了した後にリリースを行うことを意味します。時にはそれは機能やバグ修正のコレクションをリリースすることを意味します。
これは、高速リリースを必要とする「緊急事態」が頻繁にあることを意味するものではありません。リリースを簡単にするために一生懸命取り組んできたということです。私たちのコードはすべてのビルドでテスト、タグ付け、パッケージ化されています。私たちは自動受け入れテストを使用しており、その結果、テストに合格したコードに高い信頼を築いています。ローカルのyumリポジトリを介してパッケージをすぐに利用できるため、リリースのデプロイは簡単です。
決して。これは「スプリント」の基本的な前提に違反しています。決心したことを終えるまで走ります。あなたが終わった後、それは本当に終わりました、そして、本当に働きます。その後、それを解放できます。
リリースは、リリース用にパッケージ化された別の種類のスプリントにすることができます。
バグ修正リリースは、短いスプリントにすぎません。同じ長さのスプリントの定期的なスケジュールがないことは、多くの人が悪い考えだと考えています。したがって、通常のルールは、バグ修正はnextスプリント中に発生する単に優先度の高い作業であるということです。
緊急の場合は、あまりにも多くのこと（サポートと開発）が行われているため、組織を変更して、より少ないことを行うことを検討する必要があります。
チームが取り組んでいる作業が、スプリント内で複数のリリースを行うのに役立つ場合は、必要なだけリリースしてください。
同じことが、不具合修正リリースにも当てはまります。リリースすることが理にかなっている場合は、リリースしてください。
私が働いた最後のアジャイルの仕事はすべてのスプリントをリリースしました。コードは隔週木曜日に凍結され（2週間のスプリント）、その後、製品がパッケージ化され、クライアントが使用できるようにUATサーバーに公開されました。これは、製品の初期開発中です。成熟した製品、特にWebアプリではなく配布可能なプログラムの場合、2〜3週間ごとのアップグレードでユーザーに負担をかけたくないでしょう。
事実上、すべてのリリースにはストーリーポイントと欠陥（バグ）が混在していました。 「理想的でない時間」として数えられる欠陥。仕事の1日の理想的な時間は5時間です。つまり、新しいポイント作業の前向きなコーディングです。残りの1日3〜4時間は、ミーティング、ディスカッション、デザイン、「スパイク」（集中的な研究/概念実証開発）、および欠陥作業です。より良い製品に貢献し、プロセスの必要な部分ですが、単にチーム全体のスプリントを占めることができないもの。不具合のみのリリースを行ったのは、IPMの時点でバックログにストーリーポイントの作業がない場合のみでした。次に、「できるだけ多くの欠陥を解消する」ように指示されたQAスプリントをスケジュールしました。要件の準備ができていないことは常にPOの責任であり（POはクライアントのために機能しました）、契約変更通知を発行して、私たちが持っていたもので作業することができます。もちろん、実際のストーリー作業が終わり、「保証」の開発に入ると、欠陥がすべてありました。
適切に管理されたアジャイルプロジェクトでは、要件が不足することはありません。バックログには常に、スプリントに相当する作業の準備ができている必要があります。しかし、POは時として生産要件を圧倒します。 BA /テスターは、要件の品質やストーリーの競合に関連する理由により、ストーリーのリリースを開発バックログに保留することがあります。明確に定義されていなかったり、十分に見積もられていなかったり、残りのサイクルを簡単に取り上げたりすることができないストーリーをチームが「パント」する必要があると判断する場合があります。要するに、アジャイルでさえ、たわごとが起こります。
リリースとはどういう意味ですか？ PSPを意味する場合-おそらく出荷可能な製品には、2つのオプションがあります。
- 本（またはスクラムレベル2）ごとのスクラム。スプリントの最後にPSPがあり、それが回顧会議で表示されます。
- また、チームがソース管理や継続的インテグレーションなどのツールをマスターし、継続的デリバリーに移行したスクラムレベル3という用語にも会いました。そのようなチームは、毎晩のビルド（または最良の場合はすべてのビルド）の後にPSPを使用できます。すべてのビルドの後にPSPを持っているからといって、ビルドのたびにPSPを顧客に見せることはできません。それは、まだ内部リリースにすぎません。
レベル2とレベル3の主な違いは、レベル2ではスプリントの最後に最終的なPSPを作成するために多少の労力を費やす必要があるが、レベル3ではツールと構成に最初にいくらかのお金と労力を費やし、PSPを準備することです。常に自動的に=手動での作業は必要ありません。レベル3を完全に達成することはまれです。
数週間後、私たちは自分たちのニーズに合った優れたソリューションを見つけました。いつでも好きなときにリリースすることにしました。その方法：
- 誰かが実際の開発ブランチをリリースすることを決定したときは常に、マスターブランチのすべての変更をマージして、新しいリリース番号でタグ付けし、ステージングシステムにプッシュしました。
- qAと他のすべてのチームが実際の変更ログをメールで受け取り、ステージングシステムをテストするよりも
- バグが見つかった場合は、マスターで修正し、ステージングにプッシュしてから、マスターを開発ブランチにマージします
- ステージングシステムがQAに合格すると、マスターは稼働状態になります
それでおしまい。 CIシステムとしてgitとmavenを使用しており、十分なテスト範囲をカバーしています。これが、このようにできる理由の1つです。
スクラムには、新しい機能をいつ導入するかについての規則はまったくありません。すべてのチームには「完了の定義」が必要です。これには常にテストに関するいくつかの基準が含まれている必要があります。機能が「完了する」と、実際の世界で使用できるようになり、展開する前に満たす必要のある依存関係や条件がない場合は、スプリントの終了を待つ必要はありません。それを展開します。
いずれも、それがスプリントレビュー/計画会議で発表されないことを意味します。コンセプトは、チームが完了したすべてのものがPO（および他の顧客SME）に表示されるため、システムの進化に応じてシステムの理解を深めることができるということです。
ほぼ2年前の質問に答えることは少し冗長かもしれませんが、うまくいけば、この質問に来た他の人に価値を追加するために、2セント程度追加したいと思います。 :)
質問に答えるには、スプリントの最後に、スプリントにコミットしたことをリリースすることが望ましいです。そうすることは、適切なタイミングで最高のビジネス価値を引き出すことに向けられたスクラムの他のすべてのパーツ/プロセス/ガイドラインと結びついています。
しかし、緊急事態、バグ、予期しないイベントなどがあなたの手を強制する可能性があるため、「リリース計画」のコンセプトが役立つ場合があります。 「リリース計画」とは、ウォーターフォールタイプの計画ではなく、製品のバックログとスプリントなどのストーリーの優先順位を管理するのに役立つ期待の計画を意味します。
しかし、恐らく、この質問に対するDavidのコメントは、最もよく検討すべきものです。スクラムが常に正しい答えであるとは限りません。