Posts da Tag: metodologia - Blog da TreinaWeb

Engenharia de Software

O que são os 12 Factor App? – Parte 1

12 (Twelve) Factor App é uma metodologia que define 12 boas práticas para criar uma aplicação SaaS moderna, escalável e de manutenção simples.

O conceito de SaaS (Software as a Service) é um tipo de aplicação construída especialmente para ser operada em ambientes em nuvem. São aplicações web nas quais você, como consumidor, não se preocupa com pontos como o provisionamento de máquinas, licenças de software ou fatores de manutenção. Em aplicações SaaS, geralmente o que é paga é uma assinatura, que pode ser mensal ou anual. Através dessa assinatura você terá a possibilidade de acesso ao software.

Além disso, o fornecedor do software é quem é responsável pela manutenção e disponibilidade da solução. Alguns exemplos de aplicações SaaS são o Office 365 e a suíte de serviços do Google (ou Google Apps).

A metodologia dos 12 Factor App foi criada por um grupo de desenvolvedores da Heroku em 2011, visando tornar mais simples os processos de manutenção e expansão de aplicações que são disponibilizadas como serviços, ou aplicações SaaS.

Na primeira parte dessa série de artigos, vamos conhecer os três primeiros pontos do 12 Factor App: Codebase, Dependencies e Config.

Fator 1: Codebase

O código produzido é um ativo importantíssimo no processo de criação de um software, afinal, é a partir dele que o produto final será gerado – no caso, o software em si. Por isso, a maneira com que o código-fonte é gerenciado torna-se um ponto central.

Além disso, outros fatores colocam complicadores no processo de gestão do código-fonte, como equipes cada vez mais multidisciplinares e distribuídas até mesmo geograficamente, e alguns rituais de metodologias ágeis que permitem o trabalho em paralelo de equipes diferentes no mesmo projeto ao mesmo tempo de maneira produtiva.

Pelo 12 Factor App, a base de código-fonte é chamada de codebase. E existem alguns pontos que são essenciais para que possamos ter um codebase coeso e confiável. São eles:

• A base de código deve ser unificada e comum para todos os participantes do processo de criação do software. Isso evita a geração de versões “paralelas” ou “desencontradas” a partir de múltiplas origens de código-fonte;

• A base de código precisa ser temporal e auditável, ou seja, deve ser possível resgatar a situação do codebase em qualquer dia e horário, além de precisar ser possível verificar quem fez as modificações e quando estas foram feitas. Por exemplo: é essencial que seja possível obtermos o codebase na situação em que ele estava há uma semana atrás, por mais que ele tenha sido modificado no decorrer do tempo.

Também é importante ressaltar a relação 1/1 entre aplicação e codebase. Caso uma aplicação esteja espalhada em vários codebases, passamos a falar de um sistema distribuído. E isso não é problema desde que cada parte da aplicação seja independente e tenha seu próprio processo de gestão. Essa é mais ou menos a ideia por trás dos microsserviços, estilo arquitetural muito popular hoje em dia.

Para auxiliar nessa tarefa de gestão de codebase, existem algumas ferramentas chamadas de VCS (Version Control System ou Sistema de Controle de Versão). VCSs permitem justamente ter um codebase centralizado mas compartilhado entre múltiplos times, além de garantir a auditoria e o aspecto temporal do codebase. Neste tipo de ferramenta, o codebase normalmente está localizado em uma estrutura chamada repositório.

Atualmente, o VCS mais utilizado no mercado é o Git. Mas há alguns anos atrás, outros VCSs foram populares, como o Subversion (SVN) e o Mercurial.

Fator 2: Dependencies

Dependências são artefatos externos dos quais sua aplicação depende para ser executada corretamente. Por exemplo, se você está pensando em criar uma API com Node.js, é grande a possibilidade de que você considere utilizar uma biblioteca externa chamada express. Nesse caso, o express é uma dependência do seu projeto.

Quando falamos sobre a gestão das dependências do seu projeto, existem alguns pontos fundamentais segundo o próprio 12 Factor App. O primeiro deles afirma que uma aplicação não pode jamais confiar na pré-existência de alguma dependência dentro do ambiente: é responsabilidade da aplicação delimitar suas dependências de maneira explícita.

Por exemplo, se você está construindo uma aplicação que depende de uma biblioteca ou framework específicos, estes artefatos precisam ser implementados junto com a aplicação. Jamais deve-se esperar que estes artefatos já existam previamente no ambiente de execução. Isso é importante principalmente porque não é muito seguro contar que determinada biblioteca ou framework estejam instalados dentro do ambiente de execução.

O segundo ponto é que, mesmo que uma dependência já exista dentro do ambiente de execução, pode ser que a aplicação precise de uma versão específica que é incompatível com a versão existente no ambiente de execução, o que pode fazer com que o software apresente comportamentos inesperados. Por isso, entra a importância de que cada dependência seja declarada de maneira completamente explícita junto com a aplicação, indicando inclusive a versão a ser utilizada.

Para ajudar nessa tarefa, ambientes de desenvolvimento modernos disponibilizam ferramentas chamadas de gerenciadores de pacote. Cada linguagem e/ou framework possui seu próprio gerenciador de pacotes, como exemplo podemos citar o Java, que comumente utiliza Maven ou Gradle; o .NET usa o Nuget; o Node.js usa o NPM ou Yarn e o Ruby geralmente usa o Rubygems. Cada um destes pacotes provê de maneira integrada ao desenvolvimento a possibilidade de definição explícita, instalação e configuração de dependências.

Fator 3: Configs

