[MÚSICA] Olá a todos! Meu nome é Eduardo Guerra, esse é o curso "Princípios de desenvolvimento ágil de software". Hoje eu vou falar para vocês pouquinho sobre software funcionando. A gente não vai literalmente fazer o software funcionar, mas a gente vai falar pouquinho sobre a importância de você focar no software mais do que você ter uma documentação abrangente, que tenha várias coisas, mas que não funcione. Então, a gente vai estar pegando o segundo item do manifesto ágil, que diz que é mais importante você ter o software funcionamento do que uma documentação abrangente. Bom, para começar eu vou pegar gráfico bastante famoso na comunidade de desenvolvimento de software, que a gente chama das "baleinhas do RUP", que ele mostra para cada tipo de atividade qual que é o esforço que você vai ter durante cada fase do projeto. Então, você pega ali somente a última baleinha, que ela é mais gordinha para o final, que é o desenvolvimento, e aí você tem, principalmente no início do projeto, esforço maior nas outras frentes. Bom, quê que eu tenho a dizer relação a isso aí? Está vendo essa parte aí? Papel! Isso aí é papel, não é software. Então, o que acontece? No desenvolvimento tradicional, no começo, você gerava monte de papel, monte de documentação. Uma vez eu participei de processo de desenvolvimento de software que ele tinha, o processo obrigava que você tivesse documento para documentar as necessidades de treinamento da equipe. E aí, tinha documento de cinco páginas, quatro, cinco páginas para falar que a equipe não precisava de treinamento nenhum. Então, é exemplo da burocracia, do seguir o processo por seguir. Então, realmente, se você tem que fazer monte de documentação que não serve para nada, e aí eu lembro que quando eu citava isso a pessoa falava "não, mas pode ser importante escrever que a equipe não precisou de nenhum treinamento!" Não, tudo bem, se acredita nisso então vai frente. Vai gerando papel! Então, assim, que acontece? Você chega, você percorre ali uma larga porção do seu projeto sem que aquilo ali gere nenhum software. E mesmo o início ali do desenvolvimento fala assim: " não, mas logo no comecinho você tem". Você pode até ter alguma coisa, mas até você ter alguma coisa entregável, alguma coisa que o cliente possa ver, vai demorar, vai ser mais da metade do projeto. Então, que acontece? Se você pegar às vezes desenvolvimento tradicional, você vai falar assim: " qual que é o andamento do projeto? É 40%." Só que não tem nada pronto ainda. Todas as atividades que o cara tinha planejado ali fazer, que é: "! Eu preciso escrever os requisitos, preciso montar o planejamento, preciso fazer aquilo, aquilo, gerar aquele monte de documentação, fazer diagrama assim, fazer diagrama assado, fazer uma reunião assim, documentar o treinamento, documentar não sei quê lá." O cara vai estar 40% do projeto, se pegar lá o Project, o planejamento que ele fez, vai estar ali que tá tudo foi cumprido, só que ele falou assim: "Ó, aqui, eu estou com 40% de projeto de software e quantos porcento do software si está implementado?" 0%! Não tem nada pronto. Então, é complicado você chegar e falar que tem 40% do projeto e não ter nada pronto. E aí vem, e se eu trocar aquela documentação pela criação do software? Se ao invés eu falar assim: "OK, eu tenho o meu software, eu tenho aqui as necessidades do cliente. Por que é que ao invés de eu pegar, sair correndo para escrever monte de coisa ali, porquê que eu não vou e tento criar software que é parecido, que tem a ver com aquilo que o cliente falou?" Ao invés de ele ter que ler o documento, ele vai lá e vai mexer no software, vai falar: "Olha, era isso que eu queria!" ou "Não, não era isso que eu queria" ou "Ó, isso aí que vocês fizeram não tem nada a ver com o que eu queria!" Ou, sei lá, "Metade disso que vocês fizeram tem a ver, a outra metade vai ter que mudar", que costuma ser o caso. A equipe costuma não acertar tudo, mas começar já tendo várias coisas próximas daquilo que o cliente quer e evoluir a partir dali. Não estou falando que não tenha que ter documentação nenhuma. Como falei, o Manifesto Ágil, ele não diz para você ignorar uma coisa e fazer só a outra; ele diz que talvez ter o software funcionando seja mais importante do que você ter aquele monte de documento escrito. Mas de repente você escreve pouquinho ali para entender as necessidades do cliente e depois você vai e faz alguma coisa que ele realmente possa mexer, interagir, te dar feedback. Bom, aí com certeza vai vir alguém muito brabo falando pra mim, vai falar assim: "OK, mas aí com certeza se você não documentar, e não insistir, e não conversar de forma extensiva ali com o cliente, você vai fazer alguma coisa que ele não quer e aí você vai ter que mudar!" E aí esse é o medo, esse é o grande medo do pessoal do desenvolvimento tradicional. "Tem que mudar!", a mudança. Só que aqui a gente abraça a mudança, a gente não é contra a mudança. A gente sabe que o cliente às vezes, tem que ver o software para poder amadurecer na cabeça dele aquela ideia e para que chegue no final do projeto e tenha aquilo que o cliente realmente quis. Então, a ideia é essa mesmo. Você faz pouquinho e aí com o feedback do cliente você vai evoluindo o software. Então, vez de você querer, logo de cara, escrever monte de documentação, fazer monte de projeto, para depois começar a fazer e não ter que mudar mais, não! A gente faz ali pedacinho, vê o que o cliente acha, pega o feedback dele, muda se precisar e aí vai fazendo essas pequenas iterações, às vezes de uma semana, às vezes de 15 dias, no máximo de mês, que o cliente vai dando esse feedback e a equipe vai evoluindo cima disso daí. E aí, as técnicas que a gente aprendeu nos cursos anteriores, de TDD, de refatoração, isso aí vai deixando o código mais fácil de ser modificado. No TDD você está focando ali na simplicidade, na refatoração você está se preocupando deixar o código limpo; você tem os testes para saber se alguma mudança vai tá impactando outras partes do software. Então, tudo isso dá esse suporte para a gente poder alterar o software com maior facilidade. Então, não é simplesmente: "! O cliente vai falando, eu vou alterando, a gente vai fazendo." Não! O desenvolvimento ágil não tem nada a ver com isso. Precisa de muita disciplina para criar os testes automatizados, para estar sempre refatorando o software, mas a gente precisa. E aí com isso a gente, sim, consegue fazer aquelas alterações, consegue fazer aquelas iterações. Então, todas as práticas, elas são voltadas para possibilitar essas iterações, esse contato maior com o cliente. E aí, não é que você não tem que ter nenhuma documentação, às vezes, é interessante você documentar os requisitos, o que o cliente falou, de repente algum projeto que você fez que é mais importante, uma parte mais complicada, como que funciona, uma regra de negócio de repente tem ali diagrama de estado que talvez é complicado, e aí você senta com o cliente de repente e desenha aquilo ali. Mas a ideia é você fazer a documentação quando ela for agregar valor. Quando você falar assim: "OK, isso daqui", sei lá, "Esse modelo aqui de banco de dados, poxa! Vale a pena", "Essa regra aqui de negócio do cliente, todo mundo tem que estar ciente. Então vamos escrever, vamos pregar na parede, vamos tentar divulgar essa informação da melhor forma possível." É a diferença, por exemplo, daquele cara que leva três malas e aí não usa nem a metade das roupas, daquela pessoa que viaja mais leve, consegue se movimentar, consegue viajar com maior conforto, com maior tranquilidade. Então, com o desenvolvimento ágil, não é que a gente não leva nada, mas a gente procura viajar leve, a gente tenta levar com a gente a menor quantidade de documentação possível e focar naquilo que realmente vai agregar valor. Então, por exemplo, se você estar indo para lugar que vai fazer calor, para quê que você vai encher uma mala de roupa de frio? O que às vezes acontece muito; você acaba fazendo monte de documentação que ninguém nunca usa. Mesma coisa você estar carregando na sua mala coisas que você não vai usar. Então é isso, né? A gente viu a importância aí de focar no software funcionando ao invés de estar focando ter monte de documentação. Afinal, que documentação melhor de como o software funciona do que ele próprio? Certo? Então é isso, muito obrigado, até a próxima aula! [MÚSICA] [MÚSICA]
