你使用什么软件开发过程？

Question

我一直使用敏捷Feature Driven Development进程来开发软件。其他人使用什么，为什么你喜欢它？我更喜欢FDD，因为那是我从大学毕业后开始的。在大学里，一切都是非常自由的形式，而我的“客户”通常是我的教授，除了为大学做研究之外，他可能没有太多的行业经验。

现在，我的客户不那么宽容，我在医疗领域做了很多工作。敏捷和高质量是必须的！

Answer 1

在工作中我们使用ICONIX流程。 它是AGILE技术的一个子集，它是行为需求驱动的。 ICONIX流程旨在尽可能少地庆祝，尽可能少的文档 - 为了让您轻松保持最新（这与其他AGILE流程有很大不同，例如XP从业者经常做在第一稿草案声明他们的代码 文档之后，似乎没有保持文档的最新状态。

以下是该过程的实用概述：

1. 功能性快速草案 要求
2. 快速定义 域模型
3. 模型用例 前面步骤的基础
4. 可选 - 为每次使用绘制一次丢失稳健性图表 只是为了理解关系 在你的班级之间
5. 画一个 每个用例的序列图
6. 为用例建模测试用例
7. 实施
8. 测试

在每一步中，您都会检查您的工作整体更新您的域模型（第一次无法正确使用）并在您的用例中添加注释。在步骤5）结束时，如果您重新考虑或更改任何内容，最终只需要很少的文档即可实现即将实现的类和逻辑：

• 用例图
• 每个用例的序列图
• 测试用例图（或测试计划）

如果您需要添加功能，请添加新的用例并按照整个过程进行操作。

资源：

Iconix process website

Iconix Software Engineering website

图书参考：

AGILE Development with ICONIX Process

Answer 2

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

• TDD加上重构
• YAGNI（你不需要它）
• KISS（保持简单愚蠢）
• 重构设计模式
• 使用切换对进行编程
• 共享代码库
• 早期部署

Answer 3

无论当前项目需要什么。

我为自己的各种（主要是基于PHP的）Web开发人员做了很多咨询。我还没有花时间去参加这些项目的TDD，其中许多人正在使用现有的框架，这些框架并没有真正让TDD变得那么容易。

在工作中我们还没有为TDD加工，所以我们使用敏捷和旧式基于规范的流程的混合。试图转向TDD，但我们是一家小店，拥有根深蒂固的现有项目（大量维护工作）以及与ERP系统的集成工作。我想我可以让TDD继续我自己的集成工作（并且正朝着那个方向迈出宝宝的步伐），但其他的东西在很大程度上是一个失败的原因。

Answer 4

我选择敏捷Scrum ，这让我感觉'与团队有关。并且能够很好地控制里程碑和个人创造力.Morning scrums非常有用。我们使用Agile Scrum project template in Team System http://www.scrumforteamsystem.com/en/default.aspx

Answer 5

这里似乎有些混乱：

TDD更多的是关于如何实现代码，而不是关于管理软件项目的整体开发。 TDD不会帮助您确定要安排哪些功能，何时交付或如何设置优先级。

相比之下，像精益/敏捷甚至瀑布这样的问题都是关于这些更高层次的问题。 （我的投票是针对Scrum，它坚定地落入精益/敏捷领域。）

XP（极限编程）很有意思，因为它融合了这两个方面的想法。

Answer 6

我猜我上学了。我发展到客户规范。一个充满活力的设计阶段，然后是一个低调的开发，测试，错误修复周期。然后，实施。

一旦定义并同意规范，就不会发生进一步的变化。所有更改都是等待开发和错误修复完成。这可以防止范围蠕变，并允许软件编写，测试，调试和实现。此时，更改将成为增强功能，新功能等。

我发现，对于过去10年来我的几乎所有客户来说，他们在开发过程中“投入”大约90％的东西，创造范围蔓延，被认为是没有必要的。我不能告诉你有多少客户感谢我阻止他们。所以我不知道你会称之为什么过程，但它适用于我和我认识的许多其他开发人员。

Answer 7

我是Lean Software development的粉丝，由Poppendiecks推广，主要基于精益生产的原则，以丰田为榜样。它与其他敏捷方法有很多共同之处，重点是消除浪费，利用排队理论，以及“及时”思维模式（例如在最后负责的时刻指定一个故事）。

精益通常与Kanban相关联，{{3}}是一种通过管道跟踪任务的方法。

Answer 8

按合同设计并进行单元测试补充

Answer 9

我们在工作中使用瀑布，但经过一些推动，我们正朝着一些新项目的敏捷/ TDD / CI混合模式迈进。上帝愿意，我们将能够抛弃瀑布方法。我们做的每一个维护版本，我们的主要客户都会忽略reqs的最后期限，并在最后一秒向我们提出需求变更，然后只是茫然地盯着我们，同时我们解释为什么他们不能继续这样做。

Answer 10

Code and Fix !!

开玩笑，TDD真的是一个很好的方式。

Answer 11

测试驱动设计TDD

你知道代码更改没有破坏某些微妙的东西所带来的信心是很好的

Answer 12

我对Agile投了第二票。这些天我正在探索精益，但与任何开发过程一样，这不是你可以直接进入当前组的东西。但是，精益和敏捷的功能可以放宽到您当前的流程中并立即获得价值。

我以前的项目使用了瀑布方法，并以此为荣。他们已经脱离了瀑布和Prototype，这是一个很好的一步。

Answer 13

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

Answer 14

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

Answer 15

我过去几年的个人倾向一直倾向于精益发展，对我从XP中学到的一切都有着沉重的影响。我认为重要的是要注意Scrum不足以作为开发过程，因为它不会为软件开发工作提供信息，而是试图管理软件开发任务流程的工作。 ICONIX也告知了我的想法。我认为这是一种很好的方式来处理用例和图表驱动的环境，而不会陷入适得其反的官僚主义。