分布式开发。MS-1（Wargaming）经验
如何在移动开发工作室MS-1（Wargaming）进行分布式项目工作——World of Tanks Blitz的程序经理瓦迪姆·吉尔瓦尔格在App2Top.ru的专栏中进行了介绍。
坦克世界：闪击战
关于我
我叫瓦迪姆。在工作室，我负责开发团队的组成、招聘以及项目经理的发展，帮助项目中的团队领导成长。总体来说，我负责项目内部的所有流程部分，以及项目的实施方式。
瓦迪姆·吉尔瓦尔格
在加入MS-1之前，我专注于休闲游戏，并曾在一家外包公司工作，开发满足客户需求的项目（移动应用、网站等）。我最初以项目经理和Scrum大师的身份加入World of Tanks Blitz团队，在这里我参与了坦克的伪装、游戏模式、游戏内活动及其他功能的开发。
关于团队
目前，MS-1工作室有超过360名员工。我们正在开发World of Tanks Blitz和移动舰舰在线动作游戏World of Warships Blitz。此外，目前我们还在开发两款基于Unreal Engine引擎的项目，属于射击和动作类型。
我们的团队分布在五个办公室——明斯克、莫斯科（这里主要进行移动《坦克》开发）、上海（这里负责World of Warships Blitz）、柏林，最近我们在维尔纽斯开设了一个新办公室，主要开发新项目。
路标作为活工具
那么，分布式开发。在疫情之前，我们已经尝试了一些实践并将其引入到我们的工作中。
我们的团队没有制定和批准详细的路标，盲目地在一年内遵循。我们的路标是一个活的工具，可以每天发生变化。我们实践敏捷方法，认为在快速发展的行业中进行一年的规划至少是不可行的：这会导致大量机会的错失和对市场变化的反应不及时。这也不提供对推出的某些功能的正面或负面反馈的灵活响应。
例如，我们推出某个功能，这个功能表现得非常好。我们很可能在分析数据后决定近期专注于巩固和发展这个功能的成功，而不是关注最初计划的其他内容。反之，如果功能表现不佳，类似的功能可能需要重新审视——替换为其他我们用户更喜爱的功能。这样，我们从用户那里获得的反馈会极大影响我们未来对项目内容的填充。
待办事项列表作为基础
我们开发的基础是产品待办事项列表。为了创建它，我们使用一个在线平台，每个工作室员工都可以访问。任何时候，都可以查看发布日期、每个团队计划的最近版本，直接链接并检查任务状态，即了解我们计划什么以及开发处于哪个阶段。
一个重要的过程是功能进入这个待办事项列表的机制。为此，我们使用一个特殊的工具，称为创意待办事项列表——一个可以由任何团队成员添加的大清单。通过审查阶段后，提出的想法如果真正值得，就可以进入我们产品待办事项列表的最上方，我们的一个团队能将其纳入开发。
除了创意待办事项列表外，我们还有功能的待办事项列表，里面是我们认为有前景的想法，我们希望能在不久的将来向用户展示。如果我们的功能待办事项列表恰巧变空，我们总是可以回到创意待办事项列表中，选取那里的最有趣的想法。
我们的工具
我们使用Slack进行沟通。其中一些频道有使用规则：这意味着只能以特定格式撰写特定内容。其他频道没有任何规则——可以讨论当前的工作状态，交换开发所需的数据等。
显然，当我们引入Slack时，并没有那么多频道，我们逐步建立了它们——有的删除，有的添加。今天，我们已经拥有一个允许我们的团队有效沟通的频道集合，因此新员工可以相当快速地了解在哪个频道可以提出特定问题以获取所需信息。
跨团队分配
我们将产品大致划分为意义单位，称之为系统。总共有一百多个。这些系统在产品负责人的之间分配，每人大约责任十个这样的系统。而且，产品负责人将这些系统在两到三个开发团队之间分配。
例如，我们有想法开发某个功能。在它经过审查并被提升到待办事项列表顶部后，我们查看它属于哪个系统。比如，如果它是关于玩家培训的系统，那么这个功能就会交给管理该系统的产品负责人进行开发。然后，产品负责人会将功能分配给各个团队。
我们的自定义框架
我们认同Agile的价值观，并在多年中形成了对Scrum这一非常便利且有用的东西的理解。然而，作为一个优秀团队的有效工具，Scrum对于协调15-20个团队的工作却显得捉襟见肘。
我们开始思考如何将这一我们认为相当便利和有效的框架适应我们的需求。结果，我们发现许多其他公司也在全球范围内面临相同的挑战，因此出现了规模化Scrum的框架：LeSS、SAFe、Nexus及类似框架。
在为我们特有的解决方案工作过程中，我们自行设计了一些方法，也借鉴了一些现有框架。如果结果形成了我们自己的规模化Agile框架。当我们制定它并开始使用时，杰弗里·萨瑟兰（Jeffrey Sutherland）团队——Agile宣言和Scrum的作者之一，发布了他的框架Scrum@Scale，与我们自行创建的框架非常相似。
总之，我们不使用现成的工具，而是关注Scrum联盟的动向，寻找有趣的框架和与Agile无关的方法论，及全球公司采用的开发方法，选取可能对我们有用和高效的技术，然后将它们引入我们的开发流程。
我们认为Scrum的主要仪式是非常正确的工具，因为它们使整个团队面向同一个方向。Daily Stand-Up、Sprint Planning、Sprint Review和Sprint Retrospective是Scrum的四个主要仪式，被扩展到我们新版本游戏的开发水平。
我们有每个版本的规划，在此期间，每个团队的产品负责人提出相应的功能集并承诺在该版本开发结束时交付。同时我们还进行版本演示——类似Sprint Review，期间团队展示功能、展示所开发的功能并接受反馈。在这个活动中，评价所做工作的完整性以及是否会给用户带来兴趣。
此外，我们还会举行回顾会议。在会上我们选择版本开发中的关键时刻。这使我们能够发现那些由于缺乏相应流程而导致的问题，使我们能够有条理地解决某些问题。因此，在每个版本结束后我们会组织会议，识别成功与遭遇的困难，并制定未来的计划。
因此，我们在功能团队层面有Scrum仪式，在项目团队层面有规模化的Scrum仪式。这使我们不丧失聚焦，不会忘记我们不是在单独开发各自的功能，而是在共同制作一款大型游戏。
沟通语言
我们团队中有不少人不会说俄语。在与他们沟通时，我们自然使用英语——而且在MS-1工作室有许多来自其他国家的员工，他们是不同语言的母语者。因此，英语作为我们行业中大多数人的共通语言，成为了一个非常便利的沟通工具。
相反，虽然不懂英语的人仍然可以在MS-1工作，但我们会努力为他选配一个英语需求不大的团队，并且与英语使用者的交集不大。但同时，我们会尽力尽快教会他们为此安排语言课程。通常，甚至英语能力较弱的人，进入我们的团队后也会逐渐提高他们的语言水平。
沟通优先
我们定期进行所谓的团队健康检查，期间团队经理监控团队的状态、动机、工具的便利性等。在远程工作中，这些检查显得尤为重要。此类监控的一个标准是乐趣。遗憾的是，目前乐趣的指标有所下降，团队的凝聚感也减弱了。
因此，我们专注于寻找办公室面对面沟通的替代方案。我们的经理们开始提出许多活动。例如，通过在线游戏进行的共度时光。此外，经理还可以举办完整的团队建设活动、在线测验、会议。偶尔，人们自己会在周五晚上聚在一起，喝着茶或者啤酒，随意聊天，就像在酒吧那样。
我们使用语音聊天，这样可以模拟在一个房间中的感觉。这不是技术信息的交换或者工作材料的传送，而是纯粹的重复瞬间，你坐在办公室的桌子旁，可以抬起头说：“哦，伙计们，我想告诉你一个昨天发生在我身上的有趣故事！”或者“有人曾遇到过这样的麻烦吗？”这不需要打开Slack，寻找相关频道，描述问题。你只需抬起头来问：“有谁做过这样的事情吗？”对面的回答是：“有，我遇到过这样的情况，过来我给你看看。”通过使用这样的工具，我们得以保持团队集体创作的精神，使我们的团队一起进行头脑风暴，完善他们的功能。
因此，对于那些在开发中采取类似方法并努力挖掘整个团队潜力的团队，我建议特别注意沟通的简单性。那些与营利性业务无直接关系的小活动至关重要。它们是团队效率、生产力、动机和改进产品意愿的基础。
