Desafios no Desenvolvimento de Software para VR e AR

Performance e Latência

Um dos maiores desafios no desenvolvimento de software para VR e AR é garantir alta performance e baixa latência. Em aplicações de VR, qualquer atraso ou falha na renderização pode causar desconforto ao usuário, incluindo náuseas e desorientação. Por isso, é essencial que os sistemas operem com uma latência inferior a 20ms. Isso requer hardware potente e otimização eficiente do software para garantir que os gráficos sejam renderizados em tempo real.

Precisão de Rastreamento

Para criar uma experiência verdadeiramente imersiva, é necessário um rastreamento preciso dos movimentos do usuário e do ambiente. Sistemas de rastreamento, como câmeras e sensores, devem ser altamente precisos e rápidos para capturar movimentos sutis e garantir que as ações no mundo virtual correspondam aos movimentos reais do usuário. Assim, a integração desses sistemas com o software de VR/AR é complexa e desafiadora.

Interface do Usuário (UI/UX)

Desenvolver uma interface de usuário intuitiva e eficiente para VR e AR é fundamental. Diferente das interfaces tradicionais, em VR e AR os usuários interagem com o conteúdo de maneira tridimensional e imersiva. Isso exige a criação de novos paradigmas de interação que sejam naturais e fáceis de usar. Portanto, elementos como gestos, voz e até mesmo o olhar do usuário podem ser utilizados para navegar e interagir com o ambiente virtual.

Avanços no Desenvolvimento de Software para VR e AR

Ferramentas e Plataformas de Desenvolvimento

Nos últimos anos, houve um avanço significativo nas ferramentas e plataformas de desenvolvimento de VR e AR. Engines como Unity e Unreal Engine proporcionam uma base sólida para a criação de ambientes virtuais ricos e detalhados. Dessa forma, essas ferramentas oferecem bibliotecas e frameworks específicos para VR e AR, facilitando o trabalho dos desenvolvedores.

Integração com IA e Machine Learning

A integração de Inteligência Artificial (IA) e Machine Learning (ML) com VR e AR está trazendo novas possibilidades para essas tecnologias. Algoritmos de IA podem ser usados para melhorar o rastreamento de movimentos, reconhecer objetos e ambientes, e criar interações mais naturais e responsivas. Isso possibilita experiências mais realistas e personalizadas para os usuários.

Realidade Mista (MR)

A Realidade Mista (MR), que combina elementos de VR e AR, está emergindo como um campo promissor. Em MR, objetos virtuais são ancorados no mundo real, permitindo interações que combinam o físico e o digital. Assim, é possível abranger novas possibilidades para aplicações em áreas como design, educação e treinamento, onde a simulação e a interação com objetos virtuais em um ambiente real podem ser extremamente benéficas.

Aplicações Práticas de VR e AR

Educação e Treinamento

No setor educacional, VR e AR estão sendo usadas para criar ambientes de aprendizagem imersivos. Simulações em VR permitem que os alunos pratiquem habilidades em um ambiente seguro e controlado. Por exemplo, estudantes de medicina podem realizar cirurgias virtuais antes de operar em pacientes reais. Em treinamento corporativo, essas tecnologias ajudam a simular situações de trabalho, proporcionando uma experiência de aprendizagem prática e envolvente.

Engenharia e Arquitetura

Em engenharia e arquitetura, os profissionais utilizam VR e AR para visualizar projetos em escala real antes de construí-los. Dessa forma, facilita-se a identificação de problemas e ajustes no design, economizando tempo e recursos. Engenheiros podem caminhar por um edifício virtual, inspecionar detalhes e testar diferentes soluções em um ambiente controlado.

Entretenimento e Jogos

O setor de entretenimento, especialmente os jogos, tem sido um dos maiores beneficiários de VR e AR. Assim, jogos imersivos que transportam os jogadores para mundos virtuais detalhados estão se tornando cada vez mais populares. A interação em tempo real e a sensação de presença proporcionada por essas tecnologias criam experiências de jogo únicas e emocionantes.

