単体テストなしのアジャイル
「アジャイル開発」について話したり、作業しているコードベースの単体テストカバレッジが0％である場合に「アジャイル方法論」を適用していると主張したりすることは理にかなっていますか。 （そして、あなたはチームとして何もしていません）。
はっきりさせておきますが、私には意味がありません。私の個人的な経験では、ユニットテストが本当に「機敏」（つまり、変更に対応し、設計を改善し、知識を共有するなど）を可能にする唯一のツールであり、TDDが唯一の実践であることがわかりました。
たぶん他の方法があるかもしれませんが、私はまだそれらがどのように機能する可能性があるのかまだわかりません。
わかりやすくするために、アジャイルマニフェストやスクラムガイドでは、ユニットテストやTDDなどの技術的な実践についてまったく言及していません。つまり、そうです、理論的には、コラボレーションと価値なしに重点を置いてそれらを早期に実現し、それなしで自分自身をアジャイルと呼ぶことができます。実際にはagility.
しかし実際には、優れたテストスイートなしでは、数週間ごとに一貫して価値（本番環境に）を提供することはほぼ不可能です。これには、単体テストだけでなく統合テストも含まれます。単体テストはこれまでのところです。ピラミッドであり、長方形ではないのには理由があります。
安全策としてのテストがなければ、リリースごとに多くのリグレッションバグが発生するか、リファクタリングが怖くなります。どちらも持続可能ペースで継続する能力に大きな影響を与えます。必要に応じてペースを維持したりコースを変更（再設計）できない場合は、敏捷性がありません。結局のところ、俊敏性は私たちが目指している目標です。
アジャイルマニフェストは単に次のように述べています：
プロセスとツール上の個人と相互作用
包括的なドキュメントに対応した実用的なソフトウェア
顧客とのコラボレーション契約交渉
計画に従った変更への対応
そこでのユニットテストについての言及はありません。さえ 12の原則 テストについて言及していません。
したがって、技術的には、単体テストを記述せずにアジャイルチームになることは可能です。しかし実際には、チームが絶え間ない変更を行うためのテストを行わずに、アジャイル環境で作業中のソフトウェアを維持する方法を確認するのは非常に困難です。
他の人がここで答えたように、アジャイルマニフェストにはユニットテストやTDDまたはあらゆる種類のテストについて直接語っている言葉はありませんが、優れたスクラムマスターまたは開発者はマニフェストのステートメントの1つを識別できると思います。
実用的なソフトウェア包括的なドキュメント。
ソフトウェアが機能しているかどうか、誰がどのように知るのでしょうか？マニフェストでは、テストという用語を明示的に述べる必要はありません。簡潔です。
ユニットテスト（トピックのコンテキストで）を行うと、コーディングフェーズが初期の段階で遅くなりますが、進行に応じて価値があり、開発がはるかに速くなります。コードレベルのテストを細かく制御できるだけでなく、設計をスケーラブルにして、ソフトウェアが機能していて、回帰を簡単に処理できることを確信させることができます。これにより、開発がアジャイルになります。
それは絶対に理にかなっています。他の人がすでに述べたように、アジャイルはテストについてではありませんが、具体的にあなたの質問に答えることです：
いいえ、ユニットテストはまったく必要ありません。
統合テストのみでアジャイルプロセスを実行できます。たとえば、自動統合テストを毎晩実行し、翌日に見つかったバグを修正できます。必要に応じて、手動テスターで継続的に統合テストを実行することもできます。システムに関係なく、単体テストは完全にオプションです。
単体テストは開発に役立ち、それに対して十分に公平であると思うかもしれませんが、開発に役立つ可能性のある多くのものは、あなたが持っていないかもしれません。
ただし、古い「顧客ベータテスター」であっても、何らかのテストが必要です。顧客がプロセスに深く関与していて、バグを見つけることを気にしない場合は、これはうまくいく可能性があります。
必須ではありません。テストは、使い方を本当に知っている人がいるときに最適です。そうしないと、それは必要ではないだけでなく、責任になります。あまり熟練していないプログラマーも多いと思います。
アジャイルであるということは、いくつかの方法論に従うのではなく、実際にソフトウェアをどのようにリリースするかについてであるという質問であなたが認めたことをうれしく思います。アジャイルマニフェストはいい参照ですが、それは決定的なガイドではありません。アジャイルはそれが存在する前に存在していました。 「より機敏な」ソフトウェアを開発する方法はいくつかありますが、さまざまなプロジェクトでさまざまな組み合わせを使用できます。
クライアントが許容できるペースで新しいソフトウェアをリリースしている場合は、おそらく俊敏です。また、プッシュバックが多すぎないことや、開発者による機能の変更について不満を述べることも含めます。あるものを修正して別のものを壊すことも、理想的ではありません。ユーザーがいくつかのバージョンのアップグレードに遅れをとっている場合、テストするかどうかにかかわらず、おそらく非常に俊敏ではありません。
アジャイルマニフェストがこれについて明確に何かを述べていると主張する（他の答え）と反対したいと思います：
技術的卓越性への継続的な注意と優れたデザインが俊敏性を高めます。
私は LeSStechnical excellence の定義が本当に好きで、ユニットテストとTDDが含まれています。これを実現するために単体テストやTDDは必要ないかもしれないと主張できますが、これが最も一般的でおそらく推奨される方法です。
組織の俊敏性は、技術の敏捷性によって制約されます
言い換えると、製品の変更が遅い場合、チーム、組織、または採用するフレームワークをどのように構成しても、変更への対応が遅くなります。
あなたの製品が別の方法で変更に抵抗するのを防ぐことができれば、あなたは正しい軌道に乗っているかもしれませんが：
プログラマーのために世界を安全にするために、エクストリームプログラミングを発明しました。 –ケントベック
スクラムには技術的な慣習はありませんが、ジェフは次のように述べています。
エクストリームプログラミングの開発手法を使用していない、非常に生産的なスクラムチームを見たことがありません。 –ジェフサザーランド
この記事から引用： http://ronjeffries.com/articles/017-02ff/gathering2017/
私は、技術的な慣習のないスクラムチームが、最終的には回顧展を使用して同様の慣習を思い付くことを期待しています。あなたも超生産的になりたいですか？
アジャイルフルエンス モデルでは、2つ星レベルで言及しています。
便利なテクニックには、継続的インテグレーション、テスト駆動型開発、ペアプログラミング、集合的所有権などがあります。
アジャイルの流暢さの最初のレベルのみを対象とする場合は、練習をスキップできますが、より大きくて実行時間の長い製品は、少なくとも2つ星レベルを達成しようとする必要があります。
したがって、一般的なコンセンサスは、適切なユニットテスト、クリーンなコード、およびリファクタリングの実践がなければ、現在、真にアジャイルになることは不可能であるということです。これは将来、新しい技術的慣行が出現するにつれて変化する可能性があります。
ロバートC.マーティン、マーティンファウラー、ケントベックなどのマニフェストの署名者に尋ねた場合、その答えはどうなると思いますか？多分彼らはそれが依存していると言うでしょう、しかし一般的にそれはあなたがすべきことです。