我一直使用敏捷的功能驱动开发流程来开发软件。其他人都用什么，你为什么喜欢它？我更喜欢 FDD，因为那是我刚从大学毕业时开始的。在大学里，一切都非常自由，我的“客户”通常是我的教授，除了为大学做研究之外，他可能没有太多的行业经验。
现在，我的客户不那么宽容了，我在医疗领域做了很多工作。敏捷和高质量是必须的！
MaTT
问问题
1903 次
15 回答
10
在工作中，我们使用 ICONIX 流程。它是敏捷技术的一个子集，并且是行为需求驱动的。ICONIX 流程的目标是尽可能少地使用尽可能少的文档 - 以便让您轻松保持最新（这与其他 AGILE 流程有很大不同，例如 XP 从业者经常这样做在第一稿声称他们的代码是文档之后，似乎没有保持文档是最新的）。
以下是该过程的实际概述：
- 功能需求速写
- 领域模型的快速定义
- 在前面步骤的基础上建模用例
- 可选 - 为每个用例绘制一个一次性的健壮性图，以了解您的类之间的关系
- 为每个用例绘制序列图
- 在用例上为您的测试用例建模
- 实施
- 测试
在每个步骤中，您都会从整体上回顾您的工作，更新您的领域模型（不可能第一次就正确）并为您的用例添加评论。到第 5 步结束时，您将获得准备好实现的类和逻辑，如果您重构或更改任何内容，只需维护很少的文档：
- 用例图
- 每个用例的序列图
- 测试用例图（或测试计划）
如果您需要添加功能，请添加新用例并遵循整个过程。
资源：
书籍参考：
于 2008-09-24T09:39:45.480 回答
4
结合 XP 工程实践的敏捷开发方法：
- TDD 与重构相结合
- YAGNI（你不需要它）
- KISS（保持简单愚蠢）
- 重构设计模式
- 使用开关对进行配对编程
- 共享代码库
- 尽早并经常部署
于 2008-09-23T15:58:14.643 回答
4
无论当前项目需要什么。
我利用自己的时间为各种（主要是基于 PHP 的）Web 开发提供了很多咨询。我还没有为这些项目投入时间来了解 TDD，而且他们中的许多人都在使用现有的框架，这些框架并没有真正让 TDD 变得那么容易。
在工作中，我们还没有为 TDD 提供工具，因此我们使用了敏捷和旧式基于规范的流程的混合体。试图向 TDD 迈进，但我们是一家小商店，拥有根深蒂固的现有项目（大量维护工作）以及与 ERP 系统的集成工作。我认为我可以让 TDD 继续我自己的集成工作（并且正在朝那个方向迈出一小步），但其他事情在很大程度上是一个失败的原因。
于 2008-09-23T15:59:51.970 回答
3
我选择敏捷 Scrum，它让我感觉“与团队紧密相连”。并且对里程碑和个人任务有很好的控制。早上的 scrums 非常有用。我们在 Team System 中使用敏捷 Scrum 项目模板 http://www.scrumforteamsystem.com/en/default.aspx
于 2008-09-23T15:49:11.123 回答
3
这里似乎有些混乱：
TDD 更多的是关于如何实现代码，而不是关于管理软件项目的整体开发。TDD 不会帮助您决定要安排哪些功能、何时交付或如何设置优先级。
相比之下，精益/敏捷甚至瀑布之类的事情都是关于这些更高层次的问题。（我的投票是坚定地属于精益/敏捷领域的 Scrum。）
XP（极限编程）很有趣，因为它融合了这两个领域的想法。
于 2008-09-23T16:07:41.187 回答
3
我想我是老派。我根据客户规范开发。一个充满活力的设计阶段，然后是一个低调的开发、测试、错误修复周期。然后，实施。
一旦规范被定义和同意，就不会发生进一步的变化。所有更改都将等待开发和错误修复完成。这可以防止范围蔓延，并允许软件被编写、测试、调试和实施。在这一点上，变化变成了增强、新功能等。
我发现，在过去 10 年中，几乎所有客户都认为他们在开发过程中“投入”的东西中约有 90% 被认为是不必要的。我无法告诉你有多少客户感谢我阻止他们。所以我不知道你会称之为什么过程，但它适用于我和我认识的许多其他开发人员。
于 2008-09-23T16:20:10.220 回答
2
按合同设计并补充单元测试
于 2008-09-23T16:05:58.603 回答
2
我们在我工作的地方使用瀑布，但经过我的一些推动，我们正在为我们的一些新项目更多地转向敏捷/TDD/CI 混合模型。上帝保佑，我们将能够放弃瀑布方法。我们所做的每个维护版本，我们的主要客户只是忽略了请求的最后期限，并在最后一秒将需求更改交给我们，然后在我们解释为什么他们不能继续这样做时，只是茫然地盯着我们。
于 2008-09-24T14:05:04.407 回答
0
测试驱动设计 TDD
知道代码更改并没有破坏一些微妙的东西，您会获得很大的信心
于 2008-09-23T15:47:16.603 回答
0
我支持敏捷的投票。这些天我正在探索精益，但就像任何开发过程一样，这不是你可以直接加入当前团队的东西。但是，精益和敏捷的某些功能可以轻松融入您当前的流程并获得立竿见影的价值。
我以前的项目使用了瀑布方法并为此感到自豪。从那以后，他们放弃了 Waterfall 并转而使用 Prototype，这是一个很好的步骤。
于 2008-09-23T15:56:50.417 回答
0
我在一家同时进行网络和系统开发的公司工作。我们的发展模式是快速发展。我们使用更现代的定义，因此它类似于敏捷开发。没有 XP 的概念。
于 2008-09-23T16:10:06.750 回答
0
我们也使用 scrum……我认为站立会议在某些方面可能很好，但有时快速的 15 分钟至少会变成 30 分钟。
于 2008-09-23T16:10:14.270 回答
0
在过去的几年里，我个人倾向于精益开发，这对我从 XP 中学到的一切都有很大的影响。我认为这里需要注意的是，Scrum 作为一个开发过程是不够的，因为它没有通知软件开发的工作，而是试图管理软件开发任务流的工作。ICONIX 也启发了我的想法。我认为这是处理用例和图表驱动环境的好方法，而不会陷入适得其反的官僚主义。
于 2010-08-05T23:38:35.307 回答