Abrandar para impulsionar o desenvolvimento

Do tradutor:
O início do ano é um ótimo momento para avaliar cuidadosamente o ano passado. Dê uma olhada no que está acontecendo e entenda como tornar 2019 um ano melhor, mais calmo e produtivo. Nesse caso, achamos útil o artigo Como desacelerar para ir mais rápido do que nunca em Desenvolvimento de Software, escrito por Lemi Orhan Ergin . E publicamos a tradução dela abaixo.

Pontos-chave:

• A pressa não nos torna mais rápidos ou mais eficientes; aumenta o estresse e torna impossível o foco. Em vez de se apressar, você precisa de uma abordagem criativa, eficiência e foco.
• Contrate os especialistas mais talentosos, trabalhe em conjunto, pratique e estude em conjunto. Isso aumentará o profissionalismo e criará uma cultura de excelência na empresa.
• Crie flexibilidade da equipe e eficiência do processo, fazendo planos e revendo-os regularmente. Encontre, analise e elimine qualquer fonte de perda de tempo.
• Você não pode ser flexível sem uma base de código de qualidade. Elimine defeitos, libere versões com mais frequência, escreva testes antes de escrever o código principal, realize refatoração, concentre-se em um design simples.
• A execução de software não significa bem projetado. Somente profissionais verdadeiros podem criar software de alta qualidade que permitirá que você desenvolva o mais rápido possível.

A execução mais rápida possível de tarefas pode se tornar seu inimigo se você se envolver no desenvolvimento incontrolavelmente. Existem três áreas importantes para diminuir a velocidade: pessoas, processos e produtos. Antes de mergulhar nos detalhes, deixe-me contar uma história.

Tanto quanto me lembro, era 2011. Entrei para a equipe que criou a plataforma de marketing online. Minha principal tarefa era adicionar novos recursos o mais rápido possível. Eu era desenvolvedor sênior. Nós chamamos os desenvolvedores de "seniores" quando se desenvolvem mais rápido do que outros, certo? No entanto, quando comecei a trabalhar, percebemos que era quase impossível trabalhar rapidamente devido a dívidas técnicas e falhas no design do sistema. Também observamos que, a cada tentativa de acelerar, aumentamos a complexidade e destruímos a qualidade. Cheguei à conclusão de que a única maneira de acelerar é reescrever o sistema do zero.

Lembro-me de que, durante uma conversa telefônica com o gerente de produto, eu disse que precisávamos reescrever todo o sistema. Após 30 segundos de silêncio, o gerente perguntou: "Você diz que sua equipe desenvolveu um produto de tão baixa qualidade que agora essa mesma equipe deve reescrever o mesmo produto novamente, mas desta vez é melhor fazê-lo. Certo? Desculpe, mas isso é inaceitável. Você deveria ter escrito melhor agora.

O software Zombie precisa ser reescrito repetidamente

Segundo o Chaos Report do Standish Group , 94% dos projetos foram refeitos do zero mais de uma vez. Este é um número enorme. Lembrando os projetos em que trabalhei, entendo que quase todos foram reescritos do zero usando novas tecnologias, com nova arquitetura e design. Copiar do zero é tão típico do nosso setor que as empresas costumam vê-lo como a única maneira de desenvolver e gerenciar um projeto. Primeiro, escrevemos e depois reescrevemos e reescrevemos, repetidas vezes.

Precisamos conhecer nossos principais inimigos. A velocidade é uma qualidade vital no desenvolvimento de software. É importante não apenas entrar no mercado primeiro, mas também responder rapidamente às críticas dos clientes, adicionar recursos e corrigir bugs para que os usuários fiquem satisfeitos com o produto.

Mas todos nós temos problemas com o conceito de "velocidade". Acreditamos que ações rápidas e razoáveis ​​e efetivas estão de alguma forma relacionadas ao estabelecimento de prazos. Acreditamos que o resultado será alcançado mais rapidamente se você trabalhar mais ou atrair mais pessoas. Como resultado, adicionamos novas pessoas ao projeto ou trabalhamos horas extras para acelerar o trabalho. A pressa não nos torna mais rápidos ou mais produtivos. A pressa cria uma atmosfera estressante, nos priva da oportunidade de focar no trabalho e destrói a produtividade. O que é necessário é criatividade, eficiência e concentração.

