9

私は、最初にプロジェクト管理のウォーターフォール方式を採用し、それに伴い、ソフトウェア設計への予測的アプローチを採用したことを知っています。これは、ドキュメント、UML、データベース スキーマ、データ ディクショナリ、ワークフロー、アクティビティ図などの膨大なパケットがあったことを意味します。

ソフトウェアに 10 年以上携わってきた今、リアクティブなアプローチからソフトウェア設計にアプローチする方がはるかに現実的であることがわかりました。私は頻繁にプロジェクト管理にスクラム アプローチを採用していますが、そのため、重いドキュメントはほとんど生成されません。ワークフローの仕様はほとんどありません (ただし、まだ使用されています)。これは、ソフトウェア作成に対するより動的なアプローチです。もちろん、時間の経過とともに頻繁にリファクタリングが行われます。時間の経過とともに、事前に計画していれば状況が劇的に変化していたであろう新機能が見つかるからです。

私たちにとっての大きな違いは、最初のアプローチは時間がかかり、ソフトウェア構築の世界ではより頻繁に失敗するように思われ、柔軟性に欠けることです。2 番目のアプローチは柔軟性を高め、失敗をより早く認識できるようにし (コースをより速く修正できるようにします)、すべての反復の最後に何らかの形の機能を提供します。

経験から両方の側面を知っているので、ソフトウェア開発のアジャイル アプローチよりもウォーターフォール アプローチを好む人が今でも多くいます。理解できません。

質問:アジャイルを裏付けるすべての研究がある何らかの形式のアジャイルではなく、なぜウォーターフォールを使用するのでしょうか? アジャイルではなくウォーターフォールを使用することの有力な議論は何ですか?

4

15 に答える 15

6

人々がまだ滝にしがみついている理由の一部は、それがコントロールの錯覚を与えるからだと思います。滝では、考えられるすべての不測の事態にうまく対処する美しいスケジュールをまとめるのに十分な事前作業を行うことができます。次に、機能Xがいつになるかを尋ねるビジネス側の誰にでも、将来の詳細なロードマップを提供できます。利用可能。

問題は、その計画を手紙に従わせることはほとんど不可能であり、ほとんどの場合、機能を遅らせたり落としたりすることです。ただし、最初から見ると、非常に制御され、管理しやすいように見えます。

私はアジャイルの大ファンですが、私がいつも苦労しているのは、営業やマーケティングの人々からよく求められる長期的なロードマップ/予測です。滝の確実性の幻想は、管理者やビジネス関係者にとって非常に慰めになると思います。

于 2009-07-29T21:45:24.497 に答える
6

私がプログラミングを始めたとき (COBOL も同様)、ウォーターフォールは「新しい」アプローチでした。今日は、私がウォーターフォール型のアジャイル方法論を使用していることをお伝えしたいと思います。大規模なシステムでは、ウォーターフォール型の開始が最適です。巨大なドキュメントを作成するのではなく (IMO では時間の無駄です)、UI プロトタイプやユースケースを作成して、目の前のビジネス上の問題を理解するなどの手順を実行します。問題の範囲が明確になり、しっかりと理解できたら、アジャイル開発モードに移行します。

あなたの質問に答えると、ウォーターフォールが定着している大きな理由は、多くの人が変化を好まないからだと思います。変化は恐ろしく、ウォーターフォールからアジャイルへの移行は大きな変化です。

于 2009-07-29T21:10:32.460 に答える
4

私の上司は私に言う。

多くの人は選択の余地がなく、古いボスは新しいトリックを学ばないのではないかと思います。

于 2009-07-29T21:03:32.553 に答える
3

（少なくとも）XPの前提の1つは、変更が安価であるということです。ウォーターフォールモデルは、変更する場合はコストがかかるという原則に基づいて構築されました。ウォーターフォールモデルの前提は、ソフトウェアが作成されたら、問題を「完全に」理解するために時間を費やすよりも、ソフトウェアを変更する方がコストがかかるということです。