Por fim, o Blog da Engenharia é seu portal de conteúdo para todas as engenharias, oferecendo as últimas novidades e avanços tecnológicos. Continue nos acompanhando e fique por dentro de todas as novidades do mundo da engenharia!

The post Engenharia de Software para Aplicações de Realidade Virtual e Aumentada appeared first on Blog da Engenharia.

Portanto, se você já leu a PARTE 1, podemos começar segunda parte.

Neste artigo, daremos início ao framework propriamente dito, assim, abordaremos os papéis, os eventos e os principais artefatos do SCRUM e como se relacionam dentro do desenvolvimento de um projeto.

Basicamente, existem 3 papéis importantes na equipe que implementam o SCRUM. São eles:

• Product Owner (Dono do Produto).
• Scrum Master.
• Development Team (Time de Desenvolvimento).

Em alguns materiais são informados outros dois, os Stakeholders (Partes Interessadas) e os Gerentes.

Porém, embora sejam muito importantes, não tratarei desses papéis nesta série, pois a relação destes dois papéis são auxiliares e eles não se envolvem integral e frequentemente com os processos do SCRUM.

Product Owner

Todo projeto possui por excelência stakeholders, sejam os clientes, os fornecedores, investidores, a comunidade, os parceiros, o governo ou qualquer outro órgão que possa estar envolvido no projeto.

Portanto, dentro de uma equipe SCRUM é fundamental a presença de um Product Owner. Ele é o principal responsável por ser a ponte entre a equipe e os stakeholders, podendo assim gerar valor ao projeto.

Além disso, o Product Owner é o membro responsável por escrever as Product Backlogs  – artefato abordado mais abaixo.

É importante ressaltar que cada equipe SCRUM possui apenas um Product Owner.

Scrum Master

O Scrum Master é o líder facilitador do time SCRUM, cuja as principais funções são remover os impedimentos que possam vim a atrapalhar a execução das Sprints, ajudar o Time de Desenvolvimento a entender e praticar corretamente o framework, assim como garantir sua implementação dentro da organização.

Além disso, o Scrum Master também é o responsável por guiar o Time de Desenvolvimento em suas tarefas diárias, auxiliar os Daily Meetings (Reuniões Diárias) e servir como ponte entre o Time e o Product Owner.

Development Team

Por fim, temos o Time de Desenvolvimento, o time de pessoas responsável por executar as Sprints determinadas pelo Product Owner da equipe e entregar o produto.

O Time de Desenvolvimento é, geralmente, composto por 5 pessoas, no máximo nove, sendo a equipe constituída de profissionais multidisciplinares e auto gerenciáveis, no qual seu principal objetivo é entregar algum tipo de incremento funcional em cada Sprint.

O que é um SPRINT?

No esporte, um Sprint é quando um atleta se esforça para dar o máximo de si a fim atingir sua velocidade máxima, seja correndo, pedalando ou nadando. Por conta da fisiologia humana, as pessoas não conseguem se manter neste estado por muito tempo, então os sprints são rápidos, algo de 30 a 35 segundos.

Os Sprints do SCRUM seguem o mesmo preceito, isto é, são pequenos períodos de tempo, no qual o Time de Desenvolvimento se esforça para desenvolver e entregar alguma parte do trabalho. Assim como no esporte, os sprints do SCRUM duram pouco tempo, geralmente, entre 1 semana a 1 mês.

A ideia é que dividindo o trabalho em pequenas partes, a equipe possa entregar parte do projeto ao cliente e, assim, receber um feedback do trabalho realizado. Na primeira parte desta série, isto foi citado nos Princípios do AGILE, nos tópicos 1, 3, 7 e 12.

Eventos do SCRUM

Os Eventos do SCRUM são, basicamente, as tarefas que giram em torno dos Sprints. O framework apresenta 4, que são os:

