什么是最好的方式来扩展和分裂一个敏捷的团队建立一个网络应用程序？

Question

最近，我加入了一家公司，在那里我在一个敏捷开发项目中担任scrum大师，构建一个web应用程序。

该团队即将成为敏捷团队的最大规模(预计下周将达到9)。我们已经讨论过将团队分成两个团队的可能性，这并不是为了缩短僵持时间(目前这并不是过度的)，而是为了防止人们在短跑计划过程中感到完全无聊(这也不是太长)。

这个项目有两个非常不同的层--高技术后端开发(比如非常复杂的)和UI设计/构建/集成。看起来，当后端的人在谈论技术时，UI家伙就会退出，反之亦然。这似乎是分裂团队的逻辑方式，如果只是为了更有效的时间，但我有一个巨大的保留，因为我可能真正做的是减少协作和知识共享。这两支球队对其他球队正在建设的东西并不了解。

有人有处理这种事情的经验吗？

Answer 1

不幸的是，UI用户并不关心复杂后端工作的细节。这听起来更像是一个回顾性的讨论主题。将团队按照纪律划分将是一个危险的先例，在需求人员开始分区之前多久才会开始，而不关心UI人员正在做什么并要求他们自己的团队。

我一直支持为我的团队做垂直分割。UI应该听取技术人员的意见，因为他们正是能够帮助他们简化工作的人(哦，这个小部件将导致您这样做，如果我们使用这个小部件怎么办)。

就我个人而言，我会首先关注UI人员的分区问题，然后，一旦功能障碍得到解决，讨论如何最好地拆分团队。我并不是想诋毁UI人员，也许技术人员也可以做更多的工作，使他们的讨论更适合UI人员。

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

干杯!

Answer 2

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

每一个新的团队都应该有一个团队领导/技术经理，他对团队的范围有很好的了解，并且对其他团队的工作也很熟悉。

在此之后，每个团队可以举行单独的scrum会议，其他团队的领导人也可以出席。这样你就可以减少“无聊”的人的数量，但是团队仍然会知道其他人在做什么，并且能够成功地合作。

如果团队的范围是相交的，或者一个团队依赖于另一个团队，协作就变得更加重要。但是，不需要整个团队都在场--组长可以协调协作。

Answer 3

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