スクラムとは何かについての議論で、アジャイルのことを完全に誤解しているのかもしれません。スクラム（確かにアジャイルプロセスと見なされます）は、TDD、ペアプログラミング、CI、リファクタリング、その他の開発者中心のテクニックやプラクティス（今まで）アジャイルの心臓部です。今、私は困難に直面しています！
1）スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？
2）自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？
回答:
スクラムがアジャイルに等しいと考えるのはよくある間違いです。
アジャイルであることは、アジャイル宣言の 4つの原則に従っています。スクラムはこれらの原則に一致するプロジェクト管理プロセスですが、それ自体はアジャイルではありません。XP（TDD、ペアプログラミング）は開発プロセスであり、これらの原則にも一致し、スクラムにも一致しますが、アジャイルではありません。継続的インテグレーション、継続的デリバリー、DevOps、すべてがアジャイルの原則と一致しています。
何よりもまず、原則に従います。これらのバズフレーズはすべて、人々が原則に従うのを手助けすることに成功していることに気付いた方法論にすぎません。しかし、「アジャイルであること」の主な部分は、アジャイルの原則に従っていないプロセスを自由に調整できることです。
スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？
スクラムは、チームがアジャイルになることを奨励する一連のガイドラインです。
自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？
すべてのスプリントの終わりまでに、実用的な製品が必要になるため、非常に困難です。完全な手動回帰テストを実行して、機能していることを証明する必要がある場合、これは達成できない可能性があります。
Alistair Cockburn（アジャイル運動の創始者の1人）は、 Crystal Clear（彼のアジャイル方法論の1つの側面）についてこれを述べています。
Crystal Clearは、レベル3のリスナーに次の言葉で説明できます。
「ワークステーションとホワイトボードを備えた部屋に4〜6人を配置し、ユーザーにアクセスできるようにします。1〜2か月ごとに実行中のテスト済みソフトウェアをユーザーに提供し、それ以外の場合はそのままにしておきます。」
それは、アジャイルの定義であり、確かに彼らが何をしているかを知っていて、それに乗り込んでそれを行うと信頼できる経験豊富な開発スタッフにとっては明らかです。それでは、CIとTDD、ペアプログラミングなど、流行のすべてのものを使用する必要があるということですか。簡単に言えば...いいえ。
アジャイルは、一連のプロセスに従うことではなく、効果的であることです。それがあなたにとって何を意味するかは、あなたのチームとそれがどのように機能するか、あなたがあなたにとって何が役に立つかによって異なります。TDDが動作するコードの作成に役立たない場合は、WebでTDDが叫ぶあまり使われていないライトを聞くのをやめて、使用しないでください！ペアプログラミングが本当にチームが集中して仕事を遂行するのに役立つ場合は、時間の無駄だと言っている人を無視して、学校の運動会での3足レースのようにチームを編成します。
私は何年も前にアジャイルを行いましたが、アジャイルを行っていることにさえ気づいていなかったため、毎月製品の反復を提供し、定期的にバグの修正と新機能の追加を繰り返しました。そのようなものが発明されておらず、リファクタリングの本が書かれていないため、私たちは絶対にユニットテストを行いませんでした。つまり、いわゆるアジャイルの実践がなくても、アジャイルを実行できます。
アリステアはまた、ケントベックのこれを言います：
XPとSoftware Engineering Instituteの「能力成熟度モデル」の5つのレベルについて尋ねたところ、XPの3つの成熟度レベルについて回答しました。
書かれているようにすべてを行います。
それを行った後、ルールのバリエーションを試してください。
最終的には、XPを実行しているかどうかは気にしません。
最終的に、XPを実行しているかどうかは気にしないでください... この罠に陥らないように注意する賢い言葉。
開発や管理についてアジャイルですか？
アジャイルは、柔軟性と急速に変化する市場の要件、いわゆる加速デリバリーを満たすための一連のソフトウェア開発手法です。つまり、全体像としては、小さなピースで作業を分割し、2〜4週間の迅速な反復で機能を提供することにより、クライアントの複雑な要件の変化に対応するための柔軟なアプローチについてです。
ただし、この柔軟性を満たすために、開発チームはアジャイルプログラミングの実践を実践する必要があります。
アジャイルソフトウェア開発に関するWikiの説明：
アジャイルソフトウェア開発は、反復的かつ段階的な開発に基づくソフトウェア開発手法のグループであり、要件とソリューションは、自己組織化された部門横断的なチーム間のコラボレーションを通じて進化します。これは、適応型の計画、進化的な開発と提供、タイムボックス化された反復アプローチを促進し、変化への迅速で柔軟な対応を促進します。これは、開発サイクル全体で予測される相互作用を促進する概念的なフレームワークです。
1）いいえ!!!! スクラムはアジャイルです。つまり、アジャイル開発プラクティス（TDD、ペアプログラミング、CI、リファクタリングなど）は、スクラムプロジェクトのすべての面で非常に重要です。これらのプラクティスを使用していない場合、チームの実行率の把握、作業の見積もり、適切なスプリントサイズの設定などは、はるかに難しくなります。
2）ええ、アジャイルプラクティスに準拠していないチームにスクラムを実装できますが、チームの可能性を本当に制限しているように感じます。スクラム/アジャイルが非常に成功する理由の大部分は、すべてのスプリントで完全な機能を前面から背面に提供するための中核となるアジャイル開発プラクティスから得られるパフォーマンスと品質の向上です。
グループの他の誰かがアジャイル開発プラクティスは時間の無駄だと納得させようとしている場合、これらのプラクティスが常にアジャイル全体と同様に常にスクラムで強調されている理由を強調するために少し時間を費やす必要があると思います。彼らは本当に違いを生むのです。