Den*_*lly 7 agile feature-driven
极限编程,Scrum和测试驱动开发肯定是目前最流行的敏捷方法.但有人最近建议我看看功能驱动开发.
你有没有成功使用过这种方法？使用它有什么好处？
我喜欢将FDD视为一种包装方法,因为它允许您应用一种方法来管理非常高级别的项目,但它仍然允许您在较低级别使用其他方法.
FDD的重点是能够设定估计和时间表并报告整个项目的状态,或者在非常精细的层面上报告,但它没有规定应用的具体方法来创建时间表,离开由你来决定.这个想法是你可以看看你的项目,并确定项目状态是什么,你是按时,滑倒,早期等等.
我使用FDD作为将项目组织成可管理阶段的手段,以便我知道何时签署并开始任何特定阶段.但就其本身而言,FDD将毫无用处.例如,我个人使用基于证据的调度和组合的BDD/TDD作为在一种FDD保护伞下管理的开发过程的元素.就个人而言,我无法完成整个XP或SCRUMM而不会遇到问题,因为如果他们被迫参与其他不会增加我们自身独特环境价值的方法,我的项目和团队就会受到阻碍.
在任何情况下,最好不要注意任何给定的方法,因为公司和项目的需求/条件可能会定期更改,并且如果您希望它们成功,您需要灵活处理项目的管理方式.没有一种方法是灵丹妙药,因此诀窍在于确定哪种方法适合您并调整您的方法以满足您的个人需求.这就是"敏捷"从根本上讲是什么.
FDD 是一种较旧的方法。它有很多其他敏捷方法的想法，但也遗漏了其中一些。与 Scrum 一样，它有点注重管理，我认为您需要 XP 中的一些元素来进行实际实施。
FDD 确实值得研究。但就像 Scrum 和 XP 一样，我认为您必须了解其机制，而不仅仅是实施实践才能取得成功。如果你只是“做 FDD”或“做 Scrum”，那么你就没有达到应有的适应性。
如果你想了解敏捷，我会研究的事情是
Scrum 或 FDD 了解管理层可以从敏捷中获得什么。
XP 从技术角度理解如何实现敏捷。
水晶般清晰地了解通信方面。
精益敏捷可以获得对敏捷方法的完全不同的视角
顺便说一句，我不会将 TDD 称为敏捷方法。这是 XP 的实践，但本身并不是完整的方法。