As configurações para execução de um projeto são quaisquer parâmetros que podem variar com fatores externos, como o ambiente onde a aplicação será executada, por exemplo.

Geralmente, se tratam de credenciais para acesso a recursos como bancos de dados, buckets de arquivos, chaves de acesso a APIs de terceiros e outros fatores que provavelmente vão variar principalmente devido ao ambiente. Por exemplo, provavelmente, o banco de dados no ambiente de desenvolvimento não será o mesmo que no ambiente de produção, onde provavelmente as credenciais de acesso e até mesmo o host do banco serão diferentes nos dois ambientes. Esse é um clássico exemplo de um aspecto de configuração.

Existem algumas correntes que defendem que estas credenciais sejam definidas diretamente no código, na forma principalmente de constantes. Mas, isso é uma violação do 12 Factor App, pois cada implantação da aplicação exigirá uma modificação no codebase e um processo de implantação coordenado, evitando que a aplicação vá para um ambiente com as constantes erradas. O fator 3 define que deve existir uma separação clara e explícita entre configurações e o codebase, já que o codebase geralmente não varia de acordo com o ambiente, ao contrário das configurações.

Existem diferentes estratégias de gestão de processos de configuração, cada uma delas com suas particularidades e suas aplicabilidades.

Uma das formas mais usadas consiste na definição explícita de arquivos de configurações, arquivos estes que geralmente têm suas respectivas versões para cada ambiente. Se estivermos falando de Java por exemplo, um tipo de arquivo que é muito usado para armazenamento de configurações são os arquivos YAML ou PROPERTIES. Geralmente, a aplicação possui múltiplos desses arquivos, um para cada ambiente específico. A aplicação, ao perceber o ambiente onde está sendo executada, carrega as configurações a partir do arquivo correspondente.

Outra estratégia muito comum que podemos citar é a utilização de variáveis de ambiente para armazenar as configurações. Sendo assim, basta à aplicação ler as mesmas variáveis de ambiente em cada ambiente de execução, sendo que estas variáveis são configuradas de maneira independente em cada ambiente.

Também é bem comum encontrarmos uma estratégia híbrida entre arquivos de configuração e variáveis de ambiente. Por exemplo, posso ter uma aplicação que possui diferentes IDs de cliente para conexão em uma API de um fornecedor, dependendo do ambiente de execução.

Sendo assim, cada arquivo vinculado a cada ambiente pode ter a sua definição de ID de cliente explícita. Mas cada ambiente também pode ter um usuário e senha diferentes para conexão ao banco de dados. Neste caso, cada arquivo de cada ambiente pode apontar para uma variável de ambiente, sendo que esta variável é quem define o nome de usuário e senha.

Dessa maneira, é possível isolarmos credenciais de banco de dados dos arquivos de configuração, evitando a exposição destas credenciais para os integrantes que têm acesso ao codebase.

Por fim, ainda existem aplicações que podem auxiliar no processo de gestão de configurações de maneira muito mais robusta e até mesmo distribuída. Algumas dessas ferramentas são o Chef, o Puppet, o Ansible, o TeamCity e o Consul.

Encerramos por aqui o primeiro dessa série de artigos. No próximo, veremos mais 3 fatores: Backing services, Build, release, run e Processes.

Até lá! 😀


Acessibilidade e User Experience (UX)

UX Research e 360 View – O que é e como pode ser aplicado?

User Experience (UX), ou Experiência do Usuário, em português, é um conjunto de práticas e técnicas que visam gerar ao usuário uma percepção positiva em relação ao sistema, produto ou serviço. Os designers de UX analisam o comportamento humano e o serviço oferecido, com o objetivo de projetar melhores experiências e aumentar a satisfação dos clientes. Neste artigo, vamos falar sobre UX Research e 360 View, técnicas importantíssimas para elaborar uma melhor experiência do usuário.

O termo User Experience foi utilizado pela primeira vez por Donald A. Norman, professor da Universidade da Califórnia e da Universidade Northwestern, na década de 1990. De acordo com Norman, “o design centrado no cliente não é um conjunto preciso de métodos. É uma filosofia que pressupõe que a inovação começa entendendo as pessoas, vendo como elas vivem e lidam com os problemas”.

Assim sendo, a Experiência do Usuário não está relacionada somente à aspectos do design, mas também lida com questões afetivas e subjetivas, pois, são nestas experiências, que ocorrem a percepção individual do produto. Segundo Don Norman, “tudo é relacionado à sua experiência com o produto. Talvez você nem precise estar perto dele, você pode estar falando sobre ele para alguém”.

360 View

Para estruturar um projeto ou colocar uma ideia em prática, uma técnica de planejamento bastante útil é o 360 View, um modelo de gestão visual para controle de tarefas e fluxos de trabalho. Esta técnica, apresentada por Nelson Vasconcelos, divide um projeto entre as áreas de experiência do usuário, negócios e tecnologia, propondo alguns questionamentos ao seu respeito. São eles:

  • User Experience: O que as pessoas precisam? O que é útil e agradável?
  • Negócios: Quais são os objetivos de negócios? O que é lucrativo?
  • Tecnologia: O que é possível desenvolver? Quais funcionalidades podem ser construídas agora ou mais pra frente?

Estas perguntas servem para guiar os responsáveis pelo projeto e auxiliar na tomada de decisão. Com isso, os profissionais envolvidos conseguem analisar qual área do projeto está mais estruturada, qual merece mais atenção, quais funcionalidades do sistema devem ser priorizadas, se os recursos disponíveis atendem os requisitos estabelecidos, entre outros aspectos importantes. Com isso, o 360 View também se torna uma ferramenta importantíssima no momento de definir um MVP (Produto Mínimo Viável, em português).

