開発や管理についてアジャイルですか？
スクラムとは何かについての議論の中で、おそらく私はアジャイルのことを完全に誤解していることがわかりました。スクラム（確かにアジャイルプロセスと見なされます）はすべて、機能、スプリント、ロールなどを管理することに関するものであり、TDD、ペアプログラミング、CI、リファクタリング、およびその他の開発者中心の手法やプラクティス（今まで）はアジャイルの中心です。今、私は困難に直面しています！
1）スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？
2）自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？
スクラムがアジャイルに等しいと考えるのはよくある間違いです。
アジャイルであることは、 アジャイル宣言 の4つの原則に従っています。スクラムはこれらの原則に一致するプロジェクト管理プロセスですが、それ自体はアジャイルではありません。 XP（TDD、ペアプログラミング）は開発プロセスであり、これらの原則とも一致し、スクラムとも一致しますが、アジャイルではありません。継続的統合、継続的デリバリー、DevOps、すべてアジャイルの原則。
何よりもまず、原則に従います。これらのバズフレーズはすべて、人々が原則に従うのを支援することに成功していることに気付いた方法論にすぎません。しかし、「アジャイルであること」の主な部分は、アジャイルの原則に従っていないプロセスを自由に調整できることです。
スクラムは、開発者がアジャイルプラクティスを行うかどうかにとらわれませんか？
スクラムは、チームがアジャイルになることを奨励する一連のガイドラインです。
自動テストを利用しないチームにスクラムを実装できますか？リファクタリングを実行しないか、アジャイルプログラミングの実践に準拠していませんか？
すべてのスプリントの終わりまでに、実用的な製品が必要になるため、非常に困難です。完全な手動回帰テストを実行して、機能していることを証明する必要がある場合、これは達成できない可能性があります。
Alistair Cockburn（アジャイル運動の創始者の1人）は次のように述べています this 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かどうかにかかわらず、気にしないでください... this trap に陥らないように注意する賢明な言葉。
開発や管理についてアジャイルですか？
アジャイルは、柔軟性と急速に変化する市場の要件、つまりいわゆる加速配信を満たすためのソフトウェア開発手法のセットです。したがって、全体像としては、小さなピースで作業を分割し、2〜4週間の迅速な反復で機能を提供することで、クライアントの複雑な要件の変化に対応する柔軟なアプローチについてです。
ただし、この柔軟性を満たすために、開発チームは アジャイルプログラミングの実践 を実践する必要があります。
アジャイルソフトウェア開発に関するWikiの説明：
アジャイルソフトウェア開発は、反復的かつ段階的な開発に基づくソフトウェア開発方法のグループであり、要件とソリューションは、自己組織化された部門横断的なチーム間のコラボレーションを通じて進化します。これは、適応型の計画、進化的な開発と提供、タイムボックス化された反復アプローチを促進し、変化への迅速で柔軟な対応を促進します。これは、開発サイクル全体で予測される相互作用を促進する概念的なフレームワークです。
スクラムは、アジャイル開発方法論の目標を達成するために特定のパターンに従うアジャイルのフレーバーです。スクラムをフォローしてアジャイルになれない、しかしアジャイルでスクラムをフォローできない。
スクラムは自動テストの使用に影響を与えません。アジャイルはそれらを支持する傾向がありますが、決して必要ではありません。リファクタリングはアジャイルとスクラムの目標であるべきですが、しばしば無視されます。これまでリファクタリングするつもりがないのは、実際には俊敏ではありません。
実際、ソフトウェア開発とはまったく関係のないプロジェクトでスクラムを使用できます。プロジェクト管理/チーム管理の方法です。