扩展和拆分构建Web应用程序的敏捷团队的最佳方法是什么？

我最近加入了一家公司，在该公司担任Scrum主管，从事构建Web应用程序的敏捷开发项目。

该团队即将成为敏捷团队的最大规模（预计下周为9人）。我们已经讨论过将团队分成两个团队的潜在问题，不是为了缩短站立时间（目前还不过分），而是为了防止人们在sprint计划会议中完全感到无聊（这又不会太长）。

该项目有两个截然不同的层-高技术后端开发人员（例如非常复杂的开发人员）和UI设计/构建/集成。看来，当后端人员正在讨论技术时，UI人员会划分区域，反之亦然。如果只是为了提高时间效率，将团队拆分似乎是合乎逻辑的方法，但是我有一个很大的保留意见，就是我可能真正要做的就是减少协作和知识共享。这两个团队对团队其余成员的构建并没有真正的好主意。

有没有人有处理这样的事情的经验？

不幸的是，UI员工并不关心复杂的后端工作的细节。这听起来更像是回顾性讨论的话题。按照纪律划分团队将开创一个危险的先例，即要求人员开始进行分区而不关心UI团队正在做什么并要求自己的团队要花多长时间。

我一直都支持团队中的垂直切面。UI应该倾听技术人员的意见，因为他们是可以帮助简化工作的人员（哦，该小部件将导致您执行此操作，如果我们改用此小部件会怎样）。

我个人将首先关注UI人员的分区问题，然后在解决功能障碍后，讨论如何最好地拆分团队。我不是要侮辱UI专家，也许技术人员也可以做更多的事情，以使他们的讨论与UI专家更相关。

正如其他人所说，应该允许团队自我组织以确定新的结构。过去的经验告诉我，只有当每个人都关心团队时，自我组织才能真正起作用，而不是他们自己的纪律或利益。

干杯!

将团队的各个独立部分分成新的团队确实是一个好主意。在较大的项目中，开发人员几乎不可能完全熟悉整个项目，因此拆分仍然是正式或非正式的。

每个新团队都应该有一个团队负责人/技术经理，他们对团队的范围有扎实的知识，并且也熟悉其他团队的工作。

之后，每个团队可以召开单独的Scrum会议，其他团队的领导也可以出席。这样，您将减少“无聊”人员的数量，但团队仍将知道其他人在做什么，并且能够成功地进行协作。

如果团队的范围是交叉的，或者一个团队依赖另一个团队，则协作将变得更加重要。但是同样也不需要整个团队参加_团队负责人可以协调协作。

Scrum的一个关键方面是自组织。

我建议您与团队讨论该问题，然后让他们解决。

您的担心都是有充分根据的，但是请记住，作为Scrum Master，您的工作是指导和帮助。因此，请问他们如何解决这些问题。他们将拥有解决方案，并使之发挥作用。

我要补充一点：总的来说，跨职能团队是必经之路。

在拆分团队时，我总是试图记住一个事实，即团队需要能够为客户提供价值。在您的情况下，团队中将同时拥有后端和前端开发人员。

1. 前端到后端有多远？可以预见，仅当距离太远时，拆分才是一个好建议。

   • 如果后端谈论数据库架构，那还不算太远。前端和后端都需要收听有关数据库架构的讨论。

   • 如果后端谈论分片，内存缓存，磁盘延迟等，那么这有点太过分了（后端侧重于机械同情和优化，而前端侧重于人类的审美观）。

2. 前端和后端之间是否有稳定且明确的编程接口？

   • 稳定而明确的意思是，该编程接口的用户（前端开发人员）不会因更改而陷入困境，也无需阅读文本墙即可学习如何正确使用它。

   • 后端团队需要及早提供一个良好的API和一个模拟实现，然后才能开始真正的开发。

   • 这并不是说API应该一成不变。这只是减轻将团队分成两部分的后果。

3. 为什么这么多敏捷文章建议使用垂直切片？以下是一些背景信息：

   • 从成本的角度来看，大多数敏捷文章实际上建议避免进行后端工作。

   • 同样不要忘记，敏捷文章的一小部分对初创公司具有隐性偏见。

   • 并且不要忘记行销的严酷现实-大多数客户只为前端付费。

   • 后端工作往往成本高昂且回报缓慢。除非已经建立了长期的公司并产生可观的利润，否则最好通过坚持使用现成的技术和开源库来“外包”后端。

   • 大多数敏捷文章还建议实现前端，以便它可以在后端切换中幸免。该建议与前一个建议紧密结合：如果现有技术不能满足所有要求，请尝试另一个。

4. 可以减轻团队分裂带来的不良后果的实践

   • 稳定的后端
   • 稳定的API
   • 低缺陷率后端
     • 原因：避免沮丧
     • 如何：单元测试
     • 并不意味着：性能或优化；它只需要功能上正确即可。
   • 持续集成
   • 沟通，进度和决策方面的透明度
   • 鼓励两个团队进行非正式讨论
   • 鼓励团队成员（不进行分区的人员）参加另一个团队的会议。
   • 设置不定期的联席会议和联合回顾
   • 其他团队建设活动

像其他人一样，我绝对建议您使用垂直切片。这些有时被称为“功能团队”。我建议阅读Scaled Agile Framework网站上的优点/缺点：http : //scaledagileframework.com/scaled-agile-framework/team/features-components/

最初，当您拆分时，您的产品负责人和SDF管理员可能能够处理两个团队的发布待办事项以及每个功能团队的待办事项。但是，随着您的成长，您可能需要实施积压的产品功能，然后将其提供给多个敏捷团队发布积压的产品。一旦扩展到该级别，您可能需要一个单独的团队来管理功能积压，然后将这些功能交付给各个团队进行实施。在这种结构中，您可能会遇到以下情况：

1. 敏捷团队1： SM，PO，跨职能团队。有自己的团队积压的故事。
2. 敏捷团队2： SM，PO，跨职能团队。有自己的团队积压的故事。
3. 程序管理团队：产品经理，发布经理，企业架构师。拥有自己的程序清单，这些清单具有较高级别的史诗和功能，将对其进行组织，分析，然后反馈给团队。

在安全的网站具有组织大型团队很多很酷的东西，当你移动到球队，强队的规模更大一些可能对你有帮助。