Modelo Ágil & DevOps | Grupo Mult
Evolução das plataformas de RPA
quinta-feira, 30 abril 2020 por AB Digital
As plataformas de Robotic Process Automation (RPA) estão evoluindo de forma muito rápida, mostrando-se cada vez mais importantes para a rotina de muitas organizações. As grandes empresas investem em tecnologias robóticas e inteligência artificial, pois veem nos seus benefícios, grandes vantagens competitivas.
Dentre os benefícios do RPA, destaca-se principalmente o aumento da produtividade, baseado na automatização de tarefas operacionais repetitivas dentro de uma empresa.
O Quadrante Mágico de Gartner para RPA
O quadrante mágico trata-se de uma representação gráfica do mercado da Tecnologia da Informação por determinado período. Ele é uma metodologia de pesquisa que tem a finalidade de definir forças dentro de um segmento empresarial. Assim, ele evidencia as qualidades e também as falhas das empresas mais importantes do setor de tecnologia.
De acordo com o Quadrante Mágico de Gartner, há algumas plataformas de RPA consideradas as mais relevantes no segmento de automação. Falaremos delas a seguir.
A Automation Anywhere é uma ferramenta de RPA bastante utilizada pela indústria para automatizar atividades contínuas. Portanto, a plataforma tem como objetivo, oferecer aos usuários, uma força de trabalho digital composta por bots de software. Estamos falando do Enterprise A2019, uma plataforma exclusiva de RPA, inteiramente baseada na Web nativa na nuvem. Como é uma plataforma pensada para atender todos os segmentos de mercado, é de fácil utilização, ainda mais com as suas funcionalidades instantâneas.
A Automation Anywhere lançou no ano passado uma edição da comunidade para ajudar na exploração da ferramenta. A Community Edition permite que usuários e empresas possam criar bots e automações sem compromisso. A versão gratuita do Enterprise A2019 é válida pelo período de 30 dias e traz os fundamentos de RPA numa só plataforma.
Agora que você já sabe mais sobre a Automation Anywhere RPA, vamos falar um pouco sobre a sua arquitetura.
As plataformas de RPA evoluíram desde as primeiras ferramentas de teste automatizado com captura de tela até a estrutura típica das plataformas utilizadas hoje. Nó próximo tópico você vai conhecer a arquitetura da solução Automation Anywhere, que é um player RPA core.
Como funciona a arquitetura de um RPA
A arquitetura da RPA Automation Anywhere ocorre de forma distribuída. Desse modo, apresenta três componentes, que atuam integrados de forma a ajudar o usuário na realização das tarefas. Esses componentes são os bots creators, control room e bot runners.
A sala de controle funciona como o cérebro do Automation Anywhere e a ela estão conectados os outros dois componentes. Vejamos para que serve cada um deles.
Eles são aplicativos para desktop e servem para fazer upload ou download de bots e estabelecer a comunicação deles com a sala de controle durante uma operação de RPA.
Essa conexão ocorre por meio dos protocolos http/https. Resumindo, os criadores de bots são usados para criar robôs. Seu ambiente de desenvolvimento (IDE) possui mais de 500 comandos Drag and Drop. A IDE dos bots creators tem muitos outros recursos para a criação de bots, como, por exemplo:
Samart Recorder
Os bot runners, por definição, são componentes que correspondem ao ambiente onde os robôs são executados. Os bot runners são capazes de executar vários bots, com escalabilidade e de maneira ininterrupta 24/7. Por outro lado, eles não conseguem criar ou atualizar nenhuma automação. A sua função é relatar o status do log de execução para a sala de controle.
Considerado o componente mais importante da arquitetura de um RPA, a sala de controle nada mais é que um servidor que faz o gerenciamento do ambiente de maneira centralizada. Assim, ela exerce controle sobre os bots criados pelos creators, além de controlar a execução das tarefas de automação dos bots runners. Em síntese, a sala de controle oferece gestão, agendamento, execução e configuração dos robôs por meio de serviços Web. Além disso, exibe dashboards da operação de RPA.
Como já mencionamos, as plataformas de RPA evoluíram consideravelmente. E ao passo que a transformação digital ganha força, as a operações de automação tornam-se indispensável para a maior parte das empresas. Afinal, os robôs assumem os processos repetitivos e que podem ser programados, enquanto as pessoas ficam por conta de tarefas estratégicas. Logo, o RPA ajuda na diminuição de erros, passando a ser fundamental para qualquer negócio que queira de destacar em um mercado tão competitivo nos dias atuais.
Para que você fique por dentro do assunto e entenda melhor sobre o processo do RPA, oferecemos a leitura do nosso novo e-book: RPA: Conheça quando e como usar.
Publicado em Destaques, Integrações, Modelo Ágil & DevOps
quarta-feira, 19 junho 2019 por Wellington Shinmi
Design Sprint ou Design Thinking: você sabe a diferença entre esses dois conceitos? É comum que haja confusão entre eles, e isso não é por acaso. Em linhas gerais, o Design Thinking é uma forma de pensar e de abordar os problemas, como uma filosofia. Já o Design Sprint é um passo a passo, muito baseado na abordagem do Design Thinking, para se obter resultados na prática.
Neste artigo vamos falar um pouco sobre as principais diferenças entre os dois. Acompanhe!
O termo Design Thinking foi usado pela primeira vez na década de 1980, mas se popularizou mais recentemente, quando a Ideo, empresa americana de design e inovação, passou a usar e disseminar essa abordagem. Ele propõe que todos os problemas, independentemente da área de atuação, sejam vistos como uma questão de design.
O Design Thinking é, ainda, uma filosofia centrada nas pessoas, ou seja, requer que se conheça verdadeiramente o público-alvo, para estabelecer com eles um sentimento de empatia, com o objetivo de oferecer soluções que tenham um sentido real para quem for utilizá-las. A interação e colaboração entre os profissionais envolvidos no projeto é outro ponto fundamental para analisar o desafio e criar soluções.
O Design Sprint, por sua vez, foi criado pela Google Ventures com o objetivo de ser uma metodologia ágil e prática. Ele tem por base o modo de pensar proposto pelo Design Thinking e, por isso, foi formulado de forma a estimular a colaboração entre os diferentes integrantes da equipe envolvida. De acordo com esse método, que tem um cronograma de atividades rigoroso, uma semana de intenso trabalho colaborativo é o suficiente para que a equipe entenda o problema, construa um protótipo, teste e valide soluções.
Tempo e abordagem
O Design Sprint funciona como uma receita culinária: mostra exatamente o que você precisa fazer e o que é necessário para executar cada fase. A metodologia é dividia em cinco etapas claras, que devem ser executadas ao longo de uma semana (portanto, uma por dia), primeiro dia começando com o entendimento do problema, passando pelo esboço e discussão de possíveis soluções, construção de um protótipo, até testes e avaliação dos resultados.
No entanto, por ter seu tempo de execução limitado aos cinco dias úteis da semana, o Design Sprint deve ser usado para abordar problemas pontuais, que possam ser resolvidos nesse intervalo de tempo.
Já o Design Thinking, por ser uma forma de enxergar os problemas e soluções, não tem um cronograma definido e pode ser utilizado em desafios mais complexos. Por isso, permite um estudo mais aprofundado dos problemas e das ideias, o que demanda maior tempo de dedicação da equipe envolvida. Como uma filosofia, porém, não oferece uma forma sistemática de abordar os desafios na prática.
Etapas e métodos
Por ser uma metodologia prática e ágil, para ser executada em uma semana, o Design Sprint conta com as seguintes etapas, sendo uma para cada dia:
Mapear e definir;
Esboçar soluções;
Testar e validar.
Já o Design Thinking, como uma forma de enxergar os problemas, pode se utilizar de algumas ferramentas diferentes na sua aplicação. Algumas delas são:
Brainstorm, porém com regras que o tornem mais produtivo;
Construção de protótipos para testes;
Pensamento visual, expressando ideias com desenhos;
Colocar-se no lugar do usuário, em uma situação real ou simulada.
Seja como for, a colaboração, o olhar do ponto de vista do design e o foco nas pessoas deve sempre estar presente quando se fala de Design Thinking ou Design Sprint.
Agora que você já sabe a diferença entre esses dois conceitos, que tal conhecer uma empresa capaz de ajudar você a implementá-los na sua empresa? Acesse o site do Grupo Mult e veja todos os serviços que temos para oferecer. Talvez um deles de design de serviço seja o ideal para o seu projeto.
Design SprintDesign ThinkingGoogle VenturesGrupo MultmicroserviçosTI
Publicado em Arquitetura de Soluções, Modelo Ágil & DevOps
sexta-feira, 14 junho 2019 por Wellington Shinmi
Uma semana pode parecer pouco tempo dentro do seu projeto. Mas, de acordo com a metodologia Design Sprint, essas 40 horas de trabalho são o bastante para resolver questões fundamentais do negócio, testar e validar ideias. Essa abordagem funciona como um atalho, proporcionando soluções de design no curto prazo. É quase como um salto para o futuro: a metodologia permite que você construa um protótipo e realize testes para entender se a sua ideia é realmente boa antes de fazer grandes investimentos nas fases de desenvolvimento e lançamento.
Quer saber mais sobre Design Sprint e como implementá-lo na sua empresa? Então acompanhe este artigo que preparamos para você!
Criado pela Google Ventures, o Design Sprint foi inspirado em metodologias ágeis já existentes, como a consagrada Lean, e no Design Thinking. Ele consiste em um grande workshop, focado em colaboração e criatividade, do qual participa uma equipe multidisciplinar. Durante uma semana, esse time ficará dedicado à resolução de um problema específico e deverá seguir alguns passos, dia a dia:
O primeiro dia de um Design Sprint é o momento de definir um objetivo de longo prazo, mapear a situação de acordo com as informações da equipe e escolher uma parte do problema que, embora desafiadora, possa ser resolvida em uma semana.
Conhecido o problema, é hora de focar na solução. Em um primeiro momento, o time ficará focado em ideias já existentes que possam ser melhoradas, para que, então, cada participante trabalhe no seu esboço do que poderá ser feito para atingir o objetivo traçado.
É chegado o momento da decisão. No terceiro dia do Design Sprint, a equipe avalia todos os esboços apresentados e estrutura um passo a passo para fazer o protótipo da solução escolhida.
Nesse dia, o objetivo é criar um protótipo com base no passo a passo definido. Para que fique pronto rapidamente, ele deve ter como foco a interface com o usuário. Terminado o protótipo, é só verificar se está tudo certo para os testes do dia seguinte e preparar um roteiro de entrevista para aplicar com os usuários.
O último dia de um Design Sprint é o momento de submeter seu protótipo a testes com clientes reais, observá-los e entrevistá-los. Isso permitirá que você avalie a eficácia da solução, aprenda com os erros e acertos e defina os próximos passos.
O que é preciso para adotar a metodologia na sua empresa?
Depois de entender o que é e como funciona a metodologia, já é possível avaliar se o Design Sprint é a melhor forma de abordar os desafios da sua empresa ou do seu projeto. Esse tipo de metodologia ágil é ideal para validar hipóteses, criar conceitos ou acelerar ideias já existentes. Não é o mais indicado, porém, se o problema tiver um escopo muito amplo ou quando o time precisa se aprofundar em alguma tecnologia ou assunto que ainda não domina.
Se o Design Sprint for a forma escolhida para tratar do desafio que você tem nas mãos, é necessário prestar atenção a alguns detalhes para colocá-lo em prática. Veja a seguir:
Bloqueie a agenda dos participantes. A equipe escolhida deverá ficar a semana inteira focada no projeto;
Reserve uma sala para o trabalho, para que a equipe possa se concentrar e permanecer unida. É importante que o espaço seja confortável e funcional, afinal, será uma semana de intenso trabalho para todos;
Providencie quadros brancos, marcadores, post-its e outros materiais que possam ser úteis para deixar as ideias visíveis e manipuláveis;
Tenha uma sala dedicada ao Design Sprint. Isso ajuda a aproximar as pessoas, incentivando-as a trabalhar em equipe;
Pense também na alimentação do time. Ter lanchinhos saudáveis à disposição pode ajudar os profissionais a manter a motivação durante o dia.
Quem deve participar dessa semana de trabalho?
O Design Sprint deve ser realizado por um grupo multidisciplinar, com especialistas de diferentes áreas ligadas de alguma forma ao projeto. Idealmente, esse grupo deve ter até sete pessoas, como:
Especialista em design, fundamental para desenvolver o design da solução;
Tomador de decisão (CEO ou executivo sênior), que deve ser envolvido desde o início das discussões;
Desenvolvedor, que terá a visão do que pode ou não ser desenvolvido e entregue;
Especialista em marketing, que saberá a mensagem que a companhia deve passar aos clientes;
Representante do time de atendimento ao cliente, pois ele conhece melhor do que ninguém os usuários;
Facilitador, que será responsável por conduzir os processos do Design Sprint, controlar o tempo e incentivar a participação de todos.
Com esse time de profissionais, uma estrutura adequada e um bom desafio à frente, é hora de aplicar a metodologia. Ao final de cinco dias de intenso trabalho colaborativo, o resultado certamente será de muito aprendizado e soluções inovadoras.
Quer saber mais sobre Design Sprint e outras metodologias que podem contribuir para o seu negócio de forma ágil e inovadora? Então acesse o nosso site e veja tudo o que o Grupo Mult tem a oferecer!
Designer SprintGrupo MultmicroserviçosTI
Publicado em Geral, Modelo Ágil & DevOps
quinta-feira, 23 maio 2019 por suporte
O objetivo do desenvolvimento de um software é entregar uma solução para a dificuldade ou problema de um grupo de pessoas. Para isso, é preciso estudar as necessidades do público e desenvolver o projeto. Com esses passos finalizados, inicia-se o desenvolvimento do código. Porém, o método pode não entregar bons resultados.
A implementação das metodologias DDD e TDD em conjunto é a forma mais eficiente de entregar um sistema construído de acordo com as necessidades do cliente. Além disso, as chances de erro são reduzidas, podendo chegar a zero. Neste artigo, mostraremos como aplicar DDD e TDD em conjunto nos seus projetos.
O que são as metodologias DDD e TDD?
O DDD (Desenvolvimento dirigido ao Domínio) é uma metodologia com padrões e princípios utilizados na construção de aplicações de sistemas que estejam alinhados com as necessidades do negócio.
A metodologia trata da modelagem do domínio, onde primeiro é preciso entendê-la para depois aplicar suas terminologias, regras e lógica dentro do código. Ao contrário do que algumas pessoas pensam, apesar de contar com conjunto de blocos que são usados na solução, DDD não é um framework.
DDD é uma automatização do processo do negócio, que tem como objetivo principal que o domínio do software atenda completamente às necessidades do projeto.
O TDD (Desenvolvimento Orientado a Testes) também é uma metodologia, porém, seu principal objetivo é fazer com que o software seja desenvolvido a partir dos resultados obtidos por meio dos testes. Isso quer dizer que os testes são realizados antes da implementação do código.
A metodologia TDD elimina os erros que são encontrados após a finalização do código, pois sabendo quais falhas um sistema pode apresentar, o código será desenvolvido com mais qualidade e assertividade.
Como DDD e TDD podem ser aplicado em conjunto
DDD e TDD podem e devem ser aplicados em conjunto. Partindo do entendimento, o DDD trata a modelagem do domínio para identificar as necessidade do negócio e após desenvolver um projeto capaz de atendê-las.
Diversos especialistas afirmam que o DDD está mais relacionado com a comunicação entre os times de desenvolvimento do que com a prática de desenvolver um código.
Por esse motivo, o envolvimento de analistas, usuários, desenvolvedores, arquitetos e outros profissionais da área é fundamental para construir um software guiado para o domínio do negócio.
Após a identificação e modelagem das necessidades que devem ser atendidas pelo software, o TDD deve ser aplicado. Ou seja, com o projeto e seus recursos definidos, os desenvolvedores não vão escrever o código, mas sim os testes para identificar erros e falhas que o sistema pode apresentar.
Os testes vão conduzir o desenvolvedor à criação de um código mais limpo e efetivo, que entregue os recursos que foram planejados pelo DDD. Dessa forma, diminui-se os riscos de entregar um projeto deficiente ou insatisfatório para o cliente.
Além disso, não será necessário retomar o projeto com refatoração, processo que é bastante comum em práticas mais tradicionais de desenvolvimento.
Você deve estar pensando que dessa forma a entrega do projeto sofrerá uma atraso considerável, mas isso é relativo. Levando em consideração que o sistema será desenvolvido com base nas duas metodologias, o recomendado é que o prazo informado ao cliente seja adequado às novas técnicas.
Apesar de parecer que esse ajuste de datas atrasará na entrega final, depois de finalizado não será mais necessário realizar ajustes e correções.
O software será desenvolvido em total alinhamento com o que é necessário para o cliente e com um código limpo e aperfeiçoado por meio dos testes. No final, ganha-se mais do que se perde.
Por outro lado, a implementação de duas metodologias no desenvolvimento de software não é um processo rápido. Um modelo novo exige adaptação e prática, que são obtidos com o passar do tempo e a quantidade de vezes que é realizado.
Se a empresa quer investir em DDD e TDD e ter agilidade, deve começar desde já e executar em todos os seus projetos. A implementação de modelo efetivos de DDD e TDD pode ser realizada por profissionais de dentro da própria empresa, desde que sejam especialistas ou já tenham realizado esse tipo de implementação em outros projetos.
Do contrário, o ideal é contratar uma equipe que possa prestar suporte e garantir e efetividade no projeto. Veja como podemos ajudá-lo.
quinta-feira, 16 maio 2019 por suporte
TDD: fundamentos do desenvolvimento orientado a testes
quinta-feira, 02 maio 2019 por suporte
O TDD é a sigla para Test Driven Development ou Desenvolvimento Orientado a Teste. Mas exatamente, o que isso significa? Basicamente, o que queremos dizer é que antes de desenvolver os códigos de produção de um software, são desenvolvidos os testes.
A primeira impressão é de que essa ideia de pensar em testes antes de ter um produto que não existe é um contrassenso. Porém, faz sentido. Principalmente porque o TDD trabalha com redução de erro, antecipando potenciais problemas e suas respectivas soluções.
O TDD surgiu nos anos 1990, mais ou menos na mesma época em que surgiram as metodologias agile e Extreme Programming (XP), por Kent Beck. O intuito era de encorajar o desenvolvimento de códigos simples, para que pudessem ser checados e validados com uma técnica igualmente simples.
Para que o TDD funcione de forma efetiva, é recomendado que se sigam alguns passos, baseados em três fases: Red, Green e Refactor.
Red (Vermelho): É a primeira fase do ciclo, em que o desenvolvedor escreve um código de teste para uma nova funcionalidade, ainda que não tenha o código de produção elaborado. Provavelmente, esse teste vai falhar, mas é justamente essa a intenção…
Green (Verde): Esta é a segunda etapa, em que o programador constrói o código que irá passar no teste da etapa anterior. É importante que somente esse código seja escrito.
Refactor (Refatorar): Esta é a etapa final, para limpar o código, melhorar estruturas, diminuir as linhas e aprimorar a performance.
Contudo, para implementar os testes o desenvolvedor precisa compreender com detalhes a especificação do sistema e as regras de negócio.
Outro ponto importante é pensar em testes para o conjunto de unidades e não esquecer de salvá-los. Assim, fica garantida a cobertura completa e a possibilidade de reproduzir os testes no futuro, caso o cliente queira alterar alguma funcionalidade. Desta forma, o TDD funciona como deve.
O modelo F.I.R.S.T. dá uma ótima orientação de quais itens devem ser considerados na hora de executar os testes:
F (Fast) – Rápidos
I (Isolated) – Isolados
R (Repeateble) – Reproduzíveis
S (Self-verifying) – Auto verificáveis
T (Timely) – Oportunos, no momento certo
Atualmente, a prática do TDD pode ser utilizada em diversas linguagens, tais como C#, Java, Java Script e etc. Mais do que a linguagem de código, o importante do TDD é o método e a filosofia de seguir os três passos.
Quais as utilizações do TDD?
O método é tão benéfico que há quem diga que não há desvantagens em usar o TDD. O principal benefício é a capacidade de reduzir a quantidade de pequenos bugs pelo meio do código e garantir o melhor resultado final possível. No entanto, alguns programadores vão afirmar que testar cada pedacinho do código de implementação vai tomar muito tempo.
Resta apelar ao bom senso. Optar ou não pelo TDD vai depender do tamanho do projeto, da cultura da empresa, do nível de exigência do cliente, entre outros fatores. O importante é avaliar o custo benefício entre investir tempo testando durante a construção do código ou testar tudo de uma vez no final.
Já explicamos aqui quais as vantagens de implementar o TDD na rotina, mas vale reforçar o resultado final do código – que ficará mais limpo, fácil de passar por um refactoring e, no fim, o código fica com a linguagem mais direcionada ao negócio que ele atende.
Agora que você sabe quais os parâmetros de implantação do TDD, que tal descobrir mais sobre processos de negócios? Conheça os serviços do Grupo Mult.
quinta-feira, 11 abril 2019 por suporte
O desenvolvimento orientado a testes, ou do inglês Test-Driven Development (TDD), é uma prática que permite pensar nos testes que devem ser feitos no código de desenvolvimento, antes mesmo de ter sido feito.
No TDD, o teste é desenhado primeiro para ser aplicado após o desenvolvimento do código. A prática vem sendo amplamente utilizada e, com isso, gerando dúvidas nos desenvolvedores. Afinal, como é possível criar um teste para um código que ainda não foi criado? Vamos mostrar neste conteúdo. Confira!
O que é desenvolvimento orientado a testes (TDD)?
O desenvolvimento orientado a testes (TDD) é um processo usado antes ou durante o desenvolvimento de novos softwares. Seu objetivo é realizar um ciclo de repetições, enquanto o desenvolvedor escreve testes automatizados para validar requisitos, implementar novas funcionalidades, entre outros objetivos.
Geralmente, o software é desenvolvido e, após ter o código concluído, os testes começam a ser feitos. Com o TDD, os testes são feitos antes do sistema ser codificado. Depois de escrever os testes que o código começa a ser feito.
Parece impossível que isso aconteça, afinal, como é possível escrever um teste antes de saber o código do software? É mais simples do que parece e explicamos porquê.
O teste deve levar em consideração quais os pontos que serão avaliados no projeto, mesmo que não tenha um código pronto, já se sabe quais são os recursos ou funcionalidades que o software deve ter ou entregar.
Com base nessas informações, é possível pensar em erros que o sistema vai apresentar no futuro. Dessa forma, deve-se escrever os testes que podem validar esses erros. Cada projeto terá um TDD diferente, não existe receita para criá-los.
Quando implementar o TDD?
O TDD deve ser aplicado sempre que o projeto precisa ser testado. Hoje em dia, a maior parte das linguagens de programação já contam com bibliotecas e frameworks próprios para a criação e aplicação de testes. Veja algumas orientações para implementar o TDD:
Verifique onde vai aplicar o teste. Alguns processos do sistema são mais relevantes para serem testados, nem todo projeto precisa de TDD;
Avalie a necessidade do TDD, projetos com métodos de linguagem nativos já foram testados por seus desenvolvedores;
Nem sempre o TDD será capaz de cobrir todo o sistema, mas isso não quer dizer que não está bem testado.
Principais benefícios no desenvolvimento orientado a testes
O código será mais limpo e simples
O TDD incentiva o uso de baby steps (passos de bebê), ou seja, passos curtos durante o projeto. Por ser aplicado a cada passo do projeto, o TDD elimina os códigos que são desnecessários. Com isso, o código fica mais simples, pois a complexidade favorece o risco de erros.
A confiabilidade do código será maior
A prática do TDD faz com que os projetos passem por testes de validação frequentes. Dessa forma, o risco de um código apresentar erros ou bugs depois de finalizado é bem menor ou quase nulo. O sistema se torna mais confiável e menos propenso a apresentar bugs.
Favorece o processo de documentação
O TDD pode servir como documentação para entender as funcionalidades do sistema. Mas isso só é possível, quando os testes são bem definidos e foram aplicados corretamente.
Torna a Refactoring mais fácil
Os testes são rodados a cada refatoração, com isso nenhum erro ou quase nenhum passará pelos testes. Por exemplo, se em uma refatoração o código foi alterado e apresenta erros, no próximo teste ele será detectado, podendo ser corrigido para evitar que apareça novamente na próxima refactoring.
Alguns profissionais veem o TDD como um processo que torna os projetos menos produtivos, acreditando que o melhor caminho é escrever todo código e testar no final. Esse pensamento é um equívoco, pois caso o código apresente diversos bugs e erros terá que ser escrito novamente, correndo o risco de ter que começar do zero.
O TDD antecipa a possibilidade de um erro, bug ou problema interferir no projeto e elimina o tempo perdido na criação de códigos muito complexos que não são realmente necessários.
Ao iniciar a implementação do TDD na empresa, os desenvolvedores podem sentir uma diferença na execução dos projetos, mas com a prática e a rotina a tarefa se torna cada vez mais rápida e prática. Faça um teste, comece a aplicar TDD em seus projetos e veja os benefícios que você terá.
Precisa de ajuda para implementar processos de negócios em sua empresa? Entre em contato conosco.
quarta-feira, 03 outubro 2018 por Wellington Shinmi
O Modelo Ágil e o DevOps surgiram a partir da crescente necessidade de inovação. Se antes as estruturas das empresas eram pensadas para durar, agora há uma preocupação maior em acompanhar as transformações. Neste cenário, métodos ágeis proporcionam a flexibilidade e adaptabilidade que as organizações precisam para entregar valor aos clientes.
O próprio conceito de Modelo Ágil foi elaborado como alternativa ao desenvolvimento de software tradicional. O princípio rompe com o método inflexível, em modelo cascata, e propõe formas mais assertivas de construção de projetos. Portanto, a metodologia Ágil se baseia em uma visão evolutiva, caracterizada por ciclos menores para entrega contínua de valor.
O DevOps tem sua origem nas ideias do movimento Ágil e também visa melhorar os resultados do setor de TI. No entanto, seu princípio é mais organizacional do que metodológico. O conceito trata de integrar duas importantes áreas da tecnologia: o desenvolvimento (Dev) e a operação de processos (Ops). Assim, a interdependência e a comunicação entre essas duas áreas contribuem para garantir agilidade e qualidade na entrega de produtos.
A combinação de Modelo Ágil e práticas de DevOps, portanto, tem como objetivo obter maior eficiência e qualidade técnica. Ao mesmo tempo, a união desses conceitos proporciona maior agilidade e fluidez nas entregas.
Começar pelo Modelo Ágil ou por DevOps?
A implantação de práticas de DevOps pressupõe a adoção do Modelo Ágil. Neste sentido, a cultura cooperativa entre desenvolvimento e infraestrutura deve ser instituída quando a metodologia ágil já estiver sendo empregada. Afinal, não há coerência em aplicar as práticas de DevOps ao modelo de desenvolvimento tradicional.
Deve-se, portanto, começar pela implementação do Modelo Ágil a partir da capacitação da equipe de desenvolvimento. Em seguida, estrutura-se as entregas em ciclos menores e contínuos. Dessa forma, é possível avaliar as necessidades do projeto durante seu desenvolvimento e proporcionar entregas mais assertivas.
A adaptação ao Modelo Ágil exige uma profunda mudança de mindset. Trata-se de compreender que, no início de um projeto, não se tem uma visão ampla de todas as necessidades. Por isso, a metodologia prioriza a evolução constante por meio das entregas de valor contínuo.
Quando o Ágil estiver estruturado, é hora de dar mais um passo para melhorar a eficiência e qualidade nas entregas. Busca-se então caminhos para aplicar o DevOps, integrando desenvolvimento e infraestrutura (operações).
Isso impõe uma mudança na cultura organizacional ao promover a união de duas áreas distintas. A integração desses setores tende a acabar com conflitos de interesses entre as equipes, que passam a trabalhar alinhadas. Sem contar que o modelo ainda proporciona melhor entendimento da infraestrutura por parte do setor de desenvolvimento, além do feedback mais ágil em todas as etapas da execução do projeto.
Por que combinar as duas metodologias
Modelo Ágil e DevOps devem ser compreendidos como duas metodologias que trabalham juntas. Logo, optar por uma e descartar a outra é ignorar os benefícios de trabalhar com ambas.
Há, inclusive, números que demonstram a tendência de unir essas duas metodologias, provando a eficácia dessa combinação. Exemplo disso é uma pesquisa feita pela Forrester, que ouviu 230 colaboradores de empresas que adotam o Modelo Ágil. Os resultados constam no relatório The State Of Agile 2017: Agile At Scale.
O estudo apontou que ao menos 40% organizações já unem as duas práticas. Dentro desta parcela, 83% das empresas conseguiram obter maior eficiência na entrega. Além disso, 88% passaram a ter lançamentos mais frequentes e retorno financeiro mais rápido com a combinação de Ágil e DevOps. Por fim, 64% acreditam que aprimoraram a qualidade técnica de seus processos.
Sintetizando, a aplicação de Modelo Ágil e DevOps é um importante diferencial competitivo para que empresas se destaquem no mercado, uma vez que a combinação dessas metodologias assume papel estratégico ao acelerar entregas e garantir melhores produtos, o que resulta em maior satisfação do cliente.
Fique por dentro de todos os nossos conteúdos, assine a newsletter do Grupo Mult e não perca nenhuma novidade!
quarta-feira, 18 abril 2018 por Wellington Shinmi
Conquistar agilidade no processo de desenvolvimento é o foco que as empresas devem perseguir para ter promoções de funcionalidades, otimizando os ciclos de validações até possuírem um pacote de qualidade apto a estar em produção. Otimizar tempo, dinheiro e estar atualizado são o cerne da T.I. Digital.
A metodologia ágil trouxe para as empresas (em especial empresas de tecnologia) uma quebra de paradigma, na qual os impedimentos de projetos são tratados de forma mais eficaz, prezando pela transparência e pela forma de resolverem os impedimentos com maior agilidade, afim de ter um projeto com entregas segmentadas, contínuas, mais ágeis e próximas do Key User.
O objetivo é claro: reduzir o retrabalho e a rotina; fazer com qualidade e evitar as tão temidas alterações de escopo no processo de validação. Após a metodologia ágil, foi necessário dar mais um passo com foco na qualidade e eficiência das entregas.
Nasceu a cultura DevOps. Não se trata de um processo nem uma metodologia. É uma cultura em que as pessoas devem estar aculturadas, compartilhando vantagens que essa postura proporciona.
Desenvolvimento e operação, este é o lema. Ao invés de pensarmos em extinguir os times de Operação ou Desenvolvimento, a proposta é simples: apostar na sinergia entre times e áreas, em uma cultura. Um time sinérgico ao outro, em busca de um único objetivo – a qualidade e eficiência.
Como facilitar a integração de dados?
Muitas empresas utilizam de um middleware, seja Oracle Middleware ou outro, para criar seus processos de integração de dados. Com o middleware é possível criar processos ágeis com a cultura DevOps? Sim, porém algumas fases devem ser aplicadas para uma melhor integração de dados.
Seu ambiente de desenvolvimento é local ou remoto (compartilhado)? Se o ambiente de criação for compartilhado, mude rapidamente para um ambiente local, a menos que a utilização seja através de um ambiente PaaS, onde a plataforma está integrada, caso contrário crie imagens Docker ou máquinas virtuais e as disponibilize, mas deixe seu desenvolvedor com certa autonomia.
Os códigos devem ser versionados e armazenados em um repositório de fontes. O GIT é uma excelente plataforma. Lembre-se: código é código e documentação é documentação.
Faça uso de ferramentas como wikis, "doc" do GIT para documentar pontos importantes e relevantes relacionados aos códigos fontes e à infraestrutura que os cercam.
Utilize ferramentas com princípios de armazenamento de documentação e versionamento, onde é possível facilmente procurar textos específicos dentro dos documentos armazenados, analisar e aprovar alterações entre revisões e trabalhos colaborativos.
No caso do Oracle SOA Suite, utilize o Test Suite, configurado pela própria IDE JDeveloper. Com esta funcionalidade é possível simular dados de entrada e saída, e facilitar o processo de testes unitários e validações, aproveitando a integração de dados.
Utilize das ferramentas como Jenkins, Nexus, Maven e outras para validação estrutural dos fontes (PMD, Checkstyle e outros), geração de pacotes, versionamento (tags, branches, etc), disponibilização de pacotes e implantações.
Também é possível efetuar configurações para notificar responsáveis e times a qualquer problema encontrado. Desta forma, o desenvolvedor não precisa se preocupar com algumas tarefas rotineiras, pois as rotinas são automatizadas e ocorrem de forma transparente para o desenvolvedor. Assim é possível diminuir consideravelmente overloads de acesso aos ambientes para implantações, testes e outros.
É possível utilizar o Jenkins para orquestrar os processos do ciclo DevOps focado nas particularidades do Oracle Middleware. Utilizando os repositórios de fontes como gatilho, o Jenkis pode disparar as fases do processo DevOps. É possível montar um processo baseado em builds, testes, validações, versionamentos, releases e implantações em qualquer ambiente.
Todas podem ser configuradas a partir de execução manual ou automática. Muitas vezes, algumas empresas necessitam de um processo de Gestão de Mudanças (GMUD), o qual também é possível ser configurado na ferramenta Jenkins, como por exemplo, através de um processo manual para a criação de um documento de GMUD.
Uma boa politica a se implantar na empresa com a cultura DevOps é colocar de forma visível painéis com os monitores de pipelines do Jenkins para informar a saúde dos ciclos. Assim, pode-se criar dinâmicas interativas entre os times de criação, visando a assertividade e qualidade dos pacotes gerados, sempre contando com a integração de dados.
Provisionamento de ambiente
Muito se pergunta sobre auto dimensionamento do ambiente. É possível com middleware? Sim, mas acontece de forma mais fácil utilizando o Oracle Cloud. O Oracle Middleware tem uma restrição para auto dimensionamento em instalações OnPremisse, mas não é impossível, através de script WLST e muita configuração, alcançar o resultado de escalonamento em servidores OnPremisse.
DevOps faz parte do conceito da engenharia ágil, tendo como forte objetivo a qualidade e o aculturamento das equipes com base na integração de dados. Como consequência, teremos um processo maduro com maior eficiência, eliminando atividades repetitivas e suscetíveis a falhas.
Este artigo foi produzido por nossos especialistas:
* Lancer Lúcio de Castro
Bacharel em Sistemas de Informação pela PUC Minas de Belo Horizonte; arquiteto de Soluções e consultor no Grupo Mult; entusiasta das metodologias ágeis, DevOps, inovações, arquitetura orientada à serviços, microserviços e Java; vivência na área de TI com mais de 15 anos nos segmentos financeiro, aéreo, varejo, telecom, indústria e logística; experiências internacionais in-loco e remotas.
* Marcelo Umberto
Entusiasta por tecnologias de integração, é Graduado em Tecnologia da Informação com MBA em Gestão de equipe e liderança estratégica. Líder de Arquitetura e Infraestrutura no Grupo Mult. Especialista em fornecer soluções para integrar sistemas.