为了期待AppsConf 2018，我们就涉及移动应用程序开发的大型团队的独特功能和流程采访了大型公司的专家。 使用了什么工作方法，有什么陷阱等待划船手到达一个巨大的厨房。 公司的外国血统是否对工作流程留下了烙印-请仔细阅读所有相关内容。
Philip Uvarov，Spotify的Android开发人员。 该公司在过去六个月中一直在为Spotify的其他开发人员提供支持的平台团队中工作。 居住在瑞典。 在加入Spotify之前，他曾在瑞典的一家初创公司工作，甚至更早就职于Avito。
Odnoklassniki的首席IOS开发人员Artyom Olkov。 他目前正在领导iOS开发产品之一。 除了开发本身，他还负责体系结构，设计，任务分配，与设计的协调，后端API等。 现在，Odnoklassniki总共拥有大约60名移动工程师，这些工程师被分成较小的团队。 Artem团队-11人。
Uber高级软件工程师Maxim Efimov。 他在公司工作了两年，从事Android开发。 它是车手付款团队的一部分，该团队处理Uber乘客应用程序中与付款有关的所有事情。 在此之前，他曾在其他公司为Android开发（主要是按订单甚至更早），他使用C ++（SCADA系统的服务器解决方案）编写程序。 在优步，作为支付部门的一部分，还有更多其他团队为其他应用程序提供类似的团队，以及基础架构团队-共有数十个团队。
Avito移动部门开发主管Evgeny Suvorov：大约八年来，它一直在开发移动应用程序。 我尝试过游戏，自由职业者，在大型公司的外包公司工作，之后我转向产品开发。
让我们从功能开始。 与公司中大量开发人员的团队合作有什么区别？Artem Olkov（Odnoklassniki）：我认为，特殊性与公司的规模无关，而与公司内部的流程安排方式以及团队在这些流程中扮演的角色有关。 粗略地讲，如果您的团队构建了公司其他应用程序或服务所基于的移动平台，那么来自不同角落的1000个请求将飞向该平台，而没有好的产品经理，开发将被淹没。 如果团队提供没有复杂集成的独立服务，则过程看起来会简单得多。
马克西姆·埃菲莫夫（Maxim Efimov）（尤伯（Uber））：我认为，最典型的特征是工作速度。
原则上，小团队的工作要快得多。 但是，与此同时，大型团队当然拥有开发人员的最终总产值，因为整个团队从事的工作大致相同。 因此，对于项目的总体实施方式有不同的看法。
在小型公司中，我们通常有条件地适应长达一天或一周的时间。 我们可以预先计算和计划所有事情。 在大型团队中，这很难做到，因为所有事情都与大量人员相关。 因此，计划方法有所不同。 项目在时间上要有一定的容忍度，而质量和我们制作的功能至关重要。 只有在那之后，才有必要适应截止日期。
另一个有趣的观点是：团队之间如何达成共识。 如果五到十个人在项目上工作，他们可以很容易地在会议室组装，花了两到三个小时就可以解决所有问题。 您可以继续做这个项目。 但是，当数百人参与该项目时，这将行不通。 在Uber，我们拥有某些沟通机制，这些机制允许团队不互相干扰，有效整合等。在小公司中，原则上所有这些都不存在。
Philip Uvarov（Spotify） ：我认为主要功能是我并不亲自认识所有Android开发人员。 而且我们也有非常不同的责任。 这使您能够始终处于自己正在做的事情的背景中，并且足够快地向您的方向交付产品。
您的团队如何与公司内其他人员同步？Evgeny Suvorov（Avito）：我们的团队通过一个移动应用程序-Avito连接。 所有这些都为该产品做出了贡献，即我们代码库和功能中的同步点。
Philip Uvarov（Spotify） ：我们拥有处理特定问题（例如，我们如何为移动客户端开发分析方法）的跨职能团队，这些部门被合并为一个大部门-我们称其为“部落”（部落）。 通常，一个部落中的团队之间有着紧密的联系，他们之间有着积极的经验交流。 另外，当然，我们有客户-这些是其他开发人员，因此我们支持为他们创建的解决方案。
马克西姆·埃菲莫夫（Maxim Efimov）（优步） ：我们有小型团队，每个团队不超过20人。 它们合并为负责大面积区域的结构单元，例如移动应用程序。 同时，团队本身也很自治，因为如果将所有内容简化为具有直接从属关系的单个控制系统，我们将得到一个效率很低的系统。
总体产品构想通过产品经理或所有者传达给各个团队。 有一个单独的结构将这些人聚集在一起，并有助于加深对我们移动方式和方向的理解。 在较高的层次上，可以定义战略目标，例如照顾乘客安全。 好吧，下面将详细解决一到两个层次。 例如，我们在人们大多使用现金付款的国家/地区拥有某些安全机制。
Artem Olkov（Odnoklassniki）：我们从事一项单独的服务。 假设我们是一家大型公司中的一家初创公司。 当然，我们生活在相同的基础架构中。 在其他所有方面，我们都是非常独立的。 即使在集成框架内，我们也经常使用我们自己工具的公共API。
大型团队是否有典型的问题？ 你要处理什么Evgeny Suvorov（Avito） ：我认为，一个大型团队的流程主要受到影响。
通常，所有的人都有经验，即使大三也能解决技术问题。 但是流程问题很容易使每个人慢下来，因此最好使流程自动化。
这意味着高质量的持续集成，持续交付，测试自动化。
Philip Uvarov（Spotify） ：我认为最大的问题是公司内部知识的传播。 我可能对一些遥远的团队所发生的事情一无所知。 相反的方向也是如此：许多团队都不知道我们在Spotify有一支分析团队。 这就是规模感。
第二点是做出创新决策的速度：采用相同的Kotlin和其他新技术。 告诉五位开发人员是一回事：“从今天起，我们就在Kotlin上进行写作”，但是要与100位开发人员说是另一回事。 需要转换庞大的基础架构，以某种方式支持这些创新（CI等）。
Artem Olkov（Odnoklassniki）：是的，确实存在两个问题：知识的转移和行动的协调，包括现代化。
大公司是否有解决这些问题的成熟方法？菲利普·乌瓦洛夫（Philip Uvarov）（Spotify） ：要解决第一个问题-共享知识-我们有行会之类的东西。 这是按功能划分的一组开发人员，例如Android公会，该公会每两周举行一些活动：演示文稿，午餐，您可以在其中讨论紧迫的问题或分享一些东西等。我们也有公会举行内部会议。 另外，还有邮件列表等。 一个简单的人为问题仍然存在：很难跟上这一切。
我想将内部培训（高级培训）单独强调。 我们拥有自己的数据大学，您可以在其中学习如何成为数据工程师。 现在，同事们正在考虑为移动学习创建相同的方案。
Artem Olkov（同学）：我们没有发音的行会。
通过一项任务团结在一起的家伙在不同的会议上相交-他们彼此认识，在吸烟室或午餐时间进行交流。 有单独的聊天室，例如，仅用于iOS昵称。 当然，在团队内部，解决问题的方法更容易-我们都坐在同一个“雏菊”上。
如果您有任何疑问，请举手，向需要的人挥手-他会回答您。 为了传递知识，我们还使用15分钟的上午集会，每个人都告诉他们这样做的内容，方式，原因和原因。 仍然有一些要点记录在文档中。
第二个问题-行动协调-由主管管理层解决。
Maxim Efimov（Uber）：实际上，在相同的知识共享下，我看不到问题所在。 我发现共享机制本身是不同的。 在小型团队中，无论如何都可以轻松完成。 聚集-交谈。 而且我们有便捷的流程，使我们能够组织一切以便工作。 顺便说一句，我将在我在AppsConf 2018上的
演讲中谈论它们。想法是，在我们公司中，几乎所有开发都是相当透明的。 任何团队的人都可以查看其他开发人员在做什么，并在家中使用其中的一些功能。
叶夫根尼·苏沃洛夫（Avito）：我们每周还组织两次会议。 我们喜欢自动化，并且这项任务也是自动化的。 在整个过程中，人们会在一周内抛出他们想在iOS或Android开发人员大会上谈论的话题。 如果有传票，我们要去。 在会议期间，产品团队将讨论他们在产品中实现的功能，因为否则很难跟踪发生的一切。
我们从一开始就开会，但是随着公司的发展，这些会议才变得最重要。
此外，还有聊天室，您可以在其中讨论任何特定问题。
根据什么原则，将公司中的许多开发人员按平台，功能或其他方式划分是有意义的？Artem Olkov（Odnoklassniki）：这仍然取决于您的工作以及赚钱的方式。
从理论上讲，我可以想象一个外包公司的结构，例如，一个部门将在平台上工作。 但是对于一家食品公司来说，除了职能团队外，我几乎无法想象会有其他形式的部门划分。
因为如果将所有iOS昵称放入一个堆中，然后将任务扔进去，而又不能与设计，后端或测试进行短暂的沟通，那么您将不得不花太多时间进行协调。
Philip Uvarov（Spotify） ：我们都分享该产品。 例如，我们的团队从事分析，包括iOS，后端开发人员以及许多其他人员。 我认为，这是团队的非常合理的划分，这也会导致某些问题，但同时在这样的规模下效果很好。
Maxim Efimov（Uber）：在我看来，按平台（iOS，Android，后端）大规模划分团队的想法不太可行。 它将开发人员彼此隔离开很多，因此，例如，针对不同平台的两个移动应用程序的同步将花费更多。 在我看来，团队中的人员只能从平台上看到人员这一事实所带来的收益并不多。 是的，共享知识更容易，但值得吗？ 我认为不是。
另外，一些团队做其他人都可以使用的基本操作的想法，例如一些按钮，列表，文本输入字段，对我来说似乎很有趣。
Evgeny Suvorov（Avito）：我同意
，这样的结构非常成功，我们最近在我们的Avito中，至少在业务的杂货店中实现了这种结构。
当我们有五个开发人员时，我们的团队可能扩大了，因为即使有这么多的人员，自组织也很困难。 这些家伙看到一个特征变得更加困难，他们不得不以某种方式将它们分开，以不同的角度，不同的特征繁殖它们。 在建筑和其他事务上开始出现分歧，并且沟通变得更加复杂。
在某个时候，Avito有两个大团队-iOS和Android开发，每个团队15个人。 在此阶段，我们开始进入产品团队：“买方经验”，“卖方经验”，即时通讯，交付等团队脱颖而出。 这优先解决了这个问题。 以前，许多项目经理都是向团队提出功能请求的，而对于他们来说，每个功能都是头等大事。 结果，我们有20个项目，而它们的跨领域优先重点尚不明确。 父母必须手动进行管理。 在强调了多功能团队之后，每个团队都有自己的开发流程，优先级和资源，一切都变得更加简单。
同时，我们仍然有小型平台团队，我们称之为“水平”决策，这些决策将推广到所有产品团队。
经常进行团队重组吗？Philip Uvarov（Spotify） ：每周都会发生某种运动。 在我们公司中，团队规模很小且自治。 如果需要，您可以轻松地从一个转到另一个。 这种情况的发生频率取决于团队和您的工作方向。 在我工作的地方，这没有说出来。 但是Spotify因我们致力于敏捷并且在很多方面（例如OKR等）从我们而来的事实而闻名。 因此，如果公司管理层突然意识到某些问题不起作用，则不怕更改优先级。 我们只是切换到其他东西。
Maxim Efimov（Uber）：我们进行了大规模的改革，这主要与阿姆斯特丹办事处的快速增长有关。 在这一年中，员工人数几乎翻了一番。 那些招募人员的团队非常庞大，一位经理很难管理这种结构。 在这方面，团队被简单地分为几个“子命令”，每个子命令都在一个狭窄的区域内进行。 在我看来，这是一个自然的过程。
您是否同意这样一个想法，那就是在一个大型团队中，确保代码的质量不会受到影响，因此值得避免聘用资历过高的初级和高级员工？菲利普·乌瓦洛夫（Philip Uvarov） ：我想彼此都不是。 每年，Spotify都会通过暑期实习招募许多大学毕业生（实习后的一些人会收到工作邀请）。 同样，我们很容易招收拥有多个博士学位的人。
技术技能很棒，但是您可以教他们。 如果一个人不知道如何在团队中工作，那将是非常困难的。 因此，此类公司几乎更加重视软技能。
为了不影响质量，我们需要进行良好的采访，以使我们选择不低于某个基本水平的开发人员。
Maxim Efimov（Uber）：我们从略有不同的原则开始。 我们有经验丰富的开发人员和6月的理想比例。 只是为了避免在拥挤的人群中出现任何情况，而且没有人可以帮助他们并说明如何工作。 因此，我们试图保持平衡。
坚持“不招太多主”的原则是没有意义的。 寻找主人是一个相当困难的追求。 市场上有很多公司，开发人员的竞争非常激烈。 有经验的人可以在几乎任何地方成功地定居，因此，今天放弃合格的人员，然后明天再招聘它们，这是不现实的。 这些人不会坐下来等到我们想邀请他们。 按照我的实践，如果一个人具有良好的能力，那么找到他在公司中的职位也不是问题。 但是我们必须从特定情况出发。 我们需要根据团队中每个人的志向做出决定，看看即将到来的项目，是否可以自己完成这些项目，需要谁。 也就是说，有必要进行低级计划。
叶夫根尼·苏沃洛夫（Avito）：我认为，在招募老年人时，您不必担心他们的头上有自己的国王，或者他们不会服从。
在我们公司，开发人员自己提供解决某些问题的方法。 老年人通常有高质量的解决方案。 他们有经验，因此在他们的参与下，可以更快地解决问题。 还有另一个问题-您的任务似乎不像前辈有趣或雄心勃勃。
青少年也需要单独与他们联系。 当我们还是一个团队时，时不时会有一种直觉的感觉，那就是该团队可以再拿一个六月。 在那一刻，有可能雇用一个出色的雄心勃勃的人，他很快长大后成为一名质量工程师。 在拥有完善流程的团队中，培训确实非常快捷。 是的，琼斯并不相同-有些是在大学毕业后眼睛发红，但他们无能为力，而另一些则有7年的后端经验，他们只是转向了移动应用程序。
也就是说，我们不惧怕初级人员，但我们专注于团队的感觉-是否需要。
计划，同步，任务分配
大型公司（甚至是小型团队）中的开发人员的计划和同步是否会消耗大量精力？Philip Uvarov（Spotify） ：这只是按产品而非功能划分的团队：我们只计划公司内部的小型产品，而我们通常不在乎其余数百万开发人员的工作。
Artem Olkov（Odnoklassniki）：在这里，我只能谈论我们的特定团队。 我们已经开始开发，这给了您一定的纵欲-使您更自由。 目前，我们每天只有15分钟的集会，以了解当前状态，每小时关闭上一个Sprint的时间/计划每周一次。 其他一切均由个人决定。
马克西姆·埃菲莫夫（Maxim Efimov）（优步）：在我们的情况下-
规模不大。 也许是我从事外包工作时的1.5到2倍。
的确，公司中有一些阻碍开发的流程，例如代码审查。 粗略地说，直到某个负责其代码部分的团队查看您的提交，这可能会花费一些时间。 但是我不认为这是指同步费。 这更多是关于如何在较低的层次上设置整个计划-谁修改谁，如何安排等待时间等等。
Evgeny Suvorov（Avito）：我们最初通过频繁发布解决了同步问题。 结果，同步本身现在需要一点时间。 一切几乎都是自动化的。
我是否需要以特殊方式分配任务，以免影响代码质量？Philip Uvarov（Spotify） ：在大型团队中，按职责范围分配产品是有意义的。 因此，总会有人负责任地接近他们，因为他们以后会与之共处。 它们的上下文不会改变，即 , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
但是我绝对不能向所有开发人员推荐一个两周或一周的周期。正如一位同事所提到的，有些产品的发布周期需要数月的时间，这是由于对功能进行了非常全面的测试。但是有相当复杂的过程。并且我们尝试简化一切。我们对高频率的发布感到更满意，这样团队就不必考虑下一次约会的时间，而只是考虑必要的功能。在最坏的情况下，他将在两周内投产。大型团队还有其他差异。演讲者及其同事将在AppsConf 2018ApplsConf 2018上讨论详细信息。将会讨论有关组织大型团队的工具和原则。