純粋な技術用語によるアジャイル方法論
アジリティープロセスについてよく耳にしますが、それは（ほぼ）常にチーム編成とデリバリープロセスに関連付けられているようです。それは（ほぼ、再び）ボトルの底に来ることは決してありません：開発自体。
コーディング中の開発方法論、バグ/エラー処理、プラクティス、イデオロギーなど、具体的に技術的な問題を対象とするアジャイルメソッドはありますか？それとも、チームでコーディングしているときにアジャイルが何であるかを理解できていないのですか？
あなたが聞くのは主にスクラムです。そして、スクラムは技術的な実践を扱っていません。そして、適切な技術的慣行を採用しないでスクラムを採用すると「Flaccid-Scrum」が発生するため、多くの人がスクラムの失敗を考えています。
一方、あまり知られていないアジャイル手法を採用しているeXtremeプログラミングは、技術的な手法をかなり扱っています。自動テスト、リファクタリング、ペアプログラミング、継続的な導入などの技術的実践は、XPの中心です。また、XPは、迅速で持続可能な予測可能な開発を可能にするのは、こうした慣行だと信じています。
短い答え
アジャイルマニフェスト は4値と12原則。それらのどれも技術的ではありません。それは考え方とチームワークについてのみです。ただし、それぞれの価値と原則には技術的な意味があります。これらは、さまざまな実践で具体化されており、最初はどちらか一方のアジャイルメソッドによって促進されていました。
より長い答え
特定の方法論に踏み込むことなく、アジャイルプロセスはすべて 反復的で段階的 ：
- 反復的は、技術的にどのように行われているかに関係なく、作業の編成に関するものです。
- Incrementalは、機能の連続するが完全なサブセットの配信についてです。これは、コードを洗練することを意味します。
一般的な技術的影響：
- デザインはインクリメンタルである必要があります 。そのため、事前に巨大で詳細なUMLモデルはありません。
- コードは適切に設計され、各増分に対して、そして最初から堅牢でなければなりません。これは、迅速かつ汚い使い捨てコード（たとえば、そのコードベースに基づいて構築する意図なしに実現可能性を検証するプロトタイプなど）を除外します。 クリーンコード 、または リファクタリング 、または バージョン管理システム の使用などのプラクティスは、増分コード化をサポートしています。
- 各増分は受け入れられるべきです。これは、要件の明確な 受け入れ基準 と、各増分の適切なテストを意味します。 テスト駆動開発 および 自動テスト （たとえば jUnit などのフレームワークを使用）は、その目的のための2つの効果的な方法です。
- 開発者は同期して作業する必要があります。これにより、反復の終了時に増分が機能します（つまり、未完成のものはありません）。 これが組織的な側面なのか技術的な側面なのかはわかりません。
- 頻繁な統合とビルドが必要です（増分ごとに少なくとも1回、実際にはより頻繁に）。 日次ビルド または 継続的インテグレーション は、この点で2つの効果的な方法です。
反復および増分開発プロセスでは、増分を適切に識別できるようにするために、もちろん入力が必要です。通常、これは ユーザーストーリーまたはユースケース で実現されます。 ユーザーストーリーマッピング または ユースケース2. は、要件を実装可能なチャンクにスライスする効果的な方法です。
上記のプラクティスの一部が必ずしもアジャイルに拘束されないことに反対するかもしれません。そして、あなたは正しいでしょう：アジャイルは技術的な実践についてではありません。ただし、俊敏性を実現するには技術的な実践が必要です。
ソフトウェア開発の根本的な問題は、システムの実際の要件が一般的な例では不明確であり、さらに悪化することです（さまざまな理由により）。これが当てはまらない場合もありますが、例外ではありません。
人々は自分が何を望んでいるのかを知りません（彼らは通常、対処/解決しようとしている問題を理解しています）誰もがしばしば、彼らが望むものと、製品が提供されるときに求めるものとの間のギャップについてしか知りません。
ソフトウェア開発への「アジャイル」アプローチは、フィードバックから学習し、要件を適合させるために、ほとんどまたは頻繁に提供することでフィードバックループを短縮することを目的としています。この分野での多くの議論は、価値の提供に関するものです。
したがって、アジャイルはテクノロジーについてではありません（多くの共通点を持つ「リーン」製造プロセスについても同じことが言えます）。とはいえ、方法論に関係なくアジャイルになることを容易にする技術的実践はいくつもあります（変更を管理しやすくする、ハイケイデンスでの提供を容易にするなど）。そのため、技術的な問題について話し合うことは合理的です。アジャイルなコンテキスト。
アジャイル（または無駄のない）を目指すことから生じる最後の1つは、コミュニケーションの価値と開発する人々の価値です。スクラム（たとえば）は、エンジニア間のコミュニケーションを促進する手段であり、少なくともそうすることができます。配信の邪魔になる問題を明らかにする