Tendências em cultura e métodos de desenvolvimento para 2020 - Parte 3

Nesta terceira parte da minha série sobre as tendências em métodos e cultura de desenvolvimento de software para 2020 vamos explorar a penúltima categoria de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Early Majority é, como o próprio nome diz, a maioria do mercado mais ligada em inovação. Como bem apontado por G. Moore em Crossing the Chasm, não é apenas um crescimento comum de mercado sair do lado esquerdo da  Curva de Difusão da Inovação de E. Rogers para o lado direito. Existe um abismo que antecede a difusão de uma inovação de qualquer tipo para o grande mercado. Esse abismo se traduz como diferenças culturais gritantes entre os inovadores e os conservadores, se traduz no custo quando falamos de inovações em hardware e pode ser traduzido como também o “medo do novo”. Afinal, quem não lembra do medo de adotar métodos ágeis na primeira década deste século?

É importante ressaltar que, apesar de algumas tendências que você não conheça ou não pratique ainda estejam nesta penúltima categorias, não as negligencie por elas não serem mais trendy. 

Atenção: partes deste artigo são iguais a outros que escrevi em 2019, como esse para o blog da BossaBox e esse para o site Startupi, pois algumas das tendências ainda se mantém.

Algumas partes são citadas por mim também na palestra abaixo, onde passo superficialmente por vários itens.

Early Majority, Os Pragmáticos

Empresas nesta categoria são o grande filão do mercado, empresas que acabaram de perceber o que de fato está acontecendo com o desenvolvimento de software e, uma vez que muitas das empresas que eles admiram (innovators e early adopters) estão comprovadamente tendo sucesso na adoção de novas práticas, passam a adotá-las também.

Empresas pragmáticas não seguem tendências até que elas tenham cruzado o abismo, ou seja, que tenham se provado ao longo de algum tempo em diversas outras empresas. Na atualidade, são todas aquelas empresas que estão passando por transformações digitais, por exemplo, mas que em sua maioria não nasceram de tal forma.

Remote-Only Teams

Times remotos. Atire a primeira pedra qual desenvolvedor de software nunca sonhou trabalhar de casa ou de qualquer outro lugar do mundo. Existem empresas com políticas flexíveis para homeoffice e existem empresas que de fato abraçaram o jeito remote-only de se trabalhar, como a BossaBox (que atua justamente na mediação dessa relação) e outras mais icônicas como Basecamp (que inclusive lançou um livro específico sobre o assunto).

Para os desenvolvedores, a flexibilidade de horário, a economia de tempo com o commuting, a ausência de dress code, silêncio, seu café e suas regras de Internet, são alguns dos benefícios, além da tão almejada geoarbitragem (gastar em Reais e ganhar em dólares ou outra moeda forte).

Para a empresa, redução de custos com infraestrutura, maior facilidade de atrair talentos de todos os cantos do mundo e, para empresas globais, a tão sonhada produtividade 24×7 (profissionais em diferentes fusos gerariam um fluxo de trabalho ininterrupto 24h por dia).

Obviamente existem desafios, mas hoje, com a situação mundial da pandemia do Covid-19, absolutamente todas empresas que desenvolvem software já estão praticando o home office e até o desenvolvimento de projetos de todos os tamanhos usando times remote-only. 

Pragmatic Agility

Pragmatismo é a palavra-chave que separa os Early Adopters da Early Majority, certo?

Nada é mais pragmático do que olhar a agilidade com um viés de “caixa de ferramentas” e, dadas as suas necessidades, escolher aquelas mais se adequem às suas necessidades. A velha guerra das metodologias, que ainda não acabou, não produz nada de benéfico uma vez que as pessoas parecem tender a uma “futebolização” dos métodos, como se eles estivessem no mercado para competir uns contra os outros. Perguntas como: qual o melhor, Scrum ou Kanban? não possuem uma única resposta, a não ser que você esteja perguntando a um dos muitos “especialistas” que costumam ser vendedores da empresa A ou B.

Agilidade é sobre reagir à mudança. O Manifesto não fala nada sobre seguir uma única cartilha como se ela fosse a verdade universal.

Craftmanship

Craftsmanship é um termo apresentado em 2000 no livro Software Craftsmanship de Pete McBreen e propõe uma nova abordagem de ver o desenvolvimento de software, mais ligada ao artesanato do que a uma fábrica de software. McBreen disserta muito sobre essa ser uma profissão onde se evolui na base da mentoria, como os antigos artesão faziam, e não de maneira formal. De que não temos como aplicar a mesma solução para problemas diferentes, o que faz com que cada projeto seja único, como uma obra de arte. O que temos em comum entre eles? Princípios de desenvolvimento.

Fortemente baseados nestes princípios, os software craftsmen ou apenas crafters, constroem uma solução adequada para o problema do cliente, de maneira extremamente pragmática, utilizando as melhores ferramentas para o problema em questão e jamais o contrário. Colocar a tecnologia antes do problema é o primeiro passo para o fracasso técnico de um projeto.

Mais tarde, Robert C. Martin (Uncle Bob), levou adiante esses conceitos carregando muito do discurso de craftsmenship em suas obras e dissertações como Clean Code, Clean Architecture e na construção do SOLID. Por vezes Bob é assumido como idealizador do movimento, mas não o é como ele mesmo admite.

É importante ressaltar que, apesar do ‘man’ no nome, a ideia não é gerar exclusão de gênero. O termo craftsperson tem sido mais utilizado hoje em dia por ser mais inclusivo neste sentido.

BDD/DDD

