Antecipando o AppsConf 2018, entrevistamos especialistas de grandes empresas sobre os recursos e processos distintos de grandes equipes envolvidas no desenvolvimento de aplicativos móveis. Que abordagens ao trabalho são usadas, que armadilhas aguardam os remadores que chegam a uma enorme galera. Se a origem estrangeira da empresa deixa uma marca nos processos de trabalho - leia tudo sobre isso por baixo.
Philip Uvarov, desenvolvedor Android do Spotify. A empresa trabalha há seis meses - em uma das equipes de plataforma que dão suporte a outros desenvolvedores do Spotify. Vive na Suécia. Antes do Spotify, ele trabalhou em uma startup sueca e ainda mais cedo na Avito.
Artyom Olkov, desenvolvedor IOS líder em Odnoklassniki. Atualmente, ele lidera o desenvolvimento do iOS de um dos produtos. Além do próprio desenvolvimento, ele é responsável pela arquitetura, design, distribuição de tarefas, coordenação com design, APIs de back-end, etc. No total, Odnoklassniki agora tem cerca de 60 engenheiros móveis, divididos em equipes menores. A equipe do Artem - 11 pessoas.
Maxim Efimov, engenheiro de software sênior da Uber. Ele trabalha na empresa há dois anos, está envolvido no desenvolvimento do Android. Faz parte da equipe de pagamentos do passageiro, que processa tudo relacionado aos pagamentos no aplicativo de passageiros Uber. Antes disso, ele desenvolveu para o Android em outras empresas - principalmente por encomenda e ainda mais cedo - ele escreveu em C ++ (soluções de servidor para sistemas SCADA). No Uber, como parte do departamento de pagamento, existem várias equipes semelhantes para outros aplicativos, além de equipes de infraestrutura - um total de várias dezenas de equipes.
Evgeny Suvorov, chefe de desenvolvimento de unidades móveis da Avito: desenvolve aplicativos móveis há cerca de oito anos. Tentei games, freelancer, trabalhei em empresas de terceirização, em uma grande empresa, depois da qual mudei para o desenvolvimento de produtos.
Vamos começar com os recursos. Qual é a diferença entre o trabalho de equipes com uma grande equipe de desenvolvedores na empresa?Artem Olkov (Odnoklassniki): Na minha opinião, as peculiaridades estão relacionadas não com a escala da empresa, mas com a forma como os processos são organizados dentro dela e com o papel que a equipe desempenha nesses processos. De maneira geral, se sua equipe criar a plataforma móvel na qual outros aplicativos ou serviços da empresa se baseiam, 1000 solicitações de diferentes cantos serão direcionadas a ela e, sem um bom gerente de produto, o desenvolvimento se afogará. Se a equipe fizer um serviço independente sem integrações complexas, o processo parecerá muito mais simples.
Maxim Efimov (Uber): Na minha opinião, a característica mais característica é a velocidade do trabalho.
Equipes pequenas, em princípio, trabalham muito mais rápido. Mas, ao mesmo tempo, grandes equipes têm um produto final bruto do desenvolvedor, naturalmente, porque todo um grupo de pessoas está envolvido aproximadamente na mesma coisa. E disso segue uma visão diferente de como os projetos são geralmente implementados.
Nas pequenas empresas, geralmente nos encaixamos em termos condicionais, até um dia ou até uma semana. Podemos calcular e planejar tudo com antecedência. Em equipes grandes, isso é difícil, porque tudo está ligado a um grande número de pessoas. Portanto, a abordagem de planejamento é um pouco diferente. Os projetos são realizados com certas tolerâncias em termos de tempo e qualidade e os recursos que fazemos são primordiais. E somente depois disso é a necessidade de se ajustar aos prazos.
Outro ponto interessante: como as equipes concordam entre si. Se cinco a dez pessoas trabalham no projeto, elas podem ser facilmente montadas na sala de reuniões e, depois de passar de duas a três horas, resolver todos os problemas. E você pode ir além para fazer o projeto. Mas quando centenas de pessoas estão envolvidas no projeto, isso não funciona. Na Uber, temos certos mecanismos de comunicação que permitem que as equipes não interfiram umas com as outras, se integrem efetivamente etc. Nas pequenas empresas, tudo isso, em princípio, não é.
Philip Uvarov (Spotify) : Eu acho que a principal característica é que eu não conheço todos os desenvolvedores do Android pessoalmente. E também temos responsabilidades muito divididas. Isso permite que você esteja sempre no contexto do que está fazendo e com rapidez suficiente para entregar produtos em sua direção.
Como sua equipe se sincroniza com outras pessoas da empresa?Evgeny Suvorov (Avito): Nossas equipes estão conectadas por um aplicativo móvel - Avito. Todos eles estão contribuindo para este produto, ou seja, o ponto de sincronização em nossa base de código e funcionalidade.
Philip Uvarov (Spotify) : Temos equipes multifuncionais que lidam com questões específicas (por exemplo, como desenvolvemos análises para clientes móveis) são combinadas em um departamento grande - chamamos de "tribo" (tribo). Como regra, as equipes de uma tribo estão intimamente interconectadas, elas têm uma troca ativa de experiências. Além disso, é claro, temos clientes - esses são outros desenvolvedores, por isso apoiamos as soluções que criamos para eles.
Maxim Efimov (Uber) : Temos equipes pequenas, cada uma com no máximo 20 pessoas. Eles estão unidos em unidades estruturais responsáveis por grandes áreas, por exemplo, um aplicativo móvel. Ao mesmo tempo, as próprias equipes são bastante autônomas, porque se reduzirmos tudo a um único sistema de controle com subordinação direta, teremos um sistema muito ineficiente.
A ideia geral do produto é transmitida às equipes individuais por meio de gerentes ou proprietários de produtos. Existe uma estrutura separada que reúne essas pessoas e ajuda a entender como e para onde estamos nos movendo. Em algum nível superior, objetivos estratégicos, como cuidar da segurança dos passageiros, podem ser definidos. Bem, os detalhes são resolvidos de um a dois níveis abaixo. Por exemplo, temos certos mecanismos de segurança em países onde as pessoas usam principalmente dinheiro para pagar.
Artem Olkov (Odnoklassniki): Estamos envolvidos em um serviço separado. Então, digamos que somos uma startup dentro de uma grande empresa. Obviamente, vivemos na mesma infraestrutura. E em tudo o resto, somos muito separados. Mesmo dentro da estrutura de integração, geralmente usamos a API pública de nossas próprias ferramentas.
Existem problemas típicos de grandes equipes? Com o que você tem que lidar?Evgeny Suvorov (Avito) : Na minha opinião, os processos em uma grande equipe são afetados principalmente.
Todos os caras, em regra, são experientes, até os juniores são capazes de resolver problemas técnicos. Mas problemas com processos podem facilmente atrasar todo mundo, então é melhor automatizar processos.
E isso significa integração contínua de alta qualidade, entrega contínua e automação de testes.
Philip Uvarov (Spotify) : Eu acho que o maior problema é a disseminação de conhecimento dentro da empresa. Talvez eu não tenha uma idéia do que está acontecendo em algumas equipes distantes. E o mesmo acontece na direção oposta: muitas equipes não têm idéia de que temos uma equipe de análise no Spotify. É aqui que a escala é sentida.
O segundo ponto é a velocidade de tomada de decisões inovadoras: adaptação do mesmo Kotlin e outras novas tecnologias. Uma coisa é contar a cinco desenvolvedores: "A partir de hoje, escrevemos no Kotlin", mas outra é dizer a 100 desenvolvedores. Há uma enorme infraestrutura que precisa ser traduzida, para apoiar de alguma forma essas inovações (IC, etc.).
Artem Olkov (Odnoklassniki): Sim, existem realmente dois problemas: a transferência de conhecimento e a coordenação de ações, incluindo a modernização.
As grandes empresas têm alguma maneira comprovada de resolver esses problemas?Philip Uvarov (Spotify) : Para resolver o primeiro problema - compartilhar conhecimento -, temos guildas. Este é um grupo de desenvolvedores por função, por exemplo, a guilda Android, que a cada duas semanas realiza alguns eventos: apresentações, almoços, onde você pode discutir problemas urgentes ou compartilhar algo, etc. Também temos, novamente, guildas são realizadas conferências internas. Além disso, existem listas de discussão, etc. Um simples problema humano permanece: é difícil acompanhar tudo isso.
Gostaria de destacar o treinamento interno (treinamento avançado) como uma linha separada. Temos nossa própria Universidade de Dados, onde você pode aprender como se tornar um engenheiro de dados. Agora, os colegas estão pensando em criar o mesmo esquema para o aprendizado móvel.
Artem Olkov (Colegas de classe): Não temos guildas pronunciadas.
De um jeito ou de outro, os caras unidos por uma tarefa se cruzam em reuniões diferentes - eles se conhecem, se comunicam em uma sala de fumantes ou no almoço. Existem salas de chat separadas, por exemplo, apenas para apelidos do iOS. Dentro da equipe, é claro, a questão é resolvida com mais facilidade - estamos todos sentados na mesma "margarida".
Se você tiver alguma dúvida, levante a mão, acene para a que você precisa - e ele responde. Para transferir conhecimento, também usamos comícios matinais de 15 minutos, onde todos dizem o que, como, por que e por que fizeram. Ainda existe uma certa camada de documentação em que os pontos principais são abordados.
O segundo problema - coordenação de ações - é resolvido pela gerência competente.
Maxim Efimov (Uber): Na verdade, no mesmo compartilhamento de conhecimento, não vejo o problema. Vejo que o próprio mecanismo de compartilhamento é diferente. Em equipes pequenas, isso é feito de qualquer maneira. Reunidos - conversados. E temos processos convenientes que nos permitem organizar tudo para que funcione. A propósito, falarei sobre eles em meu
discurso no AppsConf 2018. A idéia é que em nossa empresa quase todo o desenvolvimento seja bastante transparente. Pessoas de qualquer equipe podem ver o que outros desenvolvedores estão fazendo e usar parte disso em casa.
Evgeny Suvorov (Avito): Também organizamos reuniões 2 vezes por semana. Adoramos automação, e essa tarefa também é automatizada. Há um processo em que durante a semana as pessoas discutem tópicos sobre os quais gostariam de conversar em uma reunião geral de desenvolvedores de iOS ou Android. E se houver uma intimação, nós estamos indo. Durante as reuniões, as equipes de produto falam sobre os recursos que implementaram no produto, porque, caso contrário, é difícil acompanhar tudo o que acontece.
Nos conhecemos desde o início, mas foi com o crescimento da empresa que essas reuniões se tornaram mais relevantes.
Além disso, existem salas de bate-papo nas quais você pode discutir problemas específicos.
Por que princípio faz sentido dividir muitos desenvolvedores em uma empresa - por plataforma, por funcionalidade ou de alguma outra maneira?Artem Olkov (Odnoklassniki): Ainda depende do que você faz e de como ganha dinheiro.
Em teoria, posso imaginar a estrutura de uma empresa de terceirização na qual uma divisão, por exemplo, funcionará em uma plataforma. Mas para uma empresa de alimentos, mal consigo imaginar uma forma diferente de divisão, exceto para equipes funcionais.
Como se você colocar todos os apelidos do iOS em uma pilha, jogue tarefas neles, sem ter uma ponte muito curta de comunicação com design, back-end ou teste, você precisará gastar muito tempo na coordenação.
Philip Uvarov (Spotify) : Todos compartilhamos o produto. Por exemplo, nossa equipe está envolvida em análises e inclui iOS, desenvolvedores de back-end e muitos outros. Na minha opinião, esta é uma divisão de equipes bastante razoável, o que também leva a certos problemas, mas ao mesmo tempo funciona bem nessa escala.
Maxim Efimov (Uber): Parece-me que a ideia de dividir equipes por plataforma - iOS, Android, back-end - em larga escala não funcionará muito bem. Separa bastante os desenvolvedores e, como resultado, a sincronização, por exemplo, de dois aplicativos móveis para plataformas diferentes, custará muito mais. E o lucro do fato de que as pessoas da equipe veem apenas pessoas de sua plataforma, como me parece, não é tanto. Sim, compartilhar conhecimento é mais fácil, mas vale a pena? Eu acho que não.
Além disso, a ideia de que algumas equipes fazem coisas básicas que todo mundo usa, por exemplo, alguns botões, listas, campos de entrada de texto, me parece interessante.
Evgeny Suvorov (Avito): Eu concordo
: essa estrutura é bastante bem-sucedida e nós a implementamos recentemente em nosso Avito, pelo menos na parte de mercearia do negócio.
Nossa equipe se tornou grande, provavelmente, quando tínhamos cinco desenvolvedores - já que mesmo com essa quantidade, a auto-organização era difícil. Tornou-se mais difícil para os caras verem uma característica, eles tinham que de alguma forma separá-los, criá-los em diferentes ângulos, em diferentes aspectos. Os desacordos começaram em assuntos arquitetônicos e outros, e as comunicações ficaram mais complicadas.
Em algum momento, a Avito tinha duas grandes equipes - desenvolvimento para iOS e Android, 15 pessoas cada. E, nesse estágio, começamos a entrar em equipes de produtos: os grupos “experiência do comprador”, “experiência do vendedor”, mensagens instantâneas, entrega etc. Isso resolveu o problema com prioridades. Anteriormente, muitos gerentes de projeto chegavam às equipes com solicitações de recursos e, para eles, cada um desses recursos tinha prioridade número um. Como resultado, temos 20 projetos e suas prioridades transversais não são claras. Os pais tiveram que gerenciar isso manualmente. Depois de destacar as equipes multifuncionais, cada uma com seu próprio pipeline de desenvolvimento, suas prioridades e recursos, tudo ficou mais simples.
Ao mesmo tempo, ainda temos pequenas equipes de plataforma que tomam, como chamamos, decisões "horizontais" que são implementadas em todas as equipes de produtos.
As reorganizações de equipe geralmente ocorrem?Philip Uvarov (Spotify) : Algum tipo de movimento acontece toda semana. Em nossa empresa, as equipes são pequenas e autônomas. Se desejar, você pode facilmente passar de um para outro. A frequência com que isso acontece depende da equipe e da direção em que você trabalha. Onde eu trabalho, isso não é pronunciado. Mas o Spotify é famoso pelo fato de trabalharmos com agilidade e, de várias maneiras, coisas como OKR etc. Portanto, a gerência da empresa não tem medo de alterar as prioridades, se de repente perceber que algo não está funcionando. Apenas mudamos para outra coisa.
Maxim Efimov (Uber): Tivemos reformas em larga escala, relacionadas principalmente ao crescimento muito rápido do escritório de Amsterdã. Durante o ano, o número de funcionários quase dobrou. As equipes em que as pessoas foram recrutadas se tornaram muito grandes e era difícil para um gerente gerenciar essa estrutura. Nesse sentido, as equipes foram simplesmente divididas em vários "subcomandos", cada um dos quais envolvido em uma área mais restrita. Parece-me que este é um processo natural.
Você concorda com a idéia de que, em uma equipe grande, para que a qualidade do código não sofra, vale a pena evitar a contratação de juniores e seniores super qualificados?Philip Uvarov (Spotify) : Acho que nem um nem o outro. Todos os anos, o Spotify recruta muitos graduados universitários durante o verão (algumas das pessoas depois do treino recebem um convite para trabalhar). Da mesma forma, facilmente levamos pessoas com vários doutores.
As habilidades técnicas são legais, mas você pode ensiná-las. Se uma pessoa não sabe trabalhar em equipe, será extremamente difícil. Portanto, essas empresas prestam quase mais atenção às habilidades sociais.
E para que a qualidade não sofra, precisamos de boas entrevistas que nos permitam selecionar desenvolvedores não inferiores a algum nível básico.
Maxim Efimov (Uber): Estamos começando com um princípio um pouco diferente. Temos uma proporção desejável de desenvolvedores experientes e junho. Apenas para que não haja situação em que haja uma multidão de dzhuns, e não haja ninguém para ajudá-los e explicar como trabalhar. Portanto, tentamos manter um equilíbrio.
Aderir ao princípio de "não recrutar muitos senhores" não entende o ponto. Encontrar um senhor é uma missão bastante difícil. Existem muitas empresas no mercado, e a competição por desenvolvedores é severa. Pessoas com experiência se instalam com sucesso em praticamente qualquer lugar, portanto, renunciar a pessoal qualificado hoje e depois recrutá-lo amanhã é algo irreal. Essas pessoas não vão sentar e esperar até que desejemos convidá-las. E, na minha prática, se uma pessoa tem boas competências, não é um problema encontrar um lugar na empresa. Mas devemos proceder a partir de uma situação específica. Precisamos tomar uma decisão, dependendo de quais ambições cada pessoa da equipe tem, analisar os próximos projetos, se podemos retirá-los nós mesmos, de quem precisamos. Ou seja, é necessário descer para o planejamento de baixo nível.
Evgeny Suvorov (Avito): Na minha opinião, ao recrutar idosos, você não deve ter medo de que eles tenham seu próprio rei em suas cabeças ou que não obedeçam.
Em nossa empresa, os próprios desenvolvedores oferecem maneiras de resolver certos problemas. E os idosos geralmente têm soluções de alta qualidade. Eles têm experiência, portanto, com sua participação, os problemas podem ser resolvidos mais rapidamente. Há outro problema - suas tarefas podem não parecer interessantes ou ambiciosas para os idosos.
Os juniores também precisam ser abordados individualmente. Quando ainda éramos uma equipe, de tempos em tempos havia uma sensação intuitiva de que a equipe poderia participar de outro mês de junho. E, naquele momento, foi possível escolher um cara maravilhoso e ambicioso que rapidamente cresceu para se tornar um engenheiro de qualidade. Em uma equipe com processos bem estabelecidos, o treinamento é realmente rápido. Sim, e os jones são diferentes - alguns vêm depois da universidade com os olhos ardentes, mas não podem fazer nada, enquanto outros têm sete anos de experiência de back-end, apenas mudaram para aplicativos móveis.
Ou seja, não temos medo de juniores, mas nos concentramos nos sentimentos da equipe - se ela precisa ou não.
Agendamento, sincronização, distribuição de tarefas
O planejamento e a sincronização de desenvolvedores em uma grande empresa (mesmo em equipes pequenas) consomem muita energia?Philip Uvarov (Spotify) : Essa é apenas a divisão das equipes por produto e não por função: planejamos apenas nosso pequeno produto dentro da empresa e geralmente não nos importamos com o que o restante do milhão de desenvolvedores faz.
Artem Olkov (Odnoklassniki): Aqui só posso falar sobre nossa equipe específica. Iniciamos o desenvolvimento, e isso dá certas indulgências - permite que você seja mais livre. No momento, temos apenas comícios diários de 15 minutos sobre o status atual e o fechamento por hora do planejamento anterior do próximo sprint uma vez por semana. Tudo o resto é decidido em uma base pessoal.
Maxim Efimov (Uber): No nosso caso - não é muito grande. Talvez seja 1,5-2 vezes mais do que me ocupou quando trabalhei em terceirização.
É verdade que existem alguns processos na empresa, como a revisão de código, que dificultam o desenvolvimento. Grosso modo, até que uma equipe responsável por seu código analise o seu commit, isso pode levar algum tempo. Mas não acho que isso se refira à taxa de sincronização. É mais sobre como todo esse esquema é configurado em um nível baixo - quem revisa quem, como a espera é organizada etc.
Evgeny Suvorov (Avito): Inicialmente resolvemos o problema de sincronização com lançamentos frequentes. Como resultado, a sincronização em si agora demora um pouco. Tudo é quase automatizado.
Preciso distribuir tarefas de uma maneira especial para que a qualidade do código não sofra?Philip Uvarov (Spotify) : Em grandes equipes, faz sentido distribuir o produto por área de responsabilidade. Assim, sempre haverá pessoas que as abordarão com responsabilidade, porque viverão com ela mais tarde. Seu contexto não muda, ou seja, , ( 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 . , .