A ferocidade da engenharia evoluída pelo mercado de software

novembro 21, 2016 11:00 am Publicado por Deixe um comentário

A evolução

Os tempos mudam, e essas mudanças (boas ou não) sempre são bem-vindas, pois nos fazem refletir sobre antigos pontos de vista e encarar os problemas através de novas óticas. Se você conversar com profissionais antigos de TI, perceberá o quão grande foi esta mudança em nosso mercado. Atualmente, muito se fala sobre engenharia de software, também chamada de ES. Um assunto antigo, mas que recebeu uma nova roupagem devido a dinamicidade atual que o mercado demanda.

Este é um assunto que você provavelmente estudou na faculdade, caso tenha estudado algo relacionado à computação. Caso não tenha, você provavelmente aprendeu sobre isso na prática. Mas de uma forma, ou de outra, você com certeza se deparou com esta ciência. E engenharia de software não é uma disciplina da ciência da computação, embora muitas vezes ela se confunda devido à falta de conhecimento.

A ES, segundo Pressman e Maxim, no seu livro “Engenharia de software, uma abordagem profissional, de 2016, é descrita da seguinte maneira: “Abrange um processo, um conjunto de métodos (práticas) e um leque de ferramentas que possibilitam aos profissionais desenvolver software de altíssima qualidade”.

Em meados da década de 1990, a ES passou a receber uma nova roupagem, quando a metodologia Agile começou a evoluir, indo de encontro aos antigos modelos de desenvolvimento, como o método cascata, por exemplo.

Segundo o especialista Fernando Sambineli, muitas empresas têm trabalhando com métodos ágeis, sobretudo com SCRUM, de forma customizada. “Muitas dão certo, mas pesquisas apontam que uma boa parte tem sérios problemas. Esses problemas vão de aspectos óbvios, como a resistência a mudanças até requisitos mais específicos, como a customização dos processos de ES, treinamentos e coach ágil”. Ele lembrou ainda que existe uma confusão de propósitos quanto aos métodos ágeis, que, em sua maioria, apresentam um conjunto de premissas, ritos e ferramentas que, de uma forma geral, trazem orientações mais gerenciais que técnicas. “Muitas práticas de ES não são apresentadas de forma prescritiva nesses métodos, deixando a critério de cada equipe ágil sua adoção e customização”, explicou.

Atualmente, principalmente devido a metodologia Agile, ao crescimento da tecnologia mobile, do software como serviço, da escalabilidade, da computação em nuvem e da concorrência no mercado, vimos uma necessidade enorme de entregas contínuas, incrementais e de alta qualidade. Vemos muitas startups se desenvolvendo de uma maneira feroz no mercado de trabalho, devido à enorme aplicação da engenharia de software. Empresas como Booking, Uber e Netflix jamais teriam se destacado se não investissem de forma massiva em ES.

O processo

Quando falamos de engenharia de software, falamos principalmente do processo de desenvolvimento de software. Desde a escolha da arquitetura a ser utilizada, a documentação, a definição dos times, as ferramentas, o modelo e, principalmente, os passos a serem seguidos para que o software seja entregue com qualidade e dentro do prazo. O processo é o que norteia o ciclo de desenvolvimento do software, é o conjunto constituído por atividades, métodos, práticas e transformações com um objetivo em comum.

Sambinelli aponta que a ES deve ter como papel principal o direcionamento do processo produtivo para que este entregue maior qualidade e satisfação aos clientes e usuários. “A ES nunca pode ser um fim em si mesmo, mas um meio para entregar mais valor aos usuários do software. Quando a ES passa a ser um fim, os times terão documentações generosas, ferramentas poderosas, ambientes de trabalho “cool”, mas correm o risco de não gerar nenhum valor aos usuários e perderem seus clientes”.

