7 minutos de leitura

E cá estamos nós novamente, trazendo para você a segunda parte da nossa série de artigos sobre as tendências em métodos e cultura de desenvolvimento de software para 2019. Nossas pesquisas tiveram como base a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Nesta segunda etapa, vamos explorar as tendências que recentemente foram criadas pelos inovadores e agora já estão dentro de um volume maior de empresas, as Early Adopters, mas que ainda não se tornaram mainstream. Esses métodos e cultura de trabalho ainda têm muito o que conquistar de espaço no mercado para conseguir cruzar o abismo que separa as empresas de ponta do restante e se firmarem como padrões de fato.

Mas deixando a conversa de lado, vamos analisar um pouco de cada um dos itens da coluna Early Adopters do gráfico de difusão de tendências.

Tenham uma boa leitura!

Early Adopters, Os Entusiastas

As empresas nesta faixa são aquelas que ainda são consideradas inovadoras por nós, meros mortais, mas que não criam tendências. Ao invés disso, o seu papel na cadeia de difusão da inovação é separar o “joio do trigo” como diriam nossos avós. Ou seja, a faixa de reais Innovators cria muita “maluquice” corporativa que só funciona no contexto delas e que muitas vezes não se espalha para o mercado, sendo que o que realmente dura são as práticas largamente adotadas pelos Early Adopters, que impulsionam tendências mais pragmáticas (mas ainda sensacionalmente disruptivas para os padrões tradicionais) para além do abismo (chasm) cunhado por Geoffrey Moore.

Resumindo: o que você lerá a seguir não é futuro utópico: é a realidade em muitas empresas de ponta e que um dia você pode ver como padrão de mercado se estiver empregado em uma boa empresa de desenvolvimento de software, ou tecnologia.

Enterprise Startups

Imagine que você fosse abrir uma startup, mas já contasse com a ajuda de consultores experientes, profissionais qualificados e… grana de uma empresa que estivesse patrocinando o seu negócio. Pois é, esse é o conceito por trás de Enterprise Startups. Grandes corporações têm feito spin offs de seus negócios em startups separadas, derivando iniciativas de maior risco ou que exigem maior velocidade de prototipação e/ou construção de MVPs.

Você acha que somente um dos lados está se beneficiando dessa conexão? Pensou errado. Lembre-se que 90% da startups falham e que 40% das maiores empresas do mundo deixarão de existir em 10 anos. Inovar não é algo opcional, e ser lento e burocrático demais está arruinando grandes negócios.

Evolutionary Architecture

Você já deve ter ouvido alguma história parecida: um projeto inicia com a necessidade de desenvolvimento de software. Eles ficam semanas (ou meses) definindo a arquitetura perfeita. Depois passam mais semanas (ou mais meses) codificando-a. Depois colocam no mercado uma obra-prima que ninguém compra. Não seria mais inteligente ter feito uma arquitetura básica, com um código rápido (MVP?) e, depois se fizer sentido para o mercado, ir evoluindo a arquitetura?

Com a velocidade (e aceleração) rápida das mudanças atualmente, o conceito Evolutionary Architecture (Arquitetura Evolucionária) é absolutamente necessária para o sucesso. No entanto, implementar este tipo de arquitetura requer mudanças técnicas e de cultura drásticas. Você sabia que o eBay surgiu de um código escrito em 3 dias em 1995? E que hoje ele é uma das maiores empresas do mundo e já está na sua quinta reescrita total de arquitetura? Ou o que dizer do Facebook, já que todo mundo deve ter visto o seu filme a esta altura? Twitter, Amazon, Google… Nenhuma gigante de tecnologia nasceu com algo sequer parecido com o que tem hoje e é dito que 90% dos sistemas do mundo ainda rodam em monolitos e rodam bem.

Claro, Evolutionary Architecture não é sobre ser displicente com arquitetura. É sobre ter em mente uma visão de longo prazo (que deve sofrer alterações com o passar do tempo), mas planejar em detalhes e executar um passo de cada vez ao invés de voltarmos ao waterfall. Uma abordagem para esse raciocínio pode ser o Toyota Kata.

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 ou executar o desenvolvimento de software, 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.

