Bom pessoal, agora a gente vai para a parte de implementação. Como é que funcionam esses tópicos que na hora de eu documentar, eu vou documentar como é que funciona a implementação. Vamos lá. O que acontece é o seguinte, implementação. Quais metodologias de desenvolvimento e ferramentas que eu vou utilizar. E isso aí galera, a gente tem que tomar muito cuidado. Por quê? Porque tem muita gente que pensa que vamos trabalhar com Scrum, vamos trabalhar com não sei o quê. Galera, cada empresa tem a sua metodologia. Eu tive a oportunidade de visitar um tempo atrás a sede do Facebook. de visitar um tempo atrás a sede do Facebook. E assim, um lugar gigante, com uma pancada de prédio, muitos funcionários, sei lá, o refeitório dos caras era maior do que várias empresas juntas que eu já trabalhei. Entendeu? E batendo um papo com o cara lá, eu perguntei, e qual é a metodologia que vocês trabalham aí dentro para conseguir fazer os projetos rolarem? Então eu falei, como assim metodologia? Eu falei, é cara, sei lá, Scrum, você usa uma metodologia ágil. O cara, sabe o que o cara virou para mim? Ele falou assim, ah cara, isso aí é pouco importante. O importante é o projeto saber. A gente trabalha com de 8 a 12 pessoas, e a gente se vira para conseguir entregar aquilo da melhor forma possível. Se vai rabiscar na lousa, se vai fazer isso, não interessa. Cada equipe trabalha da sua forma e cada um entrega da melhor forma possível. Então, o que a gente tem que entender é, a empresa tem que fornecer um norte de como as pessoas trabalham em conjunto. Claro, mas a empresa não pode fazer com que muitas metodologias acabem gerando, vamos dizer assim, uma perda de flexibilidade dos desenvolvedores para trabalhar rápido. Eu estou dizendo que Scrum vai acabar com a flexibilidade ou qualquer coisa assim de forma nenhuma. Mas o grande ponto é que é uma tendência muito grande cada empresa trabalhar com as suas diversos tipos de metodologia e com as suas ferramentas e cada dia mais os times estão tendo mais flexibilidade para se organizar em relação a isso tá então tome cuidado é como que isso vai ser gerado tem empresas que nessa parte aqui nem fala nem define qual é a metodologia porque sabe como é que a banda toca na empresa. Legal? Outra coisa, agora isso aí não tem como. Processos de deployment e infraestrutura. Isso aí são pontos extremamente críticos. A gente vai falar de infra, quando a gente fala em infraestrutura, aí a gente já volta lá no começo. É um premise, não é um premise? É cloud, qual cloud? Você fechou algum contrato com a cloud provider, quais são os descontos que você recebeu, ah você estava on-premise e quer ir para on-cloud, vamos tentar fechar um contrato para ganhar preço galera, uma coisa que você tem que acostumar muitas pessoas entram, olha aquela tabelinha de cobrança da AWS, da Google da Azure e pensa que aquele ali é o preço deles. É o preço deles. Mas se você estiver dentro de uma grande empresa, aquele preço não é o preço que eles vão te cobrar. Você vai sentar, vai falar com o gerente de contas, você vai fechar um contrato de tantos anos, aí aqueles preços vão ser muito reduzidos. Então você vai ter que saber negociar. Por isso que quando a gente fala em infraestrutura, vai depender muito também do contexto, do tipo de projeto e do tipo de contrato que você tem, por exemplo, com o Cloud Provider. É o arquiteto de solução que vai negociar isso? Não. Raramente vai ser esse cara. Mas normalmente ele é o cara que vai falar quanto de infraestrutura que você vai precisar ter para você conseguir passar uma estimativa para quem for negociar com o Cloud Provider. Legal? Processo de deployment. Mesma coisa. Como que vai ser feito? Quais são as ferramentas que a empresa já tem? Como que os desenvolvedores estão acostumados a realizar? Então, isso aí vai depender. É contexto. Legal? Outro ponto aqui aqui processos de teste de qualidade e qualidade isso aqui galera varia de empresa para a empresa tá porque quando estou falando processos de teste aqui não é necessariamente apenas o teste de software desenvolvedor tem que fazer eu já estou partindo do princípio que toda empresa tem que testar o seu software no processo de desenvolvimento. O teste de desenvolvedor, o cara que está desenvolvendo o teste, o software dele já tem que sair com o teste. Agora, quando a gente está falando em processo de teste de qualidade, a gente está falando da galera de Ikea, a gente está colocando em metodologias um pouco diferentes. Por exemplo, toda vez que eu subo a minha feature essas features sob isolada no ambiente então a galera de que a contém consegue testar somente aquela nova feature independente de outra feature também está desenvolvendo então esses tipos de coisas são extremamente importantes aqui também legal então o pessoal lembre se o seguinte toda todas as vezes que a gente falar teste qualidade eu não necessariamente estou falando do teste que o desenvolvedor está fazendo estou sempre partindo do princípio que todos os desenvolvedores da empresa tem que ter códigos né orientados guiados até se não tô dizendo que tem que seguir tdd na risca mas tem que ter teste tá isso já não existe mais o que normalmente nesse processo você pode colocar é tentar seguir uma norma um guideline falando olha eu preciso ter 70% de cobertura de testes na hora que eu for entregar pra na hora de colocar no meu pai pipeline ele bloquear em cima disso aí legal? então isso vai depender de contexto pra contexto, as vezes o projeto a solução que vai ser colocada é baseada em cima de uma solução que já é legada e que não tem teste, então nada é simples nesse mundo galera tudo depende do contexto ah, eu tô num projeto que tem 20% de teste, nossa só tem Não, o projeto tem 30 anos que foi desenvolvido. Entende como é que as coisas são diferentes aí nesses casos? Então, fiquem ligados aí.