アジャイル手法とは何ですか？[閉まっている]

アジャイル手法について簡単な文章で説明できる人はいますか？

アジャイルは多くのことと慣行ですが、私はその中核は単なる反復的な開発だと思います。

反復： 非常に小さな滝の束を考えてください。つまり、ウォーターフォールメソッド（要件->仕様->コード->テスト）ですが、1年程度にわたって行うのではなく、全体の管理可能なチャンクのために数週間にわたって行いますプロジェクト。「反復/スプリント/増分」の最後に、小規模ながら完全でテスト済みの追加機能のセットがあります。

これにより、自分がやっていることが顧客の望んでいることではなく、ビジネスニーズの変化などではないことが判明した場合、プロジェクトのコースをすばやく変更できます。したがって、「アジャイル」という用語。

アジャイル宣言そのものよりも優れているものはないと思います。

私たちは、
ソフトウェアを開発し、他の人がそれを行うのを支援することにより、ソフトウェアを開発するより良い方法を発見しています。
この作業を通して、私たちは次のことを大切にしました。

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

つまり
、右側の項目に価値がある一方で、左側の項目をより重視します。

http://agilemanifesto.org/から

私にとって最も重要なアイデアはこれです：

要件の変更は、必要なもの（プロジェクトの開始）に関する知識の最下層でソフトウェアを設計することを余儀なくされ、要件はプロジェクトの過程でのみ明確になるために発生します。

従来の（ウォーターフォール）アプローチでは、包括的な仕様を承認することで、プロジェクトの開始時に全員を契約に縛り付けて、この変化を緩和しようとします。これはCYAとして機能する可能性がありますが、ユーザーのニーズに合わないものを配信することを誰もが喜んで行うことはありません。

アジャイルメソッドは、開発チームを変更から保護するのではなく、避けられない変更を受け入れるように設計されています。これはさまざまな方法で行われますが、その主なものは、反復的な開発とプロセスへの利害関係者による継続的な関与です。私の経験では、最終的には関係者全員が幸せになりますが、筋金入りのプランナーである一部の経営者にとってはより不快になる可能性があります。

一文では、これは次のようになります。

アジャイルソフトウェア開発は、反復的かつインクリメンタルな開発に基づくソフトウェア開発方法論のグループであり、自己組織的なクロスファンクショナルチーム間のコラボレーションを通じて要件とソリューションが進化します。

これはウィキペディアの定義から来ており、とても気に入っています。中核となる原則を強調しました。

また、アジャイルではないものも追加したいと思います。アジャイルであると主張する多くのショップがありますが、それは彼らがプロジェクトを計画することに興味がなく、不合理な短期間で物事が行われることを期待していることを意味しています。

アジャイル！=プロジェクト計画なし。声明は虚偽であると暗黙に考えている人々を扱うのは難しいです。なぜなら彼らは管理タイプであり、常に矛盾しやすいとは限らないからです。

アンディはすでにアジャイル宣言にリンクしています。

アジャイルマニフェストがどこから来たのかを見るのも有用だと思います。エクストリームプログラミング（XP）、スクラム、DSDM、アダプティブソフトウェア開発、クリスタル、機能駆動開発、プラグマティックプログラミング（Alistair Cockburnからのリスト）など、いくつかの共通要素と多くの同様の動機を持つ多くの方法論がありました。それらの方法論を提案している人々は、彼らが言っていることの力が強化されるように、彼らが共通して持っているものをカバーするためにマーケティング用語を考え出すことに決めました。

興味深いことに（誰かが私に言ったことによれば）ショートリストには、「アジャイル」ではなく「アダプティブ」という名前の候補が多数ありました。個人的には、アジャイルとは「アジャイル」よりも優れているということを、一言で言うともっと良いと思います！

アジャイル手法を採用することは、製品開発の他の側面よりも高品質の製品の提供を重視し、ユーザーコミュニティからのフィードバックが高品質の製品を作成するために不可欠であることを認識することになります。

これとは対照的に、実装を重視せずに製品を開発からリリースに移行しながら、先行設計、ドキュメント、インターフェース定義を重視する従来の/ウォーターフォール開発アプローチと比較してください。

私の意見では、チームが製品に組み込むことができる本質的な品質があり、これは製品が開発チームが意図したとおりに機能し、予見可能な拡張に合理的に対応できることを確認するという形をとっています。製品がユーザーのニーズをどれだけ満たしているかを測定する、知覚のみに基づいた品質要因もあります。

アジャイルアプローチは、製品を繰り返し提供する傾向があり、ユーザーのフィードバックと開発者のフィードバックを各反復に取り入れ、頻繁なユーザーのフィードバックを引き出して開発活動の傾向を打ち消すための強制機能として最小の実行可能性を達成すると、機能の各増分の提供を促進しますユーザーからのフィードバックなしで長時間。私の考えでは、アジャイルアプローチの他の側面はこれらの重要な教義をサポートする傾向があります。

• 頻繁な顧客コラボレーションを重視することでユーザーのフィードバックが生成され、要件の変更に柔軟に対応できるため、製品開発でそのフィードバックを定期的に統合できます
• 関連する展開構成および環境への頻繁な統合は、フィードバックを提供するユーザーにとって製品の価値と関連性を維持するために、関連する構成および環境の継続的な識別と密接に関連しています。
• 自己組織化と職域を超えたチームの促進は、チーム内で個人的な説明責任を作成し、チーム内の事前に割り当てられた役割と管理階層に拘束されることなく、効率的な方法でロードブロッキングを削除する最善の方法をチームが決定できるようにすることを意味します