UX/UI - Introdução
Curso de UX/UI - Introdução
CONHEÇA O CURSO

O MVP é uma versão mais simples de um produto ou sistema. É utilizado para testar rapidamente, de maneira quantitativa ou qualitativa, a resposta de mercado sobre uma funcionalidade específica. Um MVP tem apenas as funcionalidades necessárias para mostrar o produto ao cliente e seu principal objetivo é evitar o desenvolvimento de recursos indesejáveis. Trata-se de um processo iterativo de geração de ideias, prototipagem, apresentação, coleta de dados, análise e aprendizagem.

UX Research

Pesquisa em UX, ou UX Research, em inglês, trata-se de uma pesquisa com o propósito de coletar informações sobre o potencial público-alvo do sistema, produto ou serviço. É de suma importância identificar o perfil do usuário, bem como quais são seus gostos, desejos e necessidades. O usuário e suas necessidades mudam constantemente, por isso os produtos devem mudar com eles. Gerenciar essas informações é essencial para que os gestores e desenvolvedores trabalhem para elaborar um sistema que o cliente deseja.

A UX Research busca entender a lógica de interação do usuário com o sistema, identificar suas preferências, analisar a concorrência, compreender o mercado, conhecer as expectativas dos potenciais futuros usuários, entre outros pontos. Assim sendo, o profissional de UX Research deve se colocar no lugar do cliente para entendê-lo e perceber as dificuldades que ele pode encontrar ao utilizar o seu sistema.

Com isso, a Pesquisa em UX ocorre basicamente em três momentos:

  1. Antes de iniciar o projeto: Obter essas informações permite saber a viabilidade de uma tela ou funcionalidade, analisar o nicho de mercado em que o sistema se posicionará, verificar a experiência do usuário, analisar a concorrência direta, detectar possíveis problemas e ameaças, etc.
  2. Durante o processo de desenvolvimento: Ao projetar uma página web, mesmo tendo claro que ela deve ser funcional, atraente, fácil de usar e adaptável a diferentes usos, devemos lembrar que o cliente final pode não gostar do resultado do projeto. O cliente deve sempre orientar os passos para aprimorar a experiência do usuário quando o projeto está em andamento.
  3. Quando o sistema está em produção: Os usuários de um site ou aplicativo são aqueles que validam ou não o que foi desenvolvido. A Pesquisa em UX nunca deve ser encerrada, pois esses tipos de projetos permanecem com constante evolução.

Principais métodos de UX Research

Antes de escolher um método de Pesquisa em UX, é importante considerar o que você deseja alcançar com o seu sistema. Abaixo comentaremos brevemente sobre as principais técnicas:

Entrevista em profundidade

É o método mais difundido e um dos mais eficazes para coletar informações sobre os usuários. Pode auxiliar a equipe a tomar decisões, até mesmo para se basear no modelo de negócios. Algumas boas práticas nas entrevistas contemplam o uso de questões abertas, permitindo que o usuário fale o máximo possível.

Questionários online

Pesquisa online é a maneira mais rápida de obter dados quantitativos sobre o sistema, produto ou serviço. Esse tipo de método pode confirmar, por exemplo, como os usuários reagiram a implementação de determinada funcionalidade.

Persona

O pesquisador coleta dados de seu público-alvo, bem como suas preferências, hábitos psicológicos e comportamentais, entre outros aspectos, e cria um grupo de usuários imaginários com essas características.

Focus Group

O pesquisador e um grupo de usuários realizam uma discussão moderada sobre o produto, suas características, benefícios e desvantagens. Esse método pode variar entre conversas informais, questionários e dinâmicas em grupo.

Mapas de calor

Com o uso de ferramentas especializadas, o pesquisador consegue analisar quais áreas do site ou aplicativo os usuários interagem mais ativamente e, com isso, poderá utilizar essas áreas de maneira mais eficiente e informativa.

Estudos de campo

O pesquisador vai, literalmente, até onde o usuário está. Esse método permite entender sobre como as pessoas se comportam no momento em que utilizam o sistema e quais ambientes elas estão inseridas.

Desenho colaborativo

O usuário tem a oportunidade de contribuir com sua visão do produto, desenhando alguns rascunhos, durante uma sessão em grupo.

Teste A/B

Uma parte dos usuários utilizam uma primeira versão do sistema por algum tempo e, logo em seguida, outra parte usa uma segunda versão. O pesquisador coleta as informações, junto com as métricas necessárias, e elabora uma conclusão sobre a eficiência das versões.

Relatórios diários

O usuário interage com o sistema durante um período determinado e elabora pequenos relatórios diariamente, dando recomendações sobre ele. Esse método ajuda a comprovar a usabilidade do sistema na perspectiva do uso de longo prazo.

Considerações finais

Experiência do Usuário são todos os aspectos relacionados às interações das pessoas com um determinado sistema, produto ou serviço. Diante disso, se faz cada vez mais necessário compreender as necessidades, expectativas, desejos e objetivos dos potenciais usuários. A Pesquisa em UX ajuda a moldar o produto e a definir diretrizes para fornecer uma boa experiência para seus usuários. Ao não dedicar tempo em pesquisas e tomar decisões baseadas somente em suposições, você corre o risco de não atender às necessidades dos usuários de maneira eficaz e eficiente.


Acessibilidade e User Experience (UX)

Double Diamond e sua utilização nos processos de UX

