Você está ouvindo Nerdcast no Jogin Nerd. Lá, lá, lá, lá, Nerdcast! Aqueles chandros, todo mundo em Jogin Nerd, eu adoro o método ágil do Inenaut. Aqui é o Maurício Linhres, ele nenhum projeto nunca foi entregue na data que era para entregar.

Ah, nunca, na vida, no mundo. Aqui é o Paulo Souvera e eu estou com três tarefas atrasadas no meu trelo. Só? Só! Aqui as agaldas, o aburro de alfás, que é de uma especial cebola picro de um pouco de arreino. Ah, cadê meu lanche? Hahaha! Muito bem! É deus em mais um nerd de tech trazido a você pela aluna do nosso querido Paulo Silveira. Hoje vamos falar sobre métodos ágios. É isso ou o nome? É isso aí. Eu sentei. Mas olha, eu confesso que depois de dois anos praticamente de nerd de tech, É a primeira vez que Eu não sei, absolutamente nada, ele falou metodosadios, eu não sei nada sobre a sultra, então Paulo, por favor, introduza os metodosadios. É nossos ouvidos. Em todo o episódio a gente costuma ter o fator jovem nerd, No NerdTech que é O Alexandre sempre conhece mais do assunto do que a gente imagina Pela primeira vez a gente conseguiu pegar o carro Peraça vez não sei nada Você vai ver que não vai ser bem assim Sabem aquele projeto que você tem aí que existe no jovem nerd, que vocês querem fazer já tem um ano, você já definiu um projeto, ele está em andamento e ele nunca saiu, ele pior ainda. Ele está sendo implementado, mas ele continua sendo implementado e aquela data de publicação que é sempre no mês que vem, nunca chega, ou isso nunca aconteceu pra vocês. Já, já, há muito tempo. O papo que a gente quer trazer hoje é sobre essas metodologias novas, novas que já tem umas duas décadas para tentar desenvolver projetos. E seja o projeto que for, mas a gente está falando aqui bastante de projeto de software, projeto de internet ou um produto desses de start-up pra você vender na internet no modelo de subscription. A gente está acostumado com essa forma tradicional de entregar alguma coisa, que é você fazer a tal da análise de requisitos. A gente quer criar um projeto, a gente vai sentar com quem quer esse projeto para falar. Fala aqui para mim o que você precisa, aí você pega lá o seu ponto do ox, o Google Docs e começa a notar todos os requisitos daquele usuário. Passada essa fase de análises de requisitos,

a gente vai passar para a segunda fase, que é a fase de design. do oxe ou google dox e começa a anotar todos os requisitos daquele usuário. Passada essa

fase de análises de requisitos a gente vai passar para a segunda fase que é a fase de design. Depois vem a parte de implementação e por último a implantação do esse projeto. E essas fases costumam demorar bastante tempo. Então desde aquele dia que eu sentei com o joven nerd para saber tudo o que ele precisava para aquele projeto novo, que é o sistema novo de podcast para Android, até a data da implementação e da implantação que se passaram 6 meses,

se eu chegar pro jovener de falar, olha, a sua seis meses está aqui, o que você me pediu? Muito bem aquilo que a comunidade jovener de queria. Não é muito bem aquilo. O que o jovener de falou para mim? Não era bem aquilo que ele queria dizer. Eles usam palavras erradas e eu entendi outra coisa. Então, lá na década de 2000,

começaram a surgir métodos ou metodologias tem uma disposição aí para tentar resolver esse problema, qual problema? esse problema de atraso em projetos de software e pior ainda esse problema de comunicação que é passado seis meses chega lá eu entrego o projeto para vocês e não era aquilo que você queria. Ah só para deixar claro,, você tem um gosto de cash aí de Android, não é muito sem que quis, você que ia ver o tozapone. Ah, você podia ter falado o app para Windows Phone. Vai sair o app para Windows Phone, não? Não, vai junto com o novo suporte da Microsoft, meu Deus.

