Quando pensa numa organização de elevado desempenho, já alguma vez se perguntou que boas práticas seguem para alcançar esse estatuto? Inclinam-se mais para abordagens ágeis ou DevOps?
Para alcançarem os seus objetivos, estas organizações dependem frequentemente de uma combinação de ferramentas ágeis para gerir o desenvolvimento iterativo e o planeamento adaptativo, juntamente com ferramentas DevOps que simplificam a automatização, a integração contínua e a implementação.
O objetivo de um processo de desenvolvimento e operações é ajudar a empresa a cumprir os seus requisitos, ajudar os membros da equipa a colaborar e a eliminar silos para desbloquear problemas e, por fim, concluir os projetos/funcionalidades em que estão a trabalhar, para que possam aumentar os utilizadores ativos diários ou mensais – ou, no caso das aplicações empresariais, aumentar as funcionalidades das suas aplicações.
Quando as equipas trabalham em silos, isso resulta em falhas de comunicação que, por sua vez, provocam o caos. Ao passo que, quando as equipas trabalham em conjunto, são mais eficazes.
No âmbito deste artigo, abordarei as abordagens ágil e DevOps, exemplos de quando adotar metodologias específicas e o impacto nos testes em cada um destes cenários.
Práticas de desenvolvimento de software ágil
Em comparação com o processo de desenvolvimento em cascata, o método ágil centra-se num dos princípios fundamentais, que consiste em satisfazer os clientes numa fase inicial do processo e através de uma entrega contínua. A entrega contínua só é possível quando envolvemos a equipa de qualidade numa fase inicial do processo e colaboramos frequentemente com ela.
Atualmente, algumas das empresas de pequena e média dimensão encontram-se numa situação em que não seguem totalmente nem uma abordagem ágil nem o modelo em cascata, mas uma combinação de ambos. Estes chamados membros de equipas ágeis concentram grande parte da sua energia em processos pormenorizados, como reuniões diárias de 30 minutos e reuniões de retrospetiva de 60 minutos, esquecendo o retorno do investimento que proporcionam, o que acaba por resultar numa situação em que são encontrados muitos erros em produção.
Have an account? Log In
Terá a indústria realmente evoluído a partir de uma abordagem em cascata?
Já fez parte de uma organização (que pensava seguir processos de desenvolvimento de software ágeis) apenas para perceber que a equipa de qualidade só participa nos testes depois de o desenvolvimento estar concluído?
Neste exemplo, continuavam a chamar-lhe ágil porque os membros da equipa de desenvolvimento trabalhavam em vários ramos (ou funcionalidades) em simultâneo, de forma iterativa. No entanto, quando tinham de testar as suas funcionalidades, esperavam até que todo o desenvolvimento estivesse concluído — que é o cerne da metodologia em cascata. Contudo, como as empresas querem avançar mais rapidamente para poderem expandir a sua base de clientes, na maioria das vezes, as equipas acabam por acumular dívida técnica.
A melhor forma de resolver este problema é transformar a organização para que se torne completamente ágil e trabalhe lado a lado com a equipa de qualidade de forma iterativa. Isto implica trabalhar com todas as partes interessadas para garantir que compreendem as consequências de não efetuarem a mudança e de que forma esta pode afetar a experiência do utilizador final.
Estruturas ágeis e as suas variantes
No âmbito deste artigo, abordarei duas das estruturas ágeis mais populares:
- Scrum
- Kanban
O Scrum é uma metodologia ágil utilizada no desenvolvimento de software baseada em processos iterativos e incrementais. Consiste em cumprir períodos de desenvolvimento delimitados no tempo, chamados sprints. A duração dos sprints varia consoante cada organização, podendo ir de uma semana a um mês ou a um trimestre.
Há uma sessão de planeamento do sprint, seguida do sprint, durante o qual ocorrem a implementação e os testes, incluindo as reuniões diárias, e que termina finalmente com uma sessão de retrospetiva.
O Scrum é normalmente implementado em equipas de desenvolvimento de produtos, nas quais os membros da equipa têm de limitar o tempo dedicado ao seu trabalho para cumprir os prazos dos clientes. Aplica-se sobretudo a aplicações B2C, porque, se esperar demasiado tempo, a sua funcionalidade deixa de ser nova, uma vez que alguém poderá já a ter implementado!
Nas aplicações B2B, que são sobretudo utilizadas por empresas, é comum utilizar-se uma versão modificada da metodologia ágil chamada SaFe - Estrutura Ágil Escalonada.
A maioria dos projetos em empresas enquadra-se numa das seguintes categorias:
- Nível da equipa
- Nível do programa
- Nível do portefólio
Os projetos ao nível da equipa são desenvolvimentos baseados em funcionalidades que envolvem cada membro da equipa na responsabilidade pelo seu projeto e pelos seus processos. Estas equipas utilizam normalmente Scrum ou Kanban, dependendo da natureza do seu trabalho.
Se as equipas fizerem parte de organizações de investigação e desenvolvimento ou de automação de testes, é imperativo que sigam o Kanban, que é menos rígido, e o objetivo consiste mais em concluir a tarefa atual do que em avançar para o próximo objeto brilhante que surja! Se as equipas fizerem parte da organização de desenvolvimento de produtos, tendem a utilizar processos Scrum.
Os projetos ao nível do programa envolvem várias equipas a trabalhar para um objetivo específico, como uma migração para a AWS. Embora este projeto possa ser classificado como um projeto baseado no nível do portefólio, eu diria que não afetaria necessariamente as equipas de recursos humanos ou de contabilidade.
Neste caso, o projeto de migração para a AWS poderia durar meses devido a problemas imprevistos, pelo que o foco está em concluir com êxito a migração para a AWS, dividindo-a em sprints justificáveis.
Os projetos ao nível do portefólio envolvem diferentes organizações dentro da empresa; um exemplo seria a implementação do JIRA. Cada organização necessitaria que os fluxos de trabalho do JIRA fossem implementados de forma diferente, com base nas suas necessidades. As equipas de recursos humanos não necessitam de testes; o foco está principalmente em responder a pedidos específicos dos colaboradores e, depois de os ajudarem, a tarefa é marcada como “concluída”.
As metodologias ágeis devem ser adotadas por organizações conhecidas por sofrerem alterações constantes. No entanto, estas alterações continuam a ter de passar por uma ronda de testes e correção de erros, e os testes não são necessariamente automatizados, o que conduz a um aumento dos tempos dos processos.
Por fim, quando as funcionalidades estão prontas para serem implementadas, são entregues à equipa de compilação/operações. Assim, os testes ocorrem iterativamente quando comparados com a abordagem em cascata, mas não avançam muito para a esquerda, uma vez que o foco não está nos testes e na entrega contínuos. Daí a necessidade da abordagem DevOps!
Abordagem DevOps
A abordagem DevOps centra-se em aspetos que vão além do desenvolvimento e dos testes e promove um pipeline de CI/CD totalmente automatizado, juntamente com capacidades de monitorização. Embora o Agile aceite alterações, a abordagem DevOps centra-se nos testes e na entrega contínuos para garantir que as versões frequentes para os utilizadores finais são bem-sucedidas.
O objetivo da equipa de Operações de TI é dimensionar o processo de desenvolvimento de software para acelerar a escrita e a atualização do código responsável pela criação de novas aplicações e serviços e pela atualização de funcionalidades dentro da equipa de TI.
Mesmo em termos de configuração das equipas, atualmente, as equipas de qualidade e de operações de TI fazem parte da mesma organização, para poderem trabalhar em estreita colaboração. De facto, foi introduzida uma nova função denominada TestOps, especificamente para se concentrar na configuração dos pipelines de CI/CD, onde os testes automatizados são executados sobre pedidos de integração, fornecendo feedback imediato às equipas de desenvolvimento.
Os testes automatizados são essenciais para dimensionar os esforços de teste e o seu valor perde-se se não fizerem parte dos testes contínuos e do ciclo contínuo de implementação e lançamento. Assim, os profissionais de TestOps têm sempre muito trabalho a fazer na manutenção da infraestrutura de testes automatizados.
Isto garante que os membros da equipa de operações se concentram em fornecer uma infraestrutura de excelência para o desenvolvimento de software, sem se distraírem com a infraestrutura de testes.
Atualmente, existem muitas ferramentas e práticas DevOps que simplificam o processo global.
- Um ficheiro de estado do Terraform refere-se a um conjunto de infraestruturas definidas e geridas como uma única unidade — é assim que são definidos e geridos vários ambientes de teste e desenvolvimento. O Terraform ajuda a configurar servidores, mas precisamos de uma infraestrutura para executar esses servidores.
- AWS fornece a infraestrutura através de instâncias EC2, que são atualmente a forma mais económica de configurar e executar estes servidores. Para avançar um passo, se a sua pilha tecnológica tiver muitos microsserviços, com o docker compose, pode definir e executar vários ambientes Docker em contentores.
- Ansible automatiza o processo de configuração de máquinas para executar quaisquer processos ou servidores.
- Kubernetes ajuda a gerir um cluster destas instâncias EC2 como um pod e agenda a execução de contentores neste cluster com base nos recursos computacionais disponíveis.
Deve utilizar Agile ou DevOps?
Embora a abordagem de desenvolvimento de software Agile versus DevOps seja um debate constante nas organizações, a melhor forma de a analisar é colocando as seguintes questões:
- Qual é a capacidade de adaptação da nossa organização no que diz respeito às novas tecnologias?
- Somos capazes de fazer frente aos nossos concorrentes em termos da qualidade dos nossos produtos?
- É provável que os clientes utilizem os nossos produtos, uma vez que estes correspondem às suas expectativas?
Se as respostas às questões acima envolverem alguma forma de negação, então está na altura de nos concentrarmos mais numa combinação de ambas as abordagens e de a adaptarmos às nossas necessidades.
A metodologia ideal de desenvolvimento de software
A principal diferença entre os processos de desenvolvimento de software baseados em agile e DevOps é que o primeiro se concentra mais em acomodar mudanças constantes, enquanto o segundo se concentra em testes, entrega e implementação contínuos. A colaboração entre as equipas de desenvolvimento e operações é crucial para que a equipa de desenvolvimento não fique bloqueada.
Assim, na minha opinião, um processo ideal de desenvolvimento de software deve incluir o seguinte:
- Gerir as personas de clientes/utilizadores e incorporar o feedback dos clientes
- Focar-se nas melhores práticas para evitar a acumulação de dívida técnica
- Melhoria contínua, testes contínuos, integração contínua, entrega contínua, implementação contínua e monitorização
Eis o aspeto que o processo teria:
A gestão de diferentes personas de clientes não se restringe às equipas de gestão de produto. Afinal de contas, porque estamos a desenvolver estes produtos? Qual é o objetivo destes produtos se não forem utilizados pelos clientes?
Vejamos o exemplo clássico da Nokia — quando continuaram a acumular dívida técnica por não acompanharem as tendências do mercado, nomeadamente a inovação da sua concorrente Apple. Concentraram-se em seguir ciclos rigorosos de sprint, apenas para acabarem por ser esquecidos!
Todas as empresas devem compreender por que motivo as suas funcionalidades estão a ser desenvolvidas e a que tipo de clientes se destinam. Isto garantirá que estamos a desenvolver funcionalidades centradas no utilizador.
Quando um novo produto é lançado, seja uma aplicação móvel ou uma aplicação Web, devemos garantir sempre que existe uma forma de os clientes deixarem o seu feedback. Nem todas as empresas seguem um processo rigoroso de trabalho próximo com o apoio ao cliente.
More Articles
CI/CD
Por fim, defenda a integração contínua e a entrega contínua baseadas em IA/ML. Quando um projeto falha, isso não significa necessariamente falta de competências por parte dos membros da equipa; significa, antes, que os testes foram insuficientes e que não foi possível identificar os problemas mais cedo durante o desenvolvimento.
Mas, por vezes, mesmo com testes e automatização adequados implementados, as coisas correm mal — por isso, se existisse um sistema de recomendação capaz de identificar quando lançar uma versão e quando não o fazer, talvez fosse possível evitar falhas tão catastróficas.
As iterações frequentes ajudam a equipa de desenvolvimento a compreender o que está a funcionar e o que não está, além de contribuírem para a reflexão sobre a escalabilidade. A desvantagem é que consomem tempo! Se outro sistema de recomendação/previsão pudesse recolher dados sobre os clientes e prever se uma determinada funcionalidade ajudaria a obter adesão ou falharia, mesmo antes do início do desenvolvimento, ajudaria a simplificar o processo de criação de um produto de elevada qualidade desde o primeiro dia!
O objetivo geral é garantir que os impactos no negócio se multiplicam mais rapidamente quando estas melhores práticas são adotadas como parte do processo de desenvolvimento.
Considerações finais
No final, tanto o Agile como o DevOps desempenham papéis cruciais no desenvolvimento moderno de software, mas a escolha certa depende dos objetivos da sua organização, da estrutura da equipa, das opções de preços e das necessidades do projeto.
O Agile centra-se no desenvolvimento iterativo e na flexibilidade, enquanto o DevOps dá ênfase à entrega contínua, à automatização e à colaboração entre as equipas de desenvolvimento e de operações. Muitas organizações obtêm bons resultados ao combinar ambas as abordagens para maximizar a eficiência e a qualidade. Independentemente do caminho que escolher, é essencial alinhar as suas ferramentas e processos para promover a inovação e proporcionar valor mais rapidamente.
Para obter mais informações sobre como otimizar os seus fluxos de trabalho de desenvolvimento e manter-se a par das tendências do setor, subscreva a newsletter do The CTO Club.
