TDD（テスト駆動開発）を行わない場合、自分自身（またはチーム）を「アジャイル」と正しく呼ぶことは可能ですか？

はい、はい、はい、100万回はい。

アジャイルは哲学であり、TDDは特定の方法論です。

私が本当にうるさくなりたいなら、xDDにはかなりのバリエーションがあることを簡単に指摘することができます-彼らの支持者が詳細に説明するのは TDDではありません -しかし、それらはまだ最初にテストに拘束されているので、それは不正です。

だから、これを言うことができます-あなたは「最初のテスト」開発を行わずに機敏になれます（スクラムの動作方法を見てください-コードの書き方についての詳細はどこにもありません）。かんばんボードを見て、あらゆる種類のアジャイル方法論を見てください。

単体テストが必要ですか？もちろん、あなたはあらゆる種類の理由で-あなたはユニットテストなしではアジャイルになれないという議論をするかもしれません（あなたができると疑いますが）-しかし、あなたはそれらを最初に書く必要はありませんアジャイル。

そして最後に、開発者の全体的な哲学に関係なく、アジャイルでなくてもテストファーストを実行できること、およびテストファーストを実行するための強い議論があることも同様に真実です。

他の（より堅実な担当者の）他の人も同様の意見を持っているようです...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin：http ://t.co/huxAP5cS TDDとOODなしでアジャイルを行うことは不可能ではありませんが、難しいです。TDDがなければ、反復率は...

（ツイート内のリンクは、LinkedInの完全な回答へのリンクです）

「アジャイルであること」とは、単にアジャイルマニフェストの価値と原則に従うことを意味します。その文書の何もTDDについて言及していませんし、それについては単体テストについても言及していません。

そのため、TDDや単体テストを行わなくてもアジャイルになれます。

私はそれをお勧めしませんが...

はい、

アジャイル値のいずれかを見てください

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

それはすでに答えるべきです。TDDは特定の方法論、プロセスです。実際、アジャイル開発プロセスで使用される可能性のあるプロセスですが、それ以上のものはありません。アジャイルであるとき、TDDはおそらく最先端のものだと思います。しかし、TDDが他のプラクティスに置き換えられたとしても、アジャイルの概念は引き続き有効だと思います。

私はそれを次のように要約します：

• 今日、TDDはアジャイルであることの事実上の標準です

• TDDなしでアジャイルになる方法があります

私は言う

いいえ[並べ替え]

元のソースに戻ると、http：//en.wikipedia.org/wiki/Extreme_Programming TDDはプロセスの基本です。テストは要件の仕様とウォーターフォールのユースケースを置き換え、生きたドキュメントや機能的な例などとして機能します。これらは不可欠です。

ただし、「アジャイル」にはさまざまなフレーバーが存在するため、それらの1つがTDDを回避することは完全に可能です

編集：質問の@Murphの解釈が好ましいもののようです。ええ、私もそれを支持しました、それは良い答えです。しかし、アジャイル宣言は一連の原則であり、開発方法論ではないという立場を維持しています。利益をもたらすプラクティスを実際に実装することなく、「ああ、そう、アジャイルだ」と言っても意味がありません。特に：

動作中のソフトウェアは、進歩の主要な尺度です。

そして

アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。

私にとって、これらの2つの原則はTDDを必要としないとしても意味します。少なくとも、TDDなしでそれらを達成する他の方法はありません。

編集2：はい、技術的には後でテストを書くことができます。しかし、私はまだテストファースト/ TDDを基本と考えています。それなしでは「アジャイル」になれないからではなく、よりアジャイルになるからです。テストファースト/テスト駆動は、テスト後/テスト後付けよりもはるかに効率的なアプローチです。テストの説明は要件です。後まで延期しないでください;-)

編集3：私は最終的にマーフの非常によく書かれた答えについて私がそんなに気にかけるものを理解しました。それは、実際にそれをしなくても「アジャイルになれる」という概念です。そして、「上に示すように」「それを行う」にはTDDが必要です。

厳密には、アジャイルマニフェストを順守することでアジャイルです。実際には、コードベースはテストカバレッジが良好でない限りアジャイルではありません。機能の開発前/実行中にTDDを実行してテストを作成するか、機能の開発後に機能のテストを作成できます。ただし、通常はTDD方式で行う方が簡単で効果的です。

機敏に対応できますが、おそらく改善の余地があります。