Behavior Driven Development (BDD) e Domain Driven Design (DDD) são duas siglas técnicas muito populares no meio de desenvolvimento de software tem vários anos e não cabe a mim tentar explicá-las no detalhe em um artigo como esse, então me aterei a resumi-las, para fazer você ter uma ideia do motivo pelo qual as empresas pragmáticas estão adotando-os este ano.

O Desenvolvimento Orientado a Comportamento (BDD) criado por Dan North, é tida por muitos como uma evolução do TDD (Desenvolvimento Orientado a Testes). Não apenas uma mudança no hábito de programar, partindo dos testes, mas uma mudança no jeito de pensar especificação de software (de maneira colaborativa entre análise, desenvolvimento e testes) e construção do mesmo baseado no que esperamos que os usuários façam no sistema. Afinal, construímos os sistemas para eles, e não para nós, não é mesmo?

Já o Desenvolvimento Orientado a Domínio (DDD) criado por Eric Evans, é uma abordagem de desenvolvimento de software focada no domínio da aplicação. Um domínio pode ser uma atividade-chave ou uma área de conhecimento, por exemplo, o que quer dizer que o software deve se focar em atender a esse domínio acima de tudo.

Estas duas práticas tem muito a ver como a maioria das empresas de mercado tem se reinventado na forma de vender seus serviços e de projetar seus softwares, de maneiras mais centradas nas necessidades e satisfação de seus clientes e objetivos de negócio. BDD e DDD ajudam muito neste sentido.

Coaching/Mentoring

E meio a tantas hard skills dentro das corporações, duas soft skills têm ganhado muita popularidade nos últimos anos: coaching e mentoring, em especial a primeira.

Eu falei bastante de coaching no primeiro capítulo desta série. Já o mentoring é o processo de ajudar um indivíduo com orientação em uma área de conhecimento específica, de domínio do mentor. Um mentor é um profissional experiente em um determinado campo de estudo ou competência que ajuda seu aprendiz a não cometer os mesmos erros, a aprender mais rápido e a ter resultados parecidos com os seus ou até melhores. Note que na maioria dos casos o mentor já trilhou o caminho que o aprendiz está trilhando naquele assunto, sendo um profissional procurado em busca de respostas.

Processos de mentoria e coaching estão cada vez mais comuns em empresas de todos os tamanhos. É uma resposta rápida para acelerar o crescimento dos profissionais, o atingimento de metas e até mesmo para práticas mais modernas de gestão e desenvolvimento de pessoas. Não à toa, caiu nas graças da grande maioria das empresas modernas. 

Curiosamente, o Agile Coach, papel cada vez mais comum em empresas passando por transformações digitais e ágeis, tem um pouco dos dois: ele é um mentor de agilidade e um coach de pessoas. 

Full-Stack Product Teams

Se temos uma máxima em times ágeis é que eles precisam ser multi-funcionais, certo? No entanto, o que mais se vê por aí são os times pseudo-multi-funcionais, ou seja, que possuem todas as skills de programação presentes mas pecam no restante do ciclo de desenvolvimento do produto quando se olha o todo. Afinal, quem dá o suporte ao produto? Quem faz o marketing do mesmo? Quem mantém a infraestrutura operando e monitorada? Entre outras tantas questões.

Dos clássicos times multifuncionais da Toyota ao vídeo do Spotify Engineering Culture, não é de agora que se fala da necessidade de se quebrar silos e construir esse tipo de time. Nesse artigo você encontra dicas práticas de quem já está fazendo isso. Nesse outro, o que se espera de um profissional full-stack de produto. Já esse outro questiona se isso é viável ou mesmo necessário, afinal, precisamos de pontos de vista diferentes, não é?

DevSecOps

No passado nós tínhamos dois departamentos muitas vezes rivais dentro da TI: desenvolvimento e infraestrutura/operações. Eram disciplinas e cultura completamente diferentes, havia pouca colaboração e cada cuidava apenas do seu “quadrado”.

Então surgiu a cultura DevOps e seu conjunto de ferramentas que tornaram a cultura de operação (Ops) mais próxima da desenvolvimento (Dev) e vice-versa. Com as tecnologias cada vez mais Cloud Native por causa da containerização/Dockerização de tudo, surgiram termos como Infra as a Code (Infraestrutura como Código), onde os servidores são “programados” ao invés de “configurados na mão”, versionamento de bases de dados assim como se fazia com código de programação, testes por todo lado, deploy com um clique e muito mais.

Mas e quanto à segurança disso tudo? Não lhe parece que tem gente demais “metendo a mão” nos servidores? Não estariam estas ferramentas de DevOps abrindo brechas de segurança nos ambientes? Não estaríamos deixando segregado outra disciplina importantíssima de TI que é a segurança?

É com este pensamento que o termo se adequou para DevSecOps, englobando a segurança no dia a dia dos times de solução, afinal, o freio não é colocado no final da linha de produção do carro, não é mesmo?

Para saber mais sobre DevSecOps, sugiro começar por esse material aqui.

Digital Transformation

Esse é um termo que está cada vez mais famoso no Brasil, certo? Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

A InfoQ construiu um Framework de Transformação Digital que, caso você esteja passando por isso ou planeja passar em breve, vale uma leitura, para jogar um pouco mais de luz sobre o assunto e organizar uma virada menos dolorida. Eu traduzi partes dele aqui no blog.

E com isso, encerramos a terceira parte desta série de artigos.

No próximo e último artigo da série (clique para ler), falarei dos métodos e elementos culturais que já chegaram até mesmo na maioria tardia, elementos extremamente consolidados e que se você não conhece ou não aplica, atenção!.

Até lá!

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.