00:00:00
contextualizando XP programming ou
00:00:02
extreme programming ou ainda programação
00:00:05
extrema é uma metodologia ágil de
00:00:08
desenvolvimento de software que se
00:00:09
destaca por sua abordagem flexível e
00:00:12
adaptativa bonito né Seu principal
00:00:14
objetivo é aprimorar tanta qualidade de
00:00:16
software quanto a capacidade de
00:00:18
responder eficientemente às mudanças nos
00:00:22
requisitos do projeto a medida que elas
00:00:24
surgem no cerne do XP encontramos
00:00:27
valores essenciais como comunicação
00:00:30
feedback simplicidade e coragem a partir
00:00:32
desses alicerces surgem princípios
00:00:35
básicos que moldam a prática do extreme
00:00:37
programming feedback rápido presumir
00:00:39
simplicidade mudanças incrementais
00:00:42
abraçar a mudança e compromisso com a
00:00:45
excelência no trabalho é muita coisa né
00:00:47
para isso as melhores práticas de
00:00:49
engenharia de software são elevadas ao
00:00:51
seu ápice vamos nesse episódio do
00:00:53
dicionário do programador explicar o que
00:00:55
você enquanto desenvolvedor precisa
00:00:57
entender sobre essa prática e também bem
00:01:00
quando não utilizar o Extreme
00:01:02
programming então fica com a gente
00:01:05
porque vai ter treta
00:01:08
né o XP assim como outras metodologias
00:01:12
ágeis Diverge do desenvolvimento em
00:01:14
Cascata o famoso Waterfall no qual as
00:01:17
etapas de análise design e implementação
00:01:19
e testes são conduzidos em sequência até
00:01:22
a entrega do sistema em contraste o x
00:01:25
promove um acompanhamento contínuo e a
00:01:27
realização de testes frequentes
00:01:29
permitindo indo ajustes rápidos em
00:01:31
projetos que demandam flexibilidade ou
00:01:33
enfrentam mudanças constantes Sem dúvida
00:01:36
Esses são pontos importantíssimos no
00:01:38
momento tão dinâmico que vivemos na
00:01:40
tecnologia nossas aplicações e até nós
00:01:43
enquanto profissionais devemos nos
00:01:44
manter atentos e preparados PR os
00:01:47
desafios que encontramos quando buscamos
00:01:49
evoluir e consolidar nossos
00:01:50
conhecimentos para nos prepararmos para
00:01:52
projetos maiores e mais desafiadores é
00:01:55
importante encontrar um mentor uma
00:01:57
instituição até uma comunidade que possa
00:02:00
nos guiar nessa evolução nós temos uma
00:02:02
indicação que vai te preparar para esses
00:02:04
projetos expressivos e para ser um Dev
00:02:07
desejado no mercado o curso full cycle
00:02:09
ele é uma formação completa e prática
00:02:12
onde você pode escolher até a linguagem
00:02:14
que deseja trabalhar nos seus projetos
00:02:16
java.net Python PHP e typescript além de
00:02:20
ter contato com a linguagem go em
00:02:22
módulos específicos o curso full cycle é
00:02:24
dividido em três partes essenciais
00:02:26
arquitetura desenvolvimento e devops por
00:02:29
isso ele é tão completo nós vamos deixar
00:02:31
o link para você conhecer mais e se
00:02:34
matricular aqui na descrição não deixa
00:02:36
de conferir você vai descobrir que ele
00:02:38
pode fazer a diferença na sua carreira
00:02:40
Esse aí é o pai da criança Kent Beck
00:02:42
desenvolveu o XP no seu trabalho no
00:02:44
projeto de folha de pagamento do
00:02:46
Chrysler comprehensive compensation
00:02:48
System o C3 Beck se tornou o líder do
00:02:52
projeto C3 em março de 1996 ele começou
00:02:55
a refinar a metodologia de
00:02:57
desenvolvimento usado no projeto e
00:02:59
escreveu um um livro sobre a metodologia
00:03:01
já em 99 ele é um programador super
00:03:04
renomado e autor de diversos livros
00:03:06
sobre desenvolvimento de software
00:03:07
inclusive ele é um dos nomes por trás do
00:03:10
Manifesto ágil para entender o XP
00:03:12
programming temos que entender Quais são
00:03:14
os valores que estão por trás dele seus
00:03:16
princípios são cinco valores
00:03:18
fundamentais que guiam o desenvolvimento
00:03:20
de software e orientam as práticas e
00:03:23
decisões da equipe começamos com a
00:03:25
comunicação que valoriza a comunicação
00:03:27
aberta e frequente Entre todos os
00:03:30
membros da equipe e stakeholders
00:03:31
garantindo alinhamento e colaboração
00:03:33
eficazes comunicação feedback que é o
00:03:36
próximo que promove a obtenção de
00:03:38
feedback contínuo dos clientes e colegas
00:03:40
de equipe para ajustar e melhorar o
00:03:42
software durante todo o processo de
00:03:44
desenvolvimento agora no centro da
00:03:46
imagem temos a simplicidade que prioriza
00:03:49
Justamente a simplicidade em todos os
00:03:51
aspectos do desenvolvimento de software
00:03:53
reduzindo a complexidade e facilitando a
00:03:56
compreensão do sistema é o famoso Kiss
00:03:59
né A Agora é a vez da coragem que
00:04:01
incentiva a tomada de decisões difíceis
00:04:03
de riscos calculados e a busca constante
00:04:06
por melhorias promovendo o ambiente de
00:04:07
experimentação e aprendizado falando
00:04:10
coragem parece estranho mas depois que a
00:04:11
gente explica faz todo sentido e
00:04:13
finalmente respeito que valoriza o
00:04:15
respeito pelos clientes colegas de
00:04:17
equipe e stakeholders promovendo uma
00:04:19
cultura de colaboração diversidade e
00:04:22
trabalho em equipe esses valores são
00:04:24
fundamentais pra prática bem sucedida da
00:04:26
expit vê que tem muito a ver com Cultura
00:04:28
né e ajuda orientar as equipes no
00:04:30
desenvolvimento de software de alta
00:04:32
qualidade e adaptável no x programming
00:04:35
os princípios servem como diretrizes
00:04:37
fundamentais que ajudam na tomada de
00:04:39
decisões durante o desenvolvimento do
00:04:41
projeto funcionando como critérios para
00:04:43
escolher entre diferentes soluções então
00:04:45
anota aí ó o primeiro princípio é o
00:04:47
feedback rápido que promove comunicação
00:04:50
constante entre clientes programadores e
00:04:53
gerentes essa troca de informações
00:04:55
facilita o aprendizado coletivo e a
00:04:57
identificação rápida de dúvidas riscos e
00:04:59
problemas permitindo ações corretivas
00:05:02
imediatas o segundo princípio é assumir
00:05:05
a simplicidade buscar resolver problemas
00:05:08
da forma mais simples possível como a
00:05:09
gente já falou é meio que o Kiss né isso
00:05:12
envolve fazer um bom trabalho com testes
00:05:15
refatoração e comunicação para enfrentar
00:05:18
desafios atuais confiando na capacidade
00:05:21
da equipe de lidar com complexidades
00:05:22
futuras conforme for necessário o
00:05:25
terceiro é a mudança incremental que
00:05:27
preferindo realizar mudanças de forma
00:05:30
gradual ao invés de grandes
00:05:31
transformações de uma só vez os
00:05:33
programadores têm a liberdade de fazer
00:05:35
melhorias contínuas no código
00:05:37
incorporando mudanças nos requisitos de
00:05:39
maneira incremental e abraçando mudanças
00:05:42
é o quarto princípio que valoriza a
00:05:44
inclusão de mudanças em qualquer estágio
00:05:46
do projeto Isso facilita a adaptação a
00:05:48
novos requisitos especialmente em
00:05:51
projetos com necessidades voláteis onde
00:05:53
os clientes podem não ter clareza sobre
00:05:55
as suas exigências desde lá do início e
00:05:57
o quinto é trabalho de qualidade
00:06:00
Ele defende que a qualidade não é
00:06:01
opcional mas é obrigatória isso
00:06:04
significa ter um sistema que atenda aos
00:06:06
requisitos do cliente passem todos os
00:06:08
testes olha só que importância hein e
00:06:10
agregue o máximo de valor ao negócio do
00:06:12
cliente trabalho de qualidade é o básico
00:06:14
né acho que isso tem que ter em qualquer
00:06:16
lugar agora que já aprendemos os valores
00:06:17
e os princípios é a vez de ver na
00:06:20
prática como isso funciona o XP possui
00:06:23
12 práticas essenciais que formam o
00:06:25
núcleo do processo criadas justamente
00:06:27
com base nos valores e princípios da
00:06:29
metodologia essa provavelmente é a parte
00:06:32
mais importante desse vídeo então presta
00:06:34
bastante atenção a gente vai um pouco
00:06:36
mais a fundo agora e assista mais uma
00:06:38
vez se for preciso Pois é a partir
00:06:40
dessas práticas que tudo realmente
00:06:42
acontece em projetos XP é fundamental
00:06:44
ter o cliente presente ele precisa
00:06:46
participar ativamente do desenvolvimento
00:06:49
é verdade ó essa prática Alguns chamam
00:06:51
de time coeso a presença constante do
00:06:53
cliente facilita a simplicidade dos
00:06:55
processos e garante uma comunicação
00:06:57
Clara com os desenvolvedores com cliente
00:06:59
Sempre disponível dúvidas são resolvidas
00:07:02
e respondidas rapidamente desde que o
00:07:04
cliente tenha a capacidade de Responder
00:07:06
questões de negócio e autoridade para
00:07:08
tomar decisões sobre as prioridades do
00:07:10
projeto seguindo pela borda aí do fluxo
00:07:13
a gente tem o jogo do planejamento não
00:07:15
dá para pensar em desenvolvimento de
00:07:16
software sem fazer um mínimo de
00:07:18
planejamento Mas isso não implica criar
00:07:20
um plano detalhado que leve semanas ou
00:07:22
meses para ser finalizado já que planos
00:07:25
longos tendem a ser imprecisos no início
00:07:28
de cada interação a equipe de
00:07:30
desenvolvimento incentiva o cliente a
00:07:32
escrever as funcionalidades desejadas em
00:07:34
pequenos cartões chamados de user
00:07:37
Stories essas user Stories são avaliadas
00:07:40
quanto ao tempo e o custo pela equipe
00:07:42
permitindo que o cliente priorize as
00:07:44
funcionalidades com base nessas
00:07:46
informações Essa é a prática jogo do
00:07:48
planejamento e garante que a equipe
00:07:50
sempre trabalhe nas funcionalidades mais
00:07:52
importantes e valiosas pro cliente vai
00:07:55
seguindo aí na imagem ó agora temos
00:07:57
releases e iterações sempre vale a pena
00:07:59
explicar que release é uma pequena
00:08:01
versão do sistema com funcionalidades
00:08:03
completas e relevantes colocada em
00:08:05
produção rapidamente para que o cliente
00:08:07
possa utilizá-la e fornecer feedback
00:08:10
cada release é dividido em interações
00:08:12
que refinam os requisitos garantindo que
00:08:14
o produto final atendo as necessidades
00:08:16
do cliente em geral um release dura
00:08:19
cerca de 8 semanas e as iterações duram
00:08:22
aproximadamente duas semanas e para
00:08:24
finalizar aí a borda da imagem a gente
00:08:26
tem testes de unidade quando nós
00:08:28
programadores escrevemos os testes aos
00:08:30
automatizados antes de codificar uma
00:08:32
funcionalidade a gente acaba se
00:08:34
aprofundando sobre o entendimento da
00:08:35
tarefa e a gente garante que tudo no
00:08:38
sistema funcione corretamente existem
00:08:40
dois principais motivos para realizar os
00:08:43
testes a descrição da tarefa onde os
00:08:45
testes definem claramente o que o código
00:08:48
deve fazer permitindo que os
00:08:49
desenvolvedores se concentrem no
00:08:51
essencial e a garantia de funcionamento
00:08:54
onde testes asseguram que o sistema
00:08:55
funciona conforme esperado
00:08:57
proporcionando confiança para avançar no
00:08:59
projeto sem medo de quebrar algo durante
00:09:01
alterações são três momentos Chaves que
00:09:04
devemos aplicar os testes antes do
00:09:05
refactoring após o refactory e após a
00:09:08
integração o XP considera testes um
00:09:11
investimento e não uma perda de tempo
00:09:13
agora vamos pra parte do meio da imagem
00:09:15
começando pelo código coletivo qualquer
00:09:18
membro da equipe preste atenção nisso
00:09:19
hein qualquer membro da equipe pode
00:09:21
trabalhar em qualquer parte do sistema a
00:09:23
qualquer momento isso elimina a
00:09:25
necessidade de solicitar mudanças a quem
00:09:27
Originalmente escreveu o código
00:09:29
promovendo melhorias contínuas e
00:09:31
refaturar sempre que for necessário em
00:09:33
muitos lugares Isso parece impossível
00:09:36
mas não é não viu essa prática mantém o
00:09:38
código simples e claro e evita a criação
00:09:40
de ilhas de conhecimento dentro da
00:09:42
equipe quando um desenvolvedor sai do
00:09:44
projeto O Impacto é minimizado pois o
00:09:47
conhecimento sobre o código tá
00:09:49
distribuído Entre todos além disso a
00:09:51
propriedade coletiva facilita a revisão
00:09:53
constante do código melhorando a
00:09:55
qualidade e a consistência do sistema
00:09:57
Justamente por isso temos que prezar por
00:09:59
um código padronizado senão não funciona
00:10:01
nada né Essa é a chave para garantir que
00:10:03
todos os desenvolvedores possam
00:10:05
trabalhar em qualquer parte do código
00:10:07
sem dificuldade é essencial estabelecer
00:10:09
e seguir voluntariamente ó um padrão de
00:10:11
codificação para manter o sistema
00:10:13
homogêneo e compreensível esse padrão
00:10:16
deve minimizar o trabalho especialmente
00:10:18
evitando o código duplicado a
00:10:20
padronização serve como um meio de
00:10:22
comunicação Claro e objetivo entre os
00:10:23
membros da equipe assegurando que todos
00:10:26
entendam e possam colaborar efetivamente
00:10:28
parece se Utopia viu mas se combinar
00:10:31
direitinho dá para fazer já o ritmo
00:10:33
sustentável consiste em trabalhar dentro
00:10:35
dos limites físicos e respeitar a
00:10:37
individualidade de cada membro da equipe
00:10:39
para manter a criatividade e a qualidade
00:10:40
de software é essencial que a equipe
00:10:43
esteja saudável física e principalmente
00:10:46
mentalmente a carga horária de trabalho
00:10:48
máxima recomendada é de 8 horas diárias
00:10:51
e 40 horas semanais estender a jornada
00:10:53
de trabalho para compensar atrasos Pode
00:10:55
até ser eficaz apenas ali nos primeiros
00:10:57
dias mas no longo o prazo causa cansaço
00:11:00
desmotivação e diminui o desempenho da
00:11:03
equipe já a integração contínua é a
00:11:05
prática de construir o software várias
00:11:07
vezes ao dia simples assim mantendo a
00:11:09
sincronia constante entre os deves
00:11:12
Exatamente isso evita surpresas e
00:11:14
assegura que o sistema funcione
00:11:16
harmoniosamente a cada nova integração
00:11:19
cada integração deve ser acompanhada
00:11:21
pela execução de todos os testes para
00:11:23
verificar a integridade do sistema E é
00:11:25
isso que permite a rápida detecção e
00:11:27
correção de defeitos an que se tornem
00:11:29
problemas maiores a prática garante que
00:11:31
o sistema esteja sempre em um estado de
00:11:34
funcionamento adequado a parte interna
00:11:36
do XP diz mais sobre a mão na massa com
00:11:38
código é aí que tem Total relação com
00:11:40
nós deves começando pelas metáforas que
00:11:43
são usadas para transmitir ideias
00:11:45
complexas de forma simples e Clara
00:11:47
criando uma visão comum do projeto Entre
00:11:49
cliente e desenvolvedores elas devem ser
00:11:51
baseadas no vocabulário familiar ao
00:11:53
cliente facilitando a compreensão e
00:11:55
melhorando a comunicação dessa forma
00:11:57
metáforas ajudam a alinhar as
00:11:58
expectativas e o entendimento do projeto
00:12:01
tornando a colaboração mais eficaz isso
00:12:03
que ser difícil né que desenvolvedor
00:12:04
quando fala com cliente sempre rola
00:12:07
aquele joguinho de palavras técnicas que
00:12:09
o cliente não entende nada e vice-versa
00:12:11
né e vice-versa refactoring é um
00:12:14
processo de reorganizar o código para
00:12:16
melhorar sua qualidade interna facilitar
00:12:18
a leitura e diminuir o tempo de
00:12:20
manutenção sem alterar o seu
00:12:22
comportamento externo dá para afirmar
00:12:24
que não existe projeto XP sem refactory
00:12:27
qualquer membro da equipe pode realizar
00:12:29
para manter o código organizado e
00:12:31
compreensível embora haja um certo risco
00:12:33
ali do código deixar de funcionar
00:12:35
corretamente esse risco é mitigado com
00:12:37
testes constantes que garantem que o
00:12:39
código continua a produzir os mesmos
00:12:41
resultados exatamente os testes estão aí
00:12:44
para dar liberdade para apagar o código
00:12:47
sem medo de ser feliz o dia de trabalho
00:12:49
começa com uma reunião diária de no
00:12:51
máximo 10 minutos parecido com a que a
00:12:53
gente vê aí no scrum durante essa
00:12:55
reunião cada desenvolvedor comenta
00:12:57
brevemente sobre o que realizou no dia
00:12:59
anterior proporcionando a todos uma
00:13:01
visão Geral do andamento do projeto além
00:13:03
disso a equipe usa esse momento para
00:13:06
priorizar as atividades que serão
00:13:07
realizados ao longo do dia tudo regado a
00:13:10
muita assertividade e pragmatismo senão
00:13:12
vira lavação de roupa suja e por último
00:13:15
uma prática que nós aqui fazemos há mais
00:13:17
de 20 anos o p programming basta unir
00:13:20
dois deves trabalhando juntos no mesmo
00:13:22
computador um revisão do código do outro
00:13:25
geralmente o menos experiente é o que
00:13:27
fica no comando e o outro procura suir
00:13:29
melhorias buscar erros e possíveis bugs
00:13:31
essa prática promove além da revisão
00:13:33
constante do código a disseminação do
00:13:36
conhecimento entre o time a ideia também
00:13:38
é que seja feito um rodízio de pessoas
00:13:40
na prática do per programming na nossa
00:13:42
experiência programar em par não diminui
00:13:44
a velocidade do desenvolvimento pois
00:13:46
melhora a qualidade do código e reduz
00:13:48
erros Além disso proporciona um ambiente
00:13:50
de disciplina e colaboração u fia
00:13:53
tranquilo até agora é claro que tudo
00:13:55
isso aqui que nós falamos é um resumão
00:13:57
da metodologia para você entender como
00:13:59
funciona o XP e como ele foi pensado Mas
00:14:02
calma que ainda tem mais coisa como toda
00:14:04
a metodologia é preciso definir fases do
00:14:06
projeto durante o ciclo de vida do XP
00:14:09
programming ela faz isso compondo
00:14:11
tarefas específicas isso deixa tudo
00:14:13
muito mais claro de seguir então
00:14:15
acompanha aqui comigo no ciclo de vida
00:14:17
do XP programming Tudo começa com as
00:14:19
histórias dos usuários onde os
00:14:21
requisitos do cliente são capturados e
00:14:24
transformado em histórias que descrevem
00:14:26
funcionalidades desejadas essas
00:14:28
histórias né ou user Stories servem como
00:14:31
a base de todo o processo de
00:14:32
desenvolvimento em seguida passamos
00:14:34
paraa espiga arquitetônica onde a
00:14:36
arquitetura básica do sistema é
00:14:38
estabelecida para suportar o
00:14:40
desenvolvimento das funcionalidades
00:14:41
discretas essa fase é crucial para
00:14:44
garantir que o sistema terá uma base
00:14:46
sólida e flexível para suportar futuras
00:14:48
mudanças e adições ou seja nessa fase
00:14:51
não pode ter gambiarra nas outras Pode
00:14:53
Gabriel também não não depois disso
00:14:56
ocorre o planejamento de lançamento onde
00:14:58
a as histórias doss usuários são
00:15:00
priorizadas e organizadas para as
00:15:02
interações a equipe decide quais
00:15:04
histórias serão implementadas em cada
00:15:06
interação sempre focando em entregar o
00:15:08
máximo de valor para o cliente o mais
00:15:10
rápido possível entramos então na fase
00:15:12
de iteração onde pequenos ciclos de
00:15:14
desenvolvimento acontece durante cada
00:15:16
interação as funcionalidades são
00:15:18
implementadas e testadas continuamente
00:15:20
essa abordagem permite que a equipe se
00:15:22
adapte rapidamente a novas informações e
00:15:24
mudanças nos requisitos após a
00:15:26
implementação as funcionalidades passam
00:15:28
pelo os testes de aceitação nessa fase
00:15:31
as histórias dos usuários são validadas
00:15:33
para garantir que atendam os requisitos
00:15:35
e expectativas do cliente e isso
00:15:37
assegura que o produto final será
00:15:39
exatamente o que o cliente necessita
00:15:41
finalmente o processo culmina nas
00:15:43
pequenas versões aqui versões
00:15:45
incrementais do software são lançadas
00:15:47
regularmente permitindo que o cliente
00:15:49
utilize as novas funcionalidades e
00:15:51
forneça feedback contínuo e essa é a
00:15:53
explicação resumida desse ciclo contínuo
00:15:56
de desenvolvimento teste e lançamento o
00:15:58
foco principal do X é desenvolver
00:16:00
software mas também é crucial organizar
00:16:02
a gestão do projeto e definir os papéis
00:16:05
dos envolvidos a gestão de centralizada
00:16:07
e a tomada de decisões com o gerente
00:16:09
atuando como um facilitador aí que
00:16:11
entram as métricas elas são fundamentais
00:16:14
especialmente a relação entre Tempo
00:16:16
estimado e tempo gasto visualizados em
00:16:18
gráficos atualizados regularmente a
00:16:20
gerência se divide entre treinador e
00:16:22
rastreador o treinador foca na execução
00:16:25
técnica comunicação conhecimento técnico
00:16:27
gestão de crises confiança facilitação e
00:16:30
suporte a equipe agora o rastreador
00:16:32
coleta e compara métricas minimiza
00:16:35
interrupções e monitora o progresso
00:16:37
dentro da equipe os programadores
00:16:39
analisam projetam testam codificam e
00:16:42
integram o sistema os clientes definem
00:16:44
prioridades e colaboram na definição dos
00:16:46
Testes funcionais os testadores auxiliam
00:16:49
na definição e escrita dos testes para
00:16:51
garantir a qualidade Consultores
00:16:53
oferecem conhecimento especializado para
00:16:55
resolver problemas complexos como tudo
00:16:57
no desenvolvimento não existe Bala de
00:16:59
Prata existem cenários em que a
00:17:01
aplicação do XP programming não é
00:17:03
recomendada sim é verdade em equipes
00:17:06
grandes geralmente com mais de 12
00:17:08
programadores o XP pode enfrentar
00:17:10
dificuldades de comunicação e problemas
00:17:12
na implementação das práticas como o pre
00:17:15
programming se os clientes Não Estão
00:17:16
dispostos a participar ativamente do
00:17:19
projeto e colaborar com a equipe de
00:17:21
desenvolvimento aí a coisa desanda de
00:17:23
verdade nem adianta tentar insistir é
00:17:26
Além disso o X é mais eficaz com
00:17:28
tecnologias que suportam mudanças e
00:17:30
permitem a escrita fácil de testes Pois
00:17:33
é ainda tem tecnologia que não dá para
00:17:35
testar direito né E por exemplo
00:17:37
tecnologias que são complexas ou que não
00:17:39
permitem feedback rápido podem ser
00:17:41
incompatíveis com a abordagem além disso
00:17:43
em organizações Como a cultura
00:17:45
tradicional de desenvolvimento de
00:17:46
software com muita documentação e ênfase
00:17:49
em análise e projetos prévios a
00:17:51
transição para práticas ágeis como XP
00:17:54
vai ser no mínimo desafiadora não tem
00:17:57
jeito ambiente de trabalho é é crucial
00:17:59
pro sucesso do XP e espaços que não
00:18:01
facilitam a comunicação e a colaboração
00:18:04
entre os membros da equipe podem
00:18:06
dificultar a implementação das práticas
00:18:08
do xi finalmente a participação ativa do
00:18:11
cliente preferencialmente Alguém que
00:18:13
entenda bem do negócio é fundamental
00:18:16
esses fatores criam sim Barreiras pro
00:18:18
sucesso do projeto XP e devem ser
00:18:20
considerados se você conhece outro por
00:18:22
favor é o momento de dizer aqui nos
00:18:24
comentários Agora sim podemos dizer que
00:18:27
você já conhece o basicão do que é o XP
00:18:29
programming que faz parte do mundo edel
00:18:31
se você aprendeu algo novo nesse vídeo
00:18:33
nós ficaremos super honrados de receber
00:18:35
o seu like mas nós também queremos saber
00:18:37
a sua opinião aqui nos comentários
00:18:39
principalmente você já utilizou a
00:18:41
metodologia sua experiência seja ela
00:18:44
positiva ou negativa pode ajudar demais
00:18:47
outras pessoas então fica à vontade
00:18:49
Agora sim podemos nos despedir se você
00:18:51
ficou ainda com alguma dúvida volte
00:18:53
quantas vezes você quiser nesse vídeo tá
00:18:55
Um grande beijo no coração e até um
00:18:56
próximo vídeo do código fonte TV tchau
00:18:58
tchau tchau Aliás não é assim que
00:19:00
termina Ah não é assim né cadê cadê o
00:19:02
celular celular aqui ó ó gostou desse
00:19:06
vídeo né então fica aí na pegada do edel
00:19:09
a gente tem um vídeo super legal de
00:19:11
scrum também você ver dá para fazer uma
00:19:13
comparação né muita coisa que a gente
00:19:14
falou aqui parece com scrum só que esse
00:19:16
vídeo do scrum a gente mostra também o
00:19:18
ciclo né todos pena você vai aprender
00:19:21
bastante Vai lá vai corre
00:19:25
[Música]
00:19:27
lá l