O desenvolvimento de software é uma coisa muito complicada. Não podemos nos livrar dessa complexidade. Portanto, precisamos viver com ela. A exigência de trabalhar rapidamente cria uma atmosfera instável e turbulenta, mergulha-nos no estresse e torna impossível o trabalho produtivo e intenso. Essa abordagem simplesmente não funciona.

Produtividade (capacidade) da equipe, plano diretor, estimativas de custos de mão-de-obra, horários fixos de trabalho, prazos e velocidade da equipe (velocidade da equipe) - tudo isso é ilusório. Incompetência é real. A velocidade da entrega depende diretamente do profissionalismo das pessoas, da eficiência dos processos e da qualidade do trabalho realizado. Na maioria das vezes, os próprios desenvolvedores estabelecem prazos internos para si mesmos, mesmo que isso não seja necessário.

Como resultado, obtemos um sistema legado. A pressão dos prazos combinados com a incompetência leva a um código legado - um beco sem saída para o desenvolvimento adicional do sistema. Eu costumava usar outro nome para sistemas legados - software zumbi. Essa definição funciona melhor, porque o legado é literalmente um software morto, mas parece funcionar na produção. Funciona e até gera dinheiro, mas requer o sangue, a vida e a energia dos desenvolvedores para funcionar de alguma forma. Os desenvolvedores têm medo de tocar no código que funciona, ninguém deseja desenvolvê-lo.

Robert C. Martin falou muito bem sobre sistemas legados em seu twitter : "Se o seu software está ficando cada vez mais difícil de desenvolver, você está fazendo algo errado". Trabalhando com pressa, reduzimos tanto a qualidade que, a cada passo, o trabalho diminui cada vez mais. Estou certo de que a única maneira de desenvolver mais rápido é desacelerar o processo até alcançarmos a estabilidade.

A pressa no desenvolvimento de software é má

Em uma série de CleanCoders, Robert C. Martin disse : "O principal valor do software é a capacidade do sistema de se adaptar a mudanças futuras e simplificar sua implementação". A pressa é má no desenvolvimento de software. Qualquer tentativa de apressar levará a uma queda séria na produtividade, foco, eficácia das pessoas, adaptabilidade às mudanças e flexibilidade do software.

Por exemplo, sempre temos tempo para corrigir bugs, mas não há tempo para escrever testes. Não refatoramos nem escrevemos testes porque temos pouco tempo. Mas sempre temos tempo para depurar, dirigir de muletas e corrigir bugs.

Estamos tão focados no processo que muitas vezes esquecemos os mais valiosos para o desenvolvimento de software - as pessoas. Os processos ajudam as pessoas a criar melhores produtos, aumentar a motivação e cultivar um ambiente de trabalho saudável. Por fim, a eficiência do processo é importante, mas não há nada mais valioso que as pessoas.

Você deve entender que ninguém e nada são perfeitos. Clientes, executivos, gerentes, membros da equipe, representantes de negócios e até você não são todos perfeitos. Requisitos, documentação, ferramentas, código, um sistema desenvolvido e seu design também nunca serão ideais. Portanto, devemos parar com pressa e acelerar o desenvolvimento sem pensar. A única maneira de avançar mais rapidamente em um ritmo constante é desacelerar em três direções importantes:

• Pessoas - aumentando profissionalismo e habilidade,
• O processo está melhorando a flexibilidade e a eficiência,
• Melhoria e automação da qualidade do produto.

Onde diminuir a velocidade quando se trata de pessoas

Processos e ferramentas não criam um produto. As pessoas fazem isso. Vale a pena reconhecer que “contratar talentos” é a tarefa mais importante da empresa, com impacto direto no futuro da empresa como um todo e no produto criado em particular.

