スクラムの課題の 1 つは、QA をプロセスに組み込む方法です。確かに、QA はスプリント中に個々のユーザー ストーリーについて開発者と協力しますが、本番環境にリリースする前に、完全に完了したスプリントで完全な回帰テストと負荷テストを行う時間を QA に与えるのはどうでしょうか?
私は2つのアプローチを見てきました：
どちらのアプローチにも課題があるので、すべてのスプリントをリリースするほとんどのショップは何をしているのでしょうか?
どちらのアプローチにも課題があるので、すべてのスプリントをリリースするほとんどのショップは何をしているのでしょうか?
私の意見では、スクラムの最終的な目標は、スプリントの終了後に新しいインクリメントをリリースできるようにすることです。言い換えれば、スプリントの結果は解放可能な増分です (解放された増分ではありません)。
したがって、オプション #1 は私には少し早すぎるように思えます (製品バックログ項目はスプリントの最後でデモの前に完了します。また、完了の定義に「本番環境へのリリース」は含まれていません。これは別のチームの仕事です)。
そしてどういうわけか、オプション＃2は、DONEの定義に「DONE DONE」にするために必要なすべてを含めていないことを意味していると思います. 簡単にできると言っているわけではありません。完了の定義にリリース可能に到達するために必要なすべてのステップを実際に含め、目標を達成するために必要な組織の変更を行うには、ある程度の時間がかかるでしょう。
個人的には、まだこのレベルの流動性 (各スプリントでのリリース) には達していませんでした。QA の一部は各スプリント (IST、UAT) で行われますが、実際には 2 週間の 4 つのスプリントごとにリリースしています。最後のスプリントは一種のリリース スプリントであり、負荷テストの実行、必要に応じた最適化 (現在はそれほど悪い驚きはありませんが)、ドキュメントの作成 (制作チームやユーザー向け) などの「特別な」プロダクト バックログ アイテムを使用します。リリースサイクルを短縮するには、今のところ実行できないより深い変更が必要であり、実際には私たちの場合は望ましくありません. もちろん、あなたの文脈は確かに異なります。
それは業界、市場および他の多くの要因に依存します。単一の答えはありません。スクラムはフレームワークであり、すべてに適合するわけではないことを忘れないでください。私は、ソリューション＃1が実際に動作しているのを最もよく見ました。
スプリントの最後に、リリース可能な製品バージョンが必要です。小さなスタートアップや小さな会社で非常にうまく機能します。それは彼らの競争上の優位性の1つです。QA担当者は簡単にチームに入れることができます。これは、ソフトウェアが重要でない場合に大企業で達成できます（ソリューション＃2）。
セキュリティが重要な大企業にスクラムを実装しました。規制や認証の制約により、スプリント後のリリースは不可能でした。開発者が関与しなければならない長いリリースプロセスに取り掛かる必要がありました。私たちはそれで働かなければなりませんでした。
しかし、ほとんどのソフトウェアファクトリーでは、デモの後で、ほぼワンクリックでリリースできます。これを可能にすると、反復型開発のすべての力を得ることができ、それは非常に大きな競争上の利点です。
商業的な観点から、各イテレーションの最後にリリースしないこともお勧めします。
あなたがソフトウェア業界にいるとすれば、あなたの質問に対する答えまたは問題の解決策は、堅実なプロジェクト リリース プランとプロジェクト タイムライン プランを備えたエンタープライズ スクラム モデルを使用することです。
DB 管理者、アプリケーション サーバー管理者、シニア QA 担当者、およびシニア プロダクション サポート アナリストを含むオペレーション サポート スクラム チームが必要です。このチームは、完全な QA リグレッションと負荷テスト、リリース管理、コード展開、および開発スクラム チームのその他の運用サポート活動を担当する場合があります。一方、開発スクラム チームは、リリース可能なソフトウェアを作成し、運用サポート チームのために棚に置くだけでした。
あなたのこの特定のシナリオでは、運用サポート チームは、製品バックログ リストにバックログを作成し、開発チームによって作成された棚上げ製品の回帰テストと負荷テスト アクティビティを実行します。回帰は理想的には開発プロセスの一部であるべきです!!!
現在、すべてのスプリントをリリースする組織では、運用チームが開発チームより 1 ～ 2 週間遅れている必要があります。たとえば、スクラム開発チームがリリース 2.0 コードに取り組んでいる場合、運用サポート チームは開発チームがリリース 1.0 コードを展開する必要があります。チームは 2 週間前に「棚上げ」を完了しました。
肝心なのは、リリース計画は正しいタイムラインでレイアウトする必要があるということです。スクラムでは、各スクラム チームは自己管理型であるため、独自のリリース計画を持ち、独自の展開などを行うという誤解があるかもしれませんが、これはある程度正しいかもしれませんが、チームの計画はそれに適合する必要がありますプロジェクト全体のリリース計画も同様であり、それに応じてタイムラインを合わせる必要があります。
タイムラインを調整し、プロジェクトのタイムラインに従ってバックログを整理する責任は、主に PO の肩にあり、SM は、これを最も効果的に機能させる方法について PO をトレーニングする責任があります。簡単な答えは次のとおりです = 開発チームと、QA またはリリース活動を行う運用チームとの間に 2 週間のギャップを設けるのは適切ですが、プロジェクトのニーズに応じてタイム ラインとギャップを調整する必要があります。
これについてさらに詳細が必要な場合は、お問い合わせください。これについて話し合う会話は、説明するのがはるかに簡単だったでしょうが、これがあなたの質問に答えてくれることを願っています. ところで、開発チームのためにスプリントが終わった翌日に (PROD に) リリースすることは、私にとっては悪い考えですが、いつでも試して、検査し、適応させることができます ;) そして、1 週間は十分なギャップですが、状況によって異なりますアプリケーションの大きさ、データの大きさ、リソースの数。
ありがとう、シド・テラン。認定スクラムマスター
私の理解では、スプリントの終わりに「完了する」ことが重要であり、以前にリリースされたソフトウェアを作り直さなければならない別のスプリントで「技術的負債」を引き継ぐ必要はありません。