Software Ethics

Todo mundo já deve ter visto filmes futuristas cheios de tecnologia como “Matrix”, “Eu, Robô” e “O Exterminador do Futuro”, certo? O que esses filmes possuem em comum além do cerne distópico de suas tramas? Debates éticos sobre a relação homem-máquina.

Conforme a tecnologia avança em um passo assustador (ou empolgante, para os mais entusiastas), questões de ética em desenvolvimento de software têm-se tornado cada vez mais comum. Para dar apenas um exemplo, em uma situação de atropelamento iminente, quem um carro autônomo deve escolher para ser atingido? E o caso recente do sistema de estabilização da Boeing que nada mais é do que um assistente para o piloto?

Não é apenas uma questão de saber a quem culpar em casos como esses, mas sim de entender que conforme avançamos em tecnologias como Inteligência Artificial, Blockchain, Robótica, etc temos de entender o impacto social na vida das pessoas, o impacto no comportamento social humano, que é o núcleo da ética. Alguém lembra dos Ludditas? Pois é, se não discutirmos esses delicados tópicos propostos por ética em software, teremos uma reencarnação do Luddismo.

DevEx/Employee Experience

DevEx ou Developer Experience é basicamente, para mim, como se toda a empresa trabalhasse como um grande Scrum Master, removendo os impedimentos do time de desenvolvimento. Em uma tradução mais didática, Developer Experience é sobre tornar mais fácil e simples as atividades de desenvolver, liberar e operar software. É sobre identificar e remover qualquer coisa que crie fricção no processo de construir software.

DevEx entende que, conforme o mercado exige um patamar cada vez maior de exigências em termos de tecnologia e processos, os ciclos de desenvolvimento se tornam mais lentos e mais custosos devido à alta carga cognitiva e ao overhead de processos. A empresa deve investir em ferramental e automações capazes de permitir que os ambientes e os processos de desenvolvimento sejam tão fluidos quanto possível.

Nesse podcast você aprende mais sobre este tópico com a responsável pelo assunto no Netflix.

UX Friendly Security

Assim como dito anteriormente que as práticas modernas de engenharia tem tornado o processo de desenvolvimento mais custoso e cheio de atritos, o mesmo aconteceu com as práticas de segurança da informação ou DevSecOps versus a User Experience (UX). Não é raro de ver debates acalorados de profissionais de segurança da informação com profissionais de experiência do usuário. Enquanto uns estão querendo colocar camadas de segurança adicionais, outros estão querendo tornar a vida do usuário mais simples e menos burocrática.

Você tem coragem de dizer que um dos lados está mais certo do que o outro? Eu não.

Conceitos como Continuous Security e Shift Left Security não apenas colocam segurança durante o processo de desenvolvimento, mas tornam a cultura de software seguro parte do dia a dia do Time de Desenvolvimento. Afinal, nenhum fabricante coloca o freio do carro no final da linha de montagem, não é mesmo?

Team Self-selection

De acordo com o relatório anual The State of Agile, o desenvolvimento ágil de software se tornou mainstream nas empresas; com práticas como Scrum e Kanban largamente adotadas em maior ou menor grau por times ao redor do mundo. No entanto, práticas do Extreme Programming ainda são a exceção. Ao que parece, nós sabemos exatamente quais as melhores técnicas de desenvolvimento de software, mas não temos o apetite por realmente empoderar os times e fazer as transformações necessárias para obter os mesmos benefícios que as empresas mais inovadoras do mundo obtêm dessas práticas.

Não apenas o XP, mas muitos frameworks promovem práticas verdadeiramente mais eficientes que os meios tradicionais e mesmo assim são ignorados. Uma dessas práticas é o Team Self-Selection ou Time Auto-Selecionável. Ao invés de gestores construírem os times, eles mesmo se constroem baseados nas suas competências individuais e na missão que está sendo proposta. Ao invés de apenas aspectos extrínsecos serem levados em conta (o que normalmente é a esfera de entendimento do gestor tradicional), o próprio profissional tem suas motivações e interesses respeitados, o que pode fazê-lo desejar ou não entrar no time que está se formando.

