スクラムがウォーターフォール プロセスよりも優れている点を 1 つ挙げるとしたら、それは何ですか?
4962 次
24 に答える
19
要件を収集したときに顧客が望んでいたものとは対照的に、顧客が望んでいるものを構築します。
編集：これはアジャイルメソッドの一般的な特性であり、早期に頻繁に配信することに重点が置かれています。ウォーターフォールの正反対です（配信が遅くなり、1回だけです）。
于 2009-01-08T01:23:35.810 に答える
5
それはあなたに使用可能なビジネス機能を早期にそして頻繁に提供するプロセスをあなたに与えます、そしてそれは顧客があなたの結果に満足する可能性を高めます。また、比較的低コストでこれを実行し、障害のリスクを軽減します。
于 2009-01-08T01:24:51.313 に答える
5
Waterfallは、すべてを事前に知っていることを前提としていますが、それは不可能です。
優れたスクラムプロセスは、ウォーターフォールと同じように開始され、構築したいすべてのものがリストされます。ただし、スクラムの利点は、反復のたびにそのリストを再ランク付けすることです。これにより、常に顧客が望むものを正確に構築できます。
いずれかの製品のベータ版を作成しているときに、ベータ版のお客様が次のサイクルのスタックランクを上げるのを支援できるようにしました。最終結果は、私たちが顧客に指示したものではなく、顧客が望んでいた製品でした。
于 2009-01-08T02:33:22.470 に答える
3
プロジェクトが軌道に乗る前に、自分が正しい軌道に乗っているかどうかを確認できるように、使用可能なソフトウェアを迅速に提供すること。
もちろん、これはスクラムだけでなく、ウォーターフォールではなく、あらゆるアジャイルプロセスに適用されます。
于 2009-01-08T01:25:55.773 に答える
1
ウォーターフォールフレームワーク内でスクラムの大部分を使用するソフトウェア開発の実装がいくつかある可能性があるため、質問の一部が誤った情報に基づいている可能性があります。
スクラムで私が目にする主な利点は、チームの全員が他の全員が何をしているかを知ることができ、自分がどこにいるかを共有できるように、毎日のコミュニケーションと説明責任です。これにより、何が起こっているかを確認するための可視性と、何をしているのかを説明する責任が、スクラムをソフトウェア開発の非常に優れた部分にすることができます。ある程度。
于 2009-01-08T01:24:25.697 に答える
1
幸せな開発者
于 2009-01-08T01:25:51.157 に答える
1
私がスクラムが好きな一番の理由は、バーンダウンのコンセプトです。あなたがどれだけの時間を費やしたかは誰も気にしません。彼らが知る必要があるのは、あなたがどれだけの時間を残したかだけです。
于 2009-01-08T01:29:24.423 に答える
1
数人だけでなく、チーム全体が計画プロセスに関与していることは、大きな動機付けであることがわかりました（以前の場合）。通常、これは私の経験では、より正確な見積もりにもなります。これは、プロジェクトを正しい方向に進めるために不可欠です。
また、プロジェクトリーダーに個別に割り当てを与えるのではなく、チームで実際に何が起こっているのかをよく把握し、全員がある程度取り組んでいることを知っておくのは素晴らしいことです。
于 2009-01-08T01:30:43.517 に答える
1
まず、正しい質問は「アジャイル」と「ウォーターフォール」のようなものであることに同意する場合...
元開発マネージャーとして、これに対する私の主な見解は、実際には多少異なります。バーンドー、JIT 設計などのアジャイル手法の「エンジニアリング プラクティス」のメリットが大好きです。しかし、研究によると、プロセスの選択と成功率の相関関係は、多くの人が期待するほど少ないことが示されています (一例)。確かに、アジャイルはかなり一貫してやや優れていることが示されていますが、アジャイル プロジェクトに優れた開発者がいる傾向があるという事実を研究が調整するかどうかは明らかではありません。より良い開発者。
Cockburn の作品のいくつかを見ると、ソフトウェア プロジェクトの主な成功要因はプロセスではなく、 プロジェクトに携わる人々の質であることは明らかです。
これに関するいくつかの非常に優れた基本的な説明については、 Cockburn の本を
参照してください(これはハウツー本ではなく、基本的な概念とアジャイルを行うべき理由を説明するものです)。
私の意見では、アジャイル手法は優れたプログラマーが働きたい環境を作り出すのに役立ちます。彼らはプロセスの一部であり、頭脳を使用することが許可されて
いるためです。したがって、ビジネスとして、一流の人々を引き付けて保持する可能性が高くなります。つまり、プロジェクトを成功させる可能性が高くなります。
ビジネスレベルでは、それが正当な理由です。他のすべては非常にうまくいっていますが、これは収益にとって重要であり、チェーンを販売できる唯一のことです. 本当に優れた開発者は、平均的な開発者より何倍も生産性が高いことはよく知られていますが、何倍もコストがかかるわけではありません。したがって、本当に優れた開発者を惹きつけて維持できれば、同じ金額でより多くの成果を得ることができます。ああ、あなたはその過程でもっと楽しくなるでしょう。
より良い環境 => より良い開発者 => より成功したプロジェクト
注意の言葉; 明らかな輝かしい火花を持たない平均的な開発者のチームがたまたまある場合、私はアジャイルの実装について心配します。少なくとも、問題が解決するとは思わないでください。バーンダウンの利点はありますが、同じ種類の結果が得られる可能性があります (ベッドイン期間の後)。しかし、アジャイルは、自分が何をしているかを本当に理解し、常にスキルを更新している本当に優れた開発者、または少なくともそのような人々を含むチームに依存しています。アジャイルは、伝説的なプログラマーであり、非常に賢い人々によって発明されました。
于 2009-03-18T07:24:49.263 に答える
1
真の滝の日は過ぎ去ったと思います。スパイラルがウォーターフォールを乗っ取り、多くのチームが知らず知らずのうちにスパイラルで活動しています。以前のタグの 1 つで、アジャイルはスパイラルから進化したと述べました。
于 2009-01-08T15:07:23.540 に答える
0
死の行進はありません。
すべてのスプリントを提供できるものを定義します。
それを行わないと、後続のスプリントから機能（申し訳ありませんが）をプッシュすることですぐに反映されます。
于 2009-01-08T01:30:30.367 に答える
0
ユーザー（プロダクトオーナー）は、次に何が必要かを決定することに関与します。
したがって、ユーザーからすぐに賛同することができます。
そして、ストーリーが彼らが期待したものと一致しない場合の即時のフィードバック。
于 2009-01-08T01:31:51.517 に答える
0
SCRUM（およびアジャイルマニフェストに続くすべてのアジャイル手法）は、ソフトウェア開発者が人間であることを認めています。ウォーターフォールの実践者は、ソフトウェアが交換可能な人月ロボットによって開発されていると信じる可能性が高くなります。
于 2009-01-08T02:35:46.443 に答える
0
それは緊急の設計/緊急のアーキテクチャを容易にします。
于 2009-01-08T02:36:15.257 に答える
0
Waterfall は、一般的なエンジニアリング アプローチを使用してソフトウェア開発に取り組む最初の試みです。言い換えれば、それは誰にとっても恐ろしいことです。
SCRUMの主な利点は? 実際にはソフトウェア開発に使用する予定でした。
主に、新しい情報によるコードの「成長」は、誰かがあなたが持っている情報で十分だと言った後にのみ「組み立て」られません (決してそうではありません)。
于 2009-01-08T02:19:17.147 に答える
0
スケジュール、コスト、またはパフォーマンスに劇的な影響を与えることなく、方向を変更したりコース修正を処理したりする機能。
于 2009-01-08T03:11:56.667 に答える
0
目にする最大の利点の 1 つは、反復サイクルがあることです。顧客は考えや予算などを変更しようとしています。「それは私が求めていたものではないので、お金を払っていません」という反応を得るのではなく、柔軟であることが役に立ちます。
于 2009-01-08T03:27:49.100 に答える
0
私がアジャイルを気に入っている理由の 1 つは、失敗をより早く、より早く、より安価に行えるようにすることです(つまり、プロジェクトが破綻しようとしている場合に、それをより早く発見できるということです)。
于 2009-09-13T20:30:15.680 に答える
0
この混乱がよく見られるので、具体的に説明しましょう。
- スクラムはプロジェクト管理手法であり、
- 「ウォーターフォール」はソフトウェア開発の方法論です
2つは同等ではありません。
スクラムはアジャイル開発プロセスのプロジェクト管理の一部として実践されることが多いため、混乱が生じますが、スクラムとアジャイルは同じものではありません
技術的に正確であるために、あなたの質問は悪い仮定をしています! おそらく、あなたはそれを言い換えたいですか？
于 2009-01-08T02:01:20.693 に答える
0
ウォーターフォール方式よりもアジャイル方式の方が優れていることは明らかです。私にとって、アジャイルとウォーターフォールのアプローチは、ソフトウェア開発の 2 つの異なる方法論です。アジャイル手法では、モジュール全体が小さなサブモジュールに分割され、ウォーターフォール モデルの場合のように大きなモジュール全体ではなく、迅速かつモジュール化された方法で開発が行われます。アジャイル手法では、ウォーターフォールでは困難な設計変更や要件変更にも容易に対応できます。ウォーターフォール モデルとは異なり、アジャイルでは市場投入までの時間も非常に短いです。アジャイル手法により、テスト サイクルが短縮されます。
于 2011-08-02T06:14:28.207 に答える
0
ウォーターフォール上のスクラムの最大の例は? プロジェクトのステータス/進捗状況、またはその欠如に対するほぼ毎日の可視性。ほとんどのウォーターフォール プロジェクトは、チェックポイント/フェーズ ゲートに非常に近づくまで順調に進んでいると明言されていますが、その後、不明な量だけ遅れていることが判明します。スクラムを使用すると、自分の立ち位置を常に把握でき、問題を早期に可視化できるため、実際に何かを行うことができます。何よりも、スクラム プロジェクトのステータス追跡は、ウォーターフォール プロジェクトのステータス追跡よりもはるかに簡単であり、測定単位が作業時間ではなく残りの機能であるため、本質的により正確です。
于 2009-11-25T10:06:24.307 に答える
0
ウォーターフォールの変更管理プロセスに関連するすべてのトラウマなしで、チームが変更を受け入れること。
于 2010-03-08T05:20:43.760 に答える
0
「レイト バインディング」。アジャイル方法論では、決定を延期します。プロジェクト サイクルの後半で、関連する知識を実際に持っているときに電話をかけます。これにより、意思決定の質が向上します。
于 2009-01-13T21:55:34.533 に答える
0
他の人は、スクラムは私たちに「幸せな開発者」と「やる気のある開発者」を与えてくれると言いました。私にとって、それは最も印象的な観察です。スクラムは単に (エリート/悪い) プログラマーのパフォーマンスを増幅するという意見には同意しません。私の経験では、スクラムは一貫して開発者のパフォーマンスを向上させます。
なぜ、まあ：
- チームの一員であると感じることは活力になります。彼らはあなたの背中を持っています。あなたは彼らのものを持っています。
- 自分の作品に意味があると感じることができます。POが確認します。
- あなたは手の届く範囲の目標にコミットし、コントロールしていると感じます
- 長く立ち往生することはありません。孤独を感じることはありません。
- あなたは自分の労働の成果を見て、すぐに誇りに思うことができます
これらは「技術的」ではなく、非常に「感情的」であることに注意してください。これが「幸せ」だと思います。結局のところ、あなたの幸福度をさらに高めるための唯一の方法は、より良いプログラマーになるように努力することです。
要約する：
スクラムは、開発者がより高い到達度を達成し、パフォーマンスを向上させ、本質的な楽しみをもたらします。
于 2009-09-08T15:25:13.647 に答える