我一直使用敏捷的功能驱动开发流程来开发软件。其他人都使用什么，为什么我们喜欢它？我更喜欢FDD，因为那是我刚大学毕业时就开始的。在大学里，一切都是非常自由的形式，我的"客户"通常是我的教授，除了为大学做研究以外，他可能没有太多的行业经验。

现在，我的客户不再那么宽容，我在医疗领域做了很多工作。必须具有敏捷性和高水平的素质！

解决方案

测试驱动设计TDD

知道代码更改并未破坏某些细微之处，我们将充满信心

我选择敏捷Scrum，这给了我与团队联系的感觉。并且对里程碑和个人任务有很好的控制。早晨的混乱非常有用。我们在团队系统http://www.scrumforteamsystem.com/en/default.aspx中使用Agile Scrum项目模板

编码并修复！

只是开个玩笑，TDD确实是一个绝妙的选择。

我赞成敏捷。这些天我正在探索精益，但是像任何开发过程一样，这不是我们可以加入当前团队的东西。但是，精益和敏捷的某些功能可以简化到我们当前的流程中并立即获得价值。

我以前的项目使用了Waterfall方法，并为此感到自豪。从那以后，他们就断断续续地脱离了瀑布，转而使用原型，这是一个很好的步骤。

结合XP工程实践的敏捷开发方法：

• TDD与重构
• YAGNI(我们将不需要它)
• 吻(保持简单愚蠢)
• 重构设计模式
• 使用开关对进行配对编程
• 共享代码库
• 尽早并经常部署

无论当前项目需要什么。

我在自己的时间里为各种(主要是基于PHP的)Web开发人员进行了大量咨询。我还没有花时间去为那些项目使用TDD，而且其中许多正在使用现有的框架，这些框架并没有真正使TDD变得如此简单。

在工作中，我们还没有开发TDD的工具，因此我们使用了敏捷和旧式基于规范的流程的混合体。试图迈向TDD，但是我们是一家小商店，拥有牢固的现有项目(许多维护工作)以及与ERP系统的集成工作。我认为我可以让TDD继续进行自己的集成工作(并朝着这个方向迈出了一步)，但其他因素在很大程度上是一个失败的原因。

合同设计，带有单元测试的补充

这里似乎有些混乱：

TDD的重点在于如何实现代码，而不是管理软件项目的整体开发。 TDD不会决定要安排哪些功能，何时交付或者如何设置优先级。

相反，诸如精益/敏捷甚至瀑布之类的问题与这些更高级别的问题有关。 (我的投票是肯定会落入精益/敏捷领域的Scrum。)

XP(极限编程)很有趣，因为它融合了这两个方面的思想。

我为一家同时进行Web和系统开发的公司工作。我们的发展模式是快速发展。我们使用了更现代的定义，因此它类似于敏捷开发。没有XP的概念。

我们也使用scrum ...我认为单口站立在某些方面可能会很好，但有时快速的15分钟变成至少30分钟。

我想我是老学校。我发展到客户规格。充满活力的设计阶段，然后是精简的开发，测试，错误修复周期。然后，实施。

规范一旦定义并获得同意，便无法进行进一步的更改。所有更改都将等待开发和错误修复完成。这可以防止范围蠕变，并允许对软件进行编写，测试，调试和实施。那时，更改变成了增强功能，新功能等。

我发现过去10年中几乎所有客户都认为，在开发过程中"扔进"(创建范围蠕变)的大约90％的东西被认为是不必要的。我不能告诉你有多少客户感谢我阻止他们。因此，我不知道我们将使用什么流程，但这对我和我认识的许多其他开发人员都有效。

在工作中，我们使用ICONIX流程。
它是AGILE技术的子集，它是行为要求驱动的。 ICONIX流程的目标是尽可能减少庆祝活动，并尽可能减少文档，以使我们可以轻松地使它保持最新(这与其他AGILE流程有很大不同，例如，XP从业人员通常不会似乎在第一稿声称其代码就是文档之后才更新文档)。

这是该过程的实用概述：

• 功能需求快速起草
• 快速定义领域模型
• 在先前步骤的基础上对用例进行建模
• 可选-为每个用例绘制一个一次性的鲁棒性图表，只是为了了解类之间的关系
• 为每个用例绘制序列图
• 在用例上对测试用例进行建模
• 实行
• 测试

在每个步骤中，我们都将整体上回顾工作，以更新域模型(不可能一次正确完成)并在用例中添加注释。在步骤5)结束时，如果重构或者更改任何内容，我们将获得易于准备的类和逻辑，只需很少的文档即可维护：

• 用例图
• 每个用例的序列图
• 测试用例图(或者测试计划)

如果需要添加功能，则添加一个新的用例并遵循整个过程。

资源：

Iconix流程网站

Iconix软件工程网站

书籍参考：

使用ICONIX流程进行AGILE开发

我是精益软件开发的粉丝，该软件是由Poppendiecks推动的，主要基于精益生产的原理，而丰田则是其典型。与其他敏捷方法有很多共通之处，重点是消除浪费，利用排队论和"及时"思想(例如，在最后一个负责任时刻指定一个故事)。

精益通常与看板相关，看板是通过管道跟踪任务的一种方法。

我们在工作的地方使用瀑布式设计，但是在我努力推动一些工作之后，我们正在为一些新项目向敏捷/ TDD / CI混合模型迈进。愿上帝保佑，我们将能够抛弃瀑布方法。我们所做的每个维护版本，我们的主要客户都会忽略要求的最后期限，而在最后一秒钟立即将需求变更交给我们，然后茫然地盯着我们，同时我们解释了为什么他们不能继续这样做。

在过去的几年中，我个人倾向于精益开发，这对我从XP中学到的一切都具有深远的影响。我认为在这里需要指出的是，Scrum作为开发过程是不够的，因为它没有通知软件开发工作，而是通知了管理软件开发任务流程的工作。我的想法也得到了ICONIX的支持。我认为这是一种解决用例和图表驱动环境的好方法，而不会陷入适得其反的官僚机构。