Criado pelo British Design Council, o Double Diamond é um método do Design Thinking que está sendo bastante utilizado em equipes de UX. Este processo auxilia basicamente em encontrar a melhor solução para um problema ou ainda na criação de produtos, serviços e processos.

Esse processo é representado por dois diamantes: um focado em identificar qual é o problema e outro voltado para a solução. Isso para que possamos garantir uma análise mais profunda e com um número maior de possibilidades, ou seja, a fim de se chegar em uma solução mais assertiva.

Neste processo utilizamos dois tipos de pensamentos: divergente e convergente, onde divergente será sempre na abertura do diamante e o convergente no fechamento do diamante. No pensamento divergente são criadas muitas ideias, já que precisamos expandir nossos horizontes, considerando tudo o que for possível, para que no pensamento convergente, possamos analisar as informações e reduzir as ideias para chegar na melhor opção.

Design  Thinking
Curso de Design Thinking
CONHEÇA O CURSO

As 4 etapas do Double Diamond

O double diamond é composto por 4 etapas: imersão, definição, ideação e prototipação. Mas você também pode encontrar modelos com as etapas: descoberta, definição, desenvolvimento e entrega. Ainda que com outro nome, as fases tem o mesmo propósito.

Nas etapas de imersão e definição temos o entendimento do problema, o que podemos fazer. Nas fases de ideação e prototipação vemos quais alternativas temos de solução e como vamos desenvolver.

Imersão

Temos o hábito de ao pensar em um problema já querer achar uma solução, de preferência o mais rápido possível. Porém essa solução pode não ser a melhor, ou ainda, pode ser uma solução baseada em achismos. Por conta disso, temos como primeiro passo a imersão. Devemos imergir o máximo em uma situação, para descobrir os problemas, encontrar pontos de dor, para que possamos ter dados que possam ser analisados antes de tomar qualquer decisão.

Precisamos entender o problema antes de pensar na solução.

Algumas ferramentas que podem ser utilizadas nessa fase: entrevistas, pesquisas quantitativas e qualitativas, benchmarking, análise de dados, matriz CSD, análise Heurística

Definição

Depois da etapa de imersão, de ter encontrado pontos de dor e quais problemas podemos explorar, precisamos organizar todas as informações coletadas nessa etapa anterior e definir o problema que será resolvido. Sim, é “o problema”, e precisamos escolher um bom problema.

Como provavelmente não conseguiremos resolver todos os problemas que apareceram, precisamos saber priorizar. Delimite esse problema e deixe aberto para as inúmeras soluções que possam sair dali. Precisamos entregar algo que seja tecnicamente possível de ser resolvido e que seja desejável pelas pessoas.

Algumas ferramentas que podem ser utilizadas nessa etapa: criação de personas, mapa de empatia, etc.

Ideação

Aqui chegamos no segundo diamante do Double Diamond. Agora sim chegou a hora de enfim pensar nas soluções para o problema definido. Mas, primeiramente, precisamos ter o nosso desafio em questão muito bem definido.

Caso ainda não esteja muito certo, por exemplo se está faltando dados, pesquisas, se ainda não sabe ao certo qual problema deve ser priorizado, é importante voltar às etapas anteriores – isso não é um retrocesso. Não se preocupe, pois como não é um processo linear, você pode voltar no início caso necessário.

Aqui todos da equipe podem falar suas ideias, pois uma pode complementar a outra, cada um pode ter uma visão diferente, podemos até pegar partes de cada ideia e transformar em uma só, sempre em busca de uma solução que resolva o problema das pessoas em questão. No fim precisamos juntos ver a ideia mais promissora.

Algumas ferramentas e técnicas: mapa mental, brainstorming, crazy 8’s, Benchmarking, 4x4x4, MoSCoW, Userflow, Sitemap.

Prototipação

Essa etapa pode ser a mais esperada pois é quando vemos algo mais “concreto”. Nesta etapa precisamos tangibilizar a ideia em um protótipo, podendo assim validar com pessoas usuárias e, claro, receber feedbacks. O protótipo pode ser no papel, porém a utilização de algum software fica mais próximo do mundo real.

Nesta etapa também fazemos os testes, que são muito importantes. Temos o teste de conceito, que é ideal para validar a ideia, vendo o que as pessoas pensam sobre a solução e o teste de usabilidade, onde observamos como a pessoa utiliza o protótipo, o que nos ajuda a identificar o fluxo que ela está seguindo, suas dificuldades, etc, surgindo assim melhorias.

Algumas ferramentas: protótipo no papel, protótipo navegável wireframe, Figma, etc.

Prototipação Rápida
Curso de Prototipação Rápida
CONHEÇA O CURSO

O Double Diamond pode ser utilizado nos mais diversos contextos, ainda mais em processos de descobrimentos longos, que você não conhece o resultado final. Quando uma equipe de UX utiliza o Double Diamond, eles conseguem avaliar e estudar cada possibilidade, a fim de propor a melhor solução que atenda às necessidades dos usuários.


Engenharia de Software

O que é ASD – Adaptative Software Development?

Adaptive Software Development (ASD) ou Desenvolvimento de Software Adaptativo é uma técnica para o desenvolvimento de softwares, proposta por Jim Highsmith. Este modelo concentra-se na colaboração humana e na auto-organização da equipe. Tem foco de atuação principalmente nos problemas de sistemas complexos, para grandes desenvolvimentos. O método estimula fortemente o desenvolvimento com repetições e uma constante prototipação.

