快速原型是如何融入敏捷方法的？

Question

我在一家大公司工作，这决定了敏捷过程的使用。例如，对于我们的项目，我们使用专门用于管理敏捷开发的基于云的服务。

我工作的具体工程小组传统上并没有开发软件(相反，我们帮助从更多的角度来推动项目)，但这种情况正在改变。我们有大量即将到来的/计划中的软件项目，主要是以数据为中心的--例如，我们将进行数据监控、收集、聚合和一些报告。其他任务包括具有专用硬件和各种类型的客户机/服务器(多层)体系结构的自动化。我将协助雇用几个人，并制定我们的许多计划，以向前迈进。

我的问题是，快速原型开发(丢弃代码)是否符合敏捷哲学。例如，我喜欢Python及其广泛的包。我看到了用基于Python的工作流非常快地实现我们的许多想法的可能性。然而，我认为会有很多人认为Python不是“企业质量”，因此大部分工作都需要用Java或者C++重写。

然而，创建Python原型将给我们带来巨大的好处，使我们能够快速地交付真正的结果。

您是否能够在企业环境中将快速原型(希望是Python中的快速原型)集成到一个可靠的敏捷工作流中？

Answer 1

“原型化”，如RAD中的意图的概念对于敏捷开发来说有点陌生。这并不意味着它不能完成，但这是不寻常的。

有不同的情况需要探讨：

1. 原型是一个“空壳”、一个模拟或一个演示，是用来给出一个产品外观的想法吗？你当然可以用一个或多个故事来做--然而，你是在用自己的想象力来构建一些东西，而不是用真实的反馈来构建一个产品。人们不像评估产品那样评估演示。例如，请参阅有关我们的顶杆原型和实际顶条实现的反馈。
2. 为了更好地理解问题空间，需要建立原型吗？然后，它应该作为一个尖峰来覆盖，并且只保留它的结果(源代码是暂时的)。
3. 原型是0.x版吗？一个迷你活产品？然后使用您选择的敏捷过程。如果您需要用另一种语言重新构建它，那么如果您将该产品视为另一种产品，您可能会更好。请注意，有时这被视为编写规范的一种快捷方式(“它应该与原型一样！”)。这是一种非常糟糕的记录产品的方法，但这可能更好地解释为单独的问题和答案：

Answer 2

快速原型 (即迭代和增量开发)难道不是敏捷的全部要点吗？

听起来你对组织中的“感知就是现实”有异议。您可能需要提醒每个人，敏捷并不意味着“放弃所有计划”，就像测试驱动的开发意味着“抛弃所有架构”一样。

Python不是一种玩具语言(如果它曾经是)。美国宇航局及其承包商使用Python，如果对他们来说足够好的话，对我来说就足够了。

Answer 3

在极端编程中有一种相当牢固的做法叫做尖峰。这意味着它是丢弃的代码。里面没有什么特别的东西。它只是一个Sprint，在这个Sprint中，预期的结果是关于丢弃代码的知识。

上面的链接有足够的信息，关于良好的做法，陷阱的尖峰。

您的具体使用案例似乎是一个很好的例子:它可以帮助设计接口，验证实用程序并向某些用户展示它。