对于前端和后端，进程应该如何不同？

Question

我正在寻找可能有助于解释我在软件工程中看到的关于前端和后端开发过程的参考资料。两者都是困难的，但我倾向于觉得前端更容易为之写故事，并且可能会估计付出的努力(时间)。

这可能有很多原因:沙箱技术(js，css，html)，视觉方面使它能够自己进行主题/分组/模块化等等，用户与UI交互，过程工件往往被称为“用户”故事，这意味着流程想要捕获一个完全可见的目标，并通过前端提高生活质量。

而后端则相反:没有典型的UI，而且数据差异很大，以提供操作的细节(日志、度量、部署等)。是的，前端的数据也可以不同。用户几乎总是要么是开发人员，要么是支持者，但这些人很少签署或“接受”这些故事，他们很少是实施的利益相关者，更不用说控制实施的预算了。而且，似乎没有任何概念或完整的后端工具集，如js、css、html是用于前端的，因此也没有兼容层。

考虑到这一点，我希望理解在前端和后端使用相同的软件开发流程是否有意义？是的，有任何一个系统的用户和工作需要发生，但最大的区别隐藏在上面的描述是，前端故事是经过一些视觉设计，而在后端的设计与任务分解为后端。

也许，就像一般情况一样，这是我个人经历中的一种偏见？其他方法肯定会存在，特别是基于项目规模和范围等。我只是在寻找更多的见解。对于前端和后端，进程应该如何不同？

Answer 1

用户几乎总是一个dev ...，但这些人很少签署或“接受”这些故事。

您在这里按了一个个人热点按钮:开发人员不应该是用户故事中的参与者(除非您正在开发像Tensorflow之类的框架)。您为涉众开发产品，而不是为开发人员开发。我经常看到这样的故事：“作为一个开发人员，我希望代码有单元测试”--但这不是一个用户故事，因为用户故事的形式是“作为一个X，我想要Y这样的Z”。根据我的经验，一旦你写了"Z“，你就不得不考虑你为什么要做这项工作，以及它是为谁而做的。

在这里，“支持”是一个混合的情况--我已经看到了一些实际不是故事的案例(“作为一个支持工程师，我希望系统登录到CloudWatch”--这是支持工程师实际上并不关心的实现细节)，但实际上是用户故事--例如，“作为一个支持工程师，我希望能够通过客户ID过滤日志，这样我就可以更容易地找到造成客户错误的原因”。然而，对于第二个例子，请注意，它既不是前端故事，也不是后端故事，而是产品的故事。

对于前端和后端，进程应该如何不同？

不应该。或者换个说法--你不应该用这种方式来划分你的过程。写出你的故事，这样它们就能反映出你对产品的需求。

Answer 2

我们在我的工作场所使用SAFe，它有一个单独的类别，名为使能器，用于捕获非直接用户可见的工作。我们还尝试将团队组织成可以被赋予一个特性的团队，并在团队内部同时完成前端和后端的任务。我说“试过了”，因为随着时间的推移，这些专业只是进行了一些改革。

话虽如此，我坚信，如果您的流程不是每个团队的不同之处，那么您可能并没有真正做到敏捷。不仅前端团队的工作方式与后端团队有些不同，而且后端团队的工作方式至少应该略有不同。

如果用户故事格式对您的环境没有帮助，您应该在回顾中讨论，并尝试一些新的东西。如果你觉得你没有从你的实际利益相关者那里得到正确的反馈，你应该在回顾中谈论它，并尝试一些新的东西。如果你觉得你不明白你的作品最终是如何被最终用户使用的，你应该在回顾中谈论它，并尝试一些新的东西。

像scrum这样的框架是为了给您一个起点。不管他们为你工作得有多好，他们都不是被虔诚地遵循的规则。