Bem como em metodologias ágeis, sua operação é em ciclos e em cada interação ocorrerão certas mudanças e até alguns erros. Este ciclo fornece aprendizado e adaptação contínuos ao estado emergente do projeto.

Baseado no ciclo de aprendizado colaborativo, o ASD define o seu ciclo de vida para projetos, isso faz com que os ciclos colaboração e aprendizado – que veremos mais à frente, sejam preenchidas com as suas respectivas práticas. Nesse sentido, o aprendizado é um elemento-chave para que possamos conseguir uma equipe auto-organizada.

Características do metodologia ASD

  • Focado na missão: objetivos muito bem definidos, porém podem ser ajustados de acordo com o desenvolvimento do projeto;

  • Orientado a riscos;

  • Orientado a componentes: as atividades de desenvolvimento não devem ser orientadas a tarefas, mas, focadas nas funcionalidades do desenvolvimento do software;

  • Iterativo;

  • Tolerante a mudanças: incorpora as mudanças que aparecem no meio do projeto. Como é algo frequente em desenvolvimento de software, é mais importante se adaptar à elas ao invés de tentar controlar.

Ciclo de vida do modelo

Um projeto de ASD é composto por um ciclo de três fases:

  • Especulação: Nessa fase o projeto é iniciado e se estabelecem os principais objetivos e metas do projeto, requisitos básicos que serão necessários e as limitações com as quais você trabalhará. Após completar cada ciclo tudo é revisto e ajustado, podendo sofrer mudanças. Tudo isso para que o projeto esteja na realidade que a equipe está trabalhando.

  • Colaboração: A colaboração ajuda bastante no levantamento de necessidades, especificações, etc. Por isso, deve-se existir confiança, ter críticas construtivas, trabalho árduo e promover a comunicação dos problemas e em atitudes que contribuem para o trabalho em equipe.

  • Aprendizado: consiste na compilação de tudo o que foi aprendido do início até o final, o que foi bom e o que foi ruim para que possamos melhorar no futuro.

ASD - Adaptive Software Development
Curso de ASD - Adaptive Software Development
CONHEÇA O CURSO

Vantagens:

  • É utilizada para aprender com os erros e iniciar o ciclo de desenvolvimento novamente

  • Utiliza as informações sobre as mudanças para melhorar o desempenho do software

  • Promove o trabalho em equipe

Desvantagens:

  • Erros que não são detectados anteriormente afetará a qualidade do produto e consequentemente no custo

Considerações finais…

Dessa forma, esse é um modelo que traz excelentes resultados em grupos de trabalho, pois incentiva a comunicação de todos os envolvidos. É bastante indicado para projetos com constante mudança e em ambientes que necessitam implementar projetos que são críticos para o negócio, além de ser uma boa ferramenta para equipes que atuam com projetos de alto risco.

Se você tem interesse em conhecer outras metodologias e também metodologias ágeis, confira outros artigos no nosso blog =D


Engenharia de Software Metodologias Ágeis

O que é XP – Extreme Programming?

Seguimos nossa série de artigos de metodologias, abordando hoje mais uma metodologia ágil: XP (Extreme Programming). Lembrando que já abordamos diversas metolodogias aqui, como Crystal, RAD, RUP, e AUP.

O XP (Extreme Programming ou Programação Extrema) é uma metodologia focada no desenvolvimento de software que possui valores e princípios, onde são fundamentados por um conjunto de práticas.

É uma metodologia leve que pode facilmente ser adotada por diferentes níveis de desenvolvedores (experientes ou não) e em qualquer tamanho de equipe. É uma excelente metodologia por se adaptar a requisitos que às vezes podem mudar rapidamente.

O XP pode ser utilizado de forma complementar ao Scrum, pois ele acaba focando mais em processos de engenharia e desenvolvimento de software.

Scrum - Planejamento e Desenvolvimento Ágeis
Curso de Scrum - Planejamento e Desenvolvimento Ágeis
CONHEÇA O CURSO

Princípios, valores e práticas

Como vimos acima, o XP possui um conjunto de princípios e valores, onde os princípios tendem a ser mais concretos que os valores. O conjunto de valores servem como um critério que norteiam as pessoas envolvidas no desenvolvimento do software, além de se complementarem. São eles: comunicação, simplicidade, feedback, coragem e respeito.

Além desses valores, existe um conjunto de princípios que deve ser seguido por equipes que forem usar XP em projetos, sendo o feedback rápido, presumir simplicidade, abraçar mudanças, trabalho de alta qualidade, pequenos passos, melhoria, diversidade, reflexão.