• Daily Meeting (Reunião Diária)
• Planning Meeting (Reunião de Planejamento)
• Sprint Review (Revisão do Sprint)
• Sprint Retrospective (Retrospectiva do Sprint)

Daily Meeting

Como o próprio nome sugere, os Daily Meetings são as famosas Reuniões Diárias do SCRUM que ocorrem todos os dias durante um Sprint.

O objetivo destas reuniões é alinhar os participantes com o que foi feito, o que deve ser realizado no dia, além de ajudar o Scrum Master a identificar os possíveis impedimentos e, por isso, cada membro deve fazer as seguintes perguntas:

• O que você tem feito desde ontem em direção à meta?
• O que você planeja fazer hoje em direção à meta?
• Há algo que pode te impedir de realizar seu objetivo em direção à meta?

As Reuniões Diárias do SCRUM não ultrapassam o tempo de 15 minutos, além de serem realizadas em pé – por isso às vezes também são chamadas de Stand up Meeting. O objetivo disso é gerar um ambiente levemente desconfortável, assim as reuniões são mais práticas e eficazes.

Planning Meeting

As Planning Meeting, ou Reuniões de Planejamento, são as reuniões que ocorrem com toda a equipe SCRUM, no início de cada Sprint, a fim de definir qual o objetivo do Sprint e ajudar o Product Owner a gerar o Sprint Backlog.

É importante a presença de todos os membros, pois a Equipe precisa definir o “Que” deve ser feito, “Como” e também” Quem” fará o que. Planejar bem é muito importante, pois além de ajudar a concluir o processo com mais eficiência, ajudará a motivar a equipe conforme as etapas são finalizadas.

Review Sprints

As Revisões de Sprints são as reuniões que a equipe SCRUM organizam no final de cada Sprint com o objetivo de rever o trabalho que foi executado, as tarefas que deixaram de ser feitas e apresentar as novas funcionalidades para os Stakeholders.

Além disso, durante esta reunião é importante que o projeto seja avaliado em relação ao objetivo da Sprint que foi previamente definido na Reunião de Planejamento.

Nesta reunião, participam o Time de Desenvolvimento, o Product Owner, o Scrum Master, além dos gerentes, engenheiros, clientes e qualquer outra Parte Interessada no projeto.

Sprint Retrospective

 Os Sprint Retrospectives são reuniões que ocorrem no final de cada Sprint. São, geralmente, a última atividade dentro de um Sprint, pois seu objetivo é, principalmente, procedural.

Nestas reuniões a equipe SCRUM avaliará o andamento dos Sprints a fim de buscar possíveis melhorias no processo. Perceba a diferença entre a Retrospectiva do Sprint e as Revisões de Sprint, no qual esta se preocupa com o que a equipe está construindo, enquanto aquela trata de como o processo está sendo executado.

Artefatos do SCRUM

Por fim, temos os dois artefatos oficiais do SCRUM. O Scrum Guide, o manual oficial do SCRUM, os definem como:

• Product Backlog [Backlog do Produto]
• Sprint Backlogs

Product Backlog

Como vimos anteriormente, na parte de papéis do SCRUM, uma das funções do Product Owner é gerar os Product Backlogs.

Em inglês um Backlog é “um acúmulo de algo, especialmente um trabalho incompleto ou questões que precisam ser tratadas” (Dicionário de Oxford). Seguindo esta linha de raciocínio, um Product Backlog – ou Backlog do Produto – nada mais é do que uma lista que contém os requisitos do cliente em uma ordem prioritária.

Portanto, os Product Backlogs são extremamente necessários na execução da Sprint, uma vez que ditará o que deve ser realizado.

Porém, caso o Product Owner sinta necessidade de alterações, ele – como o responsável pelo Backlog do Produto – pode mudar durante a Sprint.

Sprint Backlog

Já a Sprint Backlog é uma lista de tarefas extraída a partir do Product backlog. Estas tarefas deverão ser executadas durante a Sprint.

Os Sprints Backlogs são criados durante a Reunião de Planejamento, onde a equipe SCRUM seleciona um número de itens da Product Backlog, além de estimar a quantidade de horas necessárias para realiza-los.

