🐎 ↩️ 🌻 Sobre espinhos e estrelas no caminho para otimizar os processos de desenvolvimento 🙏🏼 📍 👎

Sonhos, Sonhos

Nas noites frias de outono, nós e os desenvolvedores de aplicativos de visualização 3D reunidos na cozinha ... bebíamos café ... e pensávamos nisso ... na organização de referência do desenvolvimento.

- Meus amigos no trabalho ágil para mim: sprints, histórias, tudo ...
- Sim, pelo menos revisaríamos ...

O fato é que, naquela época, não era muito agradável conosco. Por exemplo, armazenar projetos no git era muito incomum:

havia vários repositórios, e cada parte continha uma parte do projeto;
alguns repositórios eram comuns, outros relacionados apenas a alguns projetos, outros apenas a um;
Para obter uma cópia de trabalho, você precisava fazer o download do conteúdo de todos os repositórios e colocá-los em pastas específicas.

Como trabalhamos com gráficos 3D e usamos o conceito de “controles + modelos (a localização dos elementos na tela, a lógica das transições)”, para ser mais específico, as coisas eram assim:

ao trabalhar com controles, as confirmações foram para o repositório com controles básicos e, possivelmente, para o repositório com recursos (se os modelos tridimensionais já usados tivessem que ser usados em outro lugar);
ao trabalhar com controles e modelos (por exemplo, se fosse necessário substituir o plano de fundo no aplicativo no painel de ajuda), as imagens precisavam ser carregadas no repositório com recursos e o layout editado no repositório com modelos. Se o plano de fundo foi feito com uma capa (estilo único), três repositórios podem estar envolvidos.

Com essa abordagem, as revisões de código eram um luxo para o custo:

o desenvolvimento foi realizado em um único ramo;
as alterações em uma tarefa afetaram vários repositórios e o rastreamento de confirmações relacionadas a qual tarefa era muito problemática.

Como resultado, devido à falta de capacidade de "aprender com os erros", trocar experiências, analisando o código um do outro durante a revisão, os desenvolvedores não puderam melhorar suas habilidades com rapidez suficiente. E para desenvolver aplicativos "mais rápido" - era necessário. E, a fim de manter a velocidade de desenvolvimento em um nível aceitável, em cada novo projeto, as pessoas estavam envolvidas nessas tarefas que eram semelhantes às tarefas de projetos anteriores. I.e. se alguém trabalhava anteriormente com um mapa 3D, ele repetidamente conseguia tarefas relacionadas a mapas ou, se alguém desenvolvia o componente "gráfico", estava condenado aos gráficos. E isso tem uma lógica própria, porque mais rápido, a tarefa é realizada por alguém que encontrou similar ou idêntico a ela. Como resultado, os desenvolvedores se especializaram em coisas específicas e não são intercambiáveis.

Quanto às metodologias de desenvolvimento e um fluxo de trabalho claro, elas também não foram aplicadas por vários motivos. Partindo do fato de que para isso era necessário dedicar uma quantidade considerável de tempo para refletir sobre todos os conceitos e processos de desenvolvimento, terminando com o fato de que simplesmente não havia ninguém para trazê-lo. Nem eu, como o funcionário recém-chegado, nem os caras tinham autoridade para se reorganizar. E restava apenas resmungar e sonhar.

"Onde há um sonho, há sempre uma chance"

Obviamente, para mim, como uma pessoa que não é indiferente ao seu trabalho, o objetivo era mudar a situação. Caso contrário, qual é o sentido da minha atividade, se eu não puder influenciar positivamente os processos existentes e fornecer condições de trabalho para as pessoas sob as quais elas possam revelar suas habilidades e melhorar? O desenvolvimento daqueles que criam o aplicativo, que incorporam a idéia projetada no papel, na vida é o desenvolvimento dos projetos e da empresa como um todo.

Uma boa chance para a consecução do objetivo foi a aprovação do desenvolvimento de um novo módulo de visualização da nossa plataforma. Este projeto não era como os outros, porque Não foi o desenvolvimento de um aplicativo na plataforma, mas a implementação de parte da própria plataforma. Portanto, aqui não estávamos apegados a esse conceito estranho de armazenar e trabalhar com projetos em muitos repositórios git, o que me pareceu uma grande oportunidade para introduzir revisões de código.

