企业环境中的Scrum、DDD和前端开发

Question

所以，我在一家银行工作了4年。我的主要职责是网上银行。在过去的一年里，我们一直在实施scrum方法。我们也改变了领域驱动的设计。

现在，我的问题是管理层计划做什么。他们希望将网上银行团队划分为域名团队，因此在线银行团队中的一名开发人员将进入每个领域团队，从事属于域名的在线银行项目。例如，如果软件开发获得一个在在线银行中创建新贷款概述的项目，贷款团队将从数据库一直处理到UI。

我的问题是，网上银行不再是一种产品。没有办法否决任何新的特点。域名中的产品所有者只需将任何模糊的新功能转储到他们想要的在线银行。对我们的用户一直使用的核心功能进行改进也没有任何工作可做。每个项目都要做一些新的东西，一旦发布，开发人员就必须立即开始新项目的工作。没有团队合作，每个web开发人员都必须为一个单独的域处理一个单独的UI。没有硬化。

我们对管理层的建议是，网上银行团队是自己的scrum团队，专注于在线银行作为一种产品。该团队将拥有自己的scrum大师，而在线银行将有一个产品所有者。该产品所有者将与领域的产品所有者进行协调，并对在线银行中必须发生的项目进行优先排序。如果一个领域的项目比另一个领域的项目具有更高的优先级，他将向领域PO解释，我们必须首先处理高优先级的项目。

管理层没有听我们的话。

我的问题是，怎样才是正确的方法？

Answer 1

您所描述的方法通常被称为Scrums...except的Scrum，在集成方面，似乎没有团队之间的协作。如果没有这些功能，您就会冒着拥有大量特性的风险，而它们之间没有任何一致性。在用户从管理抵押贷款到检查储蓄余额的过程中，这一转变可能会引起人们的注意，也会让他们感到不快。基本上，您将得到一系列的筒仓，但这两种方法(Scrum或DDD)的好处都不多。

尽管如此，从几个段落中很难判断出为了避免这种情况，采取了哪些平衡措施。例如，如果产品负责人确实在特性和方法上定期会面和协作，那么他们很有希望将系统作为一个统一的整体来处理，而团队的分离实际上只是为了从管理的角度进行简化。

我想说，给它一个机会，你可能会发现他们知道的比他们一开始透露的更多;)

Answer 2

我目前正在阅读敏捷软件需求:团队、程序和企业的精益需求实践。在此之前，我读过几本关于敏捷/scrum的书，但我发现这本书的独特之处在于，作者采用了敏捷过程，并且远远超出了单个团队(组织中的100+)。

这本书指出，当有许多团队在同一个产品上工作时，必须有人决定这些团队是如何构建的。这两种方法是：

1. 特性团队-团队由来自产品不同层(DB、Web、业务逻辑等)的成员组成。整个团队都在研究一个单一的功能。
2. 组件团队-团队由所有在单一层上工作的成员组成。在许多不同的特性共享相同组件的情况下，这个团队尤其受欢迎。为了确保代码保持一致，您不希望20个不同的人一遍又一遍地修改相同的代码库。

作者指出，只要有可能，组织就应该倾向于特性团队，因为当你有一个团队在一个完整的特性上工作时，每个人都支持交付最终用户的价值。如果您只有组件团队，则每个团队都有执行本地优化的风险，这可能会以牺牲特性本身为代价。此外，由于组件团队只看到部分特性，所以现在需要系统级集成/QA团队来组装组件。

看来，您的管理层正在采取的方法是让每个人都成为一个特性团队的一部分。然而，正如书中所指出的那样，这个决定绝不应该是白纸黑字的。最后，大多数组织应该在特性和组件团队之间进行某种组合，并以这样一种方式构建它们，使两者的利益最大化。这需要平衡，而且有许多因素会将平衡转移到一个或另一个方面(例如，缺乏全面的单元测试将使其转向组件团队)。

话虽如此，我认为您的管理层正走在与许多其他公司一样的道路上，这些公司试图采用敏捷，但却不幸地失败了。我是这样说的：

Management hasn't listened to us.

传统方法有相当大的开销，当传统公司转向敏捷时，他们引入了更多敏捷过程的开销，而不放弃传统的做事方式。敏捷的基石，以及真正让它运转起来的是，你有参与的，自我思考的团队成员。最后，唯一可行的方法是，如果团队决定特性或组件团队更适合，而管理层只是根据团队的建议行事。否则，你为什么要努力去交付任何东西，或者比最低限度更努力的工作呢?在你看来，管理层已经通过命令做出一个你认为是错误的决定而让你陷入失败。

Answer 3

领域驱动的设计有一些有趣的信息，关于如何识别和处理正在出现的团队协作模式。您可能需要查看有关上下文映射的部分。

...But --您描述的场景更多地与一些组织反模式有关: DDD要求实现总体愿景，并在不同的环境中实现不同团队之间可持续的协作方式。同时，Scrum将在团队之间建立一个协调级别(正如上面所说的，使用Scrum的Scrum)以及POs之间的协调级别。如果产品负责人之间没有共同的愿景(无论是由“超级产品负责人”实现的，还是通过PO之间的密切协作实现的)，那么您很可能会交付一个没有远见的产品。

有趣的是，对将愿景应用于复杂产品感兴趣的其他角色通常是信息架构师和交互设计师，他们在您描述的情况下似乎遇到了困难(但这在银行业并不少见)。最好的人选是企业架构师，他们应该可以在银行业中找到。