[MÚSICA] Olá a todos, meu nome é Eduardo Guerra. Esse é o curso Princípios de Desenvolvimento Ágil de Software. Nessa aula vamos falar sobre a resposta a mudanças e porque que isso é tão importante para o desenvolvimento ágil. A gente vai ver poque que esse capacidade de adaptação ela está diretamente ligado à questão da agilidade do processo. Então a gente vai pegar aqui né, como a gente fez nas outras aulas vamos começar falando sobre o princípio alí né, do manifesto ágil que é a gente dar prioridade a resposta a mudanças ao invés de seguir plano. Como eu falei, a gente nunca é eliminar uma coisa completamente relação a outra, mas dar preferência para a resposta a mudança, não ficar agarrado demais no plano, e se esquecer que você se adaptar as vezes pode ser mais importante do que seguir o plano. Então o que que acontece? Às vezes o cara começa projeto ele já pega alí, como ele já faz aquele levantamento de requisito detalha e tal ele e ele já tem processo preditivo que já diz quais todas as atividades que ele precisa fazer, ele pega tudo aquilo e joga dentro de project, dentro de gráfico gigante para fazer o planejamento e às vezes já planeja alí para meses para frente com dependência de atividades, e aí com esses gráficos de você for lá e atrasar uma atividade aquilo alí vira uma cascata, e atrasa tudo que estava dependente daquilo alí dentro do projeto. Então o que que acontece? Toda mudança que acaba mudando esse planejamento, aparece uma tarefa nova, uma tarefa aumenta de tamanho isso daí causa impacto num planejamento, e se acontece no começo no projeto, isso aí impacta três meses para frente, e aí vai te dar muito trabalho de ter que ficar adaptando esse planejamento. Eu já vi projeto de cara só pra fazer isso só pra ficar controlando e modificando, e adaptando planejamento. Será que vale a pena? Será que faz sentido eu planejar para tanto tempo assim na frente? Se eu não tenho tanta certeza de como vai ser? Será que a mudança tem que ser uma coisa tão ruim pra dar tanto trabalho? Será que não tem uma forma melhor de trabalhar com isso? Né? Então normalmente quando você tem feedback do cliente você acaba gerando mudanças isso é natural, a gente já aprendeu que o cliente as vezes ele não tem maturidade no começo do projeto pra saber de tudo. Às vezes é só utilizando que ele vai saber alguma coisa. E aí essas mudanças que vão mudar o projeto consequentemente vão mudar o planejamento. Então, a gente tem que aprender a trabalhar com isso da melhor maneira possível. E aí você ter que manter aquele planejamento sem alterações para poder seguir aquilo direitinho as vezes acaba virando o foco do projeto de seguir o plano, né ao invés de você fazer o software, que é o que interessa no final das contas. Então você vai fazer várias atividades, vai se proteger para não ter que mudar aquele planejamento e reuniões com clientes para assinar, para acertar os requisitos para aquilo não mudar mais. Então essa fixação por manter o planejamento, e seguir aquilo certinho até final acaba virando o foco do projeto ao invés de desenvolver o software que o cliente realmente precisa. No desenvolvimento ágil a ideia é você usar várias práticas para você poder tornar essa resposta à mudanças mais rápidas. Então a própria forma de fazer planejamento é diferente. Então o que você vai fazer? Você a longo prazo você vai ter uma visão do que você quer. Olha, o cliente quer software para isso, eu não preciso de tantos detalhes, mas a longo prazo eu sei onde que eu quero chegar, num médio prazo eu vou ter de repente alí requisito de alto nível a funcionalidade, uma descrição mais breve do que aquilo faz. E ai as vezes no curto prazo quando eu falo curto prazo é talvez de uma ou duas semanas para frente no máximo eu vou ter detalhamento de baixo nível daquilo que eu vou fazer, não necessariamente eu vou usar o gráfico de Ganger, por exemplo ágil é muito mais comum alí o Kanban, você ter o quadro alí do Kanban, onde você vai controlando as tarefas feitas e tal, e a própria equipe vai gerenciando isso mas aí você tem esse planejamento mais detalhado no curto prazo, então é difícil né, aquela coisa, onde você vai estar daqui a mês ano, é difícil responder a essa pergunta, porque muita coisa pode acontecer e mudar esse planejamento. Então no desenvolvimento ágil a gente, é lá longe? Então vamos ter uma visão. Não vamos deixar de planejar não, é importante planejar, mas não vamos planejar com nível de detalhamento que a gente vai ter que mudar depois. Vamos planejar de uma forma que o nosso tempo fazendo isso, e a precisão do nosso planejamento é de acordo com o nível de detalhamento que ele tem. E aí mais uma vez TDD, refatoração são técnicas aí para deixar o código mais fácil de ser alterado, e você poder responder a essas mudanças mais rápido. Então não é só no nível de planejamento mas também na parte do código a gente também se preocupa com essa alteração da mudança, mais do que fazer altos diagramas e tal e aí quando você alterar alguma coisa no software causar aquele impacto alí você vai dar muito trabalho para responder a uma mudança. Aqui é o contrario, a gente foca naquilo que dá essa agilidade para a gente. Certo? Então é isso. Vimos aqui nessa aula a última parte aí do manifesto ágil. Pegamos cada daqueles princípios e destrinchamos eles mostrando a importância se a gente for ver a questão de colaborar com o cliente é importante para a resposta a mudança, que é importante para outras partes, então de uma certa forma as coisas estão interligadas, e espero que nessas aulas aí vocês tenham entendido qual que é a ideia do desenvolvimento ágil de software a partir desses princípios do manifesto ágil. Certo? Muito obrigado, até o próximo módulo. [MÚSICA]