Como parar de pegar ovos com pressa, ao mesmo tempo que cai prazos? Qual conjunto de ferramentas escolher para destruir várias tarefas ao mesmo tempo? Vamos revelar tudo isso em nosso artigo.

Tentando pegar todos os ovos

Naqueles dias em que nossa empresa estava emergindo no útero de vidro do escritório, e a equipe tinha apenas três pessoas (um gerente e dois desenvolvedores), entusiasmadas e ricas em café, não tínhamos absolutamente nenhuma metodologia de gerenciamento de projetos e agimos com pressa, aproximando o trabalho do princípio de “uma pessoa - um projeto”. Ao mesmo tempo, não era nem o fato de que os desenvolvedores, interagindo na mesma tarefa, mantinham partes de código separadas entre si, e todo o cenário do ambiente de desenvolvimento dependia da máquina do desenvolvedor. Como repositório e sistema de controle de versão, usamos o SVN , que na época era mais como uma pasta com arquivadores zip. Apesar do SVN ser um dos maiores sistemas de controle de versão e ter uma comunidade apropriada, sua funcionalidade nos convinha apenas em termos de preservação do código; caso contrário, tudo era um pouco ruim: não havia versão local e a capacidade de mesclar o código. Portanto, começamos a procurar algo mais adequado ao nosso apetite - o desenvolvimento do processo de trabalho começou. A primeira coisa que precisou ser abordada foi o planejamento e a definição de tarefas, bem como sua distribuição entre si, a fim de se afastar da monoprojetividade para o desenvolvimento conjunto e manutenção de prazos. Naquele momento, o único tipo de planejamento eram as reuniões com os cadernos. Com essa abordagem, antes da eficiência e eficiência serem como a lua no cossaco, alguém conseguiu anotar tudo, alguém esqueceu ou esqueceu. Como resultado, as pessoas saíram da reunião sem uma compreensão clara do que e como fazer, com um monte de informações em suas cabeças e alguns rabiscos em um caderno.

Selecionamos uma cadeia de ferramentas

A primeira etapa na redução da entropia do fluxo de trabalho foi criar um repositório normal para trabalhar juntos em projetos e conectar as partes individuais do código. Jogamos fora um antigo SVN e aumentamos o GIT na máquina local do nosso CEO. Para visualizar e conectar o código, use utilitários simples do console. Não era muito conveniente, mas pelo menos permitia manter a ordem e a transparência das mudanças no projeto.

Ainda tínhamos problemas com o planejamento e, como resultado, com prazos. Para isso, foi necessário encontrar um meio de decompor tarefas e exibir o status de sua implementação. Uma tentativa de resolver esse problema foi o uso do aplicativo de gerenciamento de projetos RedMine, a partir do qual o benchmarking ativo da cadeia de ferramentas começou. O utilitário era adequado para desenvolvedores (recursos de gerenciamento de projetos, fóruns, rastreamento de bugs), mas, infelizmente, era muito difícil para os gerentes. Os desenvolvedores constantemente precisavam processar todas as informações (merzhrekvesta, pullrekvesta etc.) do SUV e inseri-las no programa RedMine , para que os gerentes pudessem acompanhar o grau de conclusão da tarefa. Além disso, não havia funções adicionais suficientes de gerenciamento de projetos, então começamos a olhar para o FengOffice .

A ferramenta possuía uma gama bastante ampla de funcionalidades, possibilitando a ideia de combinar ferramentas de comunicação e planejamento como um gráfico de Gantt em um único sistema de trabalho. No entanto, com todo o equipamento deste produto, os desenvolvedores tiveram que fechar manualmente as tarefas, enquanto simultaneamente compilavam estatísticas por conta própria, pois não havia sincronização automática das tarefas executadas. Além disso, a implementação do bate-papo interno era mais uma versão antiga semelhante do ICQ do que um bate-papo corporativo normal, mas para nós esse momento foi muito importante.

