開発ライフサイクルモデルモデルを選択するにはどうすればよいですか？
アジャイル哲学の代替案に関するこの質問 とその回答とコメントに基づいて、プロジェクトの開始時に使用する「方法論」の決定に何が入るかを議論することが役立つかもしれないと思いました。
コンセンサスは、構築しているものが正確な仕様を必要とする場合、ウォーターフォールがアジャイルを超える方法であるということです。それはアジャイル開発のための巨大なスペースを残しているようです。 「これがショップがソフトウェアを開発する方法です」のほかに、クライアント/プロジェクトに何が最適に機能するかをより適切に示す可能性がある質問または「指標」が初期の計画段階にありますか？
言語と同様に、このアイデアは仕事に最適なツールです。プロの開発者として、開始しようとしているプロジェクトに正しい開発方法を使用していることを確認するために何をしますか？
それは本当にそれが橋か核反応器タイプのプロジェクトである場合は滝を使用するか、アジャイルを使用するかのように切断され乾燥していますか？
私は会社で働いている独学のプログラマーであり、柔軟性が高く、彼らは私に大きな信頼を置いているので、この種の質問は私にとって重要です。できるだけ効率的なコスト/時間の方法で自分の仕事/プロジェクトに取り組んでいることを確認したいと思います。
まず、それはウォーターフォールまたはアジャイルの選択ではなく、計画主導型かアジャイルかです。選択できる計画主導の方法論は多数あります。他の著名な計画主導の方法論は ベームのスパイラルモデル です。これは反復型開発ですが、（必然的に）増分ではありません。 他のプラン主導の方法について質問しました 、そして示された他の方法は キャップジェミニSDM でした。
計画主導の方法論とアジャイル方法論のどちらを使用するかを決定する場合、考慮すべき要素がいくつかあります。 Rapid Development：Taming Wild Software Schedules では、SteveMcConnellがライフサイクルモデルの選択に専念するセクション全体を持っています。彼は、純粋なウォーターフォール、コードアンドフィックス、スパイラル、変更されたウォーターフォール、進化的プロトタイピング、段階的配信、進化的配信、設計からスケジュール、設計からツール、COTSソフトウェアなどの多くのライフサイクルモデルを検討しています。それぞれが詳細に議論され、十分に理解されていない要件に対処し、信頼性の高いシステムを作成し、リスクを管理し、制約されたスケジュールまたは予算内に収まり、顧客および/または経営陣に可視性を提供し、高度化する能力について評価されますチームの。
したがって、はい、1つの考慮事項は、提供されるプロジェクトのタイプです。しかし、そこから選択できる多くの要因と多くのライフサイクルモデルがあります。
それは本当にそれが橋か核反応器タイプのプロジェクトである場合は滝を使用するか、アジャイルを使用するかのように切断され乾燥していますか？
はい。
実際、それはとても簡単です。
アジャイルのポイントは、解決される問題にプロセスを適合させることです。
ウォーターフォールのポイントは、建設業とソフトウェアの設計および開発の間の（一部誤り）のアナロジーです。ソフトウェアはほぼ完全に設計上の演習であるため、構築（すべてを最初に設計し、すべてを2番目に構築する）はソフトウェアにあまり適用されません。従来の建築や製造に匹敵するソフトウェア開発はほとんどありません。
それは、開発方法論が2つの考え方によって支配されていることとはあまり関係がありません。 「硬く、曲がらず、硬い」と「緩く、柔軟で、常に変化する」の間に違いがあるかどうかを尋ねるようなものです。それらは白黒であり、灰色のさまざまな色合いが無数にあります。
さらにアジャイル内には、いくつかの異なるテンプレートから選択できます 出典：ウィキペディア ：
- アジャイルモデリング
- アジャイル統一プロセス（AUP）
- 動的システム開発方法（DSDM）
- エッセンシャルユニファイドプロセス（EssUP）
- Exiaプロセス（ExP）
- エクストリームプログラミング（XP）
- 機能駆動開発（FDD）
- オープンユニファイドプロセス（OpenUP）
- スクラム
- クリスタルクリア
- 速度追跡
テンプレートと言ったことに注意してください。実際には、すべての組織には調整が必要な固有のニーズがあり、これらのテンプレートの1つが良い出発点を提供できるからです。これが、現実に基づいたソフトウェア開発の正気で現実的な方法に移行するための管理者にとって十分な選択ではない場合、彼らはただディザリングし、考えにリップサービスを支払っています。顧客のニーズに合った高品質のソフトウェアを書くことにあまり関心がなく、彼らは彼らのプロセスと人々をしっかりと完全に制御しているという幻想を維持することについてです。
私見、ウォーターフォールはどんな開発にも適していません、それは何かをやり直すことが不可能である（または少なくとも、非常に高価な）建設業界から来ます。しかし、ソフトウェアにとっては、再設計と書き換えは安価であり、仕様を継続的にレビューすることは非常に望ましいことです。
OTOH、アジャイルでは、すべてのチームメンバーがほぼ同じ経験を持っている必要があり、チームは小さい必要があります。そうしないと、かなりの通信オーバーヘッドが追加されます。経験レベルが異なる場合、最も経験豊富な人にとっては多くの時間を浪費します。
私が最も使用し、より効果的であると経験したアプローチは、定義された構造をまったく持たないことです。
最初に、プロジェクトはあなたが得ることができる最も才能があり熟練したものを必要とし、良い基盤を持っています。通常、他に何もすることはありません。この人々をプロジェクトに参加させて数日待つだけで、すぐにすべての整理が始まります。それは自然の力です。
適切な人を適切な場所に配置するだけでうまくいきます。自然のリーダーを探してください（誰もが嫌いですが、大好きです）。物事が動き始めると、彼らは物事を正気に保つためにガーディアンモードに切り替わり、スピードをキャッチします。
（まあ、私は暗黙の構造があることを認めますが、それは非常に動的です）
重要な点は、開発はほぼ完全に（この観点から）社会的相互作用から成り、不注意な介入に対して非常に複雑で耐性があるため、社会的相互作用を設計しようとする試みはすべて失敗するということです。それについて私たちができる唯一のことは、少し影響を与えることです。
成熟したアジャイルアプローチとウォーターフォールアプローチは、事実上互いに区別できるように見えます。あなたの主な目標は、ビジネスがソフトウェア開発を推進することです。機能をポイントしてその機能のビジネス要件を参照できない場合は、どのモデルを使用してもかまいません。そこでQAが登場します。
ビジネス要件の記録システムである強固なQA環境が必要です。 QAはテストではなく品質保証を表します。 QAが実行するこれらのテストはすべて、構築中のシステムが、所有している最終的な要件にマップされていることを確認するためのものです。そして、開発者はソフトウェアを開発するときに進むべき方向性を持っています。
これらを開発チームとうまく連携させるため。次に何を開発すべきかを決定することにビジネスが圧倒されないように、リリースサイクルを短くする必要があります。また、QAでは、特定の機能が想定された機能を実行しているかどうかを判断する可能性が高くなり、開発チームへのフィードバックはより具体的になります。これは、システムのその部分が壊れているかどうかについての想定が少ないためです。 。
これらはすべて、高品質のソフトウェアを作成するためのものです。開発方法論は、誰もが予測可能な方法で一緒に作業できるようにするまとまりのあるソリューションにそれらを結び付けるものです。ウォーターフォールアプローチは、アジャイルアプローチがより開発者に焦点を合わせているのに対し、ビジネスが適応するのがより簡単なことから始まる傾向があります。しかし、最終的には両者が真ん中で出会う。