As práticas consistem no núcleo principal do processo. Elas evidenciam os valores que nos ajudarão a ter sucesso no projeto. São elas:

  • Cliente presente: O cliente deve participar ativamente do processo de desenvolvimento. Tudo precisa da comunicação com o cliente. Ele deve receber o melhor resultado possível a cada semana, ver o progresso no sistema, ser informado de mudanças de planos, etc. Escute, para que saiba qual é o problema a ser resolvido.

  • Planejamento: O desenvolvimento utilizando o XP é feito em iterações. Uma iteração é um período curto de tempo (1 ou 2 semanas) onde a equipe desenvolve um conjunto de funcionalidades. Sendo assim, no início da semana, desenvolvedores e clientes se reúnem para priorizar as funcionalidades. Essa reunião chama-se jogo de planejamento e nela já devem estar criadas as estórias. Se uma estória for muito grande, ela deve ser dividida em tarefas com duração máxima de alguns dias. Essas estórias devem ser escritas pelo cliente, pois assim ele consegue pensar melhor em cada funcionalidade. O planejamento é importante para que você sempre faça a coisa mais importante a ser feita.

  • Stand Up Meeting: São reuniões feitas em pé e de curta duração – mas muito produtiva, para que o time se mantenha alinhado, para saber o que cada um está fazendo exatamente, em que ponto está o projeto e se alguém está tendo problemas para executar suas tarefas. Ainda que apareça algum problema, essa reunião não tem o propósito de pensar em soluções.

  • Programação em par: É uma programação em par (dupla) em um único computador. Como é apenas um computador, o software sempre é revisto por duas pessoas diminuindo assim a possibilidade de falhas. Busca-se sempre a evolução da equipe melhorando a qualidade do código fonte. Ela é uma das práticas primordiais do XP, pois dois programadores fazendo o trabalho juntos acaba agregando muito para o trabalho em equipe.

  • Testes constantes: É utilizado o Desenvolvimento Orientado a Testes (Test Driven Development), o conhecido TDD. Primeiro crie os testes unitários e depois crie o código para que o teste funcione, essa abordagem é complexa no início, mas os testes unitários são essenciais para que a qualidade do projeto seja mantida.

  • Refatoração: É um processo que permite a melhoria contínua da programação, o mínimo de introdução de erros e mantendo compatibilidade com o código já existente. Refatorar melhora a clareza, leitura do código e facilita a manutenção. Além disso, o código fica mais coeso e você tem um melhor aproveitamento, evitando duplicação no código fonte.

XP - Extreme Programming
Curso de XP - Extreme Programming
CONHEÇA O CURSO
  • Código coletivo: Diz que o código fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo é fazer a equipe conhecer todas as partes do sistema.

  • Padronização do código: Como todo mundo trabalha no desenvolvimento do mesmo software, a equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir essas regras, assim parecerá que todo código fonte foi digitado pela mesma pessoa. A padronização de código também é muito importante, porque o XP preza isso, o trabalho em equipe, se uma pessoa faz de um jeito e a outra faz de outro, isso fica muito confuso e futuramente pode ter problemas na revisão deste código.

  • Design simples: Essa prática se encaixa no princípio da simplicidade e é basicamente seguir o que o usuário está pedindo, por conta disso o design do software acaba sendo mais simplista. Além disso, o software acaba ficando mais fácil de ser alterado. Com essa metodologia você consegue alterar o código quando precisar, sem comprometer a qualidade.

  • Metáfora: Procura facilitar a comunicação com o cliente, entendendo qual a realidade dele. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

  • Ritmo sustentável: Manter um ritmo de trabalho com qualidade, onde eles estejam atentos e dispostos.

  • Semana de 40 horas: É trabalhar com qualidade buscando ter um ritmo de trabalho saudável, 40h por semana, 8h por dia, sem horas extras.

  • Integração contínua: Sempre que for produzido uma nova funcionalidade você nunca deve esperar uma semana para integrar com a versão atual do sistema. Isso só aumenta a possibilidade de conflitos e possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

  • Releases curtos: As liberações de pequenas versões funcionais do projeto auxiliam muito no processo de aceitação por parte do cliente que já pode testar uma parte do sistema. As versões chegam ainda ser menores que as produzidas em outras metodologias incrementais, como o RUP. Os releases são pequenos pedaços do produto que são entregues ao cliente antes do tempo, assim o cliente não precisa esperar o produto todo ficar pronto para ver.

Considerações finais

Como pudemos ver o XP é dinâmico e flexível, nos ajudando a ter rapidez, qualidade e flexibilidade no desenvolvimento de um software. Se você quer conhecer ainda mais a fundo e principalmente ver o XP funcionando na prática, confira nosso curso de Extreme Programming.

Formação:
CONHEÇA A FORMAÇÃO

Engenharia de Software

O que é Lean TI?

Os ambientes tecnológicos precisam de atualização constante. Visando isso, existem diversas metodologias que podem nos ajudar, uma delas – que é a que veremos neste artigo – é a Lean TI.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

Metodologia Lean

Primeiramente precisamos saber o que vem a ser a metologia Lean. Lean é a aplicação dos princípios da filosofia Lean manufacturing, baseada no Sistema Toyota de Produção. Essa metodologia tem como objetivo resolver os problemas e eliminar desperdícios de forma contínua, aumento na eficiência, reduzir custos, tudo isso sem perder o foco da criação de valor para o cliente. Em resumo, ele foca em criar mais valor com menos trabalho.

A metodologia defende que devemos olhar todas as áreas da empresa como um todo. Todos os processos de melhoria devem estar relacionados aos objetivos e estratégias da empresa. Um dos princípios do Lean não está apenas na implementação da metodologia, mas também no amadurecimento da cultura da empresa.

Lean TI

A Lean TI vem a ser uma adaptação da metodologia Lean para ser aplicada na área da tecnologia da informação. A Lean prioriza a integração dos colaboradores e em sua aplicação na TI não é diferente. A Lean TI representa transformação e melhorias, tanto de processos quanto de pessoas, fazendo com que as estratégias e as operações de negócio estejam cada vez mais próximas.

A Lean TI pode ser utilizada em empresas de TI propriamente ditas, como também em empresas que utilizam a TI como suporte para seus serviços. A Lean TI prega que todos os colaboradores sejam capazes de atuar nos mais diferentes tipos de situações e estejam aptos a resolve-las.

React - Tópicos Avançados
Curso de React - Tópicos Avançados
CONHEÇA O CURSO

Entre as principais vantagens no uso dessa metodologia estão:

Aumento na eficiência

