[MÚSICA] Olá a todos, meu nome é Eduardo Guerra, estamos no curso Princípios de Desenvolvimento Ágil de Software, nessa aula vamos falar sobre a estimativa de User Stories e Tarefas. Então pra gente poder fazer o planejamento, uma coisa importante voltando na aula passada, a gente viu como priorizar, ou seja, como saber o que tá lá na frente, agora a gente precisa ter uma estimativa de tempo pra gente saber como que nós vamos colocar, o que cabe dentro de uma iteração, seja ela de uma semana, de quinze dias, então nessa aula a gente vai ver pouquinho sobre a estimativa. Então, pra fazer a estimativa de User Stories, é pra que? Pra gente ter uma ideia de quais vão caber dentro de uma iteração, a gente tem que ser pouquinho vidente aí e tentar estimar aí essas tarefas, certo? Então, eu até saí aqui pra vocês poderem ver a figura que eu coloquei, então a primeira coisa que você tem que fazer é uma estimativa relativa entre as User Stories, essa estimativa não precisa ser horas e tal mas eu tenho que saber por exemplo, relação às User Stories, qual que é maior, qual que é menor, pra poder ter mais ou menos uma noção do que que cabe, do que é mais trabalhoso, do que é menos trabalhoso e etc. Então é igual esses monumentos aqui no slide, eu vou querer saber não talvez o tamanho de mas o quão é maior do que o outro. Então, exemplo que eu gosto de dar, a gente têm aqui vários livros, revistas, etc. Como que você estimaria tempo pra você ler cada deles, às vezes é complicado, mas se a gente tiver uma referência, talvez a gente consiga. Então o que que a gente faz? A gente vai pegar, por exemplo, o que a gente considera mais simples, no caso, eu consideraria a revistinha da Mônica, talvez seria o que eu leio mais rápido e aí eu vou dar valor de referência 1 para aquela revistinha que eu acho mais rápido, e aí eu vou tentar atribuir para as outras revistas ou livros, etc. qual seria o tempo que eu daria de leitura para eles considerando que o tempo da revistinha da Mônica é então vou deixar aí para você tentar fazer, então dá uma pausa no vídeo, faz aí o exercício. Fez? Bom, vou colocar aqui pouquinho do que eu fiz: então, por exemplo eu coloquei acho que a revista Caras se considerar que eu vou ler todas as reportagens realmente eu colocaria três, esse livro Sushi for Dummies é livro que tem bastante figura e tal, eu acho que eu conseguiria ler numa tamanho quatro, o Harry Potter eu também devoro mas o Relíquias da Morte é dos maiores livros, então eu coloquei sete, a revista Mundo J pra mim é muito prazerosa, foi uma revista que eu editei durante muito tempo, então eu daria valor cinco, talvez para esse Java Performance Tuning, ainda mais que é livro inglês, eu colocaria 10, e aí tem outros aqui, do Dostoiévski, talvez ainda precisasse quebrar o capim para poder fazer uma estimativa mais precisa, certo? Então, fica aí o exercício, a ideia é entender pouco dessa ideia. Por que? Porque a gente faz a mesma coisa com as User Stories, a gente pega a User Story que a gente considera mais simples e dá para ela valor e faz a estimativa das outras usando aquela como referência. " esse daqui tem mais isso, tem mais aquilo." E aí a gente vai fazendo essa estimativa, então quando uma User Story for muito grande a gente quebra menores, o mesmo caso talvez do Dostoiévski, até mesmo do Java Performance Tuning, a gente seria digamos assim mais produtivo, mais saudável, quebrar ali pra gente poder estimar melhor, pra ver se tem capítulo mais fácil, mais difícil, então se for uma User Story muito grande talvez valha a pena quebrar ela menores. Então, o que que a gente vai fazer? O famoso dividir para conquistar, a gente vai pegar daquelas User Stories que tenham maior prioridade, que a gente viu na aula passada, sobre essa parte de planejamento, a gente viu aí como fazer a priorização e vai tentar ver as que a gente acha por esses Story Points quantas cabem mais ou menos dentro de uma iteração. Com o tempo, a gente acaba sabendo mais ou menos quantos Story Points a nossa equipe consegue fazer por iteração. No começo é chute mesmo, isso aí vai melhorando, então como a gente viu aí na parte de User Stories, que a gente faz essa divisão por tarefas, agora que a gente fez essa estimativa mais alto nível por Story Points, a gente vai pegar a sua alta unidade e vai dividir elas tarefas e vai fazer cada uma dessas tarefas uma estimativa horas ideais usando ali também a escala de Fibonacci que a gente viu aí também na aula que a gente falou da prioridade. Então, a gente vai fazer horas ideais. O que que seria essas horas ideais? São aquelas sem interrupções, normalmente, a gente estima que uma pessoa que trabalha 8 horas, ela trabalha efetivamente 6 horas ideais, se ela fica só focada naquilo, ás vezes se ela tem outras funções administrativas, talvez pouco menos. A ideia é o seguinte: por exemplo, de repente eu vou pegar programador júnior e vou considerar que ele consegue fazer, sei lá, 4 horas ideais, ou talvez programador mais sênior consiga fazer 8, apesar de não trabalhar efetivamente 8, rende como se fossem 8, então a ideia dessas horas ideais é aquela hora de programador médio sem interrupções, o que você vai ajustar não é a hora, o tempo que cada demora pra fazer, mas você vai ajustar a quantas horas ideais você acha que rende o trabalho daquela pessoa por dia, aí você acaba tendo a velocidade da sua equipe. Então, uma coisa que é importante falar, muito provavelmente assim, eu já vi vários times começarem a implantar o ágil e realmente nas primeiras iterações se erra muito estimativa, se erra na hora de determinar as horas ideais, se erra nos Story Points, mas a ideia é isso mesmo, porque nas outras metodologias mais clássicas o que você planeja aí pra 6 meses, você vai saber isso muito tempo depois, aqui depois da primeira semana, dos primeiros quinze dias de projeto, já tá escancarado que o pessoal tá estimando tudo errado, aí pra próxima a gente já ajusta ou até mesmo interrompe a iteração no meio, replaneja e vai. Esse aprendizado é muito importante, não desista se você vê que tá errando, porque é normal, esse errar no começo do projeto faz parte do aprendizado e você vai ver que lá pra terceira ou quarta iteração, a equipe já vai tá bem mais afiada nas suas estimativas, você vai conseguir fazer planejamento muito mais preciso das iterações. E o Planning Poker, ele ajuda a gente a fazer essas estimativas e a gente vai ver aí mais pra frente algumas aulinhas sobre como utilizar aí o Planning Poker. Certo? Então é isso, a gente viu aí como fazer estimativa dos User Stories. Espero que tenha ficado mais claro que a gente primeiro faz as User Stories, ainda de uma forma mais relativa, dando os Story Points, depois a gente faz as estimativas horas mas aí das tarefas, que a gente consegue quebrar e ter uma estimativa de uma forma melhor. Certo? Então é isso aí e muito obrigado! Não perca a próxima aula de Planning Poker. [MÚSICA] [MÚSICA]