[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra, este é o curso Princípios de Desenvolvimento Ágil de Software e hoje vamos falar sobre como não utilizar diagramas. Muita gente acha que o desenvolvimento ágil, ele é incompatível com a utilização de diagramas. Na verdade, ninguém chegou e falou assim, isso tudo aí que vocês estavam trabalhando engenharia de software durante muito tempo não presta mais para nada. Então, os diagramas podem sim ser muito úteis, só que muitas formas que eles são utilizados, às vezes, não são adequadas. Então, nessa aula a gente vai falar que os principais erros, os principais problemas que a gente encontra quando as pessoas estão utilizando diagrama. O que é que as pessoas estão fazendo de errado? A gente vai começar vendo isso hoje. Bom, acho que o erro básico que a gente vai acabar vendo que tudo acaba girando torno disso é o cara que cria ali o diagrama só porque o processo disse que ele tem que criar. Ou seja, você vai passar pela fase quando chegar na tarefa tal, você vai fazer diagrama de classe referente a tal coisa. E o cara vai lá e cria aquilo só porque o processo disse para ele criar. Está vendo esse camarada aí? Então, para mim ele é mais ou menos isso aí, é aquele cavalinho ali que tem aquele negócio que não deixa ele olhar para o lado. Ele fica limitado àquilo que o processo diz para ele muitas vezes sem se preocupar com para que é que aquilo vai ser utilizado, qual que é a utilidade daquilo para o projeto, o que é que aquilo vai agregar de valor. Então a gente tem que tomar cuidado para não chegar num processo preditivo e falar que as pessoas precisam fazer diagrama ou precisam fazer alguma coisa, e as pessoas fazem sem nem questionar ou sem nem saber porque é que aquilo ali está sendo feito. Esse é dos principais problemas. Pode até ser que no momento que aquele processo foi feito, pensou-se nesses objetivos dos diagramas mas se a pessoa que está fazendo o diagrama não sabe disso como que ela vai tentar atingir objetivo que ela não sabe com a tarefa que ela está fazendo? Então, tenho certeza que quem colocou aquilo ali sabia o objetivo mas quem está fazendo muitas vezes não sabe, e muitas vezes também para aquela equipe aquilo ali não serve ou para aquele tipo de software aquilo não vai ser tão útil. Então, vamos ver como essa questão básica de criar diagramas sem nem saber porquê ou como, simplesmente seguindo o processo, como isso daí pode ser prejudicial. Então, muitas vezes a gente não se questiona, para que é que vai servir esse diagrama, qual que é o escopo dele? Às vezes simplesmente a gente vai colocando tudo que tem, não sabe quem vai utilizar, para que é que a pessoa vai utilizar. Às vezes, a gente sabendo que a pessoa vai utilizar a gente sabe que tipo de detalhe, que tipo de coisa tem que ir ou não. Então, vamos lá. Às vezes a pessoa cria e está ali perdida, aquele nosso amigo aí, certo? Está ali sem saber porque é que está criando aquilo, chegou aqui, tenho que criar diagrama de estado. Aí vai lá, sem saber porquê, cria lá o diagrama. Opa, chegou aqui o diagrama de classe. Deixa eu identificar aqui os substantivos, os verbos igual aprendi lá. Cria aqui as classes, nem sabe quem vai usar aquilo nem sabe porquê, nem sabe que tipo de detalhe aquela pessoa precisa. Então se você está fazendo diagrama, alguém está fazendo diagrama e você pergunta, para que é que é isso daí e a pessoa não sabe responder já tem uma coisa errada. E outra coisa, não saber as necessidades de quem vai utilizar aquele diagrama. Muitas vezes se faz diagrama com informações a mais ou a menos da pessoa que vai estar utilizando. Às vezes ela precisaria de uma coisa muito mais simples. Às vezes muitos dos detalhe que você vai colocar ali vão ser jogados fora, a pessoa vai desprezar e vai fazer do jeito dela. Então, talvez aquilo ali pudesse até ajudar mas, às vezes tem coisas a mais ou tem coisas a menos também. Às vezes tipo de relacionamento, preciso colocar aqui a multiplicidade desse relacionamento, é para muitos, é para. Isso vai ser útil para a pessoa? Essa é a informação que ela está buscando nesse diagrama? É só entender pouco melhor os relacionamentos, precisa de botar o método? Precisa de botar o parâmetro do método? E às vezes também tem diagramas que eles têm uma certa utilidade durante tempo e depois aquilo ali não faz mais sentido, seja porque modificou, seja porque era para gerar entendimento e aquele entendimento já foi gerado. Então, as pessoas, é assim é sacrilégio você fazer diagrama e não guardar ele para sempre aí, para muita gente. E as pessoas às vezes não se questionam por quanto tempo a gente tem que manter esse diagrama. Durante quanto tempo ele vai ser útil. Pode ser que chegue o momento que aquele diagrama que foi muito importante numa parte do projeto vai deixar de ser útil e aí, não faz sentido eu ter uma equipe e dispender esforço para manter uma coisa que não está agregando mais valor. Às vezes até, você pensar sobre alguma coisa é útil você ir num quadro ou num papel e fazer diagrama. Mas é diagrama que você não precisa ir lá e gastar tempo para fazer ele numa ferramenta e tal e depois ficar guardando e mantendo aquilo, porque aquilo ali já cumpriu o objetivo de melhorar o seu entendimento sobre aquilo ali ou validar aquilo com outras pessoas ou comunicar aquela ideia que às vezes era mais difícil ser comunicada sem o diagrama. Muitas vezes a gente não pensa no tempo que no ciclo de vida, quanto tempo esse diagrama é útil e quanto tempo ele tem que existir. E aí, uma outra pergunta. Como que você faz esse diagrama? Muitas vezes a pessoa, não é usando ML, vou usar tudo o que tiver e vou colocar tudo o que puder. Mas às vezes não é uma resposta trivial. Então, às vezes você ter detalhes demais ali acaba tirando o foco daquilo que a pessoa precisa. Eu me lembro, por exemplo, projeto que eu participei que a gente fez diagrama de classes que só tinha o nome das classes, porque era domínio complexo e simplesmente a gente saber o relacionamento entre as coisas era muito útil. Quais métodos tinha, quais informações tinha, isso aí era detalhe, não era o foco ali. Eu lembro que a gente fez esse diagrama, a gente atualizava ele, pregava ele na parede e utilizava ele sempre. Se ele tivesse muitos detalhes, todos os métodos e tal ia ficar negócio enorme e ia tirar o foco do que era o principal que era entender melhor o relacionamento entre as entidades ali do sistema. Então a gente antes, quando a gente sabe o objetivo do diagrama, a gente tem que pensar qual que é o nível de detalhe que é importante que ele tenha para que a gente possa cumprir esse objetivo. Às vezes você, não, mas eu estou colocando coisas a mais, às vezes a coisa que você bota a mais, além de tirar esforço desnecessário vai tirar o foco daquilo que você precisa. É a história que eu costumo falar, se alguém te pergunta: me recomenda livro sobre o tal assunto. Se você recomendar livro a pessoa vai comprar e ler, se você recomendar dez, não, mas eu estou dando mais opções. Pois é, mas a pessoa às vezes não sabe julgar e não vai ler nenhum. Às vezes quando a pessoa bater o olho naquele diagrama que tem monte de coisas vai falar, não, melhor eu perguntar para alguém ou olhar direto no código. E às vezes por ter informações a mais o diagrama deixa de atender o objetivo dele. Às vezes outro erro é usar ferramentas mais complicadas do que você precisava. Ir lá e pegar ferramentas Case ou de desenho, altamente complicadas e perder tempo ali, às vezes para diagrama que é só para gerar entendimento, só para comunicar alguma coisa com outros membros da equipe. Às vezes o quadro branco, ele é uma ferramenta importante, ou simplesmente papel às vezes se você está querendo pensar melhor ou às vezes discutir alguma coisa com a sua dupla, com seu par, isso daí pode ser bem importante. Você ter como fazer essa discussão, ter esse diagrama que você pode discutir cima dele. E às vezes não precisa de uma ferramenta muito sofisticada para isso. Depois, se vocês acharem que aquilo ali vale a pena ser guardado e mantido para, que aquele entendimento vá sendo evoluído, você pode até passar para a ferramenta. Mas naquele momento, talvez a ferramenta vá te deixar mais lento, talvez não é o momento para tomar essa decisão, se aquilo ali vai ser útil ou não, mesmo porque aquilo ali na hora da implementação pode até mudar. Quando a gente falou aí do pre-programing a gente falou daquela discussão inicial das ideias, de como são as coisas e tal, isso aí pode ser muito útil. Nessa hora o diagrama é muito importante, mas não numa ferramente super sofisticada, às vezes num quadro branco, uma folha, ele vai fazer seu papel de servir ali como uma ferramenta de comunicação entre os membros da equipe. E por fim, eu vejo muita gente pegar diagrama e tentar colocar todas as informações nele. Então, por exemplo, pega diagrama de classes que mostra a estrutura estática e começa a botar uns balõezinhos para a explicar a dinâmica. Não, pô! Existem outros diagramas para isso, como o diagrama de sequência, por exemplo. Aí o cara começa a botar ali umas observações dizendo as classes ali dos estados e aí explicar. Não, pera aí. Vamos criar então diagrama de estado aqui, não precisa de querer num diagrama só fazer tudo. Isso aí é erro que eu vejo também, a pessoa quer botar todas as informações num diagrama só. Às vezes para comunicar uma coisa, às vezes você pode usar diagramas diferentes. Vamos usar aqui pedacinho do de classes, faz mais pequinininho aqui de sequência, a gente mata isso aqui. E aí a gente deixa claro como isso vai funcionar. Então, pense também que não existe tipo de diagrama só, por motivo e utilize todos que você puder, que vá funcionar melhor baseado naquele objetivo que você tem fazendo aquele diagrama. Então, não fique preso num diagrama só, pode ser que seja necessário mais de. Então, resumindo, os diagramas eles são uma ferramenta importante sim, apesar deles não serem o foco e não serem obrigatórios quando a gente usa desenvolvimento ágil. Eles podem sim, ser uma ferramenta que a equipe vai utilizar, mas eles têm que ser utilizados de forma inteligente, eles têm que estar alinhados com as necessidades do projeto, não pode sair utilizando ele aí simplesmente porque o processo disse que você tem que utilizar. Então, eu espero que essa aula tenha conseguido mostrar para vocês algum dos erros ao se utilizar diagramas projetos e nas próximas aulas aqui vamos falar pouquinho mais sobre a modelagem ágil, como o diagrama se encaixaria aí num contexto ágil. Muito obrigado. Até à próxima aula. [MÚSICA] [MÚSICA]