Se não sabe por onde começar, esse workshop aqui deve te ajudar. Agora se não acredita que isso é possível, saiba que em 2012 eu fazia isso na RedeHost, uma startup de Web Hosting e Cloud Computing do Rio Grande do Sul, e nem sabia que isso tinha um nome bonito.

Deliberate Culture Design

A cultura de uma empresa é um dos (senão o maior) patrimônio da mesma. No entanto, é extremamente curioso o quanto muitas empresas dizem se preocupar com a sua cultura e não fazem absolutamente nada para, deliberadamente, projetá-la rumo a um futuro próspero e saudável.

Deliberate Culture Design tem a ver com, intencionalmente, ajudar a forjar a cultura da sua organização em cima de valores sólidos, propósitos inspiradores e clareza do que podemos esperar ou não, enquanto clientes e funcionários dela. Trabalhos como o dos professores de Harvard, Kegan e Lahey, incentivam este tipo de abordagem ao invés de linhas mais tradicionais de pensamento que cultivam culturas emergentes ou orgânicas.

O fato é, e se a cultura emergente da sua empresa não for boa, você não faria nada para mudá-la?

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 é?

Business Agility

Recentemente tem-se falado muito que os métodos ágeis teriam morrido e que no lugar estaria a Business Agility ou Agilidade de Negócios. Enquanto eu acredite que seja apenas mais uma jogada de marketing de gurus que querem vender novas consultorias e romper com o antigo mercado de agilidade em software (de tempos em tempos isso acontece), é fato que existe um movimento forte de Business Agility acontecendo.

O termos se refere à habilidade de um sistema de negócio (ou organização) se adaptar às mudanças de mercado rapidamente, aproveitando ao máximo as oportunidades e os recursos humanos existentes. Ou seja, pegue o conceito de agilidade que há décadas é muito popular junto a times e coloque-o na empresa como um todo, indo além do desenvolvimento de software.

O que é muito curioso é que, com o avanço das transformações digitais em mais e mais empresas, elas tem-se dado conta que estão cada vez mais se tornando empresas de software que prestam seus serviços originais através de plataformas tecnológicas construídas dentro de casa. Olhando por esse prisma, é muito natural que elas passem cada vez mais a abraçar os valores da agilidade no dia a dia.

Mob Programming

Você se lembra do início dos anos 2000 quando o Extreme Programming causou estranheza mundial ao promover práticas como Pair Programming, onde dois programadores trabalham na mesma máquina, um de cada vez digitando, mas ambos concentrados? Pois é, Mob Programming é pegar esse conceito e levá-lo a outro nível, fazendo o time inteiro trabalhar no mesmo computador, para resolver uma única coisa ao mesmo tempo.

As origens desta prática remontam ao chão de fábrica japonês, quando se parava a linha de produção quando se encontrava algum defeito e todos trabalhavam para encontrar e corrigi-lo, para só então a fila continuar. Conceitos mais modernos, do Kanban de David Anderson, trazem o WIP Limit como um mecanismo para gerar esta tipo de comportamento do time se ajudar mais para resolver seus problemas ao invés de cada um fazer a sua parte e esperar que o todo seja entregue. Mesmo no XP, menciona-se a ideia e o próprio termo Mob Programming em Extreme Programming Perspectives que mais tarde seria melhor elaborado por Woody Zuill (sim, o mesmo do movimento #noestimates).

A prática pode ser utilizada para mais do que apenas codificação, mas também para trabalhos afins como especificação de requisitos (User Stories?), UX e muito mais. Quer você busque a solução de um problema, o compartilhamento de conhecimento (similar a um Coding Dojo) ou aumento na qualidade do software, existem vários motivos pelos quais você deveria estar usar essa e outras Mob técnicas, como Mob Testing.

Enfim chegamos ao final da segunda parte da nossa série de artigos sobre tendências em cultura e métodos de desenvolvimento de software.

Na próxima e última parte, falaremos dos elementos já consolidados, que provavelmente você já está utilizando (ou deveria) e o que deve acontecer com eles nos próximos anos.

Um abraço e até lá!