E aí, bom, eu entendi, você falou que muitos projetos, uma coisa que aconteceu era isso. Você estava em várias fases de desenvolvimento e é isso, é que você chegar lá no meio e fala assim, e, por que? Para aí, não era bem isso. E a gente riria. E a gente, é a solução para a gente dar um passar por esse problema. A sua história está melhor, Giovanni Edge, porque você falou,

ah, lá no meio eu percebi que não era isso que eu queria,

porque normalmente o que acontece, é lá no final, que as pessoas percebem que não era aquilo que a gente queria. Não é, verdade. O grande problema que a gente vai ter aí é exatamente a questão de você qual é tal feedback do usuário, né, da pessoa que está realmente utilizando em vez de somente se sentar com o cliente ou se sentar com o usuário para coletar as ideias.

Muitas vezes, com isso especialmente... A área da pessoa que está realmente utilizando a aplicação, em vez de somente se sentar com o cliente,

você sentar com o usuário para coletar as ideias.

Porque muitas vezes, especialmente se você trabalha num ciclo grande, a gente chama esses métodos mais antigos, de métodos em cascata, porque você segue esses passos em sequência. E no final você tem esse produto que vai se entregue. Então imagina que você começou a pensar nessa aplicação há 6 meses atrás e o pessoal

de desenvolvimento de análise sentou com você, pegou essas coisas seis meses depois, eles simplesmente chegam com alguma coisa entregue essa coisa para você. Você não teve relacionamento com eles, você não viu que eles estavam fazendo, às vezes até o negócio que você está fazendo mudou, como você está fazendo o trabalho mudou, e você não teve nesse 6 meses, tempo para ter esse esse feedback com eles. Então a ideia desses processos é que a maior parte do aprendizado

que você vai ter na hora de você construir software não é sentando com o usuário e perguntando a ele como é que a coisa deve fazer. Mas se entregando o software que funciona para o usuário para ele olhar o software e dizer é esse é o caminho que eu quero seguir ou Não, esse não é o caminho que eu quero seguir, a gente tem que tomar outro caminho.

Então, a forma mais fácil de você fazer isso é entregando muito rápido.

Então, em vez de fácil de você fazer isso é que é entregando muito rápido.

Então, em vez de você passar esses 6 meses em desenvolvimento, se você desmede jogar o cara com a aplicação toda completa, você diminui esse ciclo para o mínimo de tempo possível, que você ir conseguir ir ficando coletando esse feedback constante do usuário, para o que o usuário consiga direcionar a aplicação do caminho que ele realmente espera

porque principalmente para uma pessoa que não trabalha com sofrer

alguém que não entende todas as capacidades que um software pode fazer, é muito mais fácil para ele entender o que a aplicação está fazendo ou como a aplicação pode resolver um problema para você usando o software porque simplesmente tentando falar com uma pessoa, né? Então é muito mais fácil você entender como a página vai ficar, se você trabalha com um Airframe, né? Você tem mais os desenhos e sonhos, é muito mais fácil você entender como a página vai ficar, se você trabalha com

wireframes, né, que você faz uns desenhos, é muito mais fácil você entender dessa forma do que somente com a conversa ou com um documento de requisitos, né, porque você está olhando para alguma coisa ali, não é só a imaginação, mas o que que seria do efeito do adio? Você fazer wireframe faz parte disso, isso é isso? Pode fazer, pode fazer você prototipar, você trabalhar com soluções que não são reais, por exemplo,

você pode fazer uma página aqui, apesar você trabalhar com soluções que não são reais,

por exemplo, você pode fazer uma página aqui, apesar dela não implementar a funcionalidade, ela finge que ela implementa, a funcionalidade. Conseguem interagir com ela, pode ser que ela não tem toda a pronta, que a funcionalidade total, tipo, salvar esses dados no banco de dados, não tem de implementar. Certo. interagir com a página de forma que ela dá uma resposta para você.

...