为什么我应该使用功能驱动开发?

发布于 2024-07-04 06:18:22 字数 1473 浏览 6 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

很酷不放纵 2024-07-11 06:18:23

我喜欢将 FDD 视为一种包装方法,因为它允许您应用一种方法来管理非常高级别的项目,但它仍然允许您在较低级别使用其他方法。

FDD 的重点是能够设置估算和进度表,并报告整个项目或在非常细粒度的级别上的状态,但它没有规定用于创建进度表的具体方法,从而使由您决定。 这个想法是,你可以查看你的项目,并确定地说明项目状态是什么,是否准时、延误、提前等等。

我使用 FDD 作为将我的项目组织为可管理阶段的方法,以便我知道何时结束并开始任何给定阶段。 但就其本身而言,FDD 毫无用处。 例如,我个人使用基于证据的调度和组合的 BDD/TDD 作为在 FDD 保护伞下管理的开发流程的元素。 就我个人而言,我无法在不遇到问题的情况下完成完整的 XP 或 SCRUMM,因为如果我的项目和团队被迫采用其他方法论的实践,而这些方法论不会为我们自己的独特环境增加价值,那么他们就会受到阻碍。

无论如何,最好不要拘泥于任何给定的方法,因为公司和项目的需求/条件可能会定期发生变化,如果您希望项目取得成功,您需要灵活地管理项目。 没有单一的方法是灵丹妙药,因此关键是确定哪种方法适合您并调整您的方法以满足您的个人需求。 这就是“敏捷”的根本含义。

FDD is what I like to think of as a wrapper methodology, in that it allows you to apply a method to manage projects at a very high level, but it still allows you to use other methodologies at a lower level.

FDD's focus is on being able to set estimates and schedules and to report on the status of a project as a whole, or at a very granular level, but it doesn't prescribe a specific method to apply in order to create the schedule, leaving that up to you to decide. The idea is that you can look at your project and state with some certainty what the project status is, whether you are on time, slipping, early and so on.

I use FDD as a means to organise my projects into manageable stages, so that I know WHEN to sign off and commence any given stage. But by itself, FDD would be pretty useless. For example, I personally use Evidence Based Scheduling and a combined BDD/TDD as elements of a development processes that are managed under a kind of FDD umbrella. Personally, I couldn't do the full XP, or SCRUMM without running into problems because my projects and team would be hindered if they were forced to engage in practices from other methodologies that don't add value to our own unique circumstances.

In any case, it is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. No single methodology is a silver bullet, so the trick is to determine which methods work for you and tune your methodology to suit your individual needs. This is what being "Agile" is fundamentally about.

傲娇萝莉攻 2024-07-11 06:18:23

FDD 是一种较旧的方法。 它有很多其他敏捷方法的想法,但也遗漏了其中一些。 与 Scrum 一样,它有点注重管理,我认为您需要 XP 中的一些元素来进行实际实施。

FDD 确实值得研究。 但就像 Scrum 和 XP 一样,我认为您必须了解其机制,而不仅仅是实施实践才能取得成功。 如果你只是“做 FDD”或“做 Scrum”,那么你就没有达到应有的适应性。

如果你想了解敏捷,我会研究

Scrum 或 FDD,以了解管理可以从敏捷中获得什么。
XP 从技术角度理解如何实现敏捷。
非常清楚地了解通信方面。
精益敏捷以获得对敏捷方法论的完全不同的视角

顺便说一句,我不会将 TDD 称为敏捷方法论。 这是 XP 的一种实践,但本身并不是完整的方法。

FDD is an older methodology. It has lot's of the ideas of other agile methodologies and misses some of them. Like Scrum it's a bit management-focussed and I think you need some elements from XP for practical implementations.

FDD is certainly interesting to look into. But just like Scrum and XP I think you have to understand the mechanics and not just implement the practices to be succesful. If you just "do FDD" or "do Scrum" you're not as adaptive as you should be.

The things I would look into if you want to understand agile would be

Scrum or FDD to understand what management can get out of agile.
XP to understand how enable agile from a technology perspective.
Crystal Clear to understand the communications aspects.
Lean Agile to get a completely different perspective on agile methodologies

I wouldn't call TDD an agile methodology by the way. It's an practice from XP but not a complete methodology per se.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文