É necessário intervir no ambiente de TI para aperfeiçoar os métodos e sempre testar novas maneiras de resolver problemas, antes que eles cheguem em um ponto mais crítico. Esses métodos podem ser utilizados para criar sistemas mais funcionais, que integrem corretamente todos os processos, tornando os procedimentos mais eficientes e seguros.

Maior agilidade

Essa é a principal vantagem em utilizar o Lean TI na gestão de TI, pois você consegue obter maior agilidade sem abrir mão da excelência. Áreas que antes agiam mais isoladas passam a interagir, e assim desenvolvem projetos com mais velocidade.

Melhores soluções

Ao aplicar os conceitos do Lean, você conseguirá uma melhora nos resultados que irão refletir não só somente nos serviços de TI como também em toda a cadeia de valor do negócio. Ao ser aplicada na área de TI ela também consegue colocar em prática dentro da realidade de negócios.

Agora você deve estar pensando: “Mas como vou colocar isso prática?”. Você pode utilizar o Canvas para seu plano de negócio, alguma metodologia ágil, Kanban… todos esses assuntos já foram abordados aqui no blog caso você queira dar uma olhada. =)

Até a próxima!

Desenvolvedor Java
Formação: Desenvolvedor Java
A formação Desenvolvedor Java da TreinaWeb tem como objetivo apresentar o desenvolvimento através do Java e todo o ecossistema para desenvolvimento da Oracle. Nesta formação, são desde tópicos básicos como o paradigma orientado a objetos, a preparação do ambiente de desenvolvimento para o Java através do Eclipse e o controle de versão de código através do Git e do GitHub. Até aspectos mais avançados como acesso a bancos de dados relacionais e o desenvolvimento de aplicações web com o Java.
CONHEÇA A FORMAÇÃO

Engenharia de Software

Kanban x Scrum: diferenças e como implementá-los

No nosso último artigo sobre Kanban, vimos alguns dos princípios básicos para que ele funcione corretamente. Começamos a abordar também que o Kanban não é uma metodologia ágil. Por ele ser comumente utilizado junto a uma metodologia ágil, como o Scrum por exemplo, pode haver essa confusão.

Sendo assim, vamos abordar nesse artigo quais são essas diferenças e como eles se complementam entre si.

