アジャイル実践を最も多く取り入れているコミュニティ (言語/フレームワーク) はどれですか?[閉まっている]

Question

私は数年間 TDD と (一部の) XP を実践してきましたが、それを導入する前の私のキャリアで抱えていた問題の多くが TDD によって解決されることがわかりました。多くの頭痛の種が解消されたことで、コーディングに対する私の愛情が再び蘇りました。問題は、これらのプラクティスを利用している .NET (私の現在のスタック) プロジェクトを見つけるのが難しいことです。

SO コミュニティに対する私の質問は次のとおりです。tdd、(実際にはすべての xDD) xp、ci などのアジャイル実践を最も受け入れているコミュニティ (言語および/またはフレームワーク) はどれだと思いますか?

この質問をするには、測定手段を定義する必要があります。特定のコミュニティ/スタックに対して次のように定義します。

(アジャイル手法を採用している現在のプロジェクトの数) / (現在のプロジェクトの数)

明らかに、おそらく存在しないデータがなければ、これを判断することは不可能です...私は人々の認識を探しているだけです

Answer 1

私はRailsとDjangoのキャンプの両方でつま先を持っています。私が見るところでは、Railsの人々が実際にテストを取得します。彼らは会議でのテストの話を、ブログでのテストについて話すと、自分のアプリの非Railsの部品をテストするために、いくつかの興味深いテストツール（例えば、ScrewUnit）をスピンオフ。これは、Railsのコミュニティではなく、テストの一部であることが本当に難しいます。

Djangoのコミュニティは、テスト前に遅れています。 Djangoのテストのための基本的なサポートに付属していますが、それを見ています。現在のDjangoの本のどれも脚注をテスト与えるよりもはるかにしない、と私はめったにDjangoのコミュニティメンバーからのブログ「をテストする方法を」任意の実質的なを参照してくださいません。最初DjangoConでの試験には何の協議はありませんでした。

フリップ側では、人々は遠くmonkeypatchingと宝石のバージョンの競合（または競合するmonkeypatchingをやって宝石やプラグイン）は、そのテストの自動化が不可欠であるために台無し会費の中に自分自身を取得する可能性が高いレール。私が見てきたDjangoのプロジェクトは、それが同じトラブルに自分自身を取得するのは難しいですのでによって滑ることができました。

他のアジャイルプラクティスとしては、それは日常的に多くのプロジェクトの中を覗き見できずに言うのは難しいのです。

Answer 2

コミュニティとは実際には何なのか、これが人々に関するものである場合、ここにいくつかのグループがあります。

アジャイルプロジェクトリーダーシップネットワーク その名前には、アジャイル アプローチを採用しているという意味が込められています。

オルタナティブネット このグループは、さまざまなアジャイル プラクティスを取り入れて、さまざまな結果を得ることができるグループだと思います。それを好む人もいれば、それに問題を抱えている人もいるかもしれません。

ただし、アジャイルは通常、特定のテクノロジーではなくプロセスに重点を置いています。あなたの質問が、アジャイルを使用している企業がどのようなテクノロジーやフレームワークを採用しているかということであれば、それは私の考えでは価値が疑わしいまったく別のワックスボールです。私の近くのアルバータ州カルガリーにあるアジャイルを採用する企業は、他の企業とは大きく異なる可能性があります。インドのバンガロールまたはイギリスのロンドンにある企業は何ですか？シリコンバレー、ニューヨーク州ニューヨーク市、ワシントン州シアトルなど、開発者が働いている場所をいくつか挙げます。通常、次のような企業を意味する場合は除きます。 思考回路 大都市の近くにオフィスがある場合は、アジャイルを実行します。

別の考え方としては、一部のテクノロジーにはさまざまなサブコミュニティやサイズがあり、それが状況を混乱させる可能性があることを考慮することもできます。たとえば、Java および .Net 開発者の中には、アジャイルを支持する人も、それを嫌う人も多くいると思われます。ウォーターフォール手法がうまく機能している企業がある場合、なぜアジャイルに切り替える必要があるのでしょうか?同時に、一部のテクノロジーには非常に小さなコミュニティが存在するため、まったく異なる観点から見られる場合があります。それが気になる場合は、これらの新しく出現したテクノロジを使用する人々がどの程度よく組織化されているかということも考慮する必要があります。

誰かがこのブレインダンプを興味深いと思ってくれれば幸いです...;)

Answer 3

私は、これらのワークフローが特定の言語に結び付けられているとは思いませんし、どの言語も必ずしもこれらのワークフローに適しているとは思いません。これからの逸脱は主に文化的なものです。

たとえば、正規の Rails プロジェクト スケルトンは、テストの作成や TDD の使用に対する障壁が非常に低いですが、NUnit を取得して TDD .NET プロジェクトを作成することを妨げるものはありません。

研究に興味があるかもしれないいくつかの .NET ツールを次に示します。

単体テスト:

• NUnit

継続的インテグレーション：

• チームシティ
• クルーズコントロール

Answer 4

私のやや限られた経験から、私は、Ruby /レールコミュニティがテストのカッティングエッジを推進していることを発見しました。新しい技術を導入し、一般的にほとんどの事にTDDとBDDの概念を統合します。一方、PHPはやや行き当たりばったりです。いくつかのグループには、宗教や他の一見全くそれを使用しています。それはルビー＆RailsのコミュニティであるとしてPHPでのツールセットは、堅牢かつ深いとは思えない。

YMMVます。