アジャイルの原則の1つは、変化に対応できる必要があるということです。これは、何を構築する必要があるかを事前に知らないことを意味します。ウォーターフォールプロセスに従っている場合、構築する必要があるものをxか月前に正確に把握し、個々のソフトウェアコンポーネントを設計して、それぞれがいくつかのより大きなスキームに参加し、最終製品に到達できるようにします（少なくとも、そうだった）。しかし、アジャイルは最終製品が何であるかを知らないことを指示するため、コードが何に使用されるか、さらに重要なことには、いつ変更されるかはわかりません。

したがって、コードベースが変更されても、既にビルドした機能が引き続き機能することを確認するには、徹底的なテストスイートが必要です。

しかし、それ自体はTDDではありません。コードを記述した後にテストを記述する場合、TDDではありません。しかし、TDDは別の側面で役立ち、過剰生産を防ぎます。

私自身のアジャイルチームでは、プロジェクトの後半で役立つと思われるコードを記述する開発者と格闘しています。次のxか月のプロジェクト計画で何かのサポートを追加していたので、おそらく大丈夫なウォーターフォール開発でした。

しかし、アジャイルの原則に従っている場合、このコードを書くべきではありません。それが必要かどうかわからないからです。来週に予定されていた機能は、突然無期限に延期される可能性があります。

TDDの原則に正しく従っていると、テストがこのコード行を指示するまで1行のコードは存在できません（個人的にはテストせずに些細なコードを書くことができます）。必要な機能を提供するために正確に必要なもの。

したがって、TDDは過剰生産の回避に役立ち、チームが可能な限り効果的になることを可能にします。これはまた、アジャイルの中核原則です。

稼働中のソフトウェアは、進捗状況の主要な指標です

TDD（テスト駆動開発）を行わなくてもアジャイルになれますか？

簡単な答え：はい。

より長い答え：この質問に対する非常に良い答えがたくさんあり、非常に良い参考文献があります。これらの点については議論しません。

私の経験では、アジャイルは手元のプロジェクトに適切なレベルのリーンネスを選択することです。リーンネスとはどういう意味ですか？そして、なぜ私はそれをこの答えに持ち込むのですか？

リーンとは、メソッドから可能な限りすべてを切り刻むことではありません。同僚の一人が指摘したように、行動にTDDや単体テストを含める必要はありません。しかし、あなたが自分自身を見つけるプロジェクトの文脈では、それは有益かもしれませんし、そうでないかもしれません。

AKにある大規模な名前のない小売業者のサプライチェーンについて考えてみましょう。消費者がいます。彼らは店に入ります。店舗はトラックを介してさまざまな製品を受け取ります。おそらくトラックは倉庫からそれらの製品を入手します。倉庫は、さまざまなメーカーからの出荷で満たされています。製造業者は、サプライチェーン全体を所有しています。

上記のサプライチェーンの配送担当ゼネラルマネージャーが、フリートにトラックが10台未満である場合、毎年100万ドルのボーナスを受け取ると言われた場合、どうなりますか？彼は直ちにフリートを9台のトラックに切り刻みます。この「ひどい」シナリオでは、これにより、倉庫に保管されている商品の量が増加します（そのノードのコストが増加します）。そして、それは店頭を「飢えさせる」でしょう。

そのため、全体を考慮せずにローカルな最適化を許可すると、サプライチェーン全体が損なわれます。

TDDとUTに戻ります。TDDは要件表現メカニズムです。システムはこれらの制約を実行する必要があります。けっこうだ。TDDは、ユースケースドライブ開発の要件動作またはユーザーストーリー駆動型開発の要件動作を置き換えることができます。これには、単体テストと要件の作業負荷を組み合わせる「学習」の利点があります。全体的な作業負荷が軽減されると、メリットがあります。サプライチェーン全体の作業負荷が増加した場合（品質を修正しましょう）ではありません。

そして、あなたは尋ねました：TDD（テスト駆動開発）をしなくてもアジャイルになれますか？

もちろんできます。別の、おそらくより良い質問は次のとおりです。-このプロジェクトにTDDを適用すると、ソフトウェアの配信が全体的に効率的になりますか？

お気に入りの著者を引用するには... JRR Tolkien

ロード・オブ・ザ・リング。リングのフェローシップ。94ページ「そして、それはまた言われている」とフロドは答えた、「助言のためにエルフに行かないでください。彼らはノーとイエスの両方をするでしょうから」。

したがって、最終的には...それは異なります。質問に答えなければなりません。どのパスが最も効率的に目的の目標につながるか。

TDDへ、またはTDDへ。それは問題のままです。:-)

PS-私はこの答えを別のサイトにも再投稿しています。 https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=en

城の設計との比較。

アジャイル城