É nesta etapa que é providenciada a interação entre usuários e projetistas, entre usuários e as ferramentas em desenvolvimento que serão utilizadas. É importante entender que a própria ferramenta deve servir como comunicação entre desenvolvedores e usuários.

Os métodos

Observando o mercado, conseguimos ver que muito se preza pela entrega contínua, e observando mais de perto este fato, vemos muitas empresas trabalhando com deploys diários. Em um artigo publicado no blog de engenharia da Uber, eles abordaram os deploys, mas foram além: explicaram como eles trabalham com algo que eles chamam de micro deploys.

De acordo com o crescimento da plataforma, houve também um crescimento do número de engenheiros, o que levou a desorganização do deploy do código. As equipes enviavam suas novas versões dos seus microsserviços, e cada vez que isso dava errado, o processo tinha que ser revertido em uma máquina de cada vez. Para resolver este problema e manter a qualidade do serviço, eles criaram o micro deploy, que é usado sempre que um código está pronto para produção, ou seja, revisado, aceito, aprovado em todos os testes unitários e feito o merge no repositório.

Para que isso fosse concretizado com sucesso, foi preciso seguir um processo. Era preciso ter builds consistentes para diferentes serviços, tempo de inatividade nula para upgrades, detecção antecipada e automatizada de erro, prevenção de interrupção, rollouts de confiança, facilidade no uso e ,por fim, utilizar uma API REST que fornecesse uma integração profunda.

Outro aspecto que comumente é esquecido, é a interação do produto com o cliente, ou com os clientes do cliente. Quando uma nova feature é implementada, por exemplo, pouco se sabe sobre a aceitação dela perante os usuários. Ou pouco se tem certeza da sua eficácia e do seu engajamento. Algo rotineiro implementado nesta etapa, são os testes A/B. Com eles é possível inserir uma nova feature e medir a sua eficácia perante os usuários. Estes testes também podem ser entendidos como testes em produção.

Normalmente, essa nova funcionalidade é enviada apenas para parte da base de usuários com o intuito de medir a discrepância entre ambas as partes e avaliar qual a melhor estratégia deve ser seguida no ciclo de desenvolvimento. E isso, por mais básico que pareça, é uma prática muito utilizada por grandes players do mercado. Mas como garantir a qualidade do código com tantos deploys diários?

Em grandes empresas como Booking, por exemplo, todos os desenvolvedores têm acesso ao código e tem total liberdade para fazer deploys e testes em produção. Aliás, algo que eles incentivam na empresa, é que até os desenvolvedores mais jovens, façam deploys no código logo nas primeiras semanas. E o mais interessante: eles torcem para que o código quebre. A ideia por trás disso é criar o sentimento de responsabilidade pelo produto, incentivar o desenvolvedor dando a ele autonomia e, principalmente, criar uma cultura organizacional forte entre todos os membros do time, fortalecendo que todos são igualmente responsáveis pelo produto e pelas decisões.

As ferramentas

Quando falamos de ferramentas para engenharia de software, precisamos ter em mente que este é um cenário extremamente volátil e robusto. A ES é norteada pela demanda do mercado, pela concorrência e pelas pesquisas feitas por empresas e pela academia.

Temos alguns pontos técnicos imprescindíveis no desenvolvimento de ferramentas, o que é o caso da automatização dos processos. Muitos players do mercado seguem a premissa: automatize tudo o que for possível. Essa prática aumenta, e muito, a entrega do software, a qualidade e os deploys diários. A automação de tarefas rotineiras é imprescindível e a automação de testes é algo mandatório, afim de garantir a qualidade do software das empresas.

Algumas ferramentas muito utilizadas no ciclo de desenvolvimento de software para automação são o Jyra, jenkins e ansible. Entretanto, se você se concentrar apenas nas práticas tecnológicas das ferramentas, sua empresa corre o risco de perder mercado.

