単体テストなしのアジャイル

作業しているコードベースのユニットテストカバレッジが0％である場合、「アジャイル開発」または「アジャイル手法」を適用していると主張することは理にかなっていますか？（そして、チームとして、あなたはそれについて何もしていません）。

それを明確にするために：私にとって、それは意味がありません。私の個人的な経験では、ユニットテストが実際に「アジャイル」（つまり、変更への対応、設計の改善、知識の共有など）を可能にする唯一のツールであり、TDDが唯一の手段であることがわかりました。 。

他の方法もあるかもしれませんが、どのように機能するかはまだわかりません。

アジャイルマニフェストやスクラムガイドの内容は、単調であるために、単体テストやTDDなどの技術的な慣行にまったく言及していません。だから、そう、理論的にはあなたがそれらなしでコラボレーションし、値を中心とした早期かつ頻繁に届けるとアジャイル自分自身を呼び出すことができ、あなたも実際に持っているかもしれない俊敏性を。

ただし、実際には、優れたテストスイートなしでは、数週間ごとに一貫して価値を（生産に）提供することはほぼ不可能です。これには、統合テストと単体テストが含まれます。単体テストはこれまでのところです。ピラミッドであり、結局は長方形ではないのには理由があります。

セーフティネットとしてのテストがなければ、各リリースで多くの回帰バグが発生するか、リファクタリングが怖くなります。両方とも、持続可能なペースで継続する能力に大きく影響します。必要に応じてペースを維持したり、コースを変更（再設計）できない場合は、敏have性がありません。アジリティは、結局のところ、私たちが目指している目標です。

アジャイルマニフェストは単に次のように述べています：

プロセスとツールを介した個人と相互作用

包括的なドキュメントよりも機能するソフトウェア

契約交渉を介した顧客コラボレーション

計画に従うことによる変化への対応

ユニットテストについての言及はありません。12の原則でさえ、テストについて言及していません。

したがって、技術的には、単体テストを作成しなくてもアジャイルチームになることが可能です。しかし実際には、チームが継続的な変更を支援するためのテストなしで、アジャイル環境で動作中のソフトウェアをどのように維持できるかを見るのは本当に難しいです。

ここで他の人が答えているように、アジャイルマニフェストにはユニットテストやTDD、またはあらゆる種類のテストについて述べる直接的な言葉はありませんが、優れたスクラムマスターまたは開発者はマニフェストのステートメントの1つを識別することができると思います。

 包括的なドキュメントよりも機能するソフトウェア。

ソフトウェアが機能しているかどうかを誰がどのように知るでしょうか？マニフェストでは、テストという用語を明示的に述べる必要はありません。簡潔です。

（トピックのコンテキストでの）単体テストは、コーディングフェーズを初期段階で遅くしますが、進行するにつれて価値があり、開発がずっと速くなります。コードレベルのテストをきめ細かく制御できるだけでなく、設計をスケーラブルにすることで、ソフトウェアが機能し、回帰を簡単に処理できるという自信を与えます。これにより、開発がアジャイルになります。

それは絶対に理にかなっています。アジャイルは、他の人がすでに述べたように、テストについてではありませんが、あなたの質問に具体的に答えるために：

いいえ、ユニットテストはまったく必要ありません。

統合テストのみでアジャイルプロセスを実行できます。たとえば、自動化された統合テストを毎晩実行し、翌日に見つかったバグを修正できます。必要に応じて、手動でテスターに​​統合テストを継続的に実行させることもできます。システムに関係なく、単体テストは完全にオプションです。

単体テストは開発に役立ち、それに対して十分に公平であると思うかもしれませんが、開発に役立つ可能性のあるものはたくさんあります。

ただし、古い「カスタマーベータテスター」であっても、何らかのテストが必要です。顧客がプロセスに深く関わっており、バグを見つけることを気にしない場合、これはうまくいく可能性があります。

必須ではありません。テストは、実際に使用方法を知っている人がいる場合に役立ちます。そうしないと、必要ではないだけでなく、責任になります。あまり熟練していないプログラマーがたくさんいると思います。

アジャイルであることは、何らかの方法論に従うのではなく、実際にソフトウェアをリリースする方法についての質問であることを認めてくれてうれしいです。アジャイルマニフェストは良いリファレンスですが、それは決定的なガイドではありません。アジャイルは存在する前に存在していました。「より機敏」にソフトウェアを開発する方法はありますが、さまざまなプロジェクトで異なる組み合わせを使用できます。

クライアントが受け入れられるペースで新しいソフトウェアをリリースしている場合は、おそらく機敏です。また、プッシュバックが多すぎず、開発者による機能の変更について不平を言うことも含めます。あるものを別のものを壊すためだけに修正することも理想的ではありません。ユーザーがアップグレードのいくつかのバージョンを使用している場合、テストするかどうかにかかわらず、おそらくあまり機敏ではありません。

私は、アジャイルマニフェストがこのことについて明確に述べていると主張します（他の答え）。

卓越した技術 と優れた設計への継続的な注意が俊敏性を高めます。

私はLeSSの技術的卓越性の定義が本当に好きで、ユニットテストとTDDが含まれています。これを達成するために単体テストやTDDを必要としないかもしれないと主張することができますが、これは最も一般的でおそらく推奨される方法です。

組織の敏ility性は技術的敏ility性によって制約されます

言い換えれば、製品の変更が遅い場合、チーム、組織、採用するフレームワークの構造に関係なく、変更への対応が遅くなります。

製品が別の方法で変更に抵抗するのを防ぐことができる場合、正しい軌道に乗っているかもしれませんが、

私はプログラマーにとって世界を安全にするためにエクストリームプログラミングを発明しました。–ケントベック

スクラムには技術的な実践はありませんが、ジェフはそれについて次のように述べています。

エクストリームプログラミング開発プラクティスを使用しなかった、非常に生産的なスクラムチームを見たことはありません。–ジェフサザーランド

この記事から引用：http : //ronjeffries.com/articles/017-02ff/gathering2017/

技術的なプラクティスのないスクラムチームは、最終的に回顧を使用して同様のプラクティスを考え出すことを期待しています。あなたも超生産的になりたいですか？

アジャイルフルエンスのモデルには、2つ星レベルでそれを言及します：

有用な手法には、継続的インテグレーション、テスト駆動開発、ペアプログラミング、および共同所有権が含まれます。

アジャイルの流fluさの最初のレベルのみを対象とする場合は、練習をスキップできますが、大きくて長時間動作する製品は、少なくとも2つ星レベルを達成しようとします。

したがって、一般的なコンセンサスは、適切なユニットテスト、クリーンなコード、リファクタリングの実践なしでは、真にアジャイルになることは現時点では不可能だということです。これは、新しい技術的慣行が出現するにつれて、将来変更される可能性があります。

ロバート・C・マーティン、マーティン・ファウラー、またはケント・ベックのようなマニフェストの署名者に尋ねたら、答えは何だと思いますか？多分彼らはそれが依存すると言うでしょうが、一般的にそれはあなたがすべきことです。