后端开发者被用户故事所压倒

我计划将后端开发垂直切入用户故事。但是我们团队的一个后端家伙开始抱怨这使他们的工作变得无形。

我的答案是

• 在冲刺计划和审查会议上，我们在利益相关者面前讨论了后端任务，以便使其可见，并且

• 在项目过程中保持高质量将导致启动速度比其他团队慢，但是在项目过程中我们的速度将保持稳定。利益相关者非常清楚地看到速度。

他仍然坚持有这样的故事：“作为开发人员，我需要一个域层，以便我可以封装业务逻辑。”

在污染团队之前，我该如何解决？

问题的根源在于，我们的管理人员系统地将后端工作视为无形的工作，并召集了受支持的开发人员矿工或其他贬义术语。

所描述的情况有一些问题，显而易见的问题是缺乏对后端开发人员的尊重。由于这个问题被标记为敏捷，因此我将继续提出其他答案，表明这只是一个社会问题。您的故事中有几种难闻的气味和可能的反样式，这些都与无知的管理甚至您如何分割故事无关。

团队中的一群人因没有从工作中获得荣耀而感到轻微的事实完成了一些可能出现的问题。

• 不应有只做后端开发的人。 通用的敏捷方法是让跨职能的团队由实践通用代码所有权的概括专家组成。个人不应只专注于后端或前端开发，尽管他们一定会比其他人更有经验或在某些方面更好。
• 建筑无法赚钱。 从用户的角度-唯一真正重要的角度-拥有层或领域语言，甚至解决方案已编程也没关系。唯一重要的是您是否为用户创造了价值。后端开发人员提议的“故事”是胡说八道-它是设计决策的摘要，从用户/客户的角度来看，这些决策并不能实现所需的功能。换句话说，任何给定的用户故事都可以通过许多不同的体系结构设计来实现。用户故事可能完全不修改后端就可以完成。这不会使它成为无效的故事。
• 系统思考仍然至关重要。 虽然架构可能无法获得价值，但对于成功而言仍然至关重要。后端开发人员有一些合理的担忧。您应该考虑如何构建系统。您应该将这些决定写下来。即使只有前端功能才是所有荣耀的东西，整个系统也很重要。

我的建议是将建筑视为头等公民，但要以正确的方式做。执行与利益相关者的质量属性车间。让关键的利益相关者参与架构审查，或者至少在重要的里程碑上总结必要的设计决策。在大纸上画出架构并将其可见，以便整个团队都能看到。

要求每个人都在系统中的任何地方（前端和后端）进行开发，如果需要，请对程序进行配对，以便可以有效地进行此操作。继续创建以用户为中心的用户故事。而且还要确定关键的质量属性方案，这些方案说明了为什么按原样设计系统并推动有关“后端”设计的决策。提升架构设计，使其不再隐身。

这似乎是一个社会问题，因此将需要一个社会解决方案。

如果（据我所知，您）后端开发人员感到被忽视和轻视，并且认为他们的工作不够重视，那么开发过程就无济于事。

如果我理解正确，我看起来开发人员会觉得他们至少应该拥有自己的“用户”故事，因此他们可以指向他们并说：“这就是我们所做的，只是我们后端的人”。但是，将这样的故事“水平”切片是一个坏主意，我同意您将其垂直切片。

最好的解决方案可能是与有问题的开发人员（单独或作为一个小组）进行静悄悄的交谈，并解决潜在的问题，这似乎是值得尊重的问题之一。在某个时候，这可能需要升级到管理。

问题的根源在于，我们的管理人员系统地将后端工作视为无形的工作，并召集了受支持的开发人员矿工或其他贬义术语。

确实，这就是问题所在。显然，您不会用故事解决问题！

一般来说，敏捷开发的特征之一就是透明度。这也意味着它使您的组织问题更加明显。

解决此问题的标准敏捷解决方案是采用更“垂直”或“全栈”的开发方法，在这种方法中，后端开发人员从上到下地讲故事，而不是简单地在后端层的舒适区域内工作，并且前端开发人员同样会向后端扩展（*）。

换句话说：让每个人都为您的最终用户创造价值。

^{（*）注意：并非所有故事都需要具有前端组件或后端组件。无需重新进行后端工作即可重新组合UI元素，而性能是其一项功能。}

您的问题是：

• 您在业务中没有任何目的的管理层。Scrum，敏捷，我不在乎。应该将管理和开发与业务问题隔离开来，产品经理应具有有关技术的@@ inging线索。也许它对史蒂夫·乔布斯（Steve Jobs）有用，但是我从来没有遇到过这样一种情况，即非技术熟练的经理接近开发人员是健康的事情，或者最终有助于生产团队可以制造的最优质的产品。

• 您的开发人员更担心外观而不是解决问题。那要么是一个非常严重的文化问题（似乎可能是整个“矿工”现象的总和），要么是开发人员的质量问题，由于缺乏信心，这也不会令我震惊。

让那些不需要在那里的人摆脱计划和站立的姿势。任何人认为后端的重要性不如前端重要的人就是不需要在那里的人，实际上是在那里阻碍了流程。

沟渠的故事。是的，我很认真。如果它们引起了这类问题，请把它们扔掉。在我目前的工作中，我们只是针对给定任务坚持“完成”标准，通常它比应用程序的用户更专注于应用程序，这可能会冒犯那些认为敏捷（不断变化20年来一直在变）的人。如果您不遵循这封信，那就行不通，但实际上，如果我们是专家，我们不需要任何会给我们造成麻烦的事物。弄皱他们，把他们抛在肩膀上。

您可能想提醒开发人员，他们真正需要担心的人是他们的直接同事，而不是那些太笨拙而无法进行冲刺计划的人。