経験から、問題を完全に理解することは非常に困難であり、いくつかの予防策（単体テストなど）を実行すると、変更がはるかに安くなる可能性があることが示されているようです。したがって、アジャイルの前提の一部が当てはまらないという問題が発生した場合、他のアプローチが再び実行可能になる可能性があります。ウォーターフォールとアジャイルの間には、少なくともスパイラル開発があります。これは、私たちが実践していることです。

于 2009-07-29T22:26:11.170 に答える
3

どちらか一方を支持するわけではありませんが、ほとんどの研究はせいぜい非科学的です。

あなたは言う（強調は私のものです）

質問: アジャイルを裏付けるすべての研究がある何らかの形式のアジャイルではなく、なぜウォーターフォールを使用するのでしょうか? アジャイルではなくウォーターフォールを使用することの有力な議論は何ですか?

ただし、どの研究にもリンクしないでください。

これは、実際にテストするのが非常に難しいことが知られているものの 1 つです。2 つの同一のチームが同じプロジェクトで同時に作業することはできません。2 つの同一のチームなどというものは存在しないからです。最初のパスが 2 番目のパスを汚染することなく、2 つの異なる方法論を使用して、同じチームが同じタスクを 2 回続けて完了することはできません。ソフトウェア開発の方法論について説得力のある議論を行うことができる実験的 (または統計的) 研究を設計している人は聞いたことがありません。もしリンクがあれば、私はそれを見たいと思います。

本当の証拠がなければ、それは個人的な好みに要約されます。バニラよりもチョコレートを支持する有力な論拠は何ですか?

于 2009-07-29T21:59:43.900 に答える
3

私は悪魔の擁護者を演じて、アジャイルには欠陥があると述べますが、ウォーターフォール方式とほぼ同じくらい多くの点があります。私はウォーターフォール方式が好きというわけではありませんが、アジャイルも好きではありません。

アジャイルに関する私の経験は、あまりポジティブなものではありませんでした。公平を期すために、私はそれを企業環境で使用しました。これは、マネージャーが長期的なマイルストーンと成果物を前もって作成することを期待しながらも、「アジャイル」にリップ サービスを支払ったものです。

しかし、アジャイル (特にスクラム) の方法論は、多くの場合、設計に関する主要な問題を隠していることがわかりました。ウォーターフォールはマネージャーにコントロールの錯覚を与えますが、アジャイルは開発チームに同じことをするようです。私は、現在のスプリント/イテレーションにない問題を持ち出すことは、「時間内に」処理されることを期待して、眉をひそめているチームを見てきました。現在のイテレーションはスムーズに進み、プロジェクトは順調に進んでいるように見えますが、プロジェクトが将来失敗するためには、いくつかの主要な設計上の決定を無視する必要があるだけです。

アジャイルの精神を理解していないのはチームの責任だと主張することもできますが、私はアジャイルの最良の部分を取り入れたより良い方法論を見たいと思っています。

于 2009-07-29T22:04:26.620 に答える
2

商品を配達するのに十分な事前準備が必要です。問題に対処するには、十分に反応する必要があります。

私はかつて、1 年かかると見積もられたプロジェクトを完了するのに 6 か月かかったこともあり、過去の経験に基づくと 2 年かかることもありました。それで私は方法論を研究するのに3ヶ月を費やしました。ウォーターフォール プロセスの適切な部分を使用して、予定どおりに (3 か月で) 完了しました。

方法論を機能させるいくつかのポイント: - 使用基準を作成し、必要に応じて更新します。- ライブラリの構築: 一度実行して、うまく実行し、既存のコードを壊さずに修正します。- 十分な文書化を行います。- できる限りのバージョン管理。- 物事を分解します。メソッドは、作業を管理するか、作業を行う必要があります。- 凝集力を高め、カップリングを減らし、再利用します。- 必要なツールを購入または作成します。- 問題と進捗状況を追跡します。

私が簡単に関わった別のプロジェクトは、6 か月のプロジェクトでした。始めてから1年半くらいしか関わりませんでした。開発責任者は、年金制度でキャリアを離れようとしていたため、極端なマークアップで雇われていました。プロジェクトの開始時に、彼はプロジェクト マネージャーに、「正しく実行してほしいですか、それとも受け身であってほしいですか?」と尋ねました。あなたは答えを推測できますか？私が関わった週は、月曜日、水曜日、金曜日に同じ機能が実装されていました。火曜日と木曜日に何が起こったと思いますか？