Entendemos que, para que todo o mecanismo funcione em harmonia, reuniões simples claramente não são suficientes. Havia a necessidade de selecionar ferramentas operacionais para estabelecer breves comunicações, necessárias mesmo para as pessoas sentadas próximas uma da outra na mesma sala. Dois pontos surgem aqui: o primeiro - se você realizar conversas curtas no formato usual, elas ocuparão muito tempo de trabalho, o que significaria Olá para o colapso de todos os prazos e um atraso grave no cronograma, e o segundo - se você fizer um mínimo de interações curtas, isso levará à perda comunicação estreita entre os membros da equipe, inconsistência de suas ações, duplicação de código e outros problemas. Portanto, chegamos a uma solução simples - transferir microconferências para um bate-papo em equipe, que permite a comunicação constante sem uma grande distração do fluxo de trabalho, coordenar as ações dos desenvolvedores e evitar a execução repetida das mesmas tarefas, além de disputas sobre quem executou a tarefa melhor. A solução pode parecer óbvia e trivial, mas o assunto não está nos meios de interação, mas na abordagem e qualidade do uso da ferramenta. A questão era como transformar o bate-papo de um local de inundação e queima em um substituto parcial para reuniões e conversas pessoais.

Enquanto isso, o GIT usual não era suficiente, havia uma forte falta de uma interface da web. Tínhamos duas opções no menu: um repositório privado no GitHub e um repositório no GitLab. O GitLab é gratuito - e eles o aceitaram. Ele também tem uma comunidade legal e amigável. Além disso, o GitLab já possuía um sistema interno de agendamento de tarefas e fornecia uma interface conveniente para o merzhrekvest. Se você trabalhou em equipe, provavelmente sabe como é importante obter rapidamente um merzhrekvest aprovado. Por fim, enterramos o FengOffice e nos instalamos no GitLab. Além disso, naquela época, já usamos o Slack como um bate-papo em equipe, e como o GitLab planejava integração mútua com o Slack, e tudo isso também era gratuito, a escolha para nós se tornou mais óbvia do que nunca.

Os livros não mentiram

Então chegou o momento em que foi necessário escolher a metodologia mais adequada para o nosso gerenciamento flexível de projetos. Decidimos duas das abordagens mais desenvolvidas e populares: Kanban e Scrum. A iniciativa veio inteiramente do nosso CEO, Ilya Bykoni, que, com o fogo de prometheus nos olhos, conversou com a equipe sobre as próximas mudanças. Mas, para sua grande surpresa, a equipe, a princípio, conheceu inovações, quando os espartanos encontraram Xerxes, com uma teimosia feroz de cópias conservadoras. O que você pode fazer, ilusões, ilusões, porque nos livros eles advertiram ... Um fato interessante foi imediatamente notado que uma atitude negativa em relação a novas abordagens não se correlacionava com a adequação e capacidade das pessoas para trabalhar. Até os jovens juncos, que deveriam entender tudo isso com facilidade, resistiram, argumentando que: "eles programavam melhor por 15 minutos do que gastariam esse tempo no dia seguinte", "por que você precisa planejar, se os prazos de qualquer maneira não são executados ou estão sendo executados, mas com desvios "," por que o desenvolvedor de front-end deve ouvir sobre o back-end ", etc. O fato é que a metodologia de abordagem ágil implica um estilo de trabalho no qual é impossível sentar nos ombros de um desenvolvedor forte na Atlântida e chegar ao projeto com base em suas habilidades, como muitas pessoas estão acostumadas a trabalhar, para que essas mudanças se tornem para eles. doloroso.


Quando começamos a introduzir o Agile no trabalho, sentimos plenamente o valor das comunicações curtas e de alta qualidade. Muitas vezes acontece que quando tarefas semelhantes vêm da entrada do departamento de RnD de várias fontes, os gerentes de projeto não conseguem capturar duplicatas. E aqui, interações de curto prazo e comícios diários, que protegem completamente contra esses problemas, começam a desempenhar um papel muito importante, identificando um terreno comum entre os desenvolvedores de diferentes equipes. Há outro ponto interessante - a maioria dos programadores é introvertida, ou seja, qualquer comunicação é microestresse, especialmente quando se trata de comícios em grandes equipes, onde uma pessoa precisa falar com uma ampla audiência de diversos especialistas. E muitas pessoas, com medo de tanto desconforto, não percebem que a alternativa para reuniões tão curtas pode ser ainda mais desagradável que a diária. Isso será substituído pela comunicação constante ao longo do dia, na tentativa de levar o trabalho a um processo controlado. Concluímos que o Agile leva em consideração a introversão dos desenvolvedores e reduz ao mínimo o desconforto associado à necessidade de comunicação. Obviamente, para os jovens funcionários da empresa, em qualquer caso, isso será estressante por algum tempo até que ele se aprofundar nas especificidades de seu trabalho e conheça a equipe mais de perto, portanto, quanto mais amigável e eficiente a cultura Agile estiver na empresa, mais rápido o processo de adaptação terminará.

