アジャイルの前に最も使用されたSDLCは何でしたか？
アジャイルを作成する前は、ソフトウェア開発で最も使用されていたモデルは何でしたか？
これらのモデルの実装に使用されるさまざまなITSソフトウェア（Jiraなど）に関する論文を書いており、アジャイルとその派生物の前に、最も使用されるモデルに関する段落を付けたいと思います。
あなたの質問を理解していれば、アジャイルが出現する前のSDLCに興味があります。つまり、 アジャイルマニフェスト 2001だけでなく、マニフェスト（XP、Crystalなど）。
SDLC時間移動
アジャイルが登場する前、90年代後半に最も人気のあったSDLCはおそらく nified Process であり、その最初のバリアントは Rational Unified Process（RUP） でした。 UML。それはすでに反復的で段階的でした。
RuPの前には、Boochメソッドと [〜＃〜] oose [〜＃〜] が90年代前半にあったことに注意してください。しかし、これらはまったく新しいものであり、業界のリーダーによってまだ推進されていません。
以前は、90年代の初めに VeeモデルまたはVモデル とそのバリエーションがありました。これらのSDLCは非常に人気があり、世界中の政府機関で採用されました。なぜなら、コンポーネント（ソフトウェア、ハードウェアや組織的な手段）で構成される非常に大規模で複雑なシステムの構築を可能にすることを意図しており、品質保証とシステム統合。一部の機関では、現在Veeがまだ有効ですが、アジャイルプラクティスを使用してコンポーネントを開発できるバリアントが存在することに注意してください。
80年代後半のもう1つの一般的なSDLCは、いわゆる spiral model でした。アイデアは、ソフトウェアを改良するために開発の連続サイクルを持つことでした。しかし、私はこの見方はより学術的であり、滝の段階に続く各サイクルの開発プロセスであったと主張します。
80年代以前の最も一般的なSDLCは ウォーターフォールモデル であり、その目的は「分析、設計、実装、テスト」です（厳密な順序で）。
ちなみにSDLCとは？
SDLCは「ソフトウェア開発ライフサイクル」を意味することに注意してください。これは、開発プロジェクトとソフトウェアの後続の段階を構築するために使用されるアプローチを説明しています。
SDLCは、使用される実践や方法についてではありません。
- たとえば、ウォーターフォールとvモデルのSDLCの両方が、SDLCよりもプログラミング技術（データとコードの強力な分離による構造化プログラミング）に関連した、YourdonやGane＆Sarsonなどのモデリング手法と共に使用されました。
- ウォーターフォールであっても、コーディングを開始する前にプロトタイピングを使用して分析と設計を検証することを推奨する作者もいます。
- Rapid Application Development は、たとえば、ユーザーとの共同設計ワークショップやラピッドプロトタイピングなどの興味深い手法を使用して、短いフィードバックループを確保しました。しかし、これらのプラクティスはウォーターフォール（またはスパイラル）モデルに組み込まれました。
- いくつかの規格（医療機器で使用されるソフトウェアなど）がありますが、それでもVモデルが必要ですが、標準の専門家はこれをSDLC要件ではなくプロセス要件として読みます）。
アジャイルソフトウェア開発のマニフェストの前は、スクラム、DSDM、エクストリームプログラミング、リーンソフトウェア開発、アダプティブソフトウェア開発、Crystal方法論などを使用する人々がいました。これらの方法のいくつか（マニフェスト以前は、「軽量」または「適応」方法と呼んでいた）の主要人物は、さまざまな会議で、最終的にはマニフェストが書かれたスノーバードで会議を行っていました。アジャイルソフトウェア開発のマニフェストは、共通の根拠と共通の価値観および原則を抽象化または特定したものであり、これらの方法が、使用されたさまざまなソフトウェア集約型プロジェクトで成功していると人々が感じた理由を捉えています。
アジャイルソフトウェア開発のマニフェストの前には、従来のプロジェクト管理手法をソフトウェアに適用しようとする人々もいました。しかし、これらの手法は、ソフトウェア開発の大部分である予測可能で再現性のない作業に適用すると、通常はうまく機能しません。また、ソフトウェア開発の経済性を活用していません。これは適切ではありませんが、人々はこれらの手法を使用して、計画されたコストとスケジュールを超過している規律と制御プロジェクトを適用しようとしました。
要するに-あまり変わっていません。ただし、「アジャイル」という名前を中心に、トレーニング、コンサルティング、書籍、会議などの名前と業界全体が築かれています。これはマニフェストのおかげで新しいことです。ソフトウェア開発の方法を改善するための、まとまりのない一連の作業を中心に、名前を付けて概念を構築しただけです。
Christophがすでに説明したように、SDLCはソフトウェア開発の方法論から独立していますが、これはまだアジャイルプラクティスがもたらすものではありません。アジャイルは主にプロセス指向です。議論のために、開発プロセスを見てみましょう。
最もポピュラーな方法は、今のところ私の考えでは、どれもありません。
私が採用した方法論を使用したほとんどの場所で、後付けとなっています。そしてしばしば彼らはふりをして、彼らのやり方を変えることを必要としないいくつかの側面を選び、次に進んだ。人々はコースに送られました、いくらか中途半端な誓約がなされました、そして、すべてが正常に戻りました。
これは過去10年ほどである程度変化したようで、今日のスクラムはかなり普及しています。または、少なくともそれは誰もがあなたに信じてほしいことですが、それでも多くは窓のドレッシングです。アジャイルであることはヒップであり、アジャイルプラクティスを適用していると主張する前に、多くを変更する必要はありません。ほとんどの場合、それはそれだけです。アジャイルの原則を完全には採用しなかった、特定の環境でのアジャイルの実践。
ほとんどのソフトウェアビジネスは、ビジネスマンとコーダー（場合によっては1人）から始まり、問題が発生したときに問題を解決しました。コーダーはちょうどビジネスが要求したものを作りました。そして、多くの場合、この「方法」も打ち負かすのが難しいです。