Design Sprint X Design Thinking: entenda as diferenças

Design Sprint X Design Thinking entenda as diferenças

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!

Origem e conceito

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), 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;
  • Decidir;
  • Prototipar;
  • 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 seja o ideal para o seu projeto.

Ver mais
Sem Comentários

Como adotar a metodologia do Design Sprint no dia a dia?

Designer Sprint Grupo Mult

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ê!

O que é Design Sprint?

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:

Segunda-feira

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.

Terça-feira

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.

Quarta-feira

É 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.

Quinta-feira

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.

Sexta-feira

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!

Ver mais
Sem Comentários

Como aplicar DDD e TDD em conjunto

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.

Ver mais
Sem Comentários

O Desenvolvimento Orientado a Testes e suas vantagens em relação aos métodos de desenvolvimento

O desenvolvimento de um software está sujeito a falhas, afinal é um ser humano digitando requisitos que devem responder a diferentes comandos. Por esse e outros motivos que o Desenvolvimento Orientado a Testes é tão necessário.

Algumas empresas não utilizam o método, porque o tempo de entrega do sistema é maior, porém pode apresentar mais bugs e impactar na experiência do usuário. Neste artigo, mostraremos quais são as vantagens de implementar o desenvolvimento orientado a testes em seus projetos. Confira!

Por que implementar o Desenvolvimento Orientado a Testes?

O Desenvolvimento Orientado a Testes proporciona mais qualidade para os projetos de software. É possível chegar a essa conclusão por uma questão bem simples. Ao escrever um código, o desenvolvedor utiliza seus conhecimentos e expertises, porém não sabe se o sistema dará certo ou apresentará erros até que seja colocado em uso.

Com o Desenvolvimento Orientado a Testes, primeiro realiza-se o teste, identifica os erros e as falhas e depois constrói o código. Ou seja, o desenvolvedor já sabe o que não deve fazer para garantir o sucesso de seu software.

Dessa forma, começar um projeto pelos testes tornará o desenvolvimento mais intuitivo, seguro e eficiente, minimizando os erros e refatorações futuras. Além desse benefício, outras vantagens são observadas pelas empresas que implementam  Desenvolvimento Orientado a Testes em seus projetos. Saiba quais são!

8 vantagens oferecidas pelo Desenvolvimento Orientado a Testes

1. Qualidade para o código

O Desenvolvimento Orientado a Teste identifica, antecipadamente, quais erros podem ser apresentados em um código. Com isso, o desenvolvedor tem a opção de seguir outro caminho e evitar os erros. A visão que os testes proporcionam aumentará a qualidade do códigos.

2. Aprimora o raciocínio

O volume de códigos que são desenvolvidos por um único profissional podem limitar seu olhar com o tempo. Quando o Desenvolvimento Orientado a Testes é implementado, o desenvolvedor é obrigado a estimular o seu raciocínio e buscar soluções para os problemas.

Dessa forma, seu raciocínio é aprimorado, favorecendo o desenvolvimento de outros códigos no futuro.

3. Estimula o trabalho em equipe

A rotina de um desenvolvedor pode ser bastante solitária. Em geral, esses profissionais focam no desenvolvimento do código durante toda a jornada de trabalho e não costumam interagir com seus colegas.

O Desenvolvimento Orientado a Testes exige que os profissionais interajam uns com os outros durante a aplicação do método e para encontrar as soluções para os erros.

4. Facilita a criação da documentação

A criação de uma documentação tradicional é feita apenas após a finalização do código do sistema. As empresas que utilizam o Desenvolvimento Orientado a Testes adiantam esse processo, pois a documentação é gerada juntamente com os testes unitários.

5. Foco no resultado

O desenvolvimento de um código que não é amparado por testes costuma ser focado em prazos. O desenvolvedor precisa entregar o projeto em um determinado período. O Desenvolvimento Orientado a Testes prioriza a qualidade e a excelência do código. Ou seja, o resultado é mais importante do que o prazo.

6. Efetividade