Contrate os mais talentosos da sua organização. Dizendo "o máximo", não quero dizer o mais inteligente e o mais experiente. Estou procurando pelo menos entusiasmado, disciplinado e motivado. Se uma pessoa tiver essas três qualidades, ela desenvolverá facilmente seus talentos.

A contratação deve ser benéfica para ambas as partes. Portanto, diminua a velocidade do processo de contratação e reserve um tempo para aprimorá-lo. As pessoas ingressam em empresas nas quais acreditam. Simule que tipo de pessoas você espera ver em sua equipe. E faça com que pessoas talentosas acreditem em você, observando sua cultura, sua ideia de futuro e seus funcionários.

O ego é o veneno que mata lentamente sua organização. Nunca deixe isso se infiltrar na sua organização. Começando com tolos que são agradáveis ​​na comunicação e terminando com idiotas brilhantes - não deixe extremos se tornar parte de sua equipe. Não contrate pessoas com um ego inchado. Com eles, você nunca criará uma cultura corporativa que irá deliciar os outros.

Parem de trabalhar sozinhos, trabalhem juntos. Não permita fragmentação na equipe. Solitários e desenvolvedores de heróis são um sinal de organização disfuncional. Sente-se por perto. Estabeleça padrões com toda a equipe. Trabalhe em pares ou grupos; rever juntos. Permita que todos os participantes do processo sejam responsáveis ​​pelo resultado.

Praticar juntos é a maneira mais eficaz de aprimorar suas habilidades. Ao interagir, não apenas inspiramos outras pessoas, mas também aprendemos umas com as outras. Execute regularmente retiro de código , codificação dojo e randori com toda a equipe. Passe 30 minutos todos os dias apenas praticando.

Deixe o conhecimento se espalhar entre as pessoas. Aprenda juntos. Realizei sessões Brown Bag / Lunch & Learn com todas as equipes em que trabalhei desde 2010. Ouvi duas vezes de meus colegas: "Participar de sessões às quartas-feiras me permite bombear, e isso me motiva muito". Isso reflete claramente os benefícios de manter mitaps internos regulares.

Obtenha feedback e dê a outros. Para coletar feedback coletivo, organize uma Grande Retrospectiva. Faço isso há mais de um ano. A propósito, essa é uma ótima maneira de mergulhar na solução de problemas com um grupo de 20 ou mais pessoas.

Ensinar os outros e compartilhar conhecimento é a melhor maneira de alcançar o domínio. Fale publicamente e contribua para a comunidade.

É geralmente aceito que os desenvolvedores odeiam escrever documentação. Mas a realidade diz o contrário. Qualquer resultado que outras pessoas leem é documentação. Começando pelo código do sistema e terminando com o código de teste, das mensagens às confirmações no gráfico de confirmação no repositório, das mensagens de log às mensagens de erro, os desenvolvedores criam muita documentação sem perceber. E, não importa o que você documente, se as pessoas o lerem - documente da melhor maneira possível.

Vocês não são filhos. A organização não é seus pais. Todos devem gerenciar suas carreiras de forma independente e investir em si mesmos. Se sua contribuição envolve desperdiçar tempo ou dinheiro, faça você mesmo.

Como desacelerar e melhorar o processo

Todos os dias nos deparamos com novos desafios. Essas não são apenas necessidades do mercado e novos requisitos de produtos. Os desafios técnicos também afetam nosso progresso.

Planos não são nada, mas planejar é tudo. Faça um plano e revise-o constantemente. Especialmente nos estágios iniciais de um projeto, quando é necessária a máxima flexibilidade. A reconciliação diária com um plano como scrum diário ou standup diário não é suficiente. É necessário interagir mais de perto com a equipe, trabalhar em pares e consultar o plano com mais frequência. Mantenha a duração mínima da iteração até uma semana. Organize vários canais de feedback com sessões regulares de revisão e demonstração.

