アジャイル開発方法論の実行可能な代替手段はありますか？

2つの主要なソフトウェア開発方法論は、ウォーターフォールとアジャイルです。これら2つを議論するとき、それらを区別する特定のプラクティス（ペアプログラミング、TDDなどと機能仕様、大きな先行設計など）に多くの焦点が置かれることがよくあります。

しかし、実際の違いははるかに深く、これらの慣行は哲学に基づいているという点です。

Waterfall氏は次の ように述べています。
アジャイルは言う： 変化は避けられないので、変化を安くする。

私の質問は、TDDや機能仕様についてどう考えているかにかかわらず、ウォーターフォール開発の方法論は本当に実行可能かということです。

ソフトウェアの変更を最小限に抑えることは、貴重なソフトウェアを提供することを望む人々にとって実行可能なオプションであると本当に考えている人はいますか？それとも、避けられない変化を管理するために、私たちの状況でどのような実践が最も効果的に機能するのかという質問ですか？

もちろん、滝は実行可能です。月に連れて行ってくれました！

そして、それはここで話しているアジャイルコーチです！

プロジェクトの管理方法に関連する問題を明確に特定できない限り、変更する正当な理由はありません。

アジャイルとウォーターフォールの方法論の代替として、あなたの方法論を提案します。特定のビジネス、特定のチーム、製品、作業方法、企業文化に適応しているため、スクラムは方法論ではなくシンプルなフレームワークと呼ばれています。

あなたが好きなブログの誰かがそれについて話したので、方法論を実装したいのは、何もせずに問題を進行させるのと同じくらい愚かです。

まず、私はあなたの声明に反対します。

Waterfall氏は次のように述べています。変更はコストがかかるため、最小限に抑える必要があります。
アジャイルは言う：変化は避けられないので、変化を安くする。

私の解釈は：

Waterfall氏は次のように述べています。顧客は自分が望むものを知っています。
アジャイルは言います：顧客は彼らが何を望むかを知らないので、我々はいくつかの異なるバージョンを作らなければなりません。

私がこれまでに見た「ウォーターフォール」の最良の実装は、非常に大きな金融顧客との巨大な統合プロジェクトであり、約40以上のサブプロジェクトが関与していました。提供したデスクトップおよびWebサイトパッケージは、これらの40以上のサブプロジェクトのうちの1つにすぎませんでした。私は彼らが他の人のお金をかなり過剰に吹き飛ばしたと思っていたが、彼らは彼らのものを一緒に持っていて、40以上の異なる船がすべて編隊で一緒に動いていた。プロジェクトは目標日に稼働しました（目標はプロジェクト中に1回移動しました）。私は彼らがもっとfru約的かつ精力的にそれを行うことができると思っていましたが、それは時間通りに、仕様に従って行われました。実稼働の夜のスケジュールは約100ページの長さで、そのうちの約40ページはあらゆる種類の関係者の緊急パニック連絡先でした。このクライアントには非常に感銘を受けました。

または、私たちがしていることを実行することもできます。これは、実行され、最新の苦情/バグレポートを実行し、そのアジャイルを呼び出します。

あなたは言うことから始めます：

ソフトウェア開発の2つの主要な哲学は、ウォーターフォールとアジャイルです。

これは誤りです。この二分法は、アジャイルコミュニティによって構築されており、自分自身を配置する相手を作成します。アジャイルが流行する前、人々はソフトウェアを構築するための無数の異なるアプローチについて語っていました。それらは現在も存在していますが、アジャイル支持者によって「滝」と呼ばれる大きな混乱にまとめられていることがよくあります。

私はOPEN / Metisとそのバリアントを10年以上使用してきましたが、大きな成功を収めています。それは間違いなくアジャイルではなく、間違いなく滝でもありません。数千人の開発者が、機敏ではない方法を使用して、航空機、生命にかかわるシステム、銀行などに非常に複雑なソフトウェアを毎日作成しています。

そのため、もちろん、アジャイルに代わる実行可能な代替手段があります。

はい、問題のドメインに応じて、さまざまなソフトウェア開発手法がすべて実行可能です。それは「コースの馬」です。

たとえば、原子力発電所を制御したり、NASAスペースシャトルを運転したりするためのソフトウェアを書いています。この種の問題ドメインは、おそらくウォーターフォール（またはさらに厳密な）アプローチに適しています。可能な場合はすべての問題を事前に整理する（またはBOOM！）必要があります。

最新のWeb 2.0 / 3.0 / buzzyマーケティング用語UIを構築していますか？アジャイルは、はるかに優れた方法です（迅速なフィードバックと変更が必要です）。

方法論がどのようなものであっても、私がまだ適用できるソフトウェアクラフトマンシップの原則と呼ぶものがあります。

• ソース管理
• ビルドとCI
• ペアプログラミング
• TDD
• ^％$$＆を渡します

もっと。

あなたが何をするにしても、方程式のどちらの側の熱狂者にも耳を傾けないでください。あなた、あなたのチーム、そしてあなたの問題の領域にふさわしいことをしてください。

問題は、ソフトウェアの複雑さに起因しています。物理学は決して変わらないので、滝は橋の建設や道路舗装のようなものに最適です。確かに、ある時点で新しいアスファルトを開発しますが、道路の建設方法に革命をもたらすことはありません。ブリッジのサスペンションのスチールは、適切なサイズかそうでないかのどちらかです。ソフトウェアでできるように、実際の建設プロジェクトを汚したりスタブしたりすることはできません。

ソフトウェアの変更。ソフトウェアは急速に変化します。ムーアの法則によれば、チップ上のトランジスタの数は18〜24か月ごとに2倍になります。当然、プログラムのコード行数も2倍になります。したがって、2 ^（2t）のようなbigOを使用すると、これらのコード行の間の複雑さが増します。

ソフトウェアは急速に変化し、複雑さは指数関数的に増大します。

ソフトウェアのコストを制御する場合、乗法的または加法的なだけでなく、指数関数的な要因を制御する必要があります。コードを変更すると、指数関数的に複雑さが増します（プロジェクトが進むにつれて指数関数的に複雑になります）。

変更は避けられません。プログラミングの性質上、クラスとカスタムメソッドによって言語が拡張され、言語自体が変更されます。他の種類の工学分野ではできません（道路の建設など。カリフォルニア州カンザスに道路を舗装するためだけに新しい舗装を発明することはありません）。

アジャイル方式は、将来のリリースとバグ修正を処理するためのプラットフォームも提供します。バージョン管理されたソフトウェアを開発するための管理ツール、プロセス、訓練された従業員がいます。ウォーターフォール法では、マイナーなバグ修正でも処理できるようにチームを再訓練する必要があります。

とにかく、私の2セント。

質問に答えるために、少なくとも一般的なケースでは、おそらくソフトウェアではない-またはまだ、実行可能な代替手段があります。それはソフトウェアの性質に起因すると思います。情報であるソフトウェアは無料で複製できます。橋や家とは違います。これは、練習すれば、家を建てるのが上手くなり、比較的単純な領域で操作できることを意味します。どの時点でワンショットアプローチを使用しないのですか？

しかし、ソフトウェアの複製コストはゼロなので、なぜ同じことを2回行うのでしょうか？ソフトウェアは製造業から遠ざかる傾向があります。したがって、すべてのソフトウェアが新製品の作成である場合、私たちは常に複雑なドメインで動作しており、ある程度まで、私たちは何をしているのかわかりません。または、前もって知るのは高価であり、実行することで見つけるのは安価です。複雑で危険な領域では、実験を試みて、増分と反復を行いたいと思います。

ウォーターフォールを行いたいソフトウェアの例として、原子力発電所とフライバイワイヤシステムがよく挙げられます。しかし、シャトルアビオニクスシステムは繰り返し開発されたのではありませんか？カナダと米国の航空交通管制システムはそうでしたか？

そして、OPEN / Metisが反復的で増分的である場合、私にとっては、他の一般的なアジャイルプラクティスと関連付けられていなくても、アジャイルの哲学を持っているように思えます。

ウォーターフォール法は最も確実に実行可能であり、他のアプローチと同じように哲学的に健全です。Waterfallはアジャイルよりもずっと長いことを忘れないでください。しかし、これは、ある方法論が別の方法論より優れているかどうかを述べる論拠ではないことに注意してください。

問題領域全体と顧客がソフトウェアパッケージで何を達成したいのかを非常に明確に理解している場合、ウォーターフォール法を使用します。契約を締結する際におそらく固定価格を見積もっていますが、顧客は合意された要件から逸脱することはできないことを理解しています。あなたのプロセスは、開発のさまざまな段階の間の一連のサインオフを厳密に通過するものであり、多くの場合、各段階は異なるチーム、時には異なる会社によっても完了します。他の人と連絡します。ウォーターフォールは、軍事および政府のプロジェクトが外部の請負業者に入札されると、それらが良い効果をもたらすことがよくあります。ウォーターフォールやその他の同様のアプローチが悪い評判を得るのは、開発者が問題に遭遇したとき、不十分な推定、不測の事態なしに計画されたスケジュール、問題ドメインの不十分または不完全な理解など。問題は、方法論の真の欠陥ではありませんが、その応用にあります。