Um pau dói, muitos paus são mortais

Uma das principais motivações de uma abordagem flexível é que as pessoas se acostumem a minimizar seus truques e erros. O fato é que, se você adota a estrutura de gerenciamento vertical padrão, o desenvolvedor é responsável por seus erros para o chefe imediato que castiga e "bate com um pau na cabeça" se o funcionário fingir ou "acariciar a cabeça" se tudo for feito com clareza. Ou seja, na estrutura vertical, uma pessoa tem a opção de se recuperar devido a relacionamentos pessoais ou "biscoitos saborosos". No Agile, a interação da equipe é construída horizontalmente, o que significa que uma pessoa precisa se reportar a toda a equipe em comícios diários. Ele estupidamente não tem dinheiro suficiente para tantos biscoitos. Portanto, você deve se acostumar com o fato de que seus erros serão analisados ​​por seus colegas, ou você estará em um cavalo e eles derramarão pétalas de rosa em você a partir do elogio de seu profissionalismo, ou você estará embaixo de um cavalo ... De qualquer forma, este é um forte bombeamento das habilidades pessoais de uma pessoa, e se a atmosfera da empresa estiver quente o suficiente, a pessoa começará a se abrir lentamente, contribuindo cada vez mais para o ecossistema de seu departamento e da empresa como um todo. Também experimentamos com a experiência o efeito de filtragem do Agile, mais de uma vez confrontado com uma situação em que desenvolvedores objetivamente fracos não conseguem suportar a análise constante de seus erros e acabam se fundindo se percebem que não têm motivação e força internas para para mudar do status do bagodel para o status do bogacode.

Resumir

Devo dizer que o processo de criação de uma máquina ágil acabou por ser bastante demorado e estressante, "não poderia ter acontecido sem violência" - inicialmente as pessoas tinham que ser praticamente orientadas a apoiar manifestações e eventos diários, para que as pessoas começassem a expressar sua posição sobre as tarefas que estavam resolvendo. Embora constantemente tenhamos que "subir debaixo do capô" e mexer no "motor", sujando as mãos no óleo combustível, vale a pena quando a equipe aumenta a velocidade e corre para a frente, coletando o ponto de verificação para o ponto de verificação. Não paramos nossa evolução nem por um segundo, estamos sempre no status de remetentes eternos, estudamos constantemente novos e modificamos os modelos existentes de gerenciamento e interação entre os funcionários. Uma coisa que entendemos absolutamente com certeza - onde não há movimento e luta, não há vida. Como dizem os monges zen: "Cheguei ao cume, continue a subida ..."

PS:

Aqui está uma lista de amostra e o cronograma das etapas que executamos:

1. Formação de planejamento ~ 4 meses
2. Trabalhe com comunicações curtas ~ 1 mês
3. Procure um desenvolvimento adequado de cadeia de ferramentas e fluxo de trabalho ~ 2 meses
4. Escolha da metodologia ~ 2 meses
5. Introdução do Scrum ao fluxo de trabalho ~ 8 meses

E aqui está uma pequena seleção do nosso CEO:

1. Compreendendo o Agile - Andrew Stellman e Jennifer Green
2. “O Caminho do Scrum-Master” - Zuzan Shokhov
3. “Scrum, um método revolucionário de gerenciamento de projetos” - Jeff Sutherland
4. “Caminho alternativo do Kanban para o Agile” - David Anderson
5. “À frente da transformação. Aplicação dos princípios do Agile e DevOps em toda a empresa "- Harry Gruver e Tommy Mauser