*(Vale lembrar que já temos um artigo explicando sobre o Scrum, caso você queira saber mais sobre essa metodologia leia nosso artigo “Scrum como ferramenta de apoio ao gerenciamento de projetos“.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

Afinal, quais são essas diferenças?

Depois de saber um pouco mais sobre o Scrum e o Kanban, podemos ver que eles compartilham alguns dos mesmos conceitos, mas com abordagens diferentes, portanto não devem ser confundidos um com o outro.

Na tabela abaixo, podemos ver de maneira geral algumas das principais diferenças.

Kanban Scrum
Ritmo Fluxo contínuo Sprints regulares definidas (ex: 1 semana, 2 semanas)
Funções Sem funções existentes Funções definidas, como Scrum Master, equipe de desenvolvimento, etc.
Entregas Contínua ou a critério da equipe No final de cada Sprint devem ser aprovadas. Caso não seja, a mesma tarefa volta para a próxima Sprint.
Mudanças Podem ocorrer a qualquer momento As equipes devem se esforçar para não fazer alterações na previsão da sprint durante a mesma, pois a estimativa fica comprometida.

Em outras palavras, o Kanban foca mais no acompanhamento visual dos processos e o Scrum no gerenciamento do projeto, por isso a junção desses dois é muito utilizada. Vamos abordar agora como é feita essa implementação em uma empresa.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

Colocando o Kanban e Scrum em prática

Primeiramente precisamos ressaltar a importância do engajamento da equipe. Sem isso você não conseguirá ter sucesso. Esse engajamento é importante pois, no Kanban, cada colaborador é responsável por manter o painel sempre atualizado.

Primeiro começamos indo mais para o lado do Scrum, onde precisamos realizar alguns passos essenciais. Você deve definir sua equipe, escolher o Product Owner (pessoa responsável pela visão do que será entregue no projeto) e o Scrum Master (quem irá orientar a equipe).

Após os cargos definidos aos responsáveis, deve ser elaborada a Product Backlog, que é uma lista geral detalhada de tudo que precisa ser feito para chegar ao objetivo final, como por exemplo, a finalização de um software.

Após definir todas as tarefas que devem ser executadas na Product Backlog, deve-se estimar o respectivo esforço para cada uma delas. Isso é necessário para determinar a produtividade e a velocidade do projeto.

Uma das formas utilizadas é utilizando a sequência de Fibonacci. Mas calma que não é tão complicado assim. É determinado uma estimativa de pontos para cada tarefa, como 1,2,3,5,6,13,21… É bem rápido de se acostumar. Por exemplo, uma tarefa com 1 ponto, é uma tarefa bem rápida de ser feita, provavelmente poucas horas do dia, enquanto uma tarefa com 13 pontos já demanda um tempo maior, como alguns dias.

Depois das tarefas e estimativas prontas, é a hora da primeira reunião. Ela servirá para planejar a Sprint, que pode ser de 1 ou 2 semanas geralmente. Também é definido a Sprint Backlog, onde algumas tarefas da Product Backlog irão para a Sprint a fim de serem concluídas durante o período estimado.

Normalmente são passadas as tarefas prioritárias ou tarefas que conseguirão ser concluídas naquele período. É importante todos os envolvidos concordarem com o objetivo da Sprint. Também é importante pensar na realidade: colocar três tarefas com 13 de pontuação para um colaborador realizar em uma semana, pode ser que essas tarefas não sejam concluídas. Por isso que temos a pontuação para nos indicar o quanto de esforço teremos em cada tarefa e assim ter a estimativa se ela vai conseguir ser concluída a tempo. Se não, você pode até quebrar essa tarefa em duas ou três tarefas menores.

Agora vamos entrar no ponto que entra a metodologia Kanban. Você irá utilizar o Kanban para organizar o desenvolvimento, podendo ser utilizado um quadro com post-its ou também por meios digitais, já que temos muitas plataformas que permitem isso. Se for um quadro físico ele deve ficar em um local de fácil acesso onde todos possam vê-lo e se informar. Esse quadro pode ser dividido em “A fazer – Em execução – Feito” ou você pode dividir as colunas de acordo com suas necessidades. O importante é a equipe saber bem o que significa cada coluna e sempre manter os post-its atualizados.

A partir daí teremos o Daily Scrum, uma reunião diária entre a equipe e o Scrum Master. É uma reunião rápida apenas para que cada um responda a três perguntas: “O que você fez ontem?”, “O que vai fazer hoje?” e “Quais os problemas encontrados?”. Lembrando que são respostas curtas e rápidas, mas que serve para que toda a equipe saiba em que ponto estão na Sprint. Com isso, o Scrum Master conseguirá ver se todas as tarefas serão concluídas a tempo, e claro, é ele quem irá resolver qualquer obstáculo que possa ter na equipe.

Após o período da Sprint (1 ou 2 semanas) é realizada a Sprint Review. É a reunião onde a equipe apresenta o que conseguiu evoluir durante a Sprint, podendo apresentar somente o que conseguir colocar no quadro como “feito”, ou seja, a tarefa deve estar totalmente concluída.

Por fim, temos a retrospectiva da Sprint, onde os envolvidos podem fazer uma avaliação de tudo o que aconteceu, como lições aprendidas, o que não deu certo, dificuldades, o que pode ser melhorado. É uma reunião de feedback para aprimoração do processo, podendo assim melhorar as próximas Sprints.

Feito isso, volta tudo de novo… Uma nova Sprint, novas tarefas a serem realizadas, e assim sucessivamente.

Concluindo…

Agora sim ficou mais claro onde o Kanban ajuda o Scrum e como eles se complementam, outro artigo que aconselho a leitura é sobre as diferenças entre metodologia ágil x tradicional. E você, já fez uso deles na sua empresa?

Formação:
CONHEÇA A FORMAÇÃO

Engenharia de Software

Princípios básicos do Kanban

O Kanban que vem da palavra japonesa “cartão visual” é uma simbologia visual utilizada para registrar ações. Inicialmente utilizada em indústrias, para a gestão do estoque e controle do fluxo de peças, hoje também vem sendo muito utilizada na área de tecnologia para potencializar os resultados, principalmente na área de desenvolvimento de software.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

O Kanban permite que todos os envolvidos no processo tenham visibilidade do mesmo, deixando também explícito os problemas e pontos de sobrecarga. Utilizar uma ferramenta visual para gestão do fluxo de desenvolvimento de um software, por exemplo, pode evitar mudanças frequentes ao longo do processo.

O Kanban é uma metodologia que prega que se use um quadro físico ou virtual, dividido em colunas que representem as etapas de um processo. Por meio de cartões, as tarefas que devem ser realizadas são descritas, colocando suas datas de entrega e os responsáveis por ela. Para melhor visualização você pode utilizar cartões de diferentes cores, cada um indicando um cliente, funcionário, o que você preferir. Uma das vantagens é que com uma simples olhada você consegue ver quantas tarefas estão sendo executadas, quantas foram concluídas…

Vamos abordar agora alguns dos princípios básicos na utilização do Kanban.

Visualize o Fluxo de trabalho

O Kanban é mais focado no fluxo contínuo, sendo assim é muito importante enxergar o que está sendo feito, para que assim possamos ver onde estarão os possíveis problemas. Além de definir as etapas que serão monitoradas, deve-se determinar quantas tarefas cada pessoa poderá ter, levando em conta o tamanho do seu time e o esforço demandado por tarefa.

Teste de Software Avançado
Curso de Teste de Software Avançado
CONHEÇA O CURSO

Pare de começar e comece a terminar

Esse é um dos principais princípios do Kanban. Por isso, é importante limitar a quantidade de itens para fazer, e claro, um por vez, para que eles não fiquem lá parados e inacabados. Quando você foca em apenas um item, você acaba interagindo 100% naquela tarefa.

Deixe explícita as políticas de cada coluna

Aparecer de parecer meio óbvio, é importante que todos saibam o que significa cada coluna e sempre manter as tarefas contidas nelas atualizadas. Você pode definir as colunas de acordo com suas necessidades ou pode utilizar o “To do – Doing – Done” (A fazer – Em execução – Feito).

Evolução constante

Depois de saber sobre as colunas e visibilidade das suas tarefas, é preciso ver como seu fluxo se comporta, para assim poder ver os possíveis problemas e melhorá-los. Alguns dos problemas que você pode identificar é a sobrecarga de um funcionário ou uma tarefa que está demorando muito para ser concluída, sendo que na verdade, ela não demanda tanto tempo assim. Por isso, é importante a transparência total no trabalho.

Muitas vezes o Kanban é confundido como uma metodologia ágil, porém ele é um complemento na utilização delas. Veja nosso artigo sobre as diferenças do Kanban e Scrum e como colocar tudo isso em prática. Até lá!

Formação:
CONHEÇA A FORMAÇÃO