アジャイルを使用して城を設計する場合。特定の機能を持つ部分を記述し、ユーザーが機能部分を使用するように促し、ユーザーの反応に合わせて将来のデザインを調整します。したがって、ダンジョンを構築し、ダンジョンキーパーと通信し、土地とダンジョンによって提供される基盤をテストします。欄干を作り、夜間警備員にそれが良いかどうか尋ねます。壁を構築し、兵士に防御値をテストさせます。あなたは台所を作り、料理人にそれを見てもらうでしょう。そして、このプロセスの間、現在の構造に加えて、これまでのすべての部分が機能します。ダンジョンを終えたら、囚人を中に入れることができます。しかし、最終的に城を完成させると、囚人が逃げたことがわかります。

TDDキャッスル

TDDを使用すると、囚人と一緒に現れ、逃げるかどうかを確認できます。その後、脱獄できないまで刑務所のセルを書きます。次に、コードをリファクタリングして不要なセルをきれいに削除し、間違った場所にあるバーを削除して、もう一度テストします。囚人は逃げませんでした。看守と通信する必要はありません。そして、すべてを終えたら、城全体を届けることができます。その時点で、刑務所はダンジョンがより多くの細胞を必要としていると言います、そして今、あなたはより多くの基礎を掘らなければなりません。

アジャイルTDDキャッスル

アジャイルとTDDを組み合わせる場合。囚人が逃げたかどうかを確認し、何が必要かを看守に尋ねてください。彼は、もっと細胞が必要だと言っています。囚人のふりをして、逃げるかどうかを確認するために、ランダムな人をつかんで行くでしょう。そうでない場合、あなたはそれを看守に見せ、彼はそれに満足しています。次に、欄干の構築を開始します。

結論

したがって、両方とも異なる問題を解決します。アジャイルは、プロセスの中で最も適応しやすい段階で製品が開発されるのを見て、ユーザーのニーズを発見することに基づいて要件を変更するのに役立ちます。設計全体から分割された安定した追加をリリースする必要があります。

TDDは、障害を予測するという問題を解決します。修正が最も簡単なプロセスのポイントで発生する障害を発見して修正します。これには、設計全体から分割された安定した分離されたコード単位のテストが含まれます。

TDDはアジャイルの拡張機能と見なすのは簡単です。どちらも同じパターン、ユニット主導の進捗、およびレビューに従うためです。違いは、アジャイルのユニットは全体として現在までに外部で機能するのに対して、TDDのユニットは一部として機能し、外部レビュー用に機能する製品を生成しない可能性があることです。そして、両方のプロセスが異なるニーズを管理します（使いやすさと正確さ）。どちらもユニット単位の開発プロセスで機能するため、TDDをより細かく分割して、両方のレビュープロセスを同様の時点で行うことができます。

ノート

• 単体テストがあるだけで、TDDを使用するわけではありません。TDDは、生産されたユニットの前にテストを行い、開発中にテストを使用してユニットを確認することを意味します。TDDを使用しないユニットテストを使用して、以前に構築した機能を無効にしないようにすることができます。
• スプリントやその他の会議を開催しても、機敏性は向上しません。マニフェストの目標により、アジャイルになります。プロセスよりも人々を支持するという約束を果たすことなく、ウォーターフォールの目標を作業単位でスプリントに分割できます。
• TDDとアジャイルの定義による。単体テストは配信不能ユニットを管理するため、TDDはアジャイルよりも高速にサイクルします。また、両方を使用する場合、アジャイルサイクルには1つ以上のTDDサイクルが含まれます（すべてのユニットをテストする場合）。
• 私が理解していることから：あなたはユーザーに成果的で意味のあるユニットを開発することに失敗することでアジャイルに失敗します。ユニットは、製品を高速化しても意味があります。しかし、アジャイルはメンテナンスを容易にするためにリファクタリングをどのように説明しますか？私はそれに答えるのに十分にそれをカバーしていません。
• ユニットテストに失敗すると、TDDに失敗します。機能を正しく生成しないコードを生成します。

アジャイルでは、繰り返しごとにスケジュールと品質のリスクに対処し、軽減する必要があります。つまり、 TDDはアジャイルと見なされる必要はありません。

ただし、TDDは、特に多数の反復または人がいるプロジェクトの場合、品質リスクを軽減するための途方もない手法です。そのようなプロジェクトでは、テストケースも作成する必要があるため、TDDは初期の反復でスケジュールリスクを追加します。ただし、TDDは品質リスクを継続的に軽減するため、後の反復で大幅なコスト削減をもたらします。すなわち、TDDが推奨されます。