Na Reuniões Diárias, o Time de Desenvolvimento poderá realizar alguma mudança no Sprint Backlog, caso seja necessário. Por exemplo, se as tarefas estiverem quantitativamente menor que a capacidade da equipe ou muito difíceis de serem executadas em uma única Sprint.

Por fim, espero que tenha ficado claro quais são os Papéis, os Artefatos e Eventos do SCRUM. Atente-se às palavras em negritos, pois tratam-se de conceitos importantes para o framework. Espero você na PARTE 3 da série, até logo!

Aproveite e siga o Blog da Engenharia no Instagram!

Já me segue no Instagram?

The post Destrinchando o SCRUM [Parte 2/4] appeared first on Blog da Engenharia.

Isso porque o SCRUM tem se tornado muito popular nos últimos anos e seus adeptos ao redor do mundo só tendem a aumentar.

Mas, se você não sabe ou nunca utilizou o SCRUM, talvez esteja se perguntando “por que será que este termo anda tão em voga?”, “da onde surgiu esse tal de SCRUM” ou mesmo “como posso utilizar o SCRUM?”.

Assim, se você pretende começar a vislumbrar este framework ou se já conhece, mas pretende aprender um pouco mais – afinal conhecimento nunca é demais – você está no lugar certo.

Nesta série DESTRINCHANDO O SCRUM, dividida em 4 partes, veremos:

1. O que é o SCRUM e como ele surgiu. [PARTE 1/4]
2. SCRUM e o Movimento Ágil. [PARTE 1/4]
3. Quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos. [PARTE 2/4]
4. Como implementar e acompanhar o SCRUM com sucesso! [PARTE 3/4]
5. Quando não se deve implementar o SCRUM. [PARTE 3/4]
6. Por fim, algumas DICAS especiais que preparei junto ao Antonio Santos,  Scrum Master e atual supervisor de implantação de projetos da Modular Mining System, para leitores que pretendem se aprofundar. [PARTE 4/4]

Sem mais delongas, vamos juntos destrinchar o SCRUM.

Afinal, o que é o SCRUM?

O SCRUM é um framework – não uma metodologia – de projetos com etapas bem definidas que, inicialmente, buscava auxiliar equipes no desenvolvimento de softwares.

Porém, sua implementação não se restringiu a este campo e, atualmente, pelo menos 60% dos projetos ágeis em todo mundo, de diferentes áreas, setores e níveis organizacionais o utilizam.

O grande destaque do SCRUM está no fato dele ter sido criado, especialmente, para lidar com alguns dos principais problemas que decorrem ao longo do desenvolvimento de um projeto, isto é, a imprevisibilidade, prazos curtos, burocracias, complexidade de problemas iminentes, hierarquias mal elaboradas, comunicação, dentre muitos outros.

Logo, dentre os principias benefícios de aplicar o SCRUM podemos citar alguns, como:

• Simplicidade
• Maior velocidade
• Mais flexibilidade
• Comunicação aprimorada
• Transparência
• Adaptabilidade
• Eficiência na execução
• Engajamento do time

Uma breve história do SCRUM

A história do SCRUM inicia-se em 1986. Em janeiro deste ano, Takeuchi e Nonaka, publicam o artigo intitulado The New Product Development Game – O novo Jogo de Desenvolvimento de Produtos – no qual destacava empresas no Japão e nos Estados Unidos que adotaram uma nova abordagem para gerenciar o processo de desenvolvimento de produtos.

Além disso, o nome SCRUM – derivado do jogo de Rugby – foi sugerido, depois que Takeuchi e Nonaka observaram que algumas equipes, pequenas, multidisciplinares e auto gerenciáveis, recorrentemente obtinham melhores resultados comparado às equipes grandes do modelo cascata de gerenciamento de projetos.

