*Por Luiz Duarte
Nesta terceira e última parte da nossa série sobre as tendências em métodos e cultura de desenvolvimento de software para 2019 vamos explorar as duas últimas categorias de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo. Vale reforçar que esta série foi criada pelo nosso Community Ambassador Luiz Duarte, do blog LuizTools, em parceria com a BossaBox.
Early Majority e Late Majority são, como o próprio nome diz, a maioria do mercado. 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 nestas duas últimas categorias, não as negligencie por elas não serem mais trendy. Scrum por exemplo, estar em Late Majority não indica que ele caiu em desuso, mas que sim, se tornou mainstream a ponto de estar sendo considerado como commodity em muitas empresas mais inovadoras e é uma tendência que acabara de chegar em empresas mais conservadoras.
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 própria 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, mesmo que informalmente, muitas empresas já estão testando o home office ou até o desenvolvimento de projetos de todos os tamanhos usando times remote-only. Esse é o dia a dia na Bossa!
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, Scurm 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.
Craftsmanship
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.
Cross-functional Teams
Agilidade é sobre times e quando se fala de times ágeis a primeira coisa que vem em mente é a pluralidade de habilidades. Times cross-funcionais ou multi-funcionais são aqueles que possuem todas as competências necessárias para entregar uma solução fim-a-fim (os chamados Feature Teams). É o contraponto à organização tradicional de times em silos, onde temos os especialistas de cada tecnologia ou camada de aplicação em cada silo, gerando extrema dependência de um time do outro e desacelerando a possibilidade de entregar valor em um lead time mais curto.
No famoso artigo de 1986 de Takeuchi e Nonaka, The New New Product Development Game, já se falava do poder que os times multi-funcionais estavam trazendo às empresas que adotavam esse modelo de trabalho à época. Não à toa que esse artigo inspirou o desenvolvimento do framework ágil Scrum, trazendo o conceito de time esportivo (rugby nesse caso) ao mundo do software, onde são necessárias diferentes habilidades em um mesmo time para conseguir vencer a partida. Já imaginou ter um time de futebol com 11 atacantes? Será que ele venceria todas partidas? E porque algumas empresas ainda insistem em ter times com apenas programadores de backend ou frontend? Ao menos a grande maioria já entendeu isso, segundo a pesquisa da InfoQ.
Justamente uma das principais competências trabalhadas na BossaBox é a construção de times multi-funcionais para atender às necessidades de desenvolvimento dos clientes, pois entende-se que esse é o caminho para a agilidade na entrega de valor.
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 tem ganhado muita popularidade nos últimos anos: coaching e mentoring, em especial a primeira. Mas, você sabe a diferença?
Coaching é o processo de ajudar um indivíduo sair de uma situação A e chegar em uma B, facilitado por um coach. Um coach é um profissional que, munido de diversas técnicas, ajuda o coachee a entender a sua situação e encontrar o seu caminho para atingir o objetivo. Note que o coach é um facilitador, ele não trilha o caminho pelo coachee e em vários casos nem mesmo já trilhou este caminho antes, sendo um profissional de perguntas, não de respostas.
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, tem um pouco dos dois: ele é um mentor de agilidade e um coach de pessoas. Além dele, um papel mais recente é o de Data Coach, que tem ajudado algumas organizações a serem mais data-driven.
Late Majority, Antes tarde do que nunca…
E por fim, temos outra grande fatia do mercado que são a “maioria atrasada”. Você imagina descobrindo ou adotando hoje práticas e tecnologias dos anos 90? Pois é, estas empresas estão fazendo isso. Mas não julgue, não é uma questão de escolha, é uma forte pressão do mercado para que elas se modernizem.
Empresas que hoje, se recusem a entender a importância dos assuntos citados a seguir estão fadadas a caírem no ostracismo ou na categoria Laggards (retardatários), que a InfoQ nem mesmo perde tempo representando em seu gráfico. Apesar de estarem atrasadas, o fato de estarem olhando para estes assuntos já as põe em posição de se reinventarem, simbolizando uma luz no fim do túnel de negócios que possam estar estagnados e sofrendo com a forte concorrência.
Além disso, lembre-se que, todos estes assuntos já foram mega inovadores e são a base para entender o que veio depois deles. Pular etapas não é uma opção, na minha opinião, e se você ainda não domina eles, dificilmente conseguirá absorver os seus sucessores.
Scrum
O Scrum dispensa apresentações. Todas as pesquisas possíveis sobre métodos ágeis como a State of Agile e a State of Scrum mostram números gigantescos de adoção de Scrum nas empresas ao redor do mundo, superando 70% das empresas que dizem estar rodando algum método ágil.
Com isto, podemos dizer que o Scrum é o padrão de facto para desenvolvimento de software utilizando métodos ágeis e que toda empresa que estiver pensando em passar a desenvolver com agilidade deveria dar uma chance para este framework que já foi inovador e hoje se tornou mainstream.
Vanilla Agile
O termo Vanilla, na tecnologia, refere-se aos fundamentos de algo, fazendo uma alusão ao sabor de baunilha que é o mais genérico e básico possível dentre os sorvetes. Assim, Vanilla Agile refere-se à essência elementar da agilidade.
Aos poucos, mais e mais empresas estão descobrindo que ser ágil não é rodar Scrum. Estão descobrindo o Manifesto, descobrindo os princípios e incorporando um ou mais elementos no dia a dia.
O mais difícil, no entanto, tem sido elas não caírem em um GoHorse Gourmet como alguns estão chamando por aí. Ou seja, abrirem mão completamente de processos alegando que assim serão mais ágeis. Frameworks mais modernos como Modern Agile e Heart of Agile (este último criado por Cockburn, um dos signatários originais do Manifesto) tentam trazer um equilíbrio a essa nova situação que estamos vivendo, de descrença com algumas receitas e as armadilhas do Go Horse Gourmet.
Scaling Frameworks
Escalar métodos ágeis em grandes organizações é hoje uma arte que a todo custo estamos tentando transformar em ciência. Da adoção de agilidade pelo PMI à criação de grandes empresas em torno de frameworks como a Scaled Agile Inc, todos estão tentando resolver essa equação, de como escalar o ágil sem torná-lo outro waterfall.
Médias e grandes empresas que estão iniciando hoje suas transformações digitais tendem a assumir abordagens bimodais como a proposta do Gartner, enquanto outras tentam ir para o chamado “modelo Spotify” de escalar o ágil. Só o tempo dirá se teremos um vencedor ou se criaremos ainda outros modelos e receitas de escalar o ágil. O que não faltam hoje são opções além e SAFe e Spotify: Less, Scrum at Scale, Nexus, DAD, etc.
ALM Tools
ALM é uma sigla para Application Lifecycle Management ou Gestão do Ciclo de Vida de Aplicação. Do início dos anos 2000 para cá evoluiu-se muito em termos de ferramental para fazer a gestão das nossas aplicações. Com a popularização de arquiteturas mais modularizadas como microservices e nanoservices (serverless) e de tecnologias que elevaram essa modularização a um nível nunca visto antes, como Docker e Kubernetes, tivemos o surgimento de uma nova disciplina chamada DevOps, cada vez mais na boca dos profissionais de tecnologia de todas empresas.
Conceitos como Infra as a Code e Continuous Delivery não são mais “rocket science” e finalmente são objetivos alcançáveis a baixo custo. Absolutamente todas empresas que trabalham com software já ouviram falar disso e mesmo a categoria Late Majority deve investir pesado em pipelines e nuvem neste ano de 2019.
Conclusões
E com essa terceira parte nós encerramos esta série sobre tendências em métodos e cultura de desenvolvimento de software para 2019. De forma alguma esta série cobriu tudo o que está acontecendo neste mundo de TI, e nem mesmo deu uma compreensão aprofundada de cada um dos tópicos apresentados. E a ideia nem era essa.
Se você terminou de ler com o sentimento de que tem muita coisa para aprender ainda, pois é, somos dois e estou muito feliz que eu não seja o único. Esse era meu objetivo principal: tirar você da incompetência inconsciente para a incompetência consciente. Agora com essa to-do list de coisas a estudar, espero que possa se antever às mudanças que estão chegando, além é claro de buscar o que pode ter deixado para trás por descuido.
Agora, se você já sabia de tudo que foi apresentado (uau!), se inscreve na nossa plataforma de prolancers, a BossaBox está de portas abertas para profissionais como você, inovadores e em com sede de entregar resultados!
Um abraço e até a próxima!
Luiz Duarte é Bacharel em Ciência da Computação (Ulbra) e Especialista em Computação Móvel (Unisinos). Agile Coach (Scrum.org) e Professional Coach (IBC), ajuda times e empresas a atingirem o seu máximo potencial em negócios de tecnologia e inovação.
0 comentário