Aqui, a propósito, o que fizemos

E numa bela manhã de inverno, ataquei o arquiteto do projeto com uma proposta para apresentar o Gitflow. No começo, ele considerou minha ideia contraditória, mas havia razões para isso: um modelo padrão nem sempre é adequado. No entanto, no processo de comunicação, a opção mais adequada foi desenvolvida para este projeto, que agora estamos usando com sucesso.

Nosso Gitflow modificado é o seguinte:

existe um ramo principal (chamamos de mestre, mas você pode dar qualquer nome para não ficar confuso);
há um sprint em Jira, formado a partir de tarefas de lista de pendências que são unidas por um micro-alvo;
o desenvolvedor leva a tarefa da lista de tarefas abertas no sprint para o progresso e cria uma ramificação de recurso do mestre, indicando o código da tarefa no nome de sua ramificação de característica (por exemplo, PLAYER-55);
assim que o trabalho na tarefa for concluído, o desenvolvedor envia seu trabalho para revisão: por meio do Gitlab, cria uma solicitação de mesclagem para dominar e transfere a tarefa para o Jira on Review com um link para a solicitação de mesclagem no comentário;
se a revisão for concluída e todas as discussões forem fechadas, a tarefa no Jira será fechada, a ramificação do recurso será mesclada no mestre e excluída;
se houver comentários após a revisão - em Jira, a tarefa é redescoberta da Revisão e o algoritmo é executado desde o início, exceto que o ramo do recurso já foi criado.

Quando todas as tarefas são fechadas, entramos no estágio de lançamento:

a ramificação de liberação é chamada de afastada do mestre, chamada de dois dígitos, por exemplo, release-3.0, em que 3 é o número da versão do projeto e 0 é o número da ramificação de liberação (respectivamente, a próxima ramificação de liberação será denominada release-3.1 etc.) );
Novos testes do candidato a liberação são realizados (geralmente o desenvolvimento de pequenas demos);
se nenhum defeito foi encontrado durante o teste, o candidato à liberação está pronto para produção: a última confirmação na ramificação de liberação é marcada com uma marca de produção que consiste em 3 dígitos (por exemplo, prod-3.0.0, em que 3 é o número da versão do projeto, 0 - número do ramo de lançamento, 0 - número da versão de produção); o ramo de lançamento fica preso no mestre e não é excluído, ao contrário do Gitflow clássico;
se ainda forem encontrados defeitos, eles são registrados no Jira como Bug e o processo de correção de erros é semelhante ao trabalho com uma tarefa no ramo de recursos (só é verificado no lançamento, não no master) e quando todos os bugs são fechados, colocamos a tag de produção, a versão é enviada para o produto e o ramo de lançamento é mesclado no mestre, sem ser excluído.

Caso sejam encontrados erros na produção, também existe um acordo:

o trabalho sobre esses bugs também é realizado no ramo de lançamento desta versão da venda, se as edições forem extremamente urgentes, elas são marcadas como hot fix e são realizadas diretamente no ramo de lançamento com os líderes da equipe;
caso contrário, o trabalho com esses erros é semelhante ao trabalho com erros encontrados no candidato a lançamento.

Então, por que exatamente o Gitflow e exatamente isso?

