[MÚSICA] Olá a todos. Meu nome é Eduardo Guerra. Esse é o curso dos Princípios do Desenvolvimento Ágil de Software. Nesse módulo vamos falar de planejamento, uma coisa extremamente importante. Como planejar, como seguir o planejamento e como sempre vamos começar jogando pedra. Vamos falar dos principais erros que as pessoas têm na hora de fazer o planejamento de software. Então, vamos lá. Eu já vou começar aqui falando. A engenharia de software ela digamos, das engenharias, talvez seja uma das engenharias mais recentes. Talvez perca para a Bioengenharia, algumas coisas assim, mas é uma das engenharias mais recentes. E o que aconteceu? Quando ela apareceu ela meio que tentou pegar ideias de outras engenharias já existentes. Por exemplo, uma engenharia civil, onde você tem que ir lá fazer o projeto da casa, validar, antes de começar a construir. Então, os processos de desenvolviemento de software pegaram essa noção. E realmente se a gente parar para pensar, se a gente chegar e falar assim, olha chega essa parede aqui uns 20 centímetros para lá, isso daí porque tem negócio que não está cabendo aqui. Isso é difícil, é caro, vai ter que quebrar, às vezes tem uma viga aí que inviabiliza. Então, realmente para outros tipos de engenharia pode ser mais complicado você fazer aí o desenvolvimento mais incremental. Mas para software não. Muita gente talvez conteste a afirmação de que o software, ele é mais flexível mas talvez nem todos sejam. Mas a questão é que software, ele pode ser mais flexível se a gente utilizar as técnicas que a gente tem visto aí nesse nosso programa aí que é o TDD, a Refatoração, utilizar as boas práticas de código, uma boa modelagem orientada a objetos, modularização. Usando tudo isso a gente consegue fazer o software ficar flexível. Não é fácil, exige disciplina, exige várias técnicas mas é possível deixar o software mais flexível de forma a conseguir construir ele de forma incremental, de forma a dar sempre alterando o que existe antes e fazer isso de uma forma sustentável. Diferente de outras engenharias. Então, tratar o software como outras engenharias, que primeiro você tem que fazer o projeto e depois fazendo tudo de uma vez, isso aí é erro. A construção não tem que ficar por último, é possível criar o software de forma que a gente possa fazer as coisas de uma forma mais dinâmica justamente devido a essa flexibilidade maior do software. Outra coisa, tentar enxergar além do que você consegue. O cara está fazendo planejamento, acha aí que é o Wild dos Thundercats, que tem ali a visão além do alcance, que vai botar a espada justiceira lá e vai conseguir ver o que é que a equipe está fazendo daqui a ano. Não dá, né. Fala uma coisa, se eu chegar para você e perguntar o quê que você vai fazer amanhã, você vai conseguir me dizer com uma certa, talvez não com certeza, mas você já vai ter talvez uma noção do que você vai fazer. Se eu perguntar, daqui a uma semana o que você vai estar fazendo? Daqui a mês, o que você vai estar fazendo? Daqui a ano, o quê que você vai estar fazendo? Não tenho menor ideia o quê eu vou estar fazendo daqui a ano. Então não adianta você querer fazer uma planejamento para muito no futuro, principalmente porque se alguma coisa mudar nesse meio do caminho, você vai ter que refazer isso tudo, é trabalho perdido. Então, a ideia é que o planejamento detalhado seja feito só a curto prazo. Então o que acontece? Lá para o longo prazo, essa figura eu já mostrei aí quando a gente estava falando do manifesto ágil. Mas eu volto com ela aqui porque isso é muito importante. Ali no longo prazo você tem uma visão de onde você quer chegar mas você sabe que o cliente ainda pode mudar muita coisa. Você tem ali no médio prazo para talvez aqui nos próximos dois meses, três meses, ali alto nível, mais ou menos quais são os objetivos da equipe alcançar e talvez no curto prazo, para uma ou duas semanas na frente, no máximo, você tenha aquele detalhamento de quais as user stories que você vai fazer. Quais são as tarefas de cada user story, para você ter esse controle mais fino, mas só nesse curto prazo. Quando que eu vou fazer o próximo planejamento? Esse próximo planejamento você vai fazer quando terminar a interação com base no que você aprendeu. Então, às vezes você tentar fazer uma planejamento muito para a frente, você está deixando de utilizar o conhecimento que você vai ganhando no começo do projeto sobre a tecnologia, sobre o que é fácil de fazer. O conhecimento sobre os membros da sua equipe, olha o fulano consegue fazer isso rápido, ciclano é mais devagar nessa parte. Então, tudo isso são informações importantes que fazem com que com o tempo a gente vá fazendo essas estimativas com mais precisão. Outro erro, você impor deadlines. O cara está fazendo o planejamento e falar, essa tarefa aqui é duas horas. Ou chegar para o cara, quanto tempo você faz isso? O cara falar, eu acho que eu preciso de cinco horas, vai e fala assim, vou botar aqui quatro horas que dá. Já vi muita gente fazer isso. Lógico que você pode conversar, você tem certeza que é cinco horas, porquê, me explica. Se você acha que o tempo está muito grande, quer negociar, conversa, tenta entender porquê das cinco horas. Propõe para ele acordo, vê se ele aceita aquilo ali. Mas não impôr. Muitas vezes isso aí é erro muito sério. Quem faz a estimativa não é quem vai fazer o software. Como é que o cara vai saber? Muitas vezes o cara não é nem técnico. O cara chuta ali, pega de histórico, não é assim que funciona. Você fazer isso, você está pedindo para o projeto atrasar. Então, é aquela coisa, você é que sabe o tempo que você precisa. Você chega ali recebe a tarefa, isso aqui vai ser uma tarefa para x horas. E aí você olha e fala assim, é nunca que eu vou conseguir cumprir isso aqui. E aí acontece o contrário também. O cara fala assim, o cara pediu dez horas para essa tarefa aqui. Olha, eu consigo fazer cinco, então posso fazer com tranquilidade. Então o cara vai e estica para fazer nas dez horas, ao invés de acabar rápido e pegar uma outra tarefa. Então, é sempre ruim quando não é o próprio desenvolvedor que faz aquilo ali. Então, você querer impor planejamento, querer impor tempo de forma que você às vezes não tem as informações que o cara que é o desenvolvedor, que ele sabe do conhecimento dele, ele às vezes conhece melhor a arquitetura e ele saberia estimar aquilo de uma forma muito mais precisa do quem está fazendo o planejamento. Você querer impor ali o tempo é você pedir para atrasar o projeto. Isso aí é fato. Outra coisa é a forma que se mede. Uma vez eu lembro que chegou o gerente de projeto e falou, o projeto está atrasado. Porquê? O fulano ele está trabalhando na tarefa e ele falou que estava 50% da tarefa pronta. Pelo tempo era já para ele estar 80%. Que é 50%, quê que é 80%? Ás vezes a gente acha que falta só pouquinho, na hora de integrar tudo a gente gasta muito mais tempo do que a gente gastou na tarefa inteira. Acontece isso. Esse tipo de previsão, eu divido aqui a, b, c e d. Se o cara fez a, b e c, então o cara fez 75%, pronto, é assim. É esse tipo de medida de progresso aí também não é realista. E muitas vezes, quando se faz isso se trabalha às vezes com tarefas de 20 horas. Às vezes que, quê que é 80% de 20 horas, ou então a gente mede pelo tempo que o cara trabalhou. Essa tarefa estava prevista para 20 horas, o cara já trabalhou dez, então está 50%. Eu já vi vários desses erros de você medir o progresso de uma forma completamente imprecisa e que não condiz com a verdade. É aquela coisa, às vezes os 10% finais demoram muito mais do que o resto. Ou depois das 20 horas o cara vai descobrir que precisa de mais 20. Então, a gente não pode pensar dessa forma. Com software não é, por exemplo, igual uma parede que o pião está levantando e se ela já está 80% na altura, você fala, está faltando mais 20. Software não é assim que funciona. O cara faz tantas linhas de código, está faltando 50 para ele terminar, está faltando tanto tempo. Não é assim que funciona. Às vezes numa linha de código, para você descobrir qual a linha que tem que ser ali, meu amigo, demora. Então, você acompanhar o projeto às vezes de uma forma não realista, às vezes ou coloca na equipe uma pressão desnecessária ou cria uma falsa sensação de segurança que mais para a frente vai ser destruída e vai pegar todo o mundo de surpresa. Outra questão é você querer fazer o planejamento igual o nosso amigo está fazendo aí, na pedra. O cara fazer planejamento para ninguém alterar, pensando que aquilo ali é, sei lá, o cara escreveu na pedra. É negócio que se mudar está errado. Não, na verdade eu costumo dizer que a única certeza que a gente tem quando a gente faz planejamento é que não vai ser daquela forma. Então, a gente tem que fazer o planejamento tendo consciência de que aquilo ali pode mudar e a gente tem que fazer o planejamento de uma forma que seja fácil a gente se adaptar, a gente consiga lidar. Até mesmo as equipes ágeis mais maduras fazem as estimativas, às vezes até cumprem ali o fizeram no tempo proposto, mas às vezes porque acaba equilibrando de uma estimativa ser pouco maior, outra pouco menor e aí as coisas acabam se equilibrando no final. Mas exatamente daquela forma muito difícil de acontecer. Então, a gente tem que pensar no planejamento como guia, como uma referência e não como uma coisa escrita na pedra que a gente não pode. Deixo para vocês essa frase, "Nada está escrito na pedra". Então, a gente não pode considerar que o nosso planejamento não vai mudar. Porque ele vai mudar e se a gente encarar ele como uma coisa estática e que a mudança desse planejamento é uma coisa ruim, é uma coisa que não deve ser feita, isso aí vai acarretar uma série de problemas, desde desenvolvedores escondendo informações, fingindo que está tudo bem, até mesmo você às vezes tem trabalho muito grande para acertar tudo depois. Então, pense no planejamento como guia, como uma referência, e não como script que tem de ser exatamente daquela forma. Então, nessa aula que falei alguns dos erros do planejamento de projeto de software e nas próximas aulas a gente vai ver aí como fazer as estimativas, prioridades e tal, dentro aí de projeto de software. Muito obrigado, espero você na próxima aula. [MÚSICA] [MÚSICA]
