いくつかの場所では、機能駆動開発(FDD)はアジャイル手法と呼ばれています。 FDDのWikipediaエントリ 。
しかし、一般に、FDDと見なされるには、次の要件を満たす必要があるようです。
裏側では、アジャイルは
どちらのコンセプトの理解にも問題がありますか?
このリンクで詳細を説明するかもしれません。 FDDはアジャイル宣言の前に来たので、常に練習する必要があるとは限りませんXPまたはアジャイルになるためにスクラムまたはだれもずっと前からその利点を考慮していませんでした。
「その主な目的は、有形で機能するソフトウェアをタイムリーに繰り返し提供することです。」
アジャイルであることの全体的なポイントではありませんか?BDDと同様に、FDDはすべてのプロジェクトに適しているわけではありません。あなたは地球上で最大のUML嫌悪者かもしれませんが、少数のプロジェクトがある場合は、管理が容易なプロジェクトがある可能性があります。
特定の方法論によって解決された理由/問題を見てください。あるタイプのプロジェクトでアジャイルであることを支援するものは、特にドキュメントや契約などに依存しない方法がそれらを完全に除外することであると考える場合、別のタイプのプロジェクトを妨げることがあります。
間違っているのはあなたのアジャイルの定義です。 アジャイルは重要です
- プロセスとツールに関する個人と相互作用
- 包括的なドキュメントに対応する実用的なソフトウェア
- 契約交渉を介した顧客のコラボレーション
- 計画の転換への対応
つまり、右側のアイテムには価値があるが、左側のアイテムにはさらに価値がある。
特定のポイントを取るために...
UMLはオプションのツールです
はい。ほとんどはアジャイルになるときです。タスクボードはアジャイル方法論であるスクラムでは必須ですが、アジャイルであることは必須ではありません。
テストはドキュメントテストは必須です
これはTDDポリシーです。 TDDはアジャイル手法の1つですが、アジャイルであることの必須の部分ではありません。
リファクタリングは顧客の変更の結果であり、お勧めできません。
FDDでもお勧めできないと思います。また、明確に述べられていません。アジャイル宣言は、リファクタリングについても明示的に言及していません。
アジャイルは 原則のセット であり、方法論のセットではありません。アジャイル方法論は、これらの原則を奨励する方法論です。
FDDがアジャイルではない方法は見当たらない。
ええと、私はFDDの専門家ではありませんが、Wikipediaの記事についての私の考えを次に示します。
色付きのUMLを使用する必要があります(ただし、ドキュメントは必要ありません)。
この記事では、ドメインモデルを開発する必要があると述べています。これは、UMLが必要であるという意味ではありません。あなたのチームは、どの種類のモデリング言語がタスクに適しているかを判断できると思います。
ペアプログラミングの代わりに、チームはソフトウェア機能によって分割されます
一部のアジャイルプロセスはペアプログラミング(XP)を必要とし、他は必要としないため、これはFDDがアジャイルでないことの証明にはなりません。
リファクタリングは推奨されないか、少なくとも、明示的なスコープを持つタスクではありません。
本当に落胆しているとは思いません。しかし、私はあなたが正しいと思います、新しい機能の上に新しい機能を重ねるのではなく、ソフトウェアを進化させる部分(既存の製品に変更を適用すること)は、プロセス全体で無視されるようです。これはもちろん、非アジャイルプロセスの兆候です。
ユニットテストは任意であり、チームリーダーが決定できます。
現在のプロジェクトのニーズに合わせたプロセスのように聞こえます。これは間違いなく俊敏です。
ワークフローは5つのFDDフェーズを通過する必要があります
これはcouldがアジャイルでないことを示しています。
要約すると、FDDはいくつかのアジャイルなもの(small機能の反復的な開発など)をいくつかの非アジャイルなもの(段階を伴う正式なプロセス)と組み合わせようとしているように見えます。必要に応じて、セミアジャイルと呼んでください。また、FDD beeing Agileと呼ばれている同じWikipediaの記事は、免責事項「この記事は参照やソースを引用していません...」から始まっていることに注意してください。