A inserção de ramificações de recursos é uma maneira de introduzir uma revisão, que permite compartilhar experiências, aumentar o nível geral de qualificação da equipe e, o mais importante, como resultado, para evitar a inserção de código de baixa qualidade no produto final que não possui um estilo comum, é difícil de entender e cheio de bugs.
Acho que muitas pessoas estão familiarizadas com a situação em que o projeto é avaliado de acordo com os termos de referência e especificações, um orçamento é alocado para isso, você implementa a funcionalidade de acordo com os requisitos da documentação, mas aqui, do nada, alguém dos chefes irá aparecer e você ouvirá: "Ah, mas vamos adicionar alguns unicórnios aqui, o cliente vai gostar ”,“ E você pode fazer uma oportunidade de ligar para um amigo nessa região clicando em uma região no mapa? Será uma bomba, prossiga ”,“ Precisamos adicionar uma legenda ”,“ Agora a legenda precisa ser removida e as assinaturas também ”,“ A remoção de assinaturas foi supérflua, devolva-a ”. E tudo isso é "gratuito, sem registro e SMS". E então, ao calcular os custos reais, foi preciso muito trabalho para desenvolver com um número tão pequeno de tarefas (afinal, "solicitações" em Jira geralmente não são registradas, porque nem todo desenvolvedor pode recusar o chefe ou enviá-lo para registrar sua "solicitação" ", E isso pode ser entendido). A introdução da regra de nomeação de ramificações individuais com código Jira e a incapacidade de mesclar ramificações em mestre sem vincular a Jira elimina a presença de trabalho não registrado e conflitos que podem surgir se o desenvolvedor "começar a baixar direitos", exigindo que você preencha a "solicitação" como uma tarefa em Jira, e também permite que você tenha uma idéia clara de quanto trabalho foi realmente executado (as tarefas no Jira são confirmadas pelo código associado a elas, código escrito por comunicação com a tarefa registrada).
A conexão do Gitflow com o Jira em termos de atualização do status da tarefa ajuda a evitar uma situação em que várias pessoas estão realizando a mesma tarefa. No caso de atualizar status de acordo com o estágio do Gitflow, todos verão que essas e essas tarefas já estão em andamento ou em revisão, respectivamente, para elas já existem ramos de recursos nos quais o código está escrito e você não precisa executá-las. Também é claramente visível quem faz o que e o que funciona pode afetar um ao outro, qual dos caras deve entrar em contato e concordar com uma implementação específica com mais frequência, para que quando a fusão não precise resolver longa e dolorosamente os conflitos de seu código.
Como estamos desenvolvendo uma plataforma para a criação de aplicativos, vale a pena considerar que os produtos acabados de alguém dependerão de nossa política de oferecer suporte a versões antigas da plataforma e introduzir novas. É possível que alguns dos usuários da plataforma, por algum motivo, usem a versão mais recente da plataforma e encontrem um bug relacionado à plataforma. Se excluirmos as ramificações da versão, não poderemos ajudar nossos usuários em tal situação, especialmente se as funções que eles usam em sua versão forem excluídas ou modificadas na implementação da nova plataforma. Assim, salvar as ramificações da versão permite fornecer suporte aos usuários que não trabalham com a versão mais recente da plataforma.

E o Agile?

Como você provavelmente já percebeu, começamos a abordar lentamente os princípios de desenvolvimento ágil do scrum, começando com a divisão de tarefas em sprints para micro alvos.

Em seguida, foram apresentados o Planning Poker, Story Points, análise de velocidade da equipe e retrospectiva.
A participação no Planning Poker e a atribuição de Story Points às tarefas permitem que a equipe tenha uma visão mais holística do projeto, a estrutura de sua arquitetura, o que geralmente buscamos e qual deve ser o resultado. As pessoas têm a oportunidade de pensar sistemicamente, e não apenas dentro da estrutura de suas tarefas. Isso afeta favoravelmente o seu desenvolvimento como profissionais e o próprio projeto:

novos recursos úteis são oferecidos, porque fica mais claro para os desenvolvedores o que e onde podem ser melhorados em geral;
mais frequentemente, são encontrados erros e falhas que podem se tornar claramente perceptíveis apenas no momento da operação da plataforma.

Devido à disponibilidade de dados sobre o número de tarefas concluídas no sprint e os Story Points correspondentes, torna-se possível analisar a velocidade da equipe de desenvolvimento para realizar estimativas de planejamento e tempo mais competentes no futuro.

É verdade que há um certo desgosto na estrutura de nosso projeto a esse respeito: a composição da equipe muda com frequência, porque alguns desenvolvedores são periodicamente retirados para projetos urgentes, substituindo-os por tarefas livres. Por esse motivo, a estimativa de velocidade é redefinida sempre. É quase impossível contar em tais condições. A única maneira que eles criaram é coletar dados de cada composição para 3-4 sprints e, em seguida, tentar identificar o valor médio.

"E vamos rapidamente" ou 3 aplicativos de demonstração completos por um mês

