关于敏捷：为什么我应该使用功能驱动开发？

极限编程，Scrum和测试驱动开发无疑是当前最受欢迎的敏捷方法。 但是最近有人建议我看一下功能驱动开发。

您曾经成功使用过此方法吗？ 使用它的好处是什么？

---

我想将FDD视为包装方法，因为它允许您将方法应用于较高级别的项目管理，但仍允许您在较低级别使用其他方法。

FDD的重点是能够设置估计值和进度表，并报告整个项目的状态或非常细粒度的状态，但是FDD并未规定要用于创建进度表的特定方法，因此由您决定。想法是您可以确定地查看项目并声明项目状态，无论您是准时，拖延，早退等等。

我使用FDD作为将项目组织到可管理阶段的一种方式，这样我就知道何时注销并开始任何给定阶段。但是就其本身而言，FDD将毫无用处。例如，我个人将基于证据的计划和结合的BDD / TDD用作开发过程的要素，并在一种FDD框架下对其进行管理。就我个人而言，我无法完成完整的XP或SCRUMM，而不会遇到问题，因为如果我的项目和团队被迫从事其他无法为我们自己的特殊环境增加价值的方法的实践，将会受到阻碍。

无论如何，最好不要固定使用任何给定的方法，因为公司和项目的需求/条件可能会定期变化，并且如果您希望项目成功，则需要灵活地对待项目。没有任何一种方法学可以解决问题，因此诀窍在于确定适合您的方法并调整方法学以适合您的个人需求。这就是所谓的"敏捷"。

---

FDD是一种较旧的方法。它具有许多其他敏捷方法论的思想，而忽略了其中一些。像Scrum一样，它有点以管理为重点，我认为您需要XP中的一些元素才能实现实际的实现。

FDD无疑很有趣。但是，就像Scrum和XP一样，我认为您必须了解机制，而不仅仅是实现成功的实践。如果您只是"做FDD"或"做Scrum"，那么您的适应性就不如您应有的好。

如果您想了解敏捷，我会考虑的事情是

Scrum或FDD来了解什么管理可以摆脱敏捷。
XP从技术角度了解如何实现敏捷。
水晶般清晰的沟通方式。
精益敏捷对敏捷方法学有完全不同的看法

顺便说一下，我不会将TDD称为敏捷方法。这是XP的做法，但本身并不是完整的方法。

---