Definir metas de curto e longo prazo. Objetivos de curto prazo definem o foco da equipe, objetivos de longo prazo impedem sua perda.

Se você quiser entender por que algo está errado, visualize o fluxo de trabalho, tanto do ponto de vista técnico quanto organizacional. Visualize erros e falhas para maximizar o aprendizado em primeira mão.

Nunca tome decisões com base em sentimentos. Sempre colete dados, analise e tome decisões com base neles. Também é importante conceder a cada desenvolvedor acesso a métricas técnicas e do produto. Isso aumenta o envolvimento e a compreensão do produto que está sendo desenvolvido.

Desperdício é tudo o que você gasta, mas que não tem valor para os negócios. Encontre e elimine desperdícios no escritório, no código e nos processos de negócios.

Escoteiros deixam o estacionamento mais limpo do que quando chegaram. A mesma filosofia se aplica ao desenvolvimento de software. Siga a regra do escoteiro e mantenha o código mais limpo após cada alteração. Se você deseja adicionar novas funcionalidades e ver falhas no arquivo que podem ser corrigidas, faça isso sem pedir permissão. Lembre-se de escrever os testes primeiro. Isso lhe dará confiança para fazer alterações.

Você pode descobrir o desperdício em qualquer ponto do ciclo de desenvolvimento do sistema. Siga critérios claramente definidos para prontidão (definição de concluído) e elimine tarefas com o espírito de "90% finalizados, 90% restantes".

Não permita o surgimento de galhos de vida longa - eles são considerados maus. Não verifique seu código manualmente. Com o teste manual, é provável que você verifique um script de execução bem-sucedido. Todos os outros scripts podem ser verificados apenas usando o código. Portanto, leve esse problema a sério.

Como a desaceleração pode melhorar a qualidade do produto

Uma coisa é certa - sem uma base de código de alta qualidade, você não pode ser flexível, desculpe. A primeira coisa a fazer é eliminar a dívida técnica e corrigir erros. Se necessário, faça uma pausa no desenvolvimento de novos recursos e concentre-se na correção de bugs.

A abordagem "corrigirei rapidamente, corrigirei" não funciona nas realidades atuais, porque é muito arriscada. Ao eliminar erros, é necessária uma abordagem mais disciplinada. Primeiro de tudo, escreva um teste que reproduza o problema. Depois disso, corrija o erro e verifique se o teste passou agora. Agora você pode enviar o patch com segurança para produção.

Trabalhei em equipes que passaram quase o tempo todo consertando bugs e mantendo o projeto. A razão de seu sofrimento é um trabalho instável na produção. Para continuar desenvolvendo novas funcionalidades, enquanto corrige erros, você precisará dividir a equipe em equipes virtuais. Por exemplo, em cada iteração, selecionamos dois indivíduos envolvidos no suporte e na correção de bugs. Nós os chamamos de Batman e Robin. Não importa qual funcionalidade você esteja com pressa para concluir, os bugs são corrigidos sem interrupção do desenvolvimento principal.

Os desenvolvedores costumam usar uma das práticas de desaceleração para acelerar ainda mais as solicitações. Eles interrompem o desenvolvimento contínuo, executam verificações e conduzem análises de código para melhorar a qualidade do código. Código não verificado nunca atingirá a produção.

Nosso objetivo final deve ser a transição para a entrega contínua e lançamentos frequentes. Começando com o uso de git branches e terminando com estratégias de implantação, de maneiras de fornecer feedback a práticas de teste automatizadas - tudo isso requer uma abordagem especial.

As práticas usadas em diferentes estágios do ciclo de desenvolvimento de software mostram a rapidez com que você está desenvolvendo. Ao trabalhar com ramificações, use a abordagem "confirmar cedo, confirmar frequentemente, aperfeiçoar mais tarde, publicar uma vez". Se estiver trabalhando sem ramificações, use Alternâncias de recursos. Isso eliminará a perda de tempo.