O Desenvolvimento Orientado a Testes reduz o número de erros apresentados pelo sistema. A aplicação final é entregue com maior qualidade, sem erros e falhas, garantindo que o sistema implementado funcione.

7. Reduz o tempo de finalização do projeto

Muitas empresas não implementam o Desenvolvimento Orientado a Testes em seus projetos com a justificativa de que o tempo de execução será maior. Porém, esse pensamento é um equívoco.

Ao desenvolver um código, baseado em testes realizados antecipadamente, é possível evitar que erros sejam adicionados ao código. Com isso, a entrega final será mais efetiva.

No modelo de desenvolvimento sem testes, a entrega pode ser rápida, mas se o projeto apresentar falhas precisará de correções e refatorações que podem ultrapassar o prazo final.

8. Segurança para o projeto

O desenvolvimento de um código, amparado por testes prévios, proporciona maior segurança para a empresa. Todo sistema é construído com base em requisitos e ferramentas que foram testadas. Com isso, o sistema pode ser colocado no mercado ou entregue ao cliente com a garantia de sua efetividade.

De forma geral, a empresa perceberá um impacto considerável na qualidade de seus processos. Profissionais que atuam de forma orientada são menos propensos a cometer erros. Dessa forma, ganha-se a confiança do cliente, aumenta a reputação da empresa e diminui o excesso de trabalho causado pelas falhas de código.

Clique aqui e saiba como implementar o Desenvolvimento Orientado a Testes em sua empresa.

Ver mais
Sem Comentários

TDD: fundamentos do desenvolvimento orientado a testes

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.

As etapas do TDD

Para que o TDD funcione de forma efetiva, é recomendado que se sigam alguns passos, baseados em três fases:  Red, Green e Refactor.

  1. 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…
  2. 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.
  3. 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.

Ver mais
Sem Comentários

Desenvolvimento Orientado a Testes: conheça as vantagens em implementar TDD

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.

Ver mais
Sem Comentários

Como funcionam os squads e times cross-funcionais?

Na busca por formas inovadoras e mais eficientes de gerenciar times e conduzir projetos, especialmente na área de tecnologia, gestores e profissionais já desenvolveram várias boas ideias. Metodologias ágeis, microsserviços, squads e times cross-funcionais são algumas delas.

Os squads parecem ser a bola da vez e muitas empresas e startups de sucesso, como Spotify e Nubank aderiram a este modelo e vêm mostrando que ele é eficaz. Ficou curioso? Continue lendo e entenda mais sobre os squads e times cross-funcionais!

O que são squads?

Em um modelo de divisão de trabalho tradicional, as equipes são divididas por área de formação e atuação. Por exemplo, existe o time de desenvolvimento, de marketing, de vendas e assim por diante. Já nos squads, a formação não importa, mas sim o projeto em que as pessoas trabalham.

Os squads são um time geralmente com 3 a 10 pessoas que trabalham em um determinado projeto e criam soluções em conjunto. Por exemplo, no Spotify, existem squads responsáveis pelo app para Android, pelo app para iOS, pelo sistema de pagamento, entre outros.

Não existe uma liderança definida e as pessoas têm autonomia para definir prioridades, se organizarem e escolherem métodos de trabalho que mais se adequam ao objetivo que precisam atingir. Os squads também são times cross-funcionais.

O que são times cross-funcionais?

São times onde atuam profissionais de diversas áreas de formação. A ideia é acabar com a divisão comum onde cada área faz uma parte do trabalho de forma independente e adotar um modelo onde todos os profissionais trabalham realmente em equipe para finalizar um projeto.

Um time cross-funcional conta com profissionais com expertises variadas de tal maneira que, juntos, eles são capazes de cobrir todas as atividades necessárias para ofertar um produto ou serviço. Não existem papeis tradicionais de divisão de trabalho e todos precisam ter uma visão global do projeto e da empresa.

Quais são as vantagens e desvantagens do modelo de squads cross-funcionais?