アジャイルの強みは、ジャ​​スト イン タイムに十分に重点を置いていることです。ウォーターフォールの方法論の強みは、考える必要があるすべてのことを網羅していることです。私はまだ、すべてのステップを実行した、または実行すべきだったプロジェクトに取り組んでいません。私は、企業ベースで行うべきステップを実行する多くのプロジェクトに取り組んできました。

于 2009-07-29T23:00:40.103 に答える
1

タイトルがすべてを物語っています。(実際には: プロアクティブとリアクティブ)。必要がない限り、なぜ受動的な方法を選択し、制御を放棄するのでしょうか? ウォーターフォールだけが唯一の選択肢ではありません。好きなときに改良したあらゆる種類の開発プロセスを持つことができます。コントロールが鍵です。

それはスペクトルであり、一方の端にはウォーターフォールがあり、もう一方の端には完全に反応的でゼロのドキュメント方法があります。強力な (そして通常優柔不断な) クライアントのためにコンサルタント業界で働いている場合は、事後対応型の方法に頼る必要があります。シュリンクラップ ソフトウェアを開発すると、事前に計画を立てて知識を管理できます。一部のプロジェクトでは、大量の仕様と規則が必要であり、コードと修正のアプローチでは対応しきれません。私にとって、ソフトウェア エンジニアリングは主にナレッジ マネジメントと設計に関するものであり、コーディングは 2 番目に重要です。

Ps アジャイルや固定価格などというものはありません。古典的な方法ではなく、彼らは通常その方法を販売しています。http://martinfowler.com/bliki/FixedPrice.htmlを参照してください。

于 2009-07-29T22:07:40.450 に答える
0

10年以上の間に数十人のチームがいる場合は、ウォーターフォール戦略を洗練して、彼らがうまく機能するようにします。 .. "？本当に、それが彼らのために働いているのなら、なぜ物事を変えるのですか？はい、これは単に質問をひっくり返すだけですが、それは有効なポイントかもしれないと思います。

于 2009-07-29T22:23:47.307 に答える
0

私のチームでは、メンテナンスプロジェクト（これは私たちが行うことの大部分です）では、おそらくいくつかのUIプロトタイプを超えて、ユーザー入力の必要性が必ずしもそれほど多くないように調整または置換していることがわかりました。

その場合、特にマクロレベルでのウォーターフォールアプローチが関係する商取引があることを考えると、うまく適合する可能性があります。それでも、実装レベルでのインクリメンタル/アジャイルアプローチが好きです。

私たちのクライアントのほとんどが彼らの事務処理を愛する大規模な製材組織であることに注意する価値があります。

于 2009-07-29T22:28:08.590 に答える
0

遡及的行動

于 2009-07-29T22:18:34.260 に答える
0

ウォーターフォールプロセス中に生成されたドキュメントは、多くのCYAを考慮に入れています。プロジェクトが軌道に乗らないときに指を指すことができます。「まあ、プロジェクトは私たちから遠ざかっていたと思います！少なくとも私たちは早期に発見しました。害はなく、ファウルもありません！」と大丈夫になる幹部はほとんどいません。

また、設計ドキュメントはテスト計画を自動的に生成できます。これはQAに役立ちます。

于 2009-07-29T22:29:59.023 に答える
0

エンドユーザーが使用するシステムを設計する場合、要件が正しくない可能性が高く、プロセスの大部分が使用可能なバージョンの形でユーザーからフィードバックを得ているため、アジャイルがうまく機能することがよくあります。

ただし、他のソフトウェアと連携するソフトウェアを作成する場合、多くの場合、要件は非常に明確に解決できます。この場合、非常に明確で正確な仕様、単体テストを確実に作成する方が生産的であることがよくあります。このモデルでは、かなり適切な作業見積もりも生成できますが、アジャイル モデルを使用するとコストが大幅に高くなります。

于 2009-07-29T21:34:35.007 に答える
0

契約を入札するとき、鉄壁の条件の 1 つは、検査ではウォーターフォールである「プロセス」に従うことであることがよくあります。

于 2009-07-29T23:47:03.893 に答える