Obviamente, ninguém cancelou o desenvolvimento de aplicativos. Especialmente se forem necessários para atingir os objetivos globais da empresa. Especialmente se for muito urgente. E, recentemente, a necessidade de implementação rápida de aplicativos de demonstração para shows aumentou significativamente.

É claro que, tendo trabalhado em um novo paradigma, eu não queria voltar a conversas antigas. Decidimos então usar partes do novo módulo de visualização (como um sistema integrado, ainda não estava totalmente preparado para essas tarefas), tomando os princípios de seu desenvolvimento como um guia.
Como nem todos os desenvolvedores ainda estavam no tema do fluxo de trabalho, e adaptar os caras ao novo dispositivo de desenvolvimento era um grande risco em termos de tempo de nossas demos "ardentes", tentamos encontrar um certo "meio termo" entre o passado e, esperançosamente, o futuro. Como resultado, eis o que aconteceu com o uso parcial dos princípios do novo módulo de visualização em demos:

Pequenas equipes. 2-3 desenvolvedores, designer, testador e gerente.
Desenvolvimento paralelo (os controles anteriores foram criados primeiro, depois os modelos com a aparência e a lógica do aplicativo).
Usando tarefas como História no Jira. Como não havia especificações claras e TK, coletei todas as informações disponíveis sobre o comportamento e a aparência esperados do aplicativo e coloquei tudo no Story. Em seguida, eles foram testados, o que causou uma reação positiva entre os testadores, porque todas as informações foram coletadas em um único local, mas ao mesmo tempo foram divididas em partes funcionais, o que facilitou a verificação. E a equipe como um todo não precisou ler um monte de texto oficial para entender e concluir a tarefa corretamente. Além disso, ao contrário dos documentos do Word com especificações, o Story foi atualizado mais rapidamente, as pessoas receberam descrições com novos refinamentos e, consequentemente, começaram a implementá-las mais rapidamente.
Gitflow com ramificações de desenvolvimento e master, mas sem recurso:

todo o desenvolvimento foi realizado no ramo de desenvolvimento, mas, a fim de excluir a presença de tarefas não registradas, cada confirmação deve ter sido marcada com o código de tarefa do Jira, no qual foi realizado;
quando todas as tarefas planejadas para a liberação foram resolvidas, uma nova compilação estava sendo montada: um líder de equipe conduziu uma revisão da ramificação de desenvolvimento e, se tudo estivesse bem lá, as alterações foram mescladas no mestre com a atribuição de uma tag com o número da compilação. Se erros e irregularidades graves foram revelados durante a revisão, o código foi enviado para revisões e somente depois que foram inseridos e verificados novamente, ele entrou no mestre.
as construções foram numeradas com dois dígitos, por exemplo, 0,1 - este é sempre o número da primeira construção de teste, onde 0 - significa pertencer à versão de produção, 1 - número da construção. E assim, no número de cada construção de teste seguinte, o último dígito aumentou, até que o testador e o gerente concluam que a construção está pronta para saída na produção. Portanto, se essa foi a quarta versão de teste (0.4), ela se tornou a primeira versão de produção (1.0) e a tag correspondente foi colocada na ramificação principal. Se forem detectados defeitos na produção e a construção da produção foi enviada para edição, o segundo dígito também aumentará ao numerar todas as construções subseqüentes (1.1, 1.2, etc.).

Assim, ao longo de um mês, implementamos três aplicativos de demonstração completos, que receberam críticas positivas e que continuam sendo úteis. Anteriormente, não era possível implementar essa funcionalidade tão rapidamente e com tantas pessoas na equipe.

Na minha humilde opinião

O que eu pessoalmente penso sobre isso?