Uso TDD há anos. Muitas vezes, as pessoas reclamam que o TDD afeta negativamente a velocidade do desenvolvimento. Joe Rainsberger compartilhou seus pensamentos sobre o TDD no twitter : “ Você está preocupado que o TDD diminua a velocidade dos seus programadores? Não precisa. Eles provavelmente precisam desacelerar.

TDD é mais refatoração do que teste; mais pensamento do que codificação; mais simplicidade do que elegância. É por isso que o TDD leva a uma qualidade superior. Ao usar o TDD, você terá apenas o número mínimo suficiente de testes e um design simples.

Você já alcançou 100% de cobertura do código com testes? Eu cheguei em um projeto de três meses, cobri todas as linhas de código de produção com testes. Naquele momento, me senti um herói com superpotências. Porém, quando implantamos o sistema na pré-produção para testes de aceitação, percebemos que as quatro funções não funcionavam. Escrevi testes funcionais e de integração para encontrar e corrigir erros. Naquele momento, percebi que os testes de unidade não garantem um bom design e funcionalidade funcional. Pare de contar a porcentagem de cobertura do código como testes. Essa métrica não mostra nada.

Corrija os erros imediatamente se demorar 30 minutos ou menos. Além disso, use 20% do tempo para eliminar a dívida técnica.

Como regra, escrevemos código sem a intenção de alterá-lo no futuro. Ao projetar um sistema, também escolhemos tecnologias e ferramentas, planejando não alterá-las no futuro. Mas estamos enganados. A refatoração deve ser possível em qualquer estágio do projeto. Como Kent Beck diz, precisamos fazer alterações fáceis para que outras alterações sejam fáceis. Para tornar isso possível, armazenamos o código de todos os nossos microsserviços em um repositório mono. Isso torna a refatoração fácil e realmente necessária.

Qualquer decisão no design é errônea se for tomada antes do que se tornou necessário. Você deve esperar o último momento aceitável para tomar uma decisão. Usamos a arquitetura “Portas e adaptadores” para obter baixo acoplamento e alta coesão no nível de design de todo o sistema. Devido a isso, obtemos monólitos perfeitamente projetados.

Um monólito não é mau, o mal é um desígnio ruim. Começamos sempre com o desenvolvimento de um monólito e, graças à arquitetura de "portas e adaptadores", extraímos parte da funcionalidade em microsserviços. Como Martin Fowler disse em seu artigo Monolith First : “Começar com a arquitetura de microsserviço imediatamente é arriscado, é melhor você começar com um monólito. Divida em microsserviços somente quando e se necessário. ”

Abrandar para acelerar como uma abordagem da vida

Andreas Möller compartilhou seus sentimentos sobre o desenvolvimento de software em um tweet : "Não quero escrever código que funcione. Quero escrever um código que seja limpo, sustentável, fácil de entender e bem testado. ”

Para conseguir isso, devemos nos concentrar em três áreas: pessoas, processo e produto. Diminuindo o trabalho das pessoas, nos esforçamos para aumentar o profissionalismo e a habilidade. Ao desacelerar o processo, nos esforçamos para aumentar a flexibilidade e a eficiência. E, diminuindo a velocidade do trabalho no produto, nos esforçamos para aumentar o nível de automação e o nível de qualidade. Quando focamos nessas três áreas, começamos a cultivar uma cultura que possibilita o desenvolvimento rápido.

Devemos lembrar o seguinte:

• Um sistema de trabalho não é necessariamente bem escrito
• Somente verdadeiros profissionais podem criar um sistema bem projetado
• Somente um sistema bem projetado permitirá que você libere novas funcionalidades o mais rápido possível

Sobre o autor

Lemi Orhan Ergin é um assistente de desenvolvimento de software que busca elevar o nível de excelência em seu setor e compartilhar sua experiência com a comunidade. Co-fundador da Craftbase e fundador da Comunidade de Artesanato de Software da Turquia . Está envolvido no desenvolvimento de software desde 2001. Ele pratica e mentora ativamente em áreas como Scrum, programação extrema, metodologias de desenvolvimento e tecnologias da web.