As maiores vantagens de trabalhar com squads são a agilidade com que as decisões podem ser tomadas e a verdadeira integração entre as áreas de conhecimento. Como todos trabalham juntos em time reduzidos, é mais fácil garantir que cada membro saiba os detalhes do projeto e consiga contribuir mais e mais rápido.

Em vez de ter processos parados esperando as burocracias de cada setor, os times cross-funcionais tomam todas as decisões juntos e com autonomia. A comunicação é um fator-chave para garantir a integração total entre os membros. Contando que a comunicação flua, as diferentes expertises podem ser verdadeiramente integradas.

Ao mesmo tempo, a autonomia dos times cross-funcionais pode criar desafios já que essa cultura de trabalhar sem uma liderança definida ainda é nova para muita gente. Além disso, pode ser necessária uma mudança na estrutura e no pensamento da empresa e dos funcionários para o desenvolvimento de um mindset ágil.

Para que os squads cross-funcionais tenham o efeito esperado, é preciso garantir que todos os membros estejam alinhados com os objetivos do projeto e da empresa e estejam prontos para assumir responsabilidades.

Outro ponto de atenção diz respeito à comunicação entre squads. Embora cada time trabalhe em um projeto, é natural que eles tenham que se integrar para entregar o todo, isto é, o objetivo central da empresa. Por isso, a comunicação entre os squads pode ser um problema se não for trabalhada corretamente.

Quais empresas adotam os squads e por quê?

Algumas grandes empresas já abandonaram as metodologias comuns e embarcaram nos métodos ágeis, adotando o modelo de squads em suas equipes. Conheça três delas!

Spotify

Como já foi mencionado, o Spotify é provavelmente o maior exemplo de aplicação eficiente do squad. As equipes são divididas por funcionalidade do software e o ambiente de trabalho na empresa inspira colaboração.

As paredes são quadros onde é possível escrever e desenhar e os funcionários participam quinzenalmente de um dia dedicado ao aprendizado e compartilhamento de conhecimento. Ou seja, as metodologias ágeis e o modelo de squad funcionaram para transformar a empresa em um ambiente extremamente colaborativo e inovador.

Nubank

O Nubank é uma das startups mais bem-sucedidas do Brasil e também utiliza os squads cross-funcionais para organizar suas equipes, aumentar o engajamento dos times para resolver problemas.

ING

O banco holandês ING decidiu mudar para as metodologias ágeis em 2015 e adotou os squads como método de divisão do trabalho. Como resultado, houve uma redução do Time to Market, isto é, tempo de desenvolvimento necessário para que o produto seja colocado no mercado, além de aumento no engajamento dos funcionários e melhoria na produtividade.

Ou seja, os squads são times compostos por profissionais de diferentes áreas e que se unem para chegarem a um objetivo comum — em vez de cada um se preocupar apenas com sua parte. Esses times cross-funcionais permitem que as decisões sejam tomadas coletivamente e de forma rápida, tornando a empresa mais colaborativa, eficiente e inovadora.

Quer saber como elaborar uma integração de dados eficiente e bem estruturada? Acesse o Guia 1.

Ver mais
Sem Comentários

Modelo Ágil e DevOps: por onde devo começar?

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!

Ver mais
Sem Comentários

Como aplicar DevOps visando a integração de dados

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.

  • Ambiente de desenvolvimento 
    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.
  • Gerenciamento de código fonte
    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.
  • Documentação Técnica
    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.
  • Documentação Funcional
    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.
  • Testes
    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.
  • Publicações
    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.
  • Ferramentas de automatização
    É 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.

 

Ver mais
Sem Comentários

DEVOPS: entenda o processo, conheça a cultura da empresa e depois defina o Landscape

Na atual economia, todo negócio depende do desenvolvimento de softwares. É por isso que o DevOps está rapidamente se tornando uma das disciplinas mais valiosas para as empresas.

Ele está focado em melhorar a qualidade e a velocidade de entrega de novos aplicativos ao mercado. A ideia é integrar o desenvolvimento e as operações para chegar lá.