Que a organização dos processos realmente afeta o resultado e que ouvir o mundo das práticas de desenvolvimento, inventado pelos próprios desenvolvedores e orientado a eles, não é apenas "estiloso, moderno, jovem", mas necessário (depois de passar as demos, pela primeira vez em vários anos de prática, continuamos fazendo o resto projetos, e não sentou até a noite mais duas semanas após a entrega, suando a face da pilha descoberta pelos defeitos vergonhosos do cliente).
O nível de caos, incompreensão e estresse em projetos com um fluxo de trabalho claro é menor (as pessoas estão melhor equipadas com informações relevantes, elas sabem onde obtê-las, se necessário).
O uso adequado das ferramentas de gerenciamento de projetos afeta o desenvolvimento dos projetos em si e de seus participantes (devido à otimização do desenvolvimento no Gitlab, Jira, à introdução dos princípios do scrum ágil, tornou-se possível trocar experiências em uma equipe, bombear habilidades em uma equipe, mais frequentemente o conhecimento e a experiência dos líderes de equipes juniores foram transferidos e desenvolvedores intermediários).

Aqui está o segredo

Apesar das conclusões acima, e algo mais se tornou óbvio para mim:

- Nem todo mundo está pronto para o que sonha.

Às vezes, quando observamos algo de lado, parece-nos que isso é algo bom, útil, necessário para o sucesso, a correção e a referência. Mas o sonho vale a pena se tornar realidade, como o entendemos: "Não foi isso que imaginei". Assim, no trabalho: parece que agora lhe proporcionamos condições nas quais "empresas normais" trabalham e você florescerá. Mas infelizmente. E acontece que você, sem poupar energia, tenta dar às pessoas algo que elas sonharam como garantia de sucesso, mas um milagre não acontece: o trabalho ainda não é feito em alta qualidade e você entende que pode ter aceitado alguém típico palavras de apoio a uma conversa na cozinha para aspirações e sonhos reais.

Portanto, no processo de introdução de novas regras e princípios, fomos confrontados não apenas com feedback e resultados positivos, mas também com uma percepção negativa do que estava acontecendo. Para alguns, trabalhar com Jira e Gitlab parecia muito barulhento, e mudar essa percepção foi extremamente difícil até que as pessoas se depararam com uma situação problemática que ocorreu devido à ignorância do fluxo de trabalho geralmente aceito.Algumas tarefas ainda eram realizadas de maneira descuidada, as descrições na História e as definições de tarefas não eram levadas em consideração ou percebidas como “solicitações pessoais” e não eram executadas, apesar de se registrar com Jira com uma declaração clara. Em geral, as compilações com implementação de configuração inadequada ou de baixa qualidade ainda surgiram, e alguns erros foram reabertos de compilação para compilação. Embora o resultado final tenha sido positivo em todas as demos, eu ainda pensava no fato de que, com os responsáveis pelo trabalho, que se preocupam em dar o maior resultado possível, conseguimos não apenas implementar a funcionalidade necessária, mas também introduzir novos recursos, otimizar o aplicativo e "Adicione ryushechek." E com equipes nas quais alguém pode se dar ao luxo de ter preguiça ou menos interesse em obter o resultado da mais alta qualidade,implementamos apenas a funcionalidade básica e alguns pequenos recursos, mediante solicitação adicional do cliente após a entrega.

Foi então que, talvez, minha conclusão mais importante chegou a mim:

- Não é um processo, não é a tecnologia - as verdadeiras chaves do sucesso, mas aqueles que criam, criam, incorporam a idéia em realidade, - pessoas e sua atitude em relação ao trabalho. Um músico que coloca sua alma em seu trabalho afetará o público, tocando até o instrumento mais barato e mais desconfortável. E dê a ele Stradivari - ele enlouquecerá o público. E há quem até o Stradivarius, pelo menos, forneça o mais recente desenvolvimento dos principais fabricantes de ferramentas - tudo parecerá sem importância.

Você pode fornecer às pessoas condições confortáveis e tecnologias de ponta, mas no final obtém um resultado insatisfatório de suas atividades, porque "e assim por diante". E é possível que, se não houver as tecnologias mais bem-sucedidas e, às vezes, até dificultando a implementação competente, você possa obter um resultado decente, porque aqueles que a alcançaram não podem se dar ao luxo de entregar um trabalho inacabado ou mal feito. E é muito importante discernir, apoiar esses membros da equipe, poder ouvi-los e criar condições favoráveis para suas atividades.

A tecnologia e a organização dos processos realmente têm um impacto no resultado e são muito importantes, mas a principal chave do sucesso está em pessoas talentosas, responsáveis e orientadas para o desenvolvimento.