アジャイルはRADのバリアントですか?


16

ウィキペディアによると、アジャイルは「RAD」の一種であり、これは間違っていると思います。私が知っていることから、アジャイルはRAD自体が90年代に成功しなかったために開発されました(変更にはあまりにも厳格です)。それとも私は間違っていますか?

(備考:どうやらアジャイルソフトウェア開発に関するWikipediaの記事は、間に改善されたが、それだけで一覧表示されますRADをないスーパーセットとして、アジャイルの前身として)。

本Radical Project Management(Thomsett)からの参照

「..RAD、アジャイル、オブジェクト指向などの新しい開発の流行...」

CISA認定情報システム監査員:

..2 つの代替ソフトウェア開発を認識しています。メソッド:アジャイルで迅速なアプリケーション開発

ソフトウェアのアジャイル管理:

アジャイルメソッドは、主にRADの軽量アプローチから派生しています。

ソフトウェア推定のベストプラクティス:

swの主な方法。開発者 次のように要約できます
。1.ウォーターフォール..
4. RAD
5.アジャイル

この質問のポイントは次のとおり
です。アジャイル型はRADですか、それともスタンドアロン開発アプローチですか?


1
RAD =迅速なアプリケーション開発。アジャイルは確かにそのカテゴリーに分類されます。
オデッド

2
@Oded:どうして多くのソースがそう言っていないのですか?主に急速に高速配信に目的としていたので、なぜ..「アジャイル」という言葉で表現される適応性のアジャイル、
ジョン・V

1
確かに、アジャイルは適応性に関するものですが、同時に、優先度の高いアイテムを迅速に提供することも重要です
Oded

1
「ウィキペディアは言う」 -に記事、看板がある「要出典」「アジャイル手法は非常に迅速なアプリケーション開発と共通している」という声明近く-この文の意味ウィキペディア標準にアップしていない
ブヨ

1
「スタンドアロン開発アプローチ」とはどういう意味ですか?
トーマスオーエンズ

回答:


15

用語としてのRADは、用語としてのアジャイルよりも約10年前ですが、実際にはアジャイルの「親」ではありません。どちらも、従来のソフトウェア開発管理手法で認識されている欠点に対する反応として作成されました。ただし、RADはソフトウェアを記述するための規範的な方法であり、連続したプロトタイプを使用して要件を引き出し、アプリケーションを改良します。アジャイルは、最初に導入された形で、伝統的なアプローチとアジャイル実践者が重視する価値との違いを説明する哲学的立場です。

そのため、アジャイルソフトウェア開発はRADの一種ではありません。抽象化のさまざまなレベルで問題に対処します。


それがまさに私が思うに、Wikiを更新すべきだと思います。
ジョンV

2
編集可能ですので、そうすることができます

11

開発方法論を階層構造に分類するのは正しいとは思いません。したがって、他の「下」または「上」にある方法論はありません。方法論の共通点について考える方がはるかに論理的です。多くの場合、現実世界での方法論の適用には、多くの同様の方法論の組み合わせが含まれ、実際の開発モデルを考案するのは管理者次第です。

RAD(私は経験がありません)対アジャイルの場合、反復的な開発が唯一の共通点のようです。RADは、特定の目標と成果を備えた厳格なフェーズを好むようです。アジャイルは、すべてが起こる単一の開発フェーズに関するものです。また、アジャイルは、事前にプロトタイプを作成する代わりに、機能が削除される可能性があるソフトウェアを直接開発します。(これはアジャイルと同じになる可能性があります。これは、プロトタイプが正しく機能するのではなく、すぐに動作するソフトウェアに統合されることが非常に多いためです)


1
そのため、アジャイルは製品の言語とは異なる言語でプロトタイプを作成することを提案しました。通常、プロトタイプは正しく実行されません。たとえば、プロトタイプのmatlabと製品のc ++
B –овић

-1

アジャイル方法論は、利害関係者への迅速な反復デモンストレーションで反復モデルのアプリケーションを構築することを指向しているため、より剃刀モードです。開発者は設計パラダイム(特にモジュール性)を維持することを免除しませんが、直接強調することはありませんが、反復の継続的な配信とビジネス要件の急速な変化に対する迅速な対応に集中します。孤立した製品の開発に事実上向けられており、製品のフレーム内で動作しますが、ソリューションのコンポーネントを明確に再利用する必要はなく、さらに、企業レベルで製品ファミリの共通プラットフォームを構築する必要もありません。誰も同じ作業をN回繰り返すことを推奨しません。幸いなことに、RADは開発をドメイン、モジュール、およびそれらの統合によって分離し、技術的な観点から、開発モデルの技術的組織により適切であり、企業の技術的管理の観点からは合理的です。これにより、モデルの柔軟性とソリューションの再利用性が高まり、他の製品に適応できるようになります。最後に、企業はフリーランサーのコミュニティではなく、1つの製品の寿命よりも寿命が長くなっています。ただし、企業が移行や変更を行わずに単一の製品を生産する場合、RADの役割はそれほど表現力がありません。しかし、通常、アジャイルのビジネス上の強みは、RADの技術的な組織上の強みと見事に組み合わされています。最後に、企業はフリーランサーのコミュニティではなく、1つの製品の寿命よりも寿命が長くなっています。ただし、企業が移行や変更を行わずに単一の製品を生産する場合、RADの役割はそれほど表現力がありません。しかし、通常、アジャイルのビジネス上の強みは、RADの技術的な組織上の強みと見事に組み合わされています。最後に、企業はフリーランサーのコミュニティではなく、1つの製品の寿命よりも寿命が長くなっています。ただし、企業が移行や変更を行わずに単一の製品を生産する場合、RADの役割はそれほど表現力がありません。しかし、通常、アジャイルのビジネス上の強みは、RADの技術的な組織上の強みと見事に組み合わされています。


4
この投稿は読みにくい(テキストの壁)。それをより良い形に編集してもいいですか?
ブヨ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.