[MÚSICA] [MÚSICA] Olá a todos, meu nome é Eduardo Guerra e estamos no curso de Princípios de Desenvolvimento Ágil de Software. Nessa aula vamos falar pouquinho sobre a dinâmica da interação. A gente falou de planejamento, falou de priorização, agora como que isso aí é executado, como que a gente acompanha isso? Isso é extremamente importante, o coração do desenvolvimento ágil. Nessa aula vamos falar sobre como isso acontece. O planejamento ele é executado interações. A gente diz que essa interação acontece num time box, por isso que tem esse relógio e essa caixinha aí, horrível. Mas tudo bem, o que é que é o time box? Ele é intervalo de tempo fixo, significa que eu não vou aumentar ele, ele é fixo. O que pode acontecer é eu não conseguir executar tudo mas logo que ele terminar eu vou ver o que aconteceu, o que deu errado, etc e vou começar novo time box. Então a interação não tem essa de esticar pouquinho mais, é intervalo fixo. Essa interação é o que o Scrum chama de Sprint. Que é que precisa ter para ser Sprint? Tem que ser curto não pode ser negócio de, estou fazendo Sprint de três meses, você tá chamando errado. Idealmente é de uma semana, 15 dias, no máximo, no máximo mês, não recomendo mas tem gente que faz Sprints de mês, mas recomendo aí no máximo 15 dias. Ele tem de entregar valor, não é passou 15 dias eu fiz aqui todas as classes que acessam banco de dados. Isso aí para o cliente não interessa, ele quer ver funcionalidade completa, ele quer ver coisa funcionado, se não entregar valor, se no final não tiver uma entrega que o cliente possa ver e possa aprovar e possa olhar, isso aí não é Sprint. E precisa ter o ciclo de desenvolvimento completo. Não é virar e falar assim, não vou fazer o Sprint aqui para escrever User Story, depois eu vou fazer o Sprint para criar diagrama. Não, não é isso. Ele tem o ciclo de desenvolvimento completo. Você vai desde pegar os requisitos e implementar, testar, fazer todos esse ciclo dentro dessa uma semana, para poucas funcionalidades e, no final entregando esse valor para o cliente. Então, não tem essa de vou pegar ali aquelas baleinhas lá do hoop e vou dividir várias, por mês ou cada 15 dias chamar de Sprint e vou ter Sprint só para escrever. Não, isso não existe, ele tem que ter o ciclo de desenvolvimento completo ali desde o zero até a entrega de funcionalidade para o cliente com teste, com tudo o que precisar ser feito. E a quantidade de User Stories vai de acordo com a velocidade do time. Como a gente viu na parte de planejamento, com o tempo a gente vai saber quantas Story Points ou quantas horas ideais nosso time consegue fazer e com isso, com o tempo a gente vai aprimorando isso aí, vai melhorando as estimativas e aí, provavelmente lá para a quarta, quinta interação você já consegue fazer planejamento com muito mais precisão. Então, eu vou sair aqui para vocês poderem ver essa tabela aqui mas já volto. Então, a execução das tarefas, elas tem que ser acompanhadas durante a interação. Uma forma de você fazer isso, por exemplo, você tem ali a User Story, você tem as tarefas dela, você tem as horas ideais que elas foram estimadas, quantas horas foram efetivamente trabalhadas e a restante. Repara que o primeiro ali, ele cumpriu o que estimou, ele estimou dez e conseguiu fazer ali o dez. O banco de dados, note que ele estimou oito e trabalhou 12 e conseguiu terminar. No controller aconteceu uma coisa diferente, ele estimou 12 mas seis ele conseguiu terminar. Olha o caso do último ali, por exemplo, ele estimou sete, ele trabalhou cinco só que ele estima que para terminar aquela tarefa ainda faltam cinco. Então, a gente sempre trabalha com o quanto que está faltando. Então, lembra que eu falei daquela questão lá das porcentagens e tudo mais? Então, essa é uma forma melhor de fazer, ao invés de falar quantos porcento você já fez. Você pergunta quantas horas ainda faltam para terminar. Pode ser que você tenha estimado cinco e agora faltem dez. Você começou a trabalhar e viu que o problema era bem maior. Não tem problema. O importante é a equipe estar ciente disso e ter tempo suficiente para agir cima desse imprevisto que aconteceu. Então, todo o controle ele acontece cima do quanto já foi trabalhado e o quanto que ainda falta. O quadrinho do Kanban que a gente tem ali as tarefas, os to do, ou os que estão sendo feitas e as que já foram concluídas é uma forma bacana. O pessoal usa os quadrinhos com post-it, uma forma bacana de você acompanhar e tornar aí esse acompanhamento da interação uma coisa visível para todo o mundo. É uma prática comum ter as daily meetings, reuniões diárias onde as pessoas vão lá, dizem o que fez, atualizam o quadrinho, atualizam as horas e para que a equipe tenha uma noção de como que está o andamento da interação. Esse quadrinho do Kanban, ele pode ter outras não precisa ser só essas três, ele pode ter outras colunas, pode ter uma, por exemplo, relacionada a se foi feito o teste. A gente pode ter a coluna aqui bloqueado, que é a coluna quando tem alguma coisa externa impedindo a equipe de fazer aquilo. Aí as pessoas já vão olhar e falar, opa, eu tenho que correr atrás senão eles não vão conseguir fazer esse negócio aqui. E aí eu posso ter várias, de acordo com o mecanismo de trabalho, até mesmo com o feedback da equipe eu posso ir tendo várias fases, várias colunas ali nas quais as minhas tarefas vão andando até poderem ser consideradas concluídas. E gráfico muito comum da gente trabalhar é o Burndown Chart. Que é que ele faz? Ele mostra a quantidade de horas faltantes por dia. Note que ele pode até dar uma aumentadinha ali no caso, por exemplo, de eu ver que uma tarefa, ela não foi bem estimada e atualizar a estimativa. Por exemplo, eu posso fazer uma tarefa e com aquilo concluir que outras parecidas vão ter agora uma estimativa maior. Então, eu posso ir lá e atualizar. A todo o momento, no mínimo, uma vez por dia eu estou atualizando essa questão das estimativas e das horas. Lembra que não é muita coisa, é tarefa para uma semana ou 15 dias só, então, dá para fazer esse tipo de controle. É o que eu falei. Para o curto prazo o planejamento é detalhado. então, no Burndown Chart a gente tem uma noção do que é que a gente trabalhou, como que estão a estimativa de horas e se a gente, pelo andamento, consegue ver se a gente vai conseguir concluir ou não. Se a gente vê que o Burndown Chart, ele está indo para cima, ele está se distanciando muito dessa linhazinha cinza, que seria mais ou menos a minha referência do que seria o ideal o normal é ficar ali permeando, ás vezes pouco mais para cima, pouco mais para baixo daquela linha. Se eu ver que está saindo muito fora, que acontece? Eu vou terminar a interação que eu sei que a minha equipe não vai conseguir concluir, que eles vão ficar estressados, vão ficar chateados no final. Não! Às vezes foi erro de planejamento, às vezes é nas primeiras interações, o pessoal não sabe fazer direito. O que é que eu vou fazer? Eu paro a minha interação, eu faço uma retrospetiva, converso com as pessoas, vejo o que está errado e aí a gente replaneja e começa uma interação do zero. É a melhor forma, que aí a equipe se sente zerada e se sente muito mais motivada de fazer aquelas tarefas naquela nova interação e para tentar cumprir ou chegar perto do objetivo no final. No começo pode ser realmente necessário, às vezes surge imprevisto. Pode ser necessário esse replanejamento e aí é melhor não mexer aí com o seu bem mais precioso que é a sua equipe. Não mexa com o bem estar psicológico dela. Zere tudo, comece de novo e a equipe vai começar nova interação motivada, agora que ela teve a oportunidade de repensar, ela vai aprender com aquele erro de estimativa para conseguir efetivamente cumprir o que foi proposto para ela dentro daquela interação. E aí é importante no final de cada interação, ter uma retrospetiva, levantar o que funcionou, o que não funcionou. Na verdade, as metodologias ágeis, elas são uma referência. Mas você tem que fazer o seu processo. O processo é dinâmico, o processo é adaptativo, então, você tem que ver o que funcionou, o que não funcionou, o tipo de estimativa, se você precisa de mais uma fasezinha lá no seu Kanban. Às vezes uma tecnologia que você está usando, tipo de refatoração, deu certo, não deu. Como que faz o teste disso? Desse jeito não ficou legal. Então, tudo isso você pode colocar na retrospetiva para que a cada interação a sua equipe esteja evoluindo e trabalhando cada vez melhor. Eu tenho amigo que diz que se você está fazendo ágil hoje da mesma forma que você fazia ano atrás você não é mais ágil. Porquê? Porque você parou de evoluir. Isso é muito legal. Então, espero que nessa aula tenha dado para entender melhor como que funciona essa dinâmica de uma interação e como casar isso com o planejamento, esse acompanhamento aí do quê que foi planejado. Muito obrigado. Até à próxima. [MÚSICA] [MÚSICA]
