このスクラムスプリントの説明に基づくと、スプリントの長さは30日であることがわかっていますが、最短で1週間になることもあります。これは継続的展開にどのように適合しますか。CDを使用すると、統合に合格した直後に完成したストーリーをリリースできます。
2週間のスプリントを行うことは可能ですが、スプリントの最後に完成したストーリーを「配信」する代わりに、すでに配信されていることを示すだけですか？あなたは実際にスプリントを通してそれらをリリースしたかもしれません。
問題は、スプリント全体で統合およびリリースしても、チームがスプリントを計画できないことです。これにより、管理者はチームにリリースリリースのリリース、手抜き、コードのプッシュを促すことができます。
スプリントの開始時に、チームは、スプリント中にどのアイテムを生成するか (長さに関係なく)、プロダクト オーナーと合意する必要があります。これは、スプリント計画会議で発生します。これは、理由からそう呼ばれています (計画が関与しています)。
スプリント中、チームは約束されたアイテムを提供します。もしアイテムを統合して製品化すると約束した場合、チームはそれを実行します。アイテムがいつ製品化できるかできないかを示すスクラム固有のものは何もありません。それはチームと製品所有者次第です。
スクラムの基本的な考え方は、チーム外の誰も (プロダクト オーナーを含む) 誰も、スプリント中にチームが作業するアイテムを変更することを許可されていないということです。
簡単な答えはノーです。あなたが説明しているプロセスモデルは、スクラムというよりかんばんに似ています。カンバンでは、チームはアイテムが最終段階を通過するとすぐにリリースします。あなたの場合、これは統合段階です。スクラムでは、PO はスプリントの最後にインクリメントをリリースするかどうかを決定する必要があります。スプリントの途中でアイテムをリリースすることは、スクラムのベスト プラクティスではありません。
Doneが生産を意味する場合は、それを出荷します。
なぜチームは計画を立てることができないのですか? 彼らは、出荷が PBI の完了基準の一部であることを知っているため、長さに関係なく、スプリントのサイジングと計画ではこれを考慮に入れる必要があります。
チームの完了の定義を犠牲にして、経営陣がより速いペースを推進する可能性は常に存在しますが、チーム、スクラム マスター、およびプロダクト オーナー (スクラム チーム) は、経営陣と協力して、その推進力の原因を解決する義務があります。 .
継続的な展開がアジャイルの中核であるという意味で、スクラムはアジャイルではないことを理解したように感じます。スクラムは、スプリントの最後に製品所有者が決定する約 1 ～ 4 週間のリリース ポイントのリズムです。スプリント中の継続的な方法ではありません。
実際、ウィキペディアは「スクラムは...アジャイルソフトウェア開発でよく見られる」と述べており、必ずしも同義ではないことを意味しています.
プレリリースされたソフトウェア開発、または自然なリリース サイクルを持つ非サーバー ベースのソフトウェアは、CI が完了するまでアジャイルであり、それでもスクラムで管理できると思います。
スクラムは、ウォーターフォールとアジャイルのちょうど中間です。Waterfall よりもはるかに優れており、Agile に近いですが、Agile ではありません。
ウォーターフォール: いくつかの大きな長いスプリント スクラム: 管理された小さなスプリント アジャイル: 継続的なスプリント
ここに、Scrum.org トレーナー リストに関する議論の結果を示します (これまでのところ、他の人が反応すると確信しています)。単純な点で非常に重要な角度を忘れていたので、リストに記載されていることに同意し、以前の回答に間違いがあると言わなければなりません.
覚えていない人も多いかもしれませんが、スプリントには包括的な、ややあいまいな目標があることが期待されています。すべてではありませんが、多くまたはほとんどのプロダクト バックログ アイテムが目標に到達するために存在します。私がよく使う簡単な例は次のとおりです。アプリケーションのソーシャル ネットワーキングでの存在感を高めたいと考えています。PBI は、Twitter フィードの表示から、製品の好み、いくつかの Google+ 統合などにまで及ぶ場合があります。
目標は、私たちがこれらのものを構築している理由に指針となる光を与えますが、一部の PBI を完了できない場合に、ビジネスとチームがスプリントが成功したかどうかを判断する余地を与えてくれます。たとえば、Twitter フィードと Facebook Like の統合を完了しても、予期しない API の安定性の問題により、Google+ の統合を解決できない場合でも、アプリで実際に「ソーシャル ネットワーキングの存在感を高めた」ため、ビジネスはスプリントで成功する可能性があります。
これは、私たちにアウトを与えてくれるので、チーム メンバーとして簡単かつ自然に捉えることができます。プレッシャーのかかる環境では、習慣によって常に必死になっているもの。本当に重要な角度は、ビジネスの観点からのものであり、私はこれが本業のコーダーであることを忘れています。
Twitter フィードが完成したら出荷し、Facebook 統合が完成したら出荷しても、Google+ 統合に失敗した場合、ビジネスは目標を達成できなかったと感じている可能性があります。これは不自然な例ですが、懸賞、オンライン ゲーム、テキスト メッセージの宝くじなどを使用したマルチチャネル マーケティング キャンペーンのような非常に重要なものと考えてください。オリンピックか何かを中心に展開します。ビジネスはこのように機能します。
継続的なフロー モデルは素晴らしいかもしれません。なぜなら、彼らは慣れていないときに物事が起こっているのを見るからです。