[MÚSICA] Olá a todos! Meu nome é Eduardo Guerra. Esse é o curso Princípios de Desenvolvimento Ágil de Software, e nessa aula vamos estar falando sobre como utilizar diagramas dentro de contexto ágil. Então a gente vai entender pouco mais como que os diagramas se encaixam, como essa parte de modelagem mais tradicional se encaixaria dentro de uma equipe ágil. Onde que isso entra, como que isso é definido. Então a primeira coisa que a gente tem a dizer é que o diagrama, ele não vai vir do processo. O processo não vai chegar para você e vai falar assim: Olha, nessa hora aqui você vai criar diagrama. Como muitas vezes acontece nos processos mais tradicionais, mais preditivos. Que aí tem, aqui tem uma fase de modelagem, ou aqui tem uma fase assim, assado, e aí nesse momento, você tem que fazer diagrama. No desenvolvimento ágil, a questão do diagrama, ele vai vir de uma necessidade da equipe. Então, poxa, a gente está com dificuldade pra entender o banco de dados. Ou a gente precisa pensar nessa solução. E, às vezes, a partir dessa necessidade que você vai falar: Vamos suprir essa necessidade ou vamos resolver esse problema ou vamos lidar melhor com essa questão utilizando diagrama. Aí você, a partir dessa necessidade, a equipe vai pensar cima e ver qual que é a melhor abordagem para a criação daquele diagrama. Primeira coisa, você tem que ver qual o objetivo daquele diagrama. É o quê? É pensar melhor sobre o problema? Principalmente no pair programming, às vezes é interessante você explicar a sua ideia de solução, você raciocinar melhor cima do problema, por exemplo, dos relacionamentos das classes de domínio. Como que vai ser as dependências, por exemplo. Às vezes num quadro branco é interessante para você ter esse tipo de discussão. Então pode ser que o objetivo do seu diagrama é pensar melhor no problema. Ou às vezes o objetivo do seu diagrama pode ser você se comunicar com a equipe, por exemplo, dizendo qual que é a abordagem que você criou no banco de dados, ou como vai ser a arquitetura da aplicação. Ou pode ser, digamos assim, a parte mais tradicional, uma própria documentação para o software. Não, o objetivo desse diagrama é documentar essa parte aqui que a gente fez. Às vezes, diagrama de estado, para mostrar como que as coisas funcionam. O diagrama, a gente tem que ter na nossa mente que ele pode ter vários objetivos, e aí a forma que a gente vai fazer, qual que é a melhor abordagem para cumprir cada desses objetivos pode ser completamente diferente. Depois, você tem que descobrir quem é o público do seu diagrama. Pode ser você mesmo. Eu mesmo, para pensar alguma coisa, eu já desenhei diagrama, para mim mesmo. Então, pode ser você mesmo, pode ser a sua equipe, pode ser uma outra equipe. Por exemplo, imagina que a sua equipe está desenvolvendo uma aplicação e ali, por exemplo, tem banco de dados. Pode ser que, vamos falar assim: Mas tem uma outra equipe, com outro software que vai também usar essa mesma base de dados. Opa, a gente precisa se comunicar com a outra equipe. Vamos usar diagrama para isso? Qual a melhor forma? É diferente de fazer diagrama para dentro da sua equipe, que as pessoas têm acesso direto umas às outras. E às vezes, é simplesmente requisito do cliente. Ó, tem que ter diagrama assim, assado, como é que a gente lida com isso? Essa questão do requisito do cliente eu vou deixar para falar no finalzinho dessa aula. Mas, você saber quem é o público do seu diagrama pode influenciar de forma definitiva como que você vai fazer isso. Como e onde fazer? Muitas vezes se a gente tem o objetivo, às vezes, de comunicar uma coisa simples, comunicar uma ideia, fazer brainstorming, às vezes, quadro branco é o que a gente precisa. Eu, hoje dia, eu acho que a maior parte dos diagramas que eu faço, eu faço no quadro branco. Faço, vou explicando enquanto eu estou fazendo. Às vezes, enquanto eu estou desenhando, explicar enquanto eu estou fazendo o diagrama, às vezes, é mais fácil para pessoa entender do que ela chegar lá e já estar o diagrama chapado pronto para ela só olhar. Pode ser que alguns casos eu queira uma ferramenta mais sofisticada, que a pessoa, de repente, consiga navegar ou que ela consiga relacionar as coisas, ou puxar coisas do software para fazer uma engenharia reversa. Alguns casos, dependendo do meu objetivo, eu posso sim querer essa segunda opção. E lembrar também que tem intermediário, às vezes, não é nem o quadro branco, às vezes, não é nem a ferramenta mais sofisticada, mas às vezes eu quero uma ferramenta mais simples. Simples desenho de bloquinhos, às vezes resolve e explica como que funciona. Eu, pelo menos, gosto muito, deixo a dica aí de site chamado iconfinder, que você consegue pegar vários ícones, muitas vezes, vários deles são gratuitos, e às vezes, para você criar esquema dizendo: Ó, tem ali uma aplicação assim, servidor desse jeito, aqui tem o usuário que vai acessar aqui. Às vezes para explicar para o cliente alguma coisa. Às vezes diagrama simples desses é melhor do que você querer usar uma ferramenta sofisticada, UML, e tudo mais. Então, lembrar que você tem essas opções e vê cada caso qual que é o mais adequado de acordo com o público e o objetivo. Então, a gente vê que fazer diagrama aqui no ágil a gente tem que pensar, a gente tem que ver o quê que a gente precisa, para que serve aquele diagrama, para quem é. E mais, a gente tem que ver qual que é o ciclo de vida daquele diagrama. Se é diagrama que eu estou fazendo para pensar, de repente eu posso fazer ele e jogar fora. Eu desenhei num papel e joguei fora. Ou até mesmo fiz ali rapidinho na ferramenta e depois aquilo não serve mais, ou apaguei o quadro, ou joguei o papelzinho fora. Às vezes, aquele diagrama que o objetivo era eu discutir com a minha dupla, ou falar uma coisa rápida para a equipe, para a equipe entender, depois que ela entendeu aquele diagrama não tem mais sentido de existir, ele não tem que virar necessáriamente uma documentação e ser guardado pra sempre. Às vezes, eu posso simplesmente falar: Não isso aqui foi interessante, vou guardar porque se eu precisar explicar para outra pessoa eu vou querer utilizar esse mesmo diagrama. Pode até ser que ele não esteja mais 100% consistente. Às vezes, por exemplo, sei lá, você tem livro do Framework 2.0, aí lança o três ponto zero. Você, às vezes, tem muita coisa comum, você não precisa jogar o livro do dois ponto zero fora. Às vezes, aquele básico que o livro do dois ponto zero te diz é o suficiente. Então, às vezes, numa documentação que não está 100% de acordo, mas, sei lá, está 95%, 90% de acordo, você guarda aquilo ali que, às vezes pode ser útil, mesmo que você decida que não vale a pena você ficar atualizando. Se dia aquilo talvez ficar muito obsoleto, e passar a não agregar mais valor, você pode jogar fora, ou pode decidir atualizar. Mas é completamente válido você ter essa opção de guardar o diagrama do jeito que ele é sem se preocupar com a atualização, obviamente deixando isso aí claro para todo mundo. Quem nunca utilizou alguma coisa que não estava 100% de acordo ou sincronizado e nem por isso, às vezes, isso daí deixou de agregar valor no momento que você estava olhando. E, por fim, pode ser que tenha algum tipo de diagrama que é muito importante, que fique na parede, que toda hora o pessoal olhe, que é importante você atualizar com frequência, ou toda vez que for necessário para que aquela informação esteja sempre atualizada. Eu, por exemplo, já participei de projeto, que ele tinha uma questão lá, uma das entidades, o sistema tinha ciclo de vida com vários estados, e o que poderia fazer cada estado, isso daí não era simples. Foi uma coisa que a gente teve que conversar bastante com o cliente para entender. E aí o que a gente fazia, a gente pegava esse diagrama, imprimia e colocava na parede. Toda vez que surgia algum tipo de mudança, ou alguma novidade nesse ciclo de vida, a gente ia lá, atualizava, colava na parede, avisava para todo mundo. Porquê? Porque aquilo era central, era importante ficar visível, era importante que todo mundo tivesse ciência de como aquilo ali funciona, qual que é versão mais atualizada. Então, pode ter esses caso que é importante atualizar o diagrama. Talvez diagrama de banco de dados, diagrama com as classes de domínio. Então, tudo isso daí vai sendo importante. Note que são várias decisões que você tem que fazer a respeito do diagrama. Você tem que saber para quem ele é, qual o objetivo, por quanto tempo você vai manter ele. E aí existe algumas outras decisões como, por exemplo, quais diagramas você vai utilizar baseado naquilo que você precisa, o objetivo, quem vai ler, qual a melhor forma de se comunicar sobre aquilo. Qual nível de detalhe vai ter? Eu estou fazendo diagrama de classe, será que Precisa ter o nome dos métodos, será que tem que ter os parâmetros e os retornos dos métodos? Ou só quais são os métodos já é suficiente? Precisa ter a visibilidade dos métodos, precisa ter os atributos. Tudo depende do que você está querendo fazer, lembrando do que eu falei na aula passada, que às vezes, você ter detalhes demais pode ser prejudicial, pode tirar o foco, pode tirar a atenção de quem está lendo. A riqueza da informação pode trazer a pobreza da atenção. Tinha professor meu que falava isso. E isso é verdade, às vezes detalhes demais tiram o foco do que é importante. E por fim, qual é o escopo, não é porque você está fazendo diagrama de banco de dados que ele tem que ter todas as tabelas. Não é porque você está fazendo diagrama de classes que tem que ter todas as classes do sistema, não é porque você está fazendo diagrama de sequência que ele tem que ter o detalhe de cada chamada de método que você está fazendo outra classe. Então, você tem que determinar o escopo e ver aquilo que vai agregar valor para poder incluir naquele diagrama, e perguntar: pô, será que eu incluo isso, será que eu incluo aquilo, e importante para quem vai estar lendo, de acordo com o objetivo disso daqui, então, decidir qual é esse escopo também é extremamente importante. Então, lembra que quando você está fazendo diagrama, você está deixando de fazer outras tarefas. Você poderia estar fazendo uma funcionalidade, você poderia estar fazendo outras coisas. E esse tempo, esse planejamento não é uma decisão sua. Você não pode de repente parar e falar assim, não, eu vou parar tudo para ir lá e fazer super diagrama aqui do banco de dados, que vai tomar três horas do meu tempo. Isso não é uma decisão sua, isso é uma decisão da sua equipe. Então, vá pergunte para ela, argumente, olha, eu acho que agregaria valor fazer diagrama assim e assado, com esse objetivo. Veja se a sua equipe concorda. Veja se ela acha que vale a pena ter esse tipo de investimento. Não tome essa decisão sozinho, ela não é sua, ela é da sua equipe. Então, pense direitinho, quando que vale a pena, lógico que uma coisa rápida ali no papel ou no quadro branco você não precisa consultar todo o mundo. Mas toda a vez que você vai tomar uma decisão de ter diagrama mais elaborado, que vai demandar tempo, que de repente vai precisar ser atualizado com frequência, isso é uma decisão da equipe e tem que ser discutido com todos. O tempo de cada dentro da equipe, as tarefas que ele vai se dedicar, não diz respeito só a você, diz respeito a todo o time, então, vocês têm que chegar a consenso de qual a melhor forma de investir aquele tempo. E muitas vezes o cliente vira e fala assim, eu quero esse diagrama. Às vezes você acha que não precisa, para a sua equipe não precisa, você acha de repente que se colocar aquilo numa documentação, você acha também que para quem for talvez da manutenção daquele software, aquilo ali também não agregue tanto valor, e muitas vezes a pessoa fala assim, poxa, Guerra, mas você fala ali que não precisa mas o meu cliente pede isso. Ele coloca que eu tenho que entregar isso. Então, nesses casos que o cliente pede diagrama como parte da sua entrega, aquilo ali deixa de ser diagrama que é para auxiliar a equipe e passa a ser parte integrante do produto que você tem que entregar. Então, passe a tratar o diagrama como uma funcionalidade do software. Da mesma forma que você vai planejar as entregas do seu software, você também vai planejar as entregas dos seu diagramas. E, não só isso tem que ser tratado como uma funcionalidade na forma de planejar e de entregar isso daí, mas também, isso daí tem que ser considerado na forma como você vai cobrar esse seu cliente. então, você tem que deixar muito claro para ele qual que é p preço que ele está pagando por aqueles diagramas. Que ao invés de entregar diagrama você podia estar entregando uma funcionalidade nova. Então, eu acho que nesse caso, às vezes a gente não tem o controle, a gente não tem, por exemplo, qual que é o objetivo do diagrama? O objetivo é cumprir requisito do cliente que é ter esse diagrama. Por mais que você não concorde, aquilo vai virar como se fosse uma funcionalidade e aí, todos esses requisitos de detalhamento, de escopo e tal é o cliente que vai dar, porque é ele que está pedindo, é ele que precisa. Então, você trata isso como uma funcionalidade e por uma questão de transparência, você deixa claro para o cliente o quanto que ele está pagando e o quanto que às vezes a sua equipe deixa de entregar para ter que dispender esforço fazendo esses diagramas. Talvez quando dói no bolso do cliente ele passa a pensar melhor sobre se aquilo realmente é necessário ou se realmente for necessário, como aquilo é necessário, talvez não com tanto detalhe ou talvez não de tudo. Então, é isso. Essa aula a gente falou pouco como utilizar os diagramas nesse contexto ágil. Espero que tenha ficado claro para vocês e na próxima aula a gente vai ver mais umas boas práticas da modelagem ágil. Muito obrigado e continuem assistindo. [MÚSICA] [MÚSICA]