Muitos desenvolvedores acabam esquecendo a parte principal da aplicação: o usuário. É o cliente, muitas vezes, que demanda a necessidade de evolução do código, das interfaces, da entrega e do processo como um todo. É necessário entender como funciona o processo humano do nosso sistema a fim de transformá-lo em uma ferramenta de sucesso.

A cada novo desafio proposto pelo mercado, surgem novas formas de pensar e construir software. Os métodos ágeis são um bom exemplo dessa resposta da indústria de software aos desafios de flexibilidade e agilidade requerido pelo mercado. ““A indústria de software passou e contínua passando por transformações. Os métodos ágeis trouxeram uma avalanche de ferramentas e práticas para as empresas. Foi preciso aprender essa nova maneira de produzir software”, firmou Sambinelli.

Como levantando pelo especialista, o mindset Lean, em sua premissa de identificar o que é valor para o cliente, também é uma prática mandatória no mercado da engenharia de software. Você já se perguntou por que o Uber, Booking e Netflix fazem tanto sucesso? Porque além de incorporar boas práticas de programação e a metodologia ágil, eles dão muito valor a experiência do usuário na utilização dos seus sistemas. Pensando nisso, algumas empresas já estão desenvolvendo algo que é chamado de design antecipatório.

Um exemplo interessante do design antecipatório é o seguinte: Imagine a sua experiência ao utilizar o Uber. Agora, imagine que você não tem mais a necessidade de pegar o seu celular para chamar um carro. Segundo a ideia do design antecipatório, o Uber, por exemplo, teria acesso a sua agenda de compromissos e a alguns dados pessoais, como o local aonde você mora. Assim, a empresa saberia quando e onde você precisaria de um carro, enviando-o sem que seja necessário solicitá-lo por meio do aplicativo.

A engenharia e a comunidade

Como falado anteriormente, a ES tem evoluído de uma maneira feroz graças a demanda do mercado e a concorrência, entretanto, sabemos que boa parte dessa evolução tem sido garantida por meio da contribuição da comunidade.

“Acredito que as adaptações normalmente são reações às provocações dos próprios cliente, seu desafios e anseios, bem como, de um monitoramento constante do que está acontecendo com o mercado e os concorrentes. Há um conceito que vem do lean chamado Gemba, que indica o local onde ‘as coisas acontecem de fato’; o local de trabalho efetivo. Os gestores das empresas precisam constantemente estar em contato com a Gemba; precisam sair dos escritórios e do ar-condicionado para potencializar as inovações que brotam desse ambiente”, ponderou Sambinelli.

Atualmente, muitas empresas mantêm um techblog voltado para a divulgação dos conhecimentos adquiridos em ES. Muitas vezes, as empresas também abrem suas ferramentas para a contribuição da comunidade. O que demonstra o valor destas empresas no mercado e enaltece a necessidade do desenvolvimento das comunidades e a importância do open source para o mercado. Como exemplo desse modelo de aproximação ES com comunidade temos, além do Uber, Booking e Netflix, o GitHub, StackOverflow e Facebook.

Ainda nesse princípio de potencializar as inovações e trabalhando em cima do Gemba, códigos do GitHub, webinars, palestras, dojo, hackatons, artigos e discussões sobre boas práticas, frameworks e metodologias também têm garantido a evolução desta ciência. Existem alguns fóruns específicos voltados para essa ciência, como o Fórum da “Viva o Linux”, entretanto, não se encontra comunidades propriamente ditas, como encontramos em linguagens de programação como Java, Go, PHP, JavaScript, Node.JS, Ruby, Android e Python, por exemplo.

Como empresa dedicada ao fomento do conhecimento na comunidade de desenvolvedores, o iMasters está sempre à disposição da comunidade e promove iniciativas de discussões para o fortalecimento desta e outras ciências. Você tem interesse em contribuir para o crescimento da área? Participe da comunidade iMasters, estamos ansiosos para recebê-los!

Mensagem do anunciante:

Experimente a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores e ganhe até R$ 100 em créditos!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *