大型公司通常会对适应性和可操作性问题感到不安。 更确切地说，几乎是因为两者都不存在。
想象一下：所有平台团队都在忙于一项功能，并且企业迫切需要做其他事情或调整已经开发的功能。 此时，一项功能的工作停止了，而另一项功能的工作开始了。 在下一个时刻，来自业务的新需求出现，并且功能仍未完成。 开发人员得罪了，业务遭受了损失。
这是另一种情况：API正在更改，您需要紧急运行到后端部门以查找详细信息，然后返回到前端（iOS / Android / Web）。 此外，在与正面讨论您的更正之后，您需要回到背面讲我们的要求。 这太累了，浪费了团队，个人开发人员和所有感兴趣的人的神经。
我叫Valery，我们的团队从事iOS版QIWI电子钱包。 但是始终必须与其他团队保持沟通，否则将导致完全不同步。 对于我们的不便之处，我们的业务始终在向前发展，并为试验提供了自由。 因此，出现了改变现有结构的问题。 Scrum是测试我们的变革创意的有利环境。 每两周，我们在平台内部可以对课程进行编辑，以便至少在某种程度上与其他团队进行协调。 测试理论花了很长时间。 从一个月到六个月。 我们尝试了哪些选项：
特色
团队中的一个人被任命负责下一个冲刺的功能。 这个人将自己的一部分时间花在了设计师身上，并且使用了其他前线团队的功能（后勤人员决定不使用功能提供者），弄清了即将进行的工作的陷阱和微妙之处，他同意与后端的合同约定。 他还监视了后端和业务的所有更改。 而且一切似乎都很好。 除了这个人承受着多变的环境的打击之外，没有人会惊慌失措。 每个人都安抚了片刻。
但是幸福一直持续到OUNER的特征在他冲刺之前生病为止。 安抚的整个幻想都消失了，我们回到了开始的地方。
一般修饰
邀请了不同平台的代表来培训一个平台团队。 情况有所好转，但这些家伙（从字面上说）根本不喜欢连续参加几次会议。 但是主要原因是API和合同的可变性，冲刺目标的变化，如果仅在冲刺的第一天进行更改，那就很好了。 但是通常都是一样，变化在整个两周内都下降了。 底线-目标没有实现，伙计们正在处理，企业正在遭受苦难。
聊天室
非标准选项之一是创建聊天。 为每个功能创建了一个单独的聊天室。 此外，还设有讨论问题的团队聊天室。 以及针对所有团队所在问题的一般性聊天。 起初，问题似乎已解决。
但是聊天很快就成倍增加，而且，这已经成为一种负担。 当出现问题时，在配置文件部分的聊天中，或者在重构网络客户端或替换用户信息模块时的聊天中，都不知道在哪里寻找信息。 结果，它变得更加混乱。 我再次不得不在部门之间奔跑。
功能时间
然后一家杂货店来到了，并提供尝试功能-tima格式的功能。 这意味着什么：从每个平台（iOS，Android，Web，后端）和两个测试人员中选出两名开发人员，然后组成一个新团队。
除了发布的一致性和发布速度之外，这种方法还应该解决几个主要问题：
自治权一起参加会议的团队尽可能彼此独立。 外部依赖项的主要链接是产品。
快速理论测试毕竟，在整个钱包团队都执行一些新功能之前，这种非常酷的功能并未进入用户。 事实证明，整个开发过程都看到了不必要的东西，预算也没有了。
整个团队都了解什么是“产品开发”实现功能或满足业务需求，开发人员并不总是了解为什么，为什么以及谁需要它。
整个团队都会影响产品。 直到发明新功能结果，每个人都喜欢这种方法，目前我们有3个独立的团队从事他们的产品任务。 现在，在更改合同时，您无需四处走动并寻找负责任的部门，也无需进行一堆令人困惑的聊天，只需戳开附近的开发人员即可。 会议将举行所有特色会议，所有平台和质量检查人员的代表将立即出席。
问题可以在几分钟之内用语言解决，没有人会遭受同样的痛苦。 此外，对企业来说，另一个巨大的好处是，如果该功能无法吸引用户，则只会花费团队中的一个功能（目前只有三个），而不是像以前那样花费整个开发时间。
结果，我们设法实现了以下优势：
- 其他团队的自主权。
- 最大程度的灵活开发，如果软件需要，我们可以安全地更改路线。
- 快速轻松地解决问题。
- 功能理论的快速测试。
我希望这个例子可以帮助您解决团队之间的沟通问题。 如果您还有其他不错的选择，那么我正在等待反馈。
谢谢啦
而且我们很快就会为iOS开发人员带来一番
热潮 。