快速原型如何适应敏捷方法？

12

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

我所服务的特定工程团队没有传统开发的软件（相反，我们从更鸟瞰的角度帮助推动项目），但是这种情况正在发生变化。我们有大量即将到来/计划中的软件项目，这些项目大多以数据为中心-例如，我们将进行数据监控，收集，汇总和一些报告。其他任务包括使用专用硬件和各种类型的客户端/服务器（多层）体系结构进行自动化。我将协助雇用多个人，并制定我们前进的许多计划。

我的问题是进行快速原型设计（一次性代码）是否适合敏捷哲学。例如，我喜欢Python及其广泛的软件包。我看到使用基于Python的工作流非常快地实现我们的许多想法的可能性。但是，我认为会有很多人认为Python不是“企业质量”的，并且许多工作都需要用Java或C ++重写。

但是，创建Python原型将使我们在快速实现真实结果方面付出巨大的努力。

您是否能够在企业环境中将快速原型制作（希望在Python中）整合到可靠的敏捷工作流程中？

— BobIsNotMyName
source

3

编写丢弃代码是一件危险的事情。如果可行，那么为什么业务应该“抛弃”呢？除非您不向他们展示，否则它总是会发生。即使我参加了hackathon，我也从不妥协代码的质量。我可能会在这里和那里放一些奇怪的东西-但是没有什么会“扔掉”的。进行原型制作时，应将重点放在制作良好演示的故事上。

— Dave Hillier

3

“决定使用敏捷的大公司” -“ dictates ”和“ agile”这两个词的有趣组合在某种程度上让我想起了《Half-Arsed Agile Manifesto》。个体和随流程和工具的互动......，我们有强制性的流程和工具来控制如何将这些个体（我们更喜欢用“资源”）相互作用

— 蚊蚋

11

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

有几种情况需要探讨：

原型是“空壳”，实体模型还是演示，旨在提供有关产品外观的想法？您当然可以用一个或多个故事来做到这一点-但是，您是在凭自己的想象力来构建某些东西，而不是在真实的反馈下来构建产品。人们不会像评估产品那样评估演示。例如，请参阅有关我们的最高标准原型与实际最高标准实施的反馈。
是否需要构建原型才能更好地理解问题空间？然后应将其覆盖为尖峰，并且仅保留其结果（源代码是瞬态的）。
原型是否为0.x版本？一个mininimum可行的产品？然后使用您选择的敏捷过程。如果您需要用另一种语言来重建它，那么对待其他产品可能会更好。请注意，有时这被视为一种捷径编写规范的方式（“它应该与原型一样！”）。那是记录产品的一种非常差劲的方法，但是最好将其解释为一个单独的问题：-)

— Sklivvz
source

我认为这是迄今为止最糟糕的答案，我很难理解所有这些支持来自何处。获得早期反馈的原型设计并不罕见，这是敏捷开发所固有的。

— 马丁·马特

@MartinMaat“原型”是指“交付给客户的产品的早期版本，该版本在产品中逐渐地演变”？当然，在这种情况下，您认为敏捷性的工作原理是正确的，而我提出的三点正是对它的正确解释。但是，这并不是人们想要的那样。

— Sklivvz

8

快速原型设计（即迭代和增量开发）不是敏捷的全部内容吗？

听起来您的组织存在“感知就是现实”的问题。您可能想提醒大家，敏捷不是意味着“抛出所有计划”，而不仅仅是测试驱动开发意味着“抛出所有架构”。

而且Python并不是玩具语言（如果有的话）。 NASA及其承包商使用Python，如果对他们足够好，那么对我也足够。

— 罗伯特·哈维
source

同意，Python并不是一种玩具语言...但是，我公司的许多组织都广泛使用Java，我们将需要与他们的代码进行接口，因此这是我们必须要具有强大Java背景的人员。另外，关注的不是理解软件的人的看法，而是那些不了解软件的人的看法。那些人想要一个他们以前听过的名字，那个名字叫“ Java”。我希望我们建立一个致力于将Python作为主要语言的团队，但这很难。

— BobIsNotMyName

1