Já em 1993, Jeff Sutherland e Jeff McKenna, insatisfeitos com os recorrentes atrasos em seus projetos de desenvolvimento de softwares, orçamentos estourados, além do estresse gerado pela utilização dos modelos tradicionais de gestão de projetos, abraçaram o estudo de Takeuchi e Nonaka e arquitetaram o framework para utilizá-lo pela primeira vez na Easel Corporation.

“Na Easel, não tínhamos nada a perder, por isso decidimos tentar, embora o artigo se concentrasse na fabricação de produtos e não no desenvolvimento de softwares. Pensei que a ideia deles abordava algo fundamental, um processo descritivo de como os seres humanos trabalhavam melhor juntos em qualquer empreendimento” – Jeff Sutherland

Depois de dois anos de sucesso implementado o SCRUM, em 1995, Jeff Sutherland e Jeff McKenna apresentaram o artigo titulado SCRUM Development Process – Processo de desenvolvimento SCRUM – no qual, objetivavam a sistematização das práticas do SCRUM na conferência de pesquisa da Association for Computing Machinery (ACM), a primeira e maior sociedade de computação científica e educacional do mundo.

Desde então, o SCRUM vem se adaptando e evoluindo, mas o núcleo apresentado na conferência continua praticamente o mesmo.

SCRUM e o Manifesto Ágil

O Manifesto Ágil – também conhecido como Agile – é um documento que foi, inicialmente, elaborado entre os dias 11 a 13 de fevereiro de 2001, em uma reunião em Utah, EUA.

Na época, grandes gestores de projetos e profissionais influentes da computação se reuniram para discutir os fatores que realmente importavam no desenvolvimento de software.  Na reunião, acabou sendo compilada uma série de 4 valores e 12 princípios que deveriam nortear a gestão, tomada de decisões e ações das equipes durante a execução de projetos ágeis, assim, otimizando os resultados.

Além disso, vale ressaltar que entre os participantes da reunião se encontravam nossos caros Jeff Sutherland e McKenna. Por isso – e por outro motivos – o SCRUM também é consistente com os valores e princípios do Agile.

Enfim, confira abaixo os 4 Valores e os 12 Princípios do Manifesto Ágil, traduzidos diretamente do site oficial do agilemanifesto.org, onde se encontra o documento.

4 Valores do AGILE

• Os indivíduos e suas interações acima de procedimentos e ferramentas.
• O funcionamento do software acima de documentação abrangente.
• A colaboração com o cliente acima da negociação e contrato.
• A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

12 Princípios do AGILE

1. Satisfação do cliente – Nossa maior prioridade é satisfazer o cliente por meio de entrega antecipada e contínua de software valioso.
2. Adaptabilidade –  mudanças de requisitos são bem-vindas, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
3. Frequência de entrega – Entrega de software funcional com frequência, de algumas semanas a alguns meses, com preferência à escala de tempo mais curta.
4. Cooperação – Empresários e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto.
5. Motivação – Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte de que precisam e confie neles para fazer o trabalho.
6. Face-to-Face – O método mais eficiente e eficaz de transmitir informações para dentro de uma equipe de desenvolvimento é a conversa ‘cara-a-cara’.
7. Softwares Funcionais – O software funcional é a principal medida de progresso.
8. Ritmo Constante – Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante, indefinidamente.
9. Bons Designs – Atenção contínua à excelência técnica e um bom design aumenta a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.
11. Auto-organização – As melhores arquiteturas, requisitos e projetos emergem de equipes auto organizáveis.
12. Feedbacks – Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, em seguida, sintoniza e ajusta seu comportamento de acordo.

Além disso, na PARTE 2 desta série abordaremos quais os eventos, os papéis e os artefatos do SCRUM, além de outros termos.

Continue atento aos próximos artigos e não deixe de acompanhar o conteúdo que trazemos diariamente aqui no Blog, pois sempre tem muita coisa interessante.

Aproveite e siga o Blog da Engenharia no Instagram!

The post Destrinchando o SCRUM [Parte 1/4] appeared first on Blog da Engenharia.