Schwaber＆Beedleの「スクラム」本（および私が読んだ他のスクラム文献）は、スプリントの終わりまでにリリース可能な製品を手に入れることに焦点を当てているようです。確立されたサイトのWeb開発（少なくとも私たちの場合）は、（さまざまなサイズの）「拡張機能」と多くの小さな「修正」の開発で構成されています。スプリントの最後にのみ（Webに）デプロイすると、大規模な拡張機能の展開が遅くなりますが（おそらく良いことです）、小さな拡張機能と修正の展開は劇的に遅くなります（つまり、バグが長く続く）。
ミッドスプリントの展開はスクラムで異端的ですか？私たちの場合、スプリントも適用できますか？私はスプリントを完全に誤解しましたか？
スプリントの途中で本番環境にデプロイするのは悪い考えのように思えます。本当のフォーカススティーラー。
たぶん、スプリントの長さを短くすることはあなたにとって何かでしょう？
スプリントの終わりに完了した作業は、レビュー ミーティング中にプロダクト オーナーによってレビューされる必要があります。途中でリリースすると、そうではない場合があります。
スプリントが終了する前に作業が完了したと感じた場合は、次のことができます。
あなたの作業環境の説明を考えると、私は 2 を選びます。
また、環境により適した別のアジャイル手法を検討することもできます。
私はスプリントの途中でリリースしません。
スプリントの最後にリリース可能なコンテンツがあるからといって、スプリント中のリリースが妨げられるわけではありません。実際、チームが生産サポートの責任を負っている場合、それは必須です。
ただし、これらのミッドスプリント リリースについていくつか質問します。
1) 以前のリリースの増分値は、展開のコストを超えていますか? 2) これらのミニ展開のそれぞれのリスクを評価して、裏目に出てより多くの作業を作成しないようにしましたか? 3) 顧客が望むものをリリースしていることを確認するために、これらのミニ リリースに対する顧客からのフィードバックを得ることができますか? 4) スプリントを短くすることを考えたことはありますか?
「厳密なスクラム主導の開発」(上記で言及) は、私にとって矛盾した表現です。マントラは検査と適応です。スクラムが利害関係者への対応を改善することに対する教義として利用されているという提案には、私は怒りを覚えます。
アリスターコーバーンクリスタルの「オレンジウェブ」メソッドをご覧ください。彼は、アジャイルの原則を公開Webサイトの制約に適合させました。
厳密なスクラム主導の開発を実行したい場合、スプリント中の展開は異端です。私の意見では、厳密なスクラム アプローチは、シナリオに使用する最適なツールではありません。展開パッケージとそれらに割り当てられたタスクを定義した、より古典的なアプローチを使用します。単一のトランクで開発し、特定の展開パッケージのすべてのタスクが完了したら、それを展開します。ただし、コードとプロジェクト内の制約に注意してください。