アジャイルと他の方法論との比較は間違っています。アジャイルは方法論ではなく、哲学でもあります。あるいは、アジャイルは、ソフトウェアの開発方法を見るための別の方法を表す包括的な用語であると言う方が良いでしょう。方法論は単なるツールであり、その価値は常に、アジャイルであることを意味するものの中心にある個人や相互作用よりも常に低くなります。

ソフトウェアの変更を最小限に抑えることは、貴重なソフトウェアを提供することを望む人々にとって実行可能なオプションであると本当に考えている人はいますか？

変更を最小限に抑えるあらゆる機会は、開発者と顧客の両方にとって貴重です。変更により、スケジュールがずれたり、スケジュールを満たすために機能が省略される可能性があります。プロジェクトの価値に影響を与える変更の影響を管理する方法です。

それとも、避けられない変化を管理するために、私たちの状況でどのような慣行が最もうまく機能するのかという質問ですか？

あなたの慣行は、変更の管理に役立つかもしれませんし、変更を完全に無視するかもしれません。重要なのは、開発プラクティスと顧客との関係の管理の組み合わせであり、これらが関係するすべての関係者にとって効果的に機能するかどうかです。

すべての意図と目的のためにアジャイルである私たちは、あなたがあなたのために働く方法を選択することを理解しています。特定のアプローチが好きなら、それに従ってください。ニーズに合わない場合は、変更します。ソフトウェアを作成する方法は、手元にあるリソースを最大限に活用しようとすることと、プロジェクトを失敗に導く可能性のあるプラクティスを最小限に抑えることになります。手元の特定のプロジェクト。

「わかりました、今私たちはアジャイルです」と言うのは本当に一つのことであり、アジャイルの哲学に従って実際に生き、働くことは全く別のことです。Waterfall、Incremental、Spiral、SCRUM、XP、FDD、またはその他の方法を使用するかどうかにかかわらず、基本的にアジャイルです：

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも機能するソフトウェア
• 契約交渉を介した顧客コラボレーション
• 計画に従うことによる変化への対応

そして、これらの価値をうまく適用するために、ツール、方法、経験をすべてまとめる場所です。

はい、ウォーターフォール、スパイラル、反復、およびその他のハイブリッドプロセスモデルはすべて実行可能ですが、変更は避けられません。プロセスとは、変化をどのように処理するかだけではありません。（最大の決定要因は、問題をどれだけ把握/理解できるか、そしてどの程度正確に計画および予測できるかです。

「2つの主要なソフトウェア開発方法論はウォーターフォールとアジャイル」であると述べると、ソフトウェア開発プロセスのスペクトルがあり、多くの企業が独自のバージョンのプロセスモデルを合成し、多くの場合、特定のプロジェクトで変化します。ソフトウェア開発には2つ以上の実行可能なアプローチがあります。ウォーターフォールとアジャイルは「変化」スペクトルの両端に該当する傾向がありますが、これらの競合する方法論を次のように類型化することは合理的です。

Waterfall氏は次のように述べています。

アジャイルは言う：変化は避けられないので、変化を安くする。

しかし、それだけではありません。ビジネスは計画と予測ができる必要がありますが、ソフトウェアは創造的なプロセスであり、見積もりはしばしば間違っています。良い-速い-安い三角形を覚えていますか？4番目の次元であるプロセスを追加すると、プロセスの労力を減らすことで、見積もりが間違っていてプロジェクトが遅れる危険がある場合にスケジュールを短縮できることがわかります。ソフトウェアは代替可能な（変更可能な）プロセスであり、アジャイル、反復、スパイラルはすべて、より短い間隔で増分機能を提供する機能を提供します。

ウォーターフォールおよびその他の要件駆動型プロセスモデルには、変更を処理するためのコントロールがあるため、ウォーターフォールは変更を最小限に抑え、ウォーターフォールが変更を認識および管理し、その変更の影響を伝えると言う方が不正確です（変更はスケジュールの影響を引き起こすため要件と設計を事前に持っている）。製品を構築するとき、または要件（機能）を完全に定義する必要があるとき、ハイブリッドモデルの1つに追い込まれます。

見積もりが間違っている場合、スケジュールを満たすためにプロセス（鉄の三角形の4番目の区間）が犠牲になることがよくあります。

成熟したアジャイルとウォーターフォールのアプローチは、互いに区別できません。ウォーターフォールアプローチの目標についてのあなたの仮定は間違っています。どちらも高品質のソフトウェアを作成するという目標を持っています。会社全体として堅実な開発アプローチがない場合は、採用する際の摩擦が最も少ないアプローチを検討する必要があります。最後の短い開発サイクルでは、一流のQAチーム、および開発を推進するビジネスが、最高のソフトウェアを作成するために最も重要です。