SDLCのアジャイル対スパイラルモデル
アジャイルはスパイラルモデルの別の実装に他ならないと私は思います。私はスパイラル（スパイラルモデルは、トップダウンコンセプトとボトムアップコンセプトの利点を組み合わせるために、設計段階とプロトタイピング段階の両方の要素を組み合わせたソフトウェア開発プロセスです）を最初から支持してきました。その多くのプロジェクトは、スパイラルの世界で動作していることを知らずにスパイラルを実装しています。アジャイルが人気を博し始めたその日から、スパイラルの概念は少し見落とされ始めました。複雑なプロジェクトではスパイラルが最良の選択肢であると確信していますが、アジャイルとスパイラルのテクニックの類似点と相違点をよりよく理解したいと思います。誰かがそれらの違い/類似性を説明できますか？
アジャイルはスパイラルです。完全に。一部、名前はマーケティング目的で変更されました。
問題は、スパイラルが「前もって大きな設計」を意味する傾向があることです。この場合、リスク順に、多くのスパイラルを計画します。ただし、スパイラルはアジャイルではありません。これは、リスクの順に実行されるだけです。
アジャイルが追加する1つの大きな違いは、「まだ知ることができないものを計画しすぎないこと」です。アジャイルはスパイラルですが、一度に1つずつ増分する詳細な計画を作成します。
アジャイルは他にも多くのことを追加します。スパイラルは非常に技術的なアプローチです。ただし、アジャイルは、テクノロジーは人間によって構築されていることを認識しています。 Agile Manifesto には、ベームの単純なリスク管理アプローチを超えた4つの原則があります。
私が見ているように、基本的な違いは、開発のほとんどのスパイラルモデルは、依然として大きな事前設計を主張していることです。重要なのは、システムがどのように使用されるかについて、できるだけ多くを知ることです。すべてのユースケースを発見します。これらを理解したら、システムを設計し、反復的な詳細設計、実装、テスト、リファクタリング設計ループに続くフェーズに分解します。アジャイルでは、それらはいくつかの事前計画であり、おそらく大まかな理解（ストーリータイトル）を収集しているため、合理的なリリースを説明できますが、各リリースは個別に計画され、開始の準備ができるまで詳細の発見を遅らせますそのリリースの実装。私たちは変化を期待し、すべてを最初に知ることを試みません。
異なるもう1つの点は、ほとんどのアジャイル哲学には「テストファースト」の方法が含まれていることです。これは、テストがしばしばそれ自体に対するアクティビティであり、テストがコードの前に開発されないスパイラルとは異なります。ほとんどの場合、事前に計画されていますが、並行して、またはコーディング後に開発されます。多くのアジャイルメソッドは、コードの仕様として最初にテストを開発することを要求します。
それらは反復的であるという点で似ています。これらは、実装と、反復とは何かについての理解が異なります。
私はスパイラルモデルの専門家ではありませんが、ウィキペディアの定義から、いくつかの重要な違いがあるように思えます。
たとえば、アジャイルプロジェクトでは、反復の最後はプロトタイプに耐えられませんが、機能リストで最も優先度の高い機能を含む、完全に機能し、完全にテストされ、潜在的に展開可能な（1）システムです。
プロジェクトの開始時に収集される要件は、（次のステップを実行するために）開始するのに十分なだけのものであり、実際に実装される直前に具体化されることを意味します。要件の変更は歓迎されます。
また、アジャイルには、反復的な開発を行うだけでなく、書面によるコミュニケーションではなく、対面での会話に重点を置き、日常業務でビジネスの人々と技術者を結びつけることに重点を置いています。契約を定義して履行するのではなく、共同で価値を最大化することに重点を置きます。
まだご覧になっていない場合は、基本的にアジャイルソフトウェア開発の定義である Agile Manifesto をご覧ください。
（1）それは、システムを配置するためにビジネス上意味がある必要があるという意味ではありません。反復の最後にシステムを展開するかどうかは、純粋なビジネス上の決定でなければなりません。
アジャイルは反復型SDLCの一種であり、スパイラルはインクリメンタルSDLCの一種であると思います。スクラムはアジャイルの一種で、他はDSDM/FDD/XPなどです。ウォーターフォール後のすべてのSDLCは、いくつかの異なる組み合わせで同じ一連の動作（要件分析、設計、コーディング、およびテスト）を実行しました。したがって、順次の基本的な一連のアクションOR反復OR増分は同じです。
アジャイルとスパイラルに関する限り、両方に共通の利点があります。1。要件処理の変更2.短期リリース3.SDLCの期間が短いため、リスク管理が容易です4.クロスチームが製品とプロジェクトの円滑化を支援します
最初のアジャイルは、実際には同様の哲学に従う多くの異なるプロセスです。それを変える哲学の1つは、各反復が実用的な製品を生み出すということです。これは、反復的かつ増分的であると説明できます。機能する製品とテストに多くの重点が置かれています。多くのアジャイルモデルでは、テストはコーディングの前に行われます。
スパイラルモデルでは反復の数は固定されていますが、アジャイルモデルの各フェーズは任意の反復で構成できます。
類似点はあると思いますが、根本的な哲学が違いを生み出します。この ページ は、アジャイルをより詳細に説明し、他の方法と比較しています。
アジャイルプロセスはユースケース主導であると言えます...エンドユーザーである人々に多くの重点を置いています。
スパイラルとアジャイルは似ています。しかし、最近、アジャイルはしばしばカウボーイコーディングを許す宣伝システムになっているようです。つまり.
- 最小限の要件
- 最小限のテクニカル分析
- 最小限のドキュメント
- コードコメントなし
- 特別なボーナス-オブジェクトモデルを過度に複雑にするドメイン駆動設計の誤用
これはスパイラルのアイデアではありませんでした。私がこれを最近何度も目にしたのには驚かれることでしょうが、それもアジャイルの本質ではない、と私は主張します。 より多くの経験豊富な開発者/ PMは、ウォーターフォールと「アジャイル」の間のよりバランスの取れたアプローチの知恵を理解し始めています-おそらくこれは単にスパイラルに戻るだけです。
アジャイルのマインドスペースにはいくつかの便利なアイデアがありますが、それはしばしば、特に負担が大きく/役に立たないソフトウェア設計方法論を持っていて、それに対する反応/過剰反応である組織にいた人々から明らかになったように見えます。