Dos monólitos às equipes modulares

As grandes empresas costumam lamentar o problema da adaptabilidade e manobrabilidade. Mais precisamente, quase pela completa ausência de ambos.

Imagine: todas as equipes da plataforma estão ocupadas com um recurso, e a empresa precisa urgentemente de fazer outra coisa ou ajustar a funcionalidade que já está sendo desenvolvida. E, neste momento, o trabalho em um recurso é interrompido e o trabalho em outro começa. No momento seguinte, novos requisitos da empresa aparecem e o recurso permanece inacabado. Os desenvolvedores estão ofendidos e os negócios estão sofrendo.



Aqui está outra situação: a API está mudando, você precisa executar urgentemente o departamento de back-end para descobrir os detalhes e, em seguida, voltar para as frentes (iOS / Android / web). Além disso, depois de discutir suas correções com as frentes, você precisa voltar atrás e falar sobre nossos requisitos. Foi muito cansativo, perdeu o tempo das equipes, um desenvolvedor individual e os nervos de todas as pessoas interessadas.

Meu nome é Valery, nossa equipe estava envolvida na QIWI Wallet para iOS. Mas sempre foi necessário manter a comunicação com outras equipes, caso contrário, uma dessincronização completa resultaria. Quanto aos nossos inconvenientes, o negócio sempre avança e dá liberdade para experimentação. Portanto, surgiu a questão de mudar a estrutura existente. Um ambiente favorável para testar nossas idéias de mudança foi o scrum. A cada duas semanas, nós, dentro da plataforma, podíamos editar o curso para que ele fosse, pelo menos de alguma forma, coordenado com outras equipes. Demorou muito tempo para testar teorias. De um mês a seis meses. Que opções tentamos:

Oouner do recurso

Uma pessoa da equipe foi nomeada responsável pelo recurso para o próximo sprint. Essa pessoa passou parte de seu tempo com designers e com um recurso de outra equipe da linha de frente (o backup decidiu não usar o recurso), descobrindo as armadilhas e sutilezas do próximo trabalho, ele concordou com o back-end sobre o contrato. Ele também monitorou todas as alterações no back-end e nos negócios. E tudo parece estar bem. Ninguém entra em pânico, exceto por essa pessoa que sofre o impacto de um ambiente mutável. Todos pacificaram por um momento.

Mas a felicidade continuou exatamente até que o traço do OUNER adoeceu exatamente antes de sua corrida. E toda a ilusão de apaziguamento foi dissolvida e voltamos ao ponto em que começamos.

Higiene geral

Representantes de diferentes plataformas foram convidados para formar uma equipe de plataforma. Tornou-se um pouco melhor, mas os caras não gostaram (pelo menos da palavra) de se sentar em várias reuniões seguidas. Mas o principal motivo é a variabilidade de APIs e contratos, a mudança nas metas do sprint e é bom que ele mude apenas no primeiro dia do sprint. Mas, no entanto, as mudanças caíram ao longo das duas semanas. Bottom line - os objetivos não são alcançados, os caras estão processando, o negócio está sofrendo.

Bate-papo

Uma das opções não padronizadas foi a criação de bate-papos. Um bate-papo separado foi criado para cada recurso. Além disso, havia também salas de bate-papo de equipes onde os problemas eram discutidos. E também um bate-papo geral especificamente para problemas em que todas as equipes estavam. A princípio, o problema parecia estar resolvido.

Mas as conversas se multiplicaram rapidamente e, você sabe, isso se tornou um fardo. Quando um problema apareceu, ficou claro onde procurar informações - no bate-papo na seção de perfil ou no bate-papo sobre refatoração do cliente de rede ou substituição do módulo de informações do usuário. Como resultado, ficou apenas mais confuso. Mais uma vez tive que correr entre departamentos.

Feature-tim

Então uma mercearia veio e se ofereceu para experimentar o formato feature-tima. O que isso significa: dois desenvolvedores são selecionados de cada plataforma (iOS, Android, web, back-end) e dois testadores) e uma nova equipe é formada.

Essa abordagem deveria resolver vários problemas importantes, além da coerência e velocidade de lançamento dos lançamentos:

Autonomia
Uma equipe que vai às reuniões juntos é o mais independente possível dos outros. O principal link de dependências externas é o produto.

Teste rápido de teoria
Afinal, antes que toda a equipe da carteira fizesse algumas novas funcionalidades, aconteceu que essa funcionalidade muito interessante não foi para os usuários. Acontece que todo o desenvolvimento viu coisas desnecessárias e o orçamento não deu em nada.

Toda a equipe entende o que é "desenvolvimento de produto"
Recursos são criados ou requisitos de negócios chegam, e o desenvolvedor nem sempre entende o porquê, o porquê e quem precisa.

Toda a equipe afeta o produto. Até a invenção de novos recursos
Como resultado, todos gostaram dessa abordagem e, no momento, temos três equipes independentes envolvidas em suas tarefas de produto. Agora, ao alterar o contrato, você não precisa percorrer os departamentos e procurar responsáveis, também não há necessidade de um monte de chats confusos, basta cutucar um desenvolvedor sentado nas proximidades. As reuniões são realizadas com todos os recursos, onde representantes de todas as plataformas e controle de qualidade estão imediatamente presentes.

As perguntas são resolvidas em palavras em alguns minutos e ninguém sente a mesma dor. Além disso, outro grande benefício para os negócios é que, se o recurso não alcançou os usuários, apenas um recurso da equipe (no momento em três) será gasto, e não todo o desenvolvimento, como era antes.

Como resultado, conseguimos obter as seguintes vantagens:

• Autonomia de outras equipes.
• O desenvolvimento flexível máximo, podemos mudar com segurança o curso, se o software exigir.
• Resolução de problemas rápida e fácil.
• Um teste rápido das teorias de recursos.

Espero que este exemplo ajude a resolver problemas de comunicação entre equipes. Se você tiver outras opções legais, estou aguardando feedback).

Obrigada

E em breve teremos um resumo para os desenvolvedores do iOS.