Isso está direcionando as empresas em todos os lugares para dar uma segunda olhada no que eles poderiam ter pensado inicialmente se tratar apenas de uma buzzword — algo muito falado em um dia e esquecido no seguinte.

Conforme estudo desenvolvido pela CA Techonologies, para as organizações médias adotando o DevOps,  vê-se uma melhoria de 20% no tempo de mercado (time to Market), uma melhoria de 22% na qualidade do software e uma melhoria de 17% na frequência de implantações de aplicativos.

E para que você também entenda como esse método pode ser aplicado no seu landscape, abaixo explicamos o que é DevOps, quais são seus pré-requisitos e como ele pode ser aplicado na sua empresa. Acompanhe conosco!

O que é o método DevOps?

O DevOps não é um produto, nem mesmo uma tecnologia específica. DevOps é uma metodologia que une as funções frequentemente separadas de desenvolvimento de software (Dev) e produção e operações (Ops) em um processo único, integrado e contínuo.

Trata-se de quebrar as barreiras entre o desenvolvimento e as operações, por meio de uma metodologia ágil. Ele aproveita pessoas, processos e tecnologia para estimular a colaboração e a inovação em todo o processo de desenvolvimento e lançamento de software. Dev e Ops devem agir e sentir como se fossem uma única equipe.

Quais os sinais de um processo disfuncional?

Colocar o desenvolvimento e as operações na mesma página pode ser difícil. Mas, primeiro, você deve reconhecer se suas equipes estão indo na mesma direção ou não. Alguns dos sinais de alerta de um processo disfuncional incluem:

  • Você não descobre defeitos do software até o final do ciclo de vida — ou pior, na produção;
  • Você usa o modelo ágil para acelerar o desenvolvimento, mas todos os ganhos se evaporam quando o aplicativo entra em produção;
  • Seus desenvolvedores estão constantemente esperando para acessar os recursos de que precisam, causando atrasos;
  • Sua plataforma de desenvolvimento ágil não responde como esperado;
  • Você não consegue identificar problemas em desenvolvimento, teste e operações de produção;
  • Você vê erros humanos simples causando estragos durante o desenvolvimento e a implantação;
  • O desenvolvimento vê seu trabalho como concluído uma vez que o aplicativo está em produção;
  • Sempre que surge um problema, todos começam a apontar os dedos para acusar outra pessoa.

Mas então, quais são os pré requisitos do DevOps?

Reconhecer que você tem um problema é o primeiro passo para fazer mudanças significativas. Ao ver o valor que o DevOps pode trazer para sua organização, você pode ter se surpreendido de estar mergulhado em alguns dos processos disfuncionais mencionados acima sem perceber.

Então, como sair da disfunção e passar para o caminho certo junto ao DevOps? Há cinco coisas que todas as organizações podem fazer para chegar lá, sendo elas:

  • Forme as equipes de aplicação que integram cada disciplina — de Dev, Testing e Ops — juntas;
  • Melhore a educação, as comunicações e as competências;
  • Reavalie e reconstrua o seu ciclo de entrega de serviços;
  • Escolha as ferramentas certas para implantar cada categoria, como controle de versão, gerenciamento de configuração, integração contínua, deploy, monitoramento e controle de logs;
  • Avalie novas tecnologias para suportar o DevOps;
  • Escolha o aplicativo certo ou a linha de negócios correta para começar com DevOps.

Não importa em que ordem você faça essas coisas; o importante é começar. Escolha uma aplicação crítica que tenha a atenção de todos como seu ponto de partida com DevOps.

A tentação é começar pequeno, mas no DevOps, você obterá o maior retorno de um aplicativo altamente crítico e altamente visível que já está causando problemas.

Isso ajudará a aliviar grande parte da inércia interna sobre “fazer as coisas de forma diferente”, e o sucesso com o DevOps terá um grande impacto na organização.

Se você pode fazê-lo em algo que é grande, difícil e importante, você pode replicar esse sucesso qualquer parte da organização.

Para trocarmos informações e experiências sobre o DevOps , entre em contato com nossos especialistas.

Ver mais
Sem Comentários