WaterfallとAgileの主要な代替手段はありますか？[閉まっている]

回答:

47

ウィキペディアはこれらを方法論/開発プロセスとしてリストしています：

  • アジャイル -反復的かつ漸進的な開発に基づいており、自己組織化された機能横断型チーム間のコラボレーションを通じて要件とソリューションが進化します。

  • クリーンルーム -クリーンルームプロセスの焦点は、欠陥の除去ではなく、欠陥の防止です。

  • 反復 -ウォーターフォールモデルの弱点に対応して開発された周期的なソフトウェア開発プロセス。最初の計画から始まり、周期的な相互作用を伴う展開で終わります。
    反復図

  • RAD-ラピッドプロトタイピングを支持して最小限の計画を使用 RADを使用して開発されたソフトウェアの「計画」は、ソフトウェア自体の作成と交互に行われます。

  • RUP -Rational Unified Process（RUP）は、適切なプロセスの要素を選択して調整することを目的とした、適応可能な反復ソフトウェア開発プロセスフレームワークです。

  • スパイラル -トップダウン概念とボトムアップ概念の利点を組み合わせようとして、設計と段階的なプロトタイピングの両方の要素を組み合わせます。この開発モデルは、プロトタイピングモデルとウォーターフォールモデルの機能を組み合わせたものです。
    らせんモデル図

  • ウォーターフォール -構想、開始、分析、設計、建設、テスト、メンテナンスの各段階を順番に実行します。
    滝図

  • リーン -リーン製造とリーンITの原則と実践のソフトウェア開発ドメインへの翻訳。顧客に価値をもたらさないものはすべて無駄と見なされます。

  • Vモデル -直線的に下に移動するのではなく、プロセス段階はコーディングフェーズの後に上向きに曲げられ、典型的なV形状を形成します。Vモデルは、開発ライフサイクルの各フェーズとそれに関連するテストフェーズとの関係を示します。
    vモデル図

  • TDD-非常に短い開発サイクルの繰り返しに依存しています：最初に、開発者は、目的の改善または新しい機能を定義する失敗した自動テストケースを記述し、次にそのテストに合格するコードを生成し、最終的に新しいコードを許容可能な標準にリファクタリングします。

— ピーター・ボートン
ソース
明確で簡潔な回答をありがとうございます。私はとても古い学校です、私はP.SEで放り出される用語の多くを聞いたことがありません。
— マイケルライリー-別名ガニー
7
TDDを除く素晴らしいリスト。それはライフサイクルではなく、開発プラクティスです。
— マイケル
18

カウボーイコーディング

純粋な非構造化、管理されていない、フリーフォーム開発。期限や明確な目標さえない小さな趣味のプロジェクトに役立ちますが、企業環境ではうまくいかないでしょう。

— ブルース・オルダーマン
ソース
2
わーい！バンバン！
— mlvljr
3
「企業環境では機能しない可能性が高い」。あなたが言います！;）
— ボビーテーブル
+1 Aaa、クール！私は時々それをしますが、私はこの「プロセス」に名前を付ける方法を知りませんでした：）
— Zzz
イェーイ・パドナ！
— イバコス
正式な成熟した企業の設定では本当です。しかし、中小企業では、「やるだけでやる」という考え方がかなりあります。
— JBキング
4

スパイラルモデル

スパイラルモデルは、トップダウン概念とボトムアップ概念の利点を結合するために、設計と段階的なプロトタイピングの両方の要素を結合するソフトウェア開発プロセスです。スパイラルライフサイクルモデル（またはスパイラル開発）とも呼ばれ、情報技術（IT）で使用されるシステム開発方法（SDM）です。この開発モデルは、プロトタイピングモデルとウォーターフォールモデルの機能を組み合わせたものです。スパイラルモデルは、大規模で高価で複雑なプロジェクトを対象としています。

- ウィキペディア 代替テキスト

— ライアン・ヘイズ
ソース
1

計画

クライアント（またはエンドユーザー）に座って、一連のユースケースを設計します。

設計

いくつかのビールとピザの上に紙/ホワイトボードでシステムをレイアウトします。何かが男根に見えるときはスニッカー。

確認する

クライアント（またはエンドユーザー）で設計を確認し、要件を凍結します。

コード

自明。

— ジョシュ・K
ソース
「フリーズ要件」は、これまでにないほど簡単なことです。
— ジャスティン・シアー
1

このウォーターフォールの議論はしばらく前から存在しており、アジャイルの思想的指導者によって早期に使用されました。彼らも、「赤い警告」としての滝の「現実」に遭遇しました。

ソフトウェア開発プロジェクトで作業を開始すると、使用されている開発方法論が、開発されたコードの速度と品質に大きな役割を果たすことがすぐにわかります。アジャイルの短所は、プロジェクトの成果物に最適かどうかを判断できるようにします。

アジャイルソフトウェア開発は、ソフトウェアエンジニアリングプロジェクトを実施するための概念的なフレームワークです。ほとんどのアジャイル手法は、通常1〜4週間続く反復と呼ばれる短いタイムボックスでソフトウェアを開発することにより、リスクを最小限に抑えようとします。各反復は、それ自体のミニチュアソフトウェアプロジェクトのようなもので、計画、要件分析、設計、コーディング、テスト、およびドキュメントなどの新機能のミニインクリメントをリリースするために必要なすべてのタスクが含まれます。

開発プロセスに顧客を含め、製品の配信を担当するため、会社にとっては良いプロセスです。反対側では、顧客は製品の開発に自ら参加していることに気付くので満足しています。

アジャイルのデメリット：

  • アジャイルはプログラマ中心であり、組織全体で作業のバランスを取る方法が不明確です。
  • どこに行くのかわからない場合、アジャイルはあなたをそこに連れて行きません！
  • 明確なニーズのないフレームワークの作成。
  • 言語機能の過剰使用（不適切）。
  • テストファーストの考え方はありません。

AGILEの代替として機能する可能性のある興味深い方法論については、次の3つのリンクで最適に表示されます。

代替アジャイル実装としてのかんばん

かんばんソフトウェア開発

クラウドでのリーンソフトウェア開発

— トニー
ソース
3
どこに行くのかわからない場合、滝はそこにあなたを取得しません！
— エリックウィルソン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.