如果你曾经参与过与多个团队一起开发一个产品，你就会知道这有多棘手. 竞争的想法和不同的优先事项并不总是一帆风顺.
The good thing is, 总有解决方案和好习惯来克服像这样扩展项目所带来的各种挑战. 以下是你可能遇到的一些挑战，以及我遇到这些挑战时学到的教训和经历.
Navigating silos and low morale
你在这类工作中遇到的第一个挑战是建立一个真正统一的团队. 我最常看到的情况是，没有让所有人聚在一起确定共同目标的预先计划会议. 当你很快发现自己没有一个工作积压时，这种孤立的工作感就会变得很明显(稍后会详细介绍)。. 在你意识到之前，整个团队都感到了压力，现在士气低落.
Siloed working is like eating the same food every day. 每天吃披萨一开始可能听起来很棒，但过了一段时间就会变得无聊. It’s the same with work. 如果你有一个很长的项目，而人们在同一件事情上工作了很长时间——总是看到和收到同样的问题——你会让整个团队士气低落.
Before you know it, each team is working in an isolated fashion. So how do we fix this? 是时候让每个小组的代表参加团队会议了. 通过这种方式，他们可以了解每个人的工作流程，并将信息反馈给他们的团队. 为每个人的工作提供一个可见的空间，让人们有机会与同事交谈，并决定谁最适合承担某些任务. I’ve also seen this space encourage teams to support one another, 通常是有机发生的——建立必不可少的团队士气.
Conflicting product backlogs
在竖井中工作也意味着每个团队都有自己的待办事项，没有可见性，你经常不知道其他人在做什么. 由于缺乏监督，你很容易失去为你的单一产品而努力的实际目标.
So the easiest thing to do is get everything onto one backlog. Then let’s share the backlog with everyone. 让我们对待办事项进行优先排序，不是每个团队，而是团队的团队. 让Scrum Master成为不同团队的产品负责人是至关重要的. They’ll be the person who can help you prioritise, 而不是对不同的群体有冲突的优先级.
从那里你可以一起决定你想要在几周内完成的目标. What’s that one thing you want to accomplish? 好的，为了完成这个，我们需要什么关键的结果? What are the essential outcomes of the things we need to do? That’s how to get started.
Help! There’s too many dependencies
Each team has areas they specialise in. 因此，如果工作过于依赖于一个特定的团队，那么你就会开始看到队列增长并导致延迟. On the other side of the coin, if you don’t have any work to be done on the user interface, for example, 那支球队会非常闲散——这对任何人都没有好处.
现在，系统的某些部分通常比其他部分需要更多的TLC. And that means there’s always people in higher demand. 但如果那个团队有人在度假，这意味着你的交付能力 really slows down. And then your growing queue of tasks gets even longer.
但重要的是要记住，总有工作要做. If you’ve been facing multiple challenges in your product so far, it’s worth thinking about refactoring and solving technical debt. 专注于此意味着您不仅要在技术上改进软件，还要为用户解决问题.
如果你也实施了我们之前提到的团队会议(眨眼)，那么更多的可见性意味着优先级可以转移和调整——真正地传达了敏捷宣言. In my experience, 我看到过，当你以这种方式打破竖井时，团队合作的效率会高得多. 团队之间相互交流，每个人都了解其他能力. 经常会有合作来确保每个人都清楚谁承担了什么任务, so nobody feels the pressure.
Techniques, habits and communication
Scaling agile practices can be tricky, 特别是当你在项目中引入比以往更多的团队时. 当致力于一款产品时，需要平衡许多优先级，并经常面临相互冲突的挑战. 但我真的相信，如果您从敏捷技术的武器库中汲取经验, 建立良好的习惯和强大的沟通，你可以创建一个统一的团队，提供有效的产品.
通过这篇文章分享我的学习，我知道总有教训可以学习，总有经验可以借鉴. 我很高兴能继续在Made Tech的项目中练习扩展敏捷，并建立我自己的技巧和诀窍.
如果您想了解更多全球最大的博彩平台项目交付的信息，请注册 Made Tech Insights 让新的博客文章和其他内容直接发送到您的收件箱.