即使您使用Python进行原型设计并用Java重写其中的一部分或全部，也不一定是一件坏事（Python没有某些应用程序所需的性能配置文件）。听到一种语言并不完全是一种认可。给出选择之后，我个人会选择Java以外的其他语言，但是其他因素常常会决定语言的选择。

— 罗伯特·哈维

@Robert Harvey：“快速原型设计（即迭代和增量开发）不是敏捷的全部要点吗？”：据我了解，快速原型设计意在制造一个快速的，可丢弃的原型，并且在客户之后已批准该产品，以制造真实的产品（具有适当的设计等）。在敏捷中，您需要在两者之间进行权衡：您始终拥有一个在技术上“足够好”的原型（可能不如预先设计的系统那么好，但足以用于生产），因此可以作为一个产品交付。客户满意后立即购买产品。

— Giorgio 2014年

1

@Giorgio：很好，但是客户直到您向他们展示时才知道他们想要什么，他们说“不，那不是我想要的，我想要这个。 ”无论您是用代码还是在纸上做只要对客户的需求有所识别，对我来说就没有任何区别。

— 罗伯特·哈维

2

极限编程中有一种非常成熟的实践，称为Spike。这意味着它是一次性代码。没有什么特别的。它只是一个Sprint，其预期结果是有关一次性代码的知识。

上面的链接提供了有关良好做法和峰值陷阱的足够信息。

您的特定使用案例似乎是一个很好的例子：设计界面，验证实用程序并将其显示给某些用户可能会有所帮助。

— Borjab
source

1

您将把代码扔掉而不是投入生产（这对每个人都非常清楚），因此，敏捷与否并不重要。对于原型，任何敏捷实践都是纯可选的：冲刺，燃尽，测试，结对编程或您打算使用的其他任何方法。

如果您主要要使用Python构建功能模型来帮助产品所有者和其他决策者将项目概念化，那么您不需要为企业做好准备。但是，如果要创建概念证明或试图查看是否可以处理某些性能水平，则可能应该坚持使用生产语言。这并不意味着您不能在Python中尝试它。

无论如何，您都将丢弃该代码，但是要具有使这项工作能够更好地理解所有者想要的知识的知识。现在，您可以使用所需的任何方法。

— 杰夫
source

1

我还要补充说，原型对于学习以及敏捷精神都至关重要。如果原型允许您学习，尤其是在更快的反馈周期内学习，那就去做吧。这是关于最大化学习并与团队共享学习的全部。

— 梅丽莎
source

0

在学习方面，我补充说，原型制作可以使您更快地学习。这样，您可以验证人们是否甚至在乎您要解决的问题-以及您所考虑的解决方案是否正是他们所要寻找的内容-而不会浪费大量时间来构建可能需要解决的问题的完整解决方案最后，没有解决一个痛苦的问题，或者没有解决正确的方法。

— 滕国强
source

0

敏捷的真正精神在于互动和交流。我想说，如果原型可以很好地用作帮助交流的工具，那么在敏捷世界中使用它就没有错。在我们的团队（我们从事敏捷已有5年以上的经验）中，我们会不时使用它。从中我可以看到一些好处

1）协助沟通

2）让用户参与解决方案面试并获得早期反馈

警告：

UX与工程师之间的直接通信绝不能被任何原型工件所代替。如果可能，与工程师配对比通过中介（原型）进行交流的方式要好得多。

— 惠民
source

0

其他人已经提到尖峰的学习目的。缺少的是其潜在的敏捷原则，即快速失败。

敏捷开发的支柱之一是认识困难的部分并进行概念验证，看看您是否能够做到。如果您发现无法在项目后期做某事，那么按照某种“逻辑”顺序完成所有任务的经典方法可能会变得非常昂贵。到目前为止所做的一切都可能是浪费。

如果必须以这种方式结束，您希望尽快知道。然后，利益相关者可以选择要么在不花很多钱的时候停止烧钱，要么接受他们想要的东西是不可行的，或者尝试采取根本不同的方法来解决将有新的成功机会的问题。如果您的原型达到了这个目的，那么它们确